Hvorfor et domænes rod ikke kan være et CNAME - og andre ting om DNS

Dette indlæg vil bruge ovenstående spørgsmål til at udforske DNS, dig, Aoptegnelser, CNAMEregistreringer og ALIAS/ANAMEoptegnelser fra en nybegynder perspektiv. Så lad os komme i gang.

For det første nogle definitioner

  • Domain Name System (DNS): det samlede system til konvertering af et menneskeligt mindeværdigt domænenavn (eksempel.com) til en IP-adresse (93.184.216.34). IP-adressen er på en server, ofte en webserver, hvor de filer, der er nødvendige for at vise en webside, er gemt.
  • DNS-server (også kendt som en navneserver eller navneserver): Bruger DNS-software til at gemme oplysninger om domæneadresser. Der er flere niveauer - dem, der tilhører hver ISP, Root (13 i alt på verdensplan), Top Level Domain (TLD, f.eks. '.Com') og DNS-servere på domæneniveau.
  • Domænenavn : domænet (eksempel) kombineret med TLD (.com). Udtrykket 'domæne' bruges ofte synonymt med domænenavnet, selvom de er forskellige. Når du køber et 'domæne' fra en registrator eller forhandler, køber du rettighederne til et specifikt domænenavn (eksempel.com) og eventuelle underdomæner, du vil oprette (min-site.example.com, mail.example.com, etc).

Forespørgsel på højt niveau

Flowet på højt niveau af hvad der sker, når du skriver "example.com" i din browser, kan forenkles for at fjerne humle til ISP-, Root- og TLD-DNS-servere som nedenfor:

Et domæne har typisk to eller flere navneservere, der indeholder poster, der vedrører domænenavnet (eksempel.com).

Mange typer optegnelser kan gemmes, hvoraf de fleste kan have flere poster pr. Type:

  • A: Adresseoptegnelser, der kortlægger domænenavnet til en IP-adresse
  • CNAME: Kanonisk navneoptegnelse. Bruges til at kalde et domænenavn (eller underdomænenavn) til et andet. Vi vil se nærmere på dette senere.
  • MX: Mail eXchange-poster, der fortæller e-mail-leveringsagenter, hvor de skal levere din e-mail
  • TXT: fleksible tekstoptegnelser til lagring af strenge til forskellige anvendelser
  • SOA: ental Start of Authority-post, der holdes på domænets øverste niveau. Indeholder specifikke krævede oplysninger om domænet, for eksempel dets primære navneserver
  • NS: Navneserverne tilknyttet domænet

Når din enhed sender en forespørgsel, der når en navneserver, ser serveren i domænes Apostknudepunkt efter en post og den tilknyttede lagrede IP-adresse (eksempel.com: 93.184.216.34). Dette returneres derefter til enheden for at blive brugt til at sende en anmodning til den korrekte webserver for at hente den ønskede webside eller ressource.

Brug 'grave'

dig( domæneinformationshandler ) er et kommandolinjeværktøj til forespørgsel til DNS-servere. Denne kommando bruges generelt til fejlfinding eller som nu for at forstå mere om opsætningen af ​​et system.

$ dig example.comresulterer i et langt svar udskrevet til terminalen, standardoutputtet beskrevet her, som vi er interesseret i ANSWER SECTION.

;; ANSWER SECTION: example.com. 72703 IN A 93.184.216.34

Og der går vi, vi kan se, at example.comreturnerer en Aregistrering af 93.184.216.34. Undertiden vil domæner have mere end en Apost, hvis mere end en webserver kan give de nødvendige oplysninger.

Der er mere! Hvis vi prøve nogle andre eksempler, kan vi hurtigt se, at en anden almindelig post vises: CNAME.

$ dig www.skyscanner.net:

;; ANSWER SECTION: www.skyscanner.net. 169 IN CNAME www.skyscanner.net.edgekey.net. www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net. e11316.a.akamaiedge.net. 20 IN A 23.217.6.192
www.skyscanner.net.edgekey.net. 5639 IN CNAME e11316.a.akamaiedge.net.
e11316.a.akamaiedge.net. 20 IN A 23.217.6.192

Brug af +shortflag giver os mulighed for tydeligt at se den dannede sti:

$ dig www.skyscanner.net +short

www.skyscanner.net.edgekey.net. e11316.a.akamaiedge.net. 23.217.6.192

CNAME

En CNAMEpost tillader, at et domænenavn bruges som et alias for et andet kanonisk (sandt) domæne.

Når DNS-serveren returnerer en CNAMEpost, returnerer den ikke den til klienten. Snarere vil det igen slå op på det returnerede domænenavn og til gengæld returnere Apostens IP-adresse. Denne kæde kan fortsætte mange CNAMEniveauer dybt, men får derefter mindre ydeevnehits fra flere opslag, før caching finder sted.

Et simpelt eksempel på dette kan være, hvis du har en server, hvor du gemmer alle dine fotos. Du kan normalt få adgang til det igennem photos.example.com. Du kan dog også ønske, at det giver adgang via photographs.example.com. En måde at gøre dette på er at tilføje en CNAMEpost, der peger photographspå photos. Dette betyder, at når nogen besøger, photographs.example.comfår de samme indhold som photos.example.com.

Ved hjælp af forespørgslen $ dig photographs.example.comville vi se:

photographs.example.com IN CNAME photos.example.com photos.example.com IN A xx.xxx.x.xxx

Det er vigtigt at bemærke, at det CNAMEer det stykke til højre. Venstre side er aliasnavnet eller etiketten.

En anden almindelig anvendelse er til wwwunderdomænet. Efter at have købt vil example.comdu sandsynligvis også have brugere, der skriver ind, for www.example.comat se det samme indhold.

Det er værd at bemærke her, der example.comkan kaldes toppunkt, rod eller nøgent domænenavn.

En mulighed ville være at oprette en anden Apost, der peger på den samme IP-adresse som for example.com. Dette er helt gyldigt, og det er hvad den virkelige example.comgør, men den skalerer ikke godt. Hvad sker der, hvis du har brug for at opdatere den IP-adresse, der example.compeger på? Du skal også opdatere det til wwwunderdomænet og andre, du måtte bruge.

Hvis en CNAMEpost blev brugt til alias www.example.comat pege på, example.comskulle kun roddomænet opdateres, da alle andre noder peger på det.

CNAME-begrænsninger

På det tidspunkt, hvor DNS-standarderne blev skrevet, blev der fastsat nogle regler, der styrede deres anvendelse. RFC 1912 og RFC 2181 fastslog, at:

  • SOAog NSoptegnelser er obligatoriske for at være til stede på roddomænet
  • CNAMEoptegnelser kan kun eksistere som enkelte poster, og kan ikke kombineres med nogen anden ressource rekord (DNSSEC SIG, NXTog KEY RRoptegnelser undtaget)

Dette udelukker at CNAMEblive brugt på roddomænet, da de to regler ville være i modstrid med hinanden.

Hvad der er vigtigt her er, at dette er en kontraktlig begrænsning, ikke en teknisk. Det er muligt at bruge a CNAMEved roden, men det kan resultere i uventede fejl, da det bryder den forventede adfærdskontrakt.

Et eksempel på dette fortælles af Cloudflare, der beskriver problemer, de stødte på med Microsoft Exchange-mailservere efter at have brugt a CNAMEpå deres roddomæne:

Domæner udpeger generelt de servere, der håndterer deres e-mail via det, der kaldes en MX Record. Problemet var, at Exchange-servere ... kunne hente CNAME ved rodoptagelsen og derefter ikke respektere CNAME-indstillingen på MX-posten korrekt. Du kan ikke rigtig bebrejde Exchange. De fungerede under de antagelser, der er angivet i DNS-specifikationen.

Here you see the downside that can appear in several server softwares or libraries. Because a standard is in place for a CNAME to be the only record at a node, no other records are looked for. All other records will be silently ignored, without warning or error messages. Even if an MX record was set to receive email, the MX will be ignored as if it doesn’t exist because the CNAME is evaluated first. The same is true if there were an A record: the CNAME would take precedence and the A record would not be read.

The modern internet

So why is this a problem? Why would you ever want to use a CNAME for your root domain anyway? Surely that is the end of the path when looking for the IP address of the web server hosting your content?

In the modern internet landscape, that is no longer the case. The world is very different from when the DNS standards were written.

You may choose to use a Platform as a Service (PaaS) provider like Heroku and store content on their web servers. You control the content, but not the infrastructure, and the PaaS provider does the heavy lifting of the network maintenance. They typically provide you with a URL (my-app.herokuapp.com) that is a subdomain of their root domain, and you can view the IP addresses for the web server(s) your content is on. But these are entirely under the PaaS provider’s control, and will change without warning.

The scale and frequency of backend changes made by the PaaS provider can make it hard to maintain your root domain A record pointing at a single IP address. Ideally you would wish to do this:

example.com IN CNAME my-app.herokuapp.com.www.example.com IN CNAME my-app.herokuapp.com.example.com IN CNAME my-app.herokuapp.com. www.example.com IN CNAME my-app.herokuapp.com.

to allow Heroku (or your chosen host provider) to manage updating the A record that the CNAME points to without any changes made on your side. However, as we now know, this breaks the DNS specification, so is a very bad idea.

It is possible to simply implement a 301/302 redirect from example.com to www.example.com. However, that instruction takes place either on the web server (so still having the problem of needing to use a fixed A record in DNS to point to that web server), or a custom DNS provider redirect (that suffers complications with HTTPS).

This also has the side effect of changing the domain that you see in the URL bar, which you may not want. This method is intended for when your website has permanently moved, or when you’re trying to preserve SEO rankings, rather than solving our problem of pointing to a complex changing backend in a scaleable way.

The solution

Several DNS providers have now developed custom solutions to work around this problem, including:

  • ALIAS at DNSimple
  • ANAME at DNS Made Easy
  • ANAME at easyDNS
  • CNAME (virtual) at CloudFlare

These are all virtual record types that provide CNAME like behaviour, with none of the downsides. The exact implementation can differ, but at a high level when the DNS server sees one of these virtual record types, it acts as a DNS resolver. It follows the chain created by the alias until it resolves at an A record (or records) and returns these A records to the DNS server. This ‘flattens’ the CNAME chain into the A record(s) returned, and is indistinguishable to the sent query. The query sees only a pure A record, which doesn’t break the DNS specification, and doesn’t have any of the disadvantages of a CNAME.

Disse virtuelle poster kan sidde sammen med andre poster ved roden uden frygt for utilsigtet adfærd. Afhængigt af udbyderens metode til DNS-opløsning, når de følger CNAMEkæden, kan de også have ydelsesfordele ved at cache tidligere opslag.

For en DNS-simpel opsætning konfigurerer vi derefter som nedenfor. Denne løsning har alle fordelene ved aliasing af domænenavne og ingen af ​​risiciene ved at bruge det på rodniveau.

example.com IN ALIAS my-app.herokuapp.com.www.example.com IN CNAME my-app.herokuapp.com.

Tak for læsningen! ?

Åbn som altid for eventuelle rettelser eller yderligere punkter.

Ressourcer

  • Hvad er en DNS-server
  • Opret en DNS-navneserver
  • DNSenkle supportsider og ALIAS-blog
  • Cloudflare support og CNAME blog
  • dig Hvordan
  • Flere gode Stack Overflow eller StackExchange indlæg
  • Velskrevne Wikipedia-poster
  • Netlify-blog 'Til www eller ikke www'