Miks domeeni juur ei saa olla CNAME - ja muud DNS-i pisipildid

See postitus kasutada eespool nimetatud küsimust uurida DNS, dig, Adokumente, CNAMEandmeid ja ALIAS/ANAMEdokumente alates algaja seisukohast. Nii et alustame.

Esiteks mõned määratlused

  • Domeeninimede süsteem (DNS): üldine süsteem inimese meeldejääva domeeninime (example.com) teisendamiseks IP-aadressiks (93.184.216.34). IP-aadress on server, tavaliselt veebiserver, kuhu on salvestatud veebilehe kuvamiseks vajalikud failid.
  • DNS-server (tuntud ka kui nimeserver või nimeserver): kasutab domeeniaadresside kohta teabe salvestamiseks DNS-tarkvara. Neid on mitu taset - need kuuluvad igale Interneti-teenuse pakkujale, juur (kogu maailmas kokku 13), tipptasemel domeen (TLD, nt .com) ja domeenitaseme DNS-serverid.
  • Domeeninimi : domeen (näide) koos TLD-ga (.com). Terminit "domeen" kasutatakse sageli domeeninime sünonüümina, ehkki need on erinevad. Kui ostate „domeeni” registripidajalt või edasimüüjalt, ostate õigused konkreetsele domeeninimele (example.com) ja kõikidele alamdomeenidele, mida soovite luua (minu-sait.näide.com, mail.näide.com, jne).

Kõrgel tasemel päringute voog

Kõrgetasemelist voogu selle kohta, mis juhtub, kui sisestate brauserisse „example.com”, saab hüppe eemaldamiseks Interneti-teenuse pakkuja, juur- ja TLD-DNS-serveritesse lihtsustada järgmiselt:

Domeenil on tavaliselt kaks või enam nimeserverit, mis sisaldavad domeeninimega (example.com) seotud kirjeid.

Salvestada saab mitut tüüpi kirjeid, millest enamikul võib olla mitu tüüpi kirjet:

  • A: Aadressikirjed, mis kaardistavad domeeninime IP-aadressiga
  • CNAME: Kanooniline nimedokument. Kasutatakse ühe domeeninime (või alamdomeeninime) teise nimeks muutmiseks. Vaatame seda üksikasjalikumalt hiljem.
  • MX: Mail eXchange'i kirjed, mis ütlevad e-posti kohaletoimetamise agentidele, kuhu nad peaksid teie e-posti edastama
  • TXT: paindlikud tekstikirjed stringide salvestamiseks erinevatel eesmärkidel
  • SOA: ainsuse autoriteedi alguse register, mida hoitakse domeeni tipptasemel. Sisaldab konkreetset nõutavat teavet domeeni kohta, näiteks selle esmast nimeserverit
  • NS: Domeeniga seotud nimeserverid

Kui teie seade saadab päringu, mis jõuab nimeserverini, otsib server domeeni Akirjesõlmest kirjet ja sellega seotud salvestatud IP-aadressi (näide.com: 93.184.216.34). Seejärel tagastatakse see seadmesse, mida kasutatakse päringu saatmiseks õigele veebiserverile taotletud veebilehe või ressursi hankimiseks.

'Dig' kasutamine

dig( domeeniinfo groper ) on käsurea tööriist DNS-serverite päringuteks. Seda käsku kasutatakse tavaliselt tõrkeotsinguks või nagu praegu süsteemi seadistamise kohta lisateabe saamiseks.

$ dig example.comtulemuseks on terminalile prinditud pikk vastus, siin on vaikeväljund, millest me oleme huvitatud ANSWER SECTION.

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

Ja seal me läheme, näeme, et see example.comannab Arekordi 93.184.216.34. Mõnikord on domeenidel rohkem kui üks Akirje, kui rohkem kui üks veebiserver suudab pakkuda vajalikku teavet.

Seal on veel! Kui me proovida mõningaid teisi näiteid, saame kohe näha, et üks ühine kirje ilmub: 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

Kasutades +shortlipu võimaldab meil selgelt näha teed moodustatud:

$ dig www.skyscanner.net +short

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

CNAME

CNAMERekord võimaldab domeeninime kasutada pseudonüümi veel kanooniline (true) domeeni.

Kui DNS-server tagastab CNAMEkirje, ei tagasta see seda kliendile. Pigem otsib see uuesti tagastatud domeeninime ja tagastab omakorda Akirje IP-aadressi. See kett võib jätkuda mitmel CNAMEtasandil sügavalt, kuid kannatab siis enne vahemällu salvestamist mitme otsingu käigus väiksemaid jõudlushitte.

Selle lihtne näide võib olla see, kui teil on server, kuhu kõik fotod alles jäävad. Sellele pääseb tavaliselt juurde photos.example.com. Kuid võite ka soovida, et see võimaldaks juurdepääsu kaudu photographs.example.com. Üks võimalus selle võimaldamiseks on lisada CNAMEkirje, millele photographsviidatakse photos. See tähendab, et kui keegi külastab, photographs.example.comantakse talle sama sisu, mis photos.example.com.

Päringu abil $ dig photographs.example.comnäeme:

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

On oluline märkida, et see CNAMEon see tükk paremal küljel. Vasakul küljel on varjunimi või silt.

Teine levinud kasutusala on wwwalamdomeen. Ostsite, example.comet soovite, www.example.comet ka sisestavad kasutajad näeksid sama sisu.

Siinkohal väärib märkimist, mida example.comvõib nimetada tipp-, juur- või alasti domeeninimeks.

Üks võimalus oleks teise Akirje seadistamine , osutades samale IP-aadressile, mis oli example.com. See kehtib täiesti ja seda teeb tegelik example.com, kuid see ei ole hästi skaalal. Mis juhtub, kui peate värskendama osutavat IP-aadressi example.com? Samuti peate seda värskendama wwwalamdomeeni ja kõigi teiste jaoks, mida võite kasutada.

Kui CNAMEkirjet kasutati varjunime www.example.comosutamiseks example.com, tuleb värskendada ainult juurdomeeni, kuna kõik muud sõlmed sellele osutavad.

CNAME piirangud

Ajal, mil DNS-standardid kirjutati, olid nende kasutamist reguleerivad mõned reeglid. RFC 1912 ja RFC 2181 sätestavad, et:

  • SOAja NSkirjed on juurdomeenis kohustuslikud
  • CNAMEandmeid võib eksisteerida ainult ühe arvestust ja ei saa kombineerida teiste ressursside rekord (DNSSEC SIG, NXTning KEY RRandmeid välja arvatud)

See välistab CNAMEjuurdomeenis kasutamise, kuna need kaks reeglit oleksid üksteisega vastuolus.

Oluline on see, et see on lepinguline, mitte tehniline piirang. Juures on võimalik kasutada a- CNAMEtähte, kuid see võib põhjustada ootamatuid vigu, kuna see rikub eeldatava käitumislepingu.

Selle näite räägib Cloudflare, kirjeldades probleeme, millega nad Microsoft Exchange'i meiliserveritega kokku puutusid pärast juurdomeenis a CNAMEkasutamist:

Domeenid määravad tavaliselt serverid, mis töötlevad nende e-kirju nn MX-kirje kaudu. Probleem seisnes selles, et Exchange'i serverid ... said CNAME-i juurte juurest üles võtta ja siis MX-kirjel määratud CNAME-i õigesti mitte austada. Vahetust ei saa tegelikult süüdistada. Nad töötasid DNS-i spetsifikatsioonis sätestatud eelduste kohaselt.

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.

Need virtuaalsed kirjed võivad istuda teiste juurte kõrval olevate kirjete kõrval, kartmata tahtmatut käitumist. Sõltuvalt pakkuja DNS-i eraldusmeetodist CNAMEketi jälgimisel võivad neil olla ka varasemate otsingute vahemällu salvestamise eelised.

DNSimple'i seadistamiseks konfigureerime siis allpool. Sellel lahendusel on kõik domeeninimede aliasimise eelised ja ükski risk selle juurkasutamisel pole.

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

Täname lugemast! ?

Nagu alati, avage kõik parandused või lisapunktid.

Ressursid

  • Mis on DNS-server
  • DNS-nimeserveri seadistamine
  • DNS-i lihtsad tugilehed ja ALIAS-i ajaveeb
  • Cloudflare'i tugi ja CNAME ajaveeb
  • dig Kuidas
  • Mitu suurepärast Stack Overflow või StackExchange postitust
  • Hästi kirjutatud Vikipeedia sissekanded
  • Netlify ajaveeb 'www või mitte www'