Miért nem lehet egy domain gyökere CNAME - és más apróságok a DNS-ről

Programozás

Ezt a bejegyzést fogja használni a fenti kérdésre, hogy vizsgálja meg DNS, dig, Afeljegyzések, CNAMEnyilvántartások és ALIAS/ANAMEfeljegyzések egy kezdő szemszögéből. Tehát kezdjük.

Először néhány definíció

  • Domain névrendszer (DNS): az emberi emlékezetes tartománynév (példa.com) IP-címre konvertálásának általános rendszere (93.184.216.34). Az IP-cím egy szerver, általában webszerver, ahol a weboldal megjelenítéséhez szükséges fájlokat tárolják.
  • DNS-kiszolgáló (névkiszolgáló vagy névszerver néven is ismert): DNS-szoftver segítségével tárolja a tartománycímekre vonatkozó információkat. Számos szint létezik - az egyes internetszolgáltatókhoz, a gyökérhöz (világszerte összesen 13), a legfelső szintű tartományhoz (TLD, pl. '.Com') és a tartományi szintű DNS-kiszolgálókhoz.
  • Domain név : a tartomány (példa) a TLD-vel (.com) kombinálva. A „domain” kifejezést gyakran használják a domain név szinonimájában, bár ezek különböznek. Amikor „domainet” vásárol egy regisztrátortól vagy viszonteladótól, megvásárolja egy adott domain név (példa.com) és minden létrehozni kívánt aldomain (saját webhelyem.pelda.com, mail.pelda.com, stb).

Magas szintű lekérdezési folyamat

Az „example.com” beírásakor a böngészőbe történő magas szintű folyamat egyszerűsíthető, hogy az alábbiak szerint távolítsa el a komlót az ISP, a Root és a TLD DNS szerverekről:

Egy tartománynak általában két vagy több névkiszolgálója van, amelyek a tartománynévre vonatkozó rekordokat tartalmaznak (példa.com).

Sok típusú rekord tárolható, amelyek többségének típusonként több bejegyzése lehet:

  • A: Címrekordok, amelyek a domain nevet IP-címhez társítják
  • CNAME: Canonical Name Record. Az egyik domainnév (vagy aldomainnév) álnevének a másikra való alias. Ezt később részletesebben megvizsgáljuk.
  • MX: A Mail eXchange rekordok megmondják az e-mail kézbesítési ügynököknek, hová kell kézbesíteniük az e-mailt
  • TXT: rugalmas szöveges rekordok, karakterláncok tárolására különféle felhasználásokra
  • SOA: a domain legfelső szintjén őrzött egyedi hatósági nyilvántartás. Konkrétan szükséges információkat tartalmaz a tartományról, például az elsődleges névszerverről
  • NS: A domainhez társított névszerverek

Amikor az eszköz egy lekérdezést küld, amely eléri a névkiszolgálót, a kiszolgáló a tartomány Arekordcsomópontjában keresi a rekordot és a hozzá tartozó tárolt IP-címet (példa.com: 93.184.216.34). Ezt azután visszaküldi az eszközre, hogy felkérést küldjön a megfelelő webszerverre a kért weboldal vagy erőforrás lekérésére.

A „dig” használata

dig( domain information groper ) egy parancssori eszköz a DNS-kiszolgálók lekérdezéséhez. Ezt a parancsot általában hibaelhárításra használják, vagy mint most, hogy többet megtudjanak a rendszer beállításáról.

$ dig example.coma terminálra nyomtatott hosszú választ eredményez, az itt részletezett alapértelmezett kimenetet, amely a ANSWER SECTION.

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

És ott tartunk, láthatjuk, hogy example.comez Arekordot ad vissza 93.184.216.34. Előfordul, hogy a domaineknek egynél több Arekordja van, ha egynél több webszerver képes megadni a szükséges információkat.

Van még! Ha megpróbáljuk néhány más példát, akkor meglátjuk, hogy egy másik gyakori rekord jelenik meg: 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

A +shortzászló használatával tisztán láthatjuk a kialakult utat:

$ dig www.skyscanner.net +short

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

CNAME

A CNAMErekord lehetővé teszi, hogy egy domainnév egy másik kanonikus (igaz) tartomány álneveként használható legyen.

Amikor a DNS-kiszolgáló visszaad egy CNAMErekordot, azt nem adja vissza az ügyfélnek. Inkább újra megkeresi a visszaküldött domain nevet, és visszaadja a Arekord IP-címét. Ez a lánc sok CNAMEszinten folytatódhat , de ezután kisebb teljesítményű találatokat ér el több kereséstől, mielőtt a gyorsítótárazás megtörténne.

Egyszerű példa erre lehet, ha van egy szervere, ahol az összes fényképét megőrzi. Általában keresztül érheti el photos.example.com. Azonban akkor is szeretnénk, hogy hozzá lehessen férni keresztül photographs.example.com. Az egyik módja annak, hogy ez lehetséges, hogy adjunk egy CNAMErekordot, amely pont photographsa photos. Ez azt jelenti, hogy amikor valaki felkeresi photographs.example.com, ugyanaz a tartalom kapja meg, mint photos.example.com.

A lekérdezés segítségével a $ dig photographs.example.comkövetkezőket látjuk:

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

Fontos megjegyezni, hogy ez a CNAMEdarab a jobb oldalon. A bal oldal az álnév vagy a címke.

Egy másik gyakori alkalmazás az wwwaldomain. Miután megvásárolta example.com, valószínűleg azt is szeretné, ha a beírók a felhasználók www.example.comugyanazt a tartalmat látják.

Itt érdemes megjegyezni, hogy example.comnevezhető csúcsnak, gyökérnek vagy meztelen domain névnek.

Az egyik lehetőség egy másik Arekord beállítása, ugyanarra az IP-címre mutatva, mint ami example.com. Ez teljesen érvényes, és a valós is ezt example.comteszi, de nem méretezhető jól. Mi történik, ha frissítenie kell a rámutató IP-címet example.com? Frissítenie kell az wwwaldomainhez és minden máshoz, amelyet használhat.

Ha egy CNAMErekordot álnévre www.example.commutatnak, example.comakkor csak a gyökértartományt kell frissíteni, mivel az összes többi csomópont erre mutat.

CNAME korlátozások

A DNS-szabványok megírásakor néhány szabályt meghatároztak azok használatára. Az RFC 1912 és az RFC 2181 előírja, hogy:

  • SOAés a NSnyilvántartásoknak kötelezően jelen kell lenniük a gyökérdomainben
  • CNAMEiratokat csak létezhetnek egyetlen nyilvántartások és nem vonható össze semmilyen más erőforrás rekord (DNSSEC SIG, NXTés KEY RRfeljegyzések kivételével)

Ez kizárja CNAMEa gyökérdomain használatát, mivel a két szabály ellentmondana egymásnak.

Ami itt fontos, hogy ez szerződéses korlátozás, nem pedig műszaki. Lehetséges az a használata CNAMEa gyökérnél, de ez váratlan hibákat eredményezhet, mivel ez megbontja a várható viselkedési szerződést.

Erre mutat példát a Cloudflare, leírva azokat a problémákat, amelyekkel a Microsoft Exchange levelezőszerverekkel találkoztak, miután CNAMEa gyökértartományukban a-t használtak :

A domainek általában az MX rekordnak nevezett kiszolgálókat jelölik ki. A probléma az volt, hogy az Exchange szerverek ... fel tudták venni a CNAME-t a gyökérrekordon, majd nem tartották be megfelelően az MX rekordnál beállított CNAME-t. Nem igazán hibáztathatja az Exchange-t. A DNS-specifikációban meghatározott feltételezések szerint működtek.

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’