Zašto korijen domene ne može biti CNAME - i druge sitnice o DNS-u

Ovaj post će se koristiti gore pitanje istražiti DNS, dig, Azapisa, CNAMEevidencija i ALIAS/ANAMEevidencija iz perspektive početnika. Pa krenimo.

Prvo, neke definicije

  • Sustav imena domena (DNS): cjelokupni sustav za pretvorbu ljudskog imena domene (example.com) u IP adresu (93.184.216.34). IP adresa je poslužitelja, obično web poslužitelja, na kojem se pohranjuju datoteke potrebne za prikaz web stranice.
  • DNS poslužitelj (poznat i kao poslužitelj imena ili poslužitelj imena): koristi DNS softver za pohranu podataka o adresama domena. Postoji nekoliko razina - one koje pripadaju svakom ISP-u, root (ukupno 13 u cijelom svijetu), domena najviše razine (TLD, npr. '.Com') i DNS poslužitelji na razini domene.
  • Ime domene : domena (primjer) u kombinaciji s TLD-om (.com). Pojam "domena" često se koristi sinonimno s nazivom domene, iako su različiti. Kada kupujete 'domenu' od registra ili preprodavača, kupujete prava na određeno ime domene (example.com) i sve poddomene koje želite stvoriti (my-site.example.com, mail.example.com, itd.).

Tok upita na visokoj razini

Protok na visokoj razini onoga što se događa kada upišete "example.com" u svoj preglednik može se pojednostaviti kako bi se uklonili skokovi na ISP, Root i TLD DNS poslužitelje kao što je prikazano u nastavku:

Domena obično ima dva ili više poslužitelja imena koji sadrže zapise koji se odnose na ime domene (example.com).

Mogu se pohraniti mnoge vrste zapisa, od kojih većina može imati više unosa po tipu:

  • A: Adresni zapisi koji mapiraju naziv domene na IP adresu
  • CNAME: Kanonski zapis imena. Koristi se za zamjenu imena jednog domene (ili imena poddomene) na drugo. To ćemo detaljnije razmotriti kasnije.
  • MX: Mail eXchange zapisi koji agentima za dostavu e-pošte govore gdje trebaju dostaviti vašu e-poštu
  • TXT: fleksibilni tekstualni zapisi za pohranu nizova za razne namjene
  • SOA: singular Zapis o pokretanju ovlasti čuva se na najvišoj razini domene. Sadrži specifične potrebne informacije o domeni, na primjer njezin primarni poslužitelj imena
  • NS: Poslužitelji imena pridruženi domeni

Kada vaš uređaj pošalje upit koji dolazi do poslužitelja imena, poslužitelj u čvoru zapisa domene traži zapis Ai povezanu pohranjenu IP adresu (example.com: 93.184.216.34). Zatim se vraća na uređaj kako bi se koristio za slanje zahtjeva ispravnom web poslužitelju za preuzimanje tražene web stranice ili resursa.

Korištenje "kopanja"

dig( groper podataka o domeni ) alat je naredbenog retka za postavljanje upita DNS poslužiteljima. Ova se naredba obično koristi za rješavanje problema ili kao i sada za razumijevanje više o postavljanju sustava.

$ dig example.comrezultira dugim odgovorom ispisanim na terminalu, zadani izlaz ovdje detaljno opisan, od kojeg smo zainteresirani ANSWER SECTION.

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

I tu smo, možemo vidjeti da se example.comvraća Azapis o 93.184.216.34. Ponekad će domene imati više Azapisa, ako više web poslužitelja može pružiti potrebne podatke.

Ima još! Ako ćemo isprobati neke druge primjere, možemo uskoro vidjeti da se pojavi još jedan zajednički rekord: 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

Korištenje +shortzastave omogućuje nam da jasno vidimo put koji je stvoren:

$ dig www.skyscanner.net +short

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

CNAME

CNAMERekord omogućuje naziv domene koji će se koristiti kao pseudonim za drugom kanonskom (true) domene.

Kada DNS poslužitelj vrati CNAMEzapis, neće ga vratiti klijentu. Umjesto toga, ponovno će potražiti vraćeno ime domene i zauzvrat vratiti AIP adresu zapisa. Ovaj se lanac može nastaviti na više CNAMErazina duboko, ali tada trpi manje pogođene performanse iz više pretraživanja prije nego što se izvrši predmemoriranje.

Jednostavan primjer za to može biti ako imate poslužitelj na kojem čuvate sve svoje fotografije. Možete mu normalno pristupiti putem photos.example.com. Međutim, možda biste htjeli da dozvoli pristup putem photographs.example.com. Jedan od načina da se to realizira se dodati CNAMEzapis koji ukazuje photographsna photos. To znači da će, kad netko posjeti photographs.example.com, dobiti isti sadržaj kao i photos.example.com.

Korištenjem upita $ dig photographs.example.comvidjeli bismo:

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

Važno je napomenuti da CNAMEje to onaj komad s desne strane. Lijeva strana je nadimak ili naziv.

Druga uobičajena upotreba je za wwwpoddomenu. Nakon kupnje example.comvjerojatno želite da i korisnici koji upisuju www.example.comvide isti sadržaj.

Ovdje je vrijedno napomenuti da se example.commožemo nazvati vrhom, korijenom ili golim imenom domene.

Jedna od mogućnosti bila bi postavljanje drugog Azapisa, ukazujući na istu IP adresu kao i za example.com. To u potpunosti vrijedi i stvarno je ono što stvarno example.comčini, ali nema dobre razmjere. Što se događa ako trebate ažurirati IP adresu na koju example.comupućuje? Morali biste ga također ažurirati za wwwpoddomenu i sve druge koje možete koristiti.

Ako se CNAMEzapis koristio za zamjensko ime www.example.comna koje bi upućivalo, example.comtada bi se trebala ažurirati samo korijenska domena, kao što na njega upućuju svi drugi čvorovi.

CNAME ograničenja

U vrijeme kada su napisani DNS standardi, postavljena su neka pravila koja reguliraju njihovu upotrebu. RFC 1912 i RFC 2181 utvrđuju da:

  • SOAa NSzapisi su obavezni da budu prisutni na korijenskoj domeni
  • CNAMEzapisi mogu postojati samo kao pojedinačni evidencije i ne može se kombinirati s bilo kojim drugim resursima zapisa (DNSSEC SIG, NXTi KEY RRzapisi iznimka)

To isključuje CNAMEupotrebu na korijenskoj domeni, jer bi ta dva pravila bila u suprotnosti.

Ovdje je važno da je ovo ugovorno ograničenje, a ne tehničko. Moguće je koristiti a CNAMEu korijenu, ali to može rezultirati neočekivanim pogreškama jer krši očekivani ugovor o ponašanju.

Primjer za to govori Cloudflare, opisujući probleme na koje su naišli s Microsoft Exchange poslužiteljima pošte nakon što su koristili a CNAMEna svojoj matičnoj domeni:

Domene općenito određuju poslužitelje koji obrađuju njihovu e-poštu putem onoga što je poznato kao MX zapis. Problem je bio u tome što su Exchange poslužitelji ... mogli podići CNAME u korijenskom zapisu, a zatim nisu pravilno poštovati CNAME postavljen u MX zapisu. Ne možete zapravo kriviti Exchangea. Djelovale su prema pretpostavkama utvrđenim u DNS specifikaciji.

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.

These virtual records can sit alongside other records at the root without any fear of unintended behaviours. Depending on the provider’s method of DNS resolution when following the CNAME chain, they may also have performance benefits from caching previous lookups.

For a DNSimple setup, we would then configure as below. This solution has all the advantages of domain name aliasing, and none of the risks of using it at root level.

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

Thanks for reading! ?

As always, open to any corrections or additional points.

Resources

  • What is a DNS Server
  • Set Up a DNS Name Server
  • DNSimple support pages and ALIAS blog
  • Cloudflare support and CNAME blog
  • dig HowTo
  • Several great Stack Overflow or StackExchange posts
  • Well written Wikipedia entries
  • Netlify blog ‘To www or not www’