Kodėl domeno šaknis negali būti CNAME - ir kiti patarimai apie DNS

Ši žinutė bus naudoti minėtą klausimą ištirti DNS, dig, Aįrašus, CNAMEdokumentus ir ALIAS/ANAMEįrašus iš pradedančiųjų perspektyvos. Taigi pradėkime.

Pirma, keletas apibrėžimų

  • Domenų vardų sistema (DNS): bendra sistema, skirta žmogaus įsimenamam domeno vardui (example.com) paversti IP adresu (93.184.216.34). IP adresas yra serveris, paprastai žiniatinklio serveris, kuriame saugomi failai, reikalingi tinklalapiui rodyti.
  • DNS serveris (taip pat žinomas kaip vardų serveris arba vardų serveris): naudoja DNS programinę įrangą informacijai apie domeno adresus saugoti. Yra keli lygiai - tie, kurie priklauso kiekvienam interneto paslaugų teikėjui, šakniniai (iš viso 13 visame pasaulyje), aukščiausio lygio domenas (TLD, pvz., „.Com“) ir domeno lygio DNS serveriai.
  • Domeno vardas : domenas (pavyzdys) kartu su TLD (.com). Terminas „domenas“ dažnai vartojamas sinonimu su domeno vardu, nors jie ir skiriasi. Perkant „domeną“ iš registratoriaus ar perpardavėjo, jūs perkate teises į konkretų domeno vardą (example.com) ir visus padomenius, kuriuos norite sukurti (mano-svetainė.pavyzdys.com, paštas.pavyzdys.com, ir pan.).

Aukšto lygio užklausų srautas

Aukšto lygio srautas, kas nutinka, kai įvedate „example.com“ į savo naršyklę, gali būti supaprastintas, kad pašalintumėte apynius iš ISP, „Root“ ir TLD DNS serverių, kaip nurodyta toliau:

Domenas paprastai turi du ar daugiau vardų serverių, kuriuose yra įrašų, susijusių su domeno vardu (pavyzdys.com).

Galima laikyti daugybę įrašų tipų, kurių daugumoje gali būti keli įrašai kiekvienam tipui:

  • A: Adresų įrašai, kurie susieja domeno vardą su IP adresu
  • CNAME: Kanoninis vardų įrašas. Naudojamas kito domeno vardo (arba padomenio vardo) slapyvardžiui. Vėliau tai panagrinėsime išsamiau.
  • MX: „Mail eXchange“ įrašai nurodo el. Pašto pristatymo agentams, kur jie turėtų pristatyti jūsų el. Laišką
  • TXT: lankstūs teksto įrašai, skirti stygoms saugoti įvairiems tikslams
  • SOA: vienaskaitos pradžios įrašas, saugomas aukščiausiame domeno lygyje. Pateikiama konkreti reikalinga informacija apie domeną, pavyzdžiui, jo pagrindinis vardų serveris
  • NS: Vardų serveriai, susieti su domenu

Kai jūsų įrenginys siunčia užklausą, kuri pasiekia vardų serverį, serveris ieško domeno įrašo mazge Aįrašo ir susieto saugomo IP adreso (pavyzdys.com: 93.184.216.34). Tada jis grąžinamas į įrenginį, kad būtų naudojamas išsiųsti užklausą teisingam žiniatinklio serveriui gauti prašomą tinklalapį ar šaltinį.

„Dig“ naudojimas

dig( domeno informacijos groper ) yra komandinės eilutės įrankis užklausoms DNS serveriuose. Ši komanda paprastai naudojama trikčių šalinimui arba kaip dabar, norint daugiau sužinoti apie sistemos sąranką.

$ dig example.comrezultatas yra ilgas atsakymas, atspausdintas terminalui, numatytasis išvestis, išsamiai aprašyta čia, kuri mus domina ANSWER SECTION.

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

Ir mes einame, galime pamatyti, kad tai example.comgrąžina Aįrašą 93.184.216.34. Kartais domenai turės daugiau nei vieną Aįrašą, jei reikalingą informaciją gali pateikti daugiau nei vienas interneto serveris.

Yra dar daugiau! Jei mes išbandyti keletą kitų pavyzdžių, galime greitai pamatyti, kad atsiranda dar vienas bendras įrašas: 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

Naudodami +shortvėliavą galime aiškiai pamatyti susiformavusį kelią:

$ dig www.skyscanner.net +short

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

CNAME

CNAMEĮrašas leidžia domeno vardas turi būti naudojamas kaip kito kanoninės (tiesa) domeno alias.

Kai DNS serveris grąžins CNAMEįrašą, jis jo negrąžins klientui. Veikiau ji vėl ieškos grąžinto domeno vardo ir savo ruožtu grąžins Aįrašo IP adresą. Ši grandinė gali tęstis daugeliu CNAMElygių giliai, bet tada patiria nedidelius našumo smūgius iš kelių paieškų, kol dar nėra talpyklos.

Paprastas to pavyzdys galėtų būti, jei turite serverį, kuriame saugote visas savo nuotraukas. Paprastai prie jo galite prisijungti per photos.example.com. Tačiau galbūt norėsite, kad jis leistų pasiekti per photographs.example.com. Vienas iš būdų, kad tai įmanoma, yra pridėti CNAMEįrašą, kad taškai photographsbūtų photos. Tai reiškia, kad kai kas nors lankosi, photographs.example.comjam bus suteiktas toks pat turinys, kaip ir photos.example.com.

Naudodami užklausą $ dig photographs.example.compamatytume:

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

Svarbu pažymėti, kad CNAMEtas kūrinys yra dešinėje pusėje. Kairėje pusėje yra slapyvardis arba etiketė.

Kitas įprastas naudojimas yra wwwpadomenis. Įsigiję example.comtikriausiai taip pat norėsite, kad įvedę vartotojai www.example.commatytų tą patį turinį.

Čia verta atkreipti dėmesį į tai, kas example.comgali būti vadinama viršūnės, šaknies arba nuogo domeno vardu.

Viena iš galimybių būtų nustatyti kitą Aįrašą, nurodant tą patį IP adresą kaip ir example.com. Tai visiškai galioja ir tai, ką daro tikrasis example.com, tačiau tai nėra gerai. Kas nutiks, jei reikės atnaujinti nurodantį IP adresą example.com? Taip pat turėsite jį atnaujinti wwwpadomeniui ir visiems kitiems, kuriuos galite naudoti.

Jei CNAMEįrašas buvo naudojamas slapyvardžiui www.example.comnurodyti, example.comtada reikės atnaujinti tik šakninį domeną, nes į jį nurodo visi kiti mazgai.

CNAME apribojimai

Tuo metu, kai buvo rašomi DNS standartai, buvo nustatytos kai kurios taisyklės, reglamentuojančios jų naudojimą. RFC 1912 ir RFC 2181 nustatyta, kad:

  • SOAir NSįrašai yra būtini šakniniame domene
  • CNAMEįrašai gali egzistuoti tik kaip atskirų įrašų ir negali būti derinamas su bet kokiu kitu išteklių įrašo (DNSSEC SIG, NXTir KEY RRįrašų neįtraukė)

Tai neleidžia CNAMEnaudoti šakniniame domene, nes abi taisyklės prieštarautų viena kitai.

Čia svarbu tai, kad tai yra ne techninis, o sutarties apribojimas. Galima naudoti a CNAMEšaknyje, tačiau tai gali sukelti netikėtų klaidų, nes tai laužo numatomą elgesio sutartį.

To pavyzdį pasakoja „Cloudflare“, aprašydamas problemas, su kuriomis jie susidūrė su „Microsoft Exchange“ pašto serveriais, naudoję a CNAMEšakniniame domene:

Domenai paprastai nurodo serverius, kurie el. Laiškus tvarko per vadinamąjį „MX Record“. Problema buvo ta, kad „Exchange“ serveriai ... galėjo paimti CNAME šakniniame įraše ir tada tinkamai nepaisyti MAME, nustatyto MX įraše. Iš tikrųjų negalima kaltinti „Exchange“. Jie veikė pagal DNS specifikacijoje išdėstytas prielaidas.

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.

Šie virtualūs įrašai gali būti greta kitų įrašų šaknyje, nebijant nenumatyto elgesio. Atsižvelgiant į tiekėjo DNS skiriamosios gebos metodą sekant CNAMEgrandinę, jie taip pat gali turėti naudos iš ankstesnių paieškų talpyklos talpinimo.

Tada nustatydami „DNSimple“ sąranką sukonfigūruosime taip, kaip nurodyta toliau. Šis sprendimas turi visus domeno vardo slapyvardžio pranašumus ir neturi jokios rizikos jį naudoti šakniniame lygyje.

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

Ačiū, kad skaitėte! ?

Kaip visada, atidarykite bet kokius pataisymus ar papildomus klausimus.

Ištekliai

  • Kas yra DNS serveris
  • Nustatykite DNS vardų serverį
  • „DNSimple“ palaikymo puslapiai ir ALIAS tinklaraštis
  • „Cloudflare“ palaikymas ir CNAME tinklaraštis
  • dig Kaip
  • Keli puikūs „Stack Overflow“ arba „StackExchange“ įrašai
  • Gerai parašyti Vikipedijos įrašai
  • „Netlify“ tinklaraštis „Į www ar ne www“