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
, A
optegnelser, CNAME
registreringer og ALIAS/ANAME
optegnelser 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-adresseCNAME
: 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-mailTXT
: fleksible tekstoptegnelser til lagring af strenge til forskellige anvendelserSOA
: 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 navneserverNS
: Navneserverne tilknyttet domænet
Når din enhed sender en forespørgsel, der når en navneserver, ser serveren i domænes A
postknudepunkt 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.com
resulterer 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.com
returnerer en A
registrering af 93.184.216.34
. Undertiden vil domæner have mere end en A
post, 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 +short
flag 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 CNAME
post tillader, at et domænenavn bruges som et alias for et andet kanonisk (sandt) domæne.
Når DNS-serveren returnerer en CNAME
post, returnerer den ikke den til klienten. Snarere vil det igen slå op på det returnerede domænenavn og til gengæld returnere A
postens IP-adresse. Denne kæde kan fortsætte mange CNAME
niveauer 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 CNAME
post, der peger photographs
på photos
. Dette betyder, at når nogen besøger, photographs.example.com
får de samme indhold som photos.example.com
.
Ved hjælp af forespørgslen $ dig photographs.example.com
ville 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 CNAME
er det stykke til højre. Venstre side er aliasnavnet eller etiketten.
En anden almindelig anvendelse er til www
underdomænet. Efter at have købt vil example.com
du sandsynligvis også have brugere, der skriver ind, for www.example.com
at se det samme indhold.
Det er værd at bemærke her, der example.com
kan kaldes toppunkt, rod eller nøgent domænenavn.
En mulighed ville være at oprette en anden A
post, der peger på den samme IP-adresse som for example.com
. Dette er helt gyldigt, og det er hvad den virkelige example.com
gør, men den skalerer ikke godt. Hvad sker der, hvis du har brug for at opdatere den IP-adresse, der example.com
peger på? Du skal også opdatere det til www
underdomænet og andre, du måtte bruge.
Hvis en CNAME
post blev brugt til alias www.example.com
at pege på, example.com
skulle 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:
SOA
ogNS
optegnelser er obligatoriske for at være til stede på roddomænetCNAME
optegnelser kan kun eksistere som enkelte poster, og kan ikke kombineres med nogen anden ressource rekord (DNSSECSIG
,NXT
ogKEY RR
optegnelser undtaget)
Dette udelukker at CNAME
blive 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 CNAME
ved 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 CNAME
på deres roddomæne:
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 DNSimpleANAME
at DNS Made EasyANAME
at easyDNSCNAME
(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 CNAME
kæ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'