Miksi verkkotunnuksen juuret eivät voi olla CNAME - ja muita DNS-nimisiä juttuja

Tämä viesti käyttää edellä kysymys tutkia DNS, dig, Akirjaa, CNAMEkirjaa, ja ALIAS/ANAMElevyjä aloittelijan näkökulmasta. Joten aloitetaan.

Ensinnäkin joitain määritelmiä

  • Domain Name System (DNS): kokonaisjärjestelmä, jolla muunnetaan ihmisen mieleenpainuva verkkotunnus (esimerkki.com) IP-osoitteeksi (93.184.216.34). IP-osoite on palvelin, tavallisesti web-palvelin, johon verkkosivun näyttämiseen tarvittavat tiedostot on tallennettu.
  • DNS-palvelin (tunnetaan myös nimellä nimipalvelin tai nimipalvelin): Käyttää DNS-ohjelmistoa verkkotunnuksen osoitteiden tietojen tallentamiseen. On olemassa useita tasoja - kullekin Internet-palveluntarjoajalle, juurille (maailmanlaajuisesti 13), ylätason verkkotunnukselle (TLD, esim. .Com) ja verkkotunnuksen DNS-palvelimille.
  • Verkkotunnus : toimialue (esimerkki) yhdistettynä TLD: hen (.com). Termiä "verkkotunnus" käytetään usein synonyyminä verkkotunnuksen kanssa, vaikka ne ovatkin erilaisia. Kun ostat 'verkkotunnuksen' rekisteröijältä tai jälleenmyyjältä, ostat oikeudet tiettyyn verkkotunnukseen (esimerkki.com) ja kaikkiin luomiin aliverkkotunnuksiin (omasivusto.esimerkki.fi, posti.esimerkki.fi, jne).

Korkean tason kyselykulku

Korkean tason tapahtumia siitä, mitä tapahtuu, kun kirjoitat selaimeesi “esimerkki.fi”, voidaan yksinkertaistaa poistamalla humalat ISP-, Root- ja TLD-DNS-palvelimille seuraavasti:

Verkkotunnuksessa on tyypillisesti kaksi tai useampia nimipalvelimia, jotka sisältävät verkkotunnukseen (esimerkki.com) liittyviä tietueita.

Voidaan tallentaa monen tyyppisiä tietueita, joista useimmilla voi olla useita merkintöjä tyyppiä kohti:

  • A: Osoitetietueet, jotka yhdistävät verkkotunnuksen IP-osoitteeseen
  • CNAME: Kanoninen nimitietue. Käytetään verkkotunnuksen (tai aliverkkotunnuksen) aliaksen vaihtamiseen toiseen. Tarkastelemme tätä myöhemmin tarkemmin.
  • MX: Mail eXchange -tietueet, jotka kertovat sähköpostijakeluagentteille, mihin heidän pitäisi toimittaa sähköpostisi
  • TXT: joustavat tekstitietueet merkkijonojen tallentamiseen erilaisiin käyttötarkoituksiin
  • SOA: Yksittäinen auktoriteetin aloitusrekisteri pidetään verkkotunnuksen ylimmällä tasolla. Sisältää tarkkoja vaadittuja tietoja verkkotunnuksesta, esimerkiksi sen ensisijaisesta nimipalvelimesta
  • NS: Toimialueeseen liittyvät nimipalvelimet

Kun laitteesi lähettää kyselyn, joka saavuttaa nimipalvelimen, palvelin etsii verkkotunnuksen tietueesta Atietueen ja siihen liittyvän tallennetun IP-osoitteen (esimerkki.com: 93.184.216.34). Tämä palautetaan sitten laitteeseen, jota käytetään lähettämään pyyntö oikealle verkkopalvelimelle pyydetyn verkkosivun tai resurssin noutamiseksi.

'Dig' -toiminnon käyttäminen

dig( domain information groper ) on komentorivityökalu DNS-palvelimien kyselyyn. Tätä komentoa käytetään yleensä vianmääritykseen tai kuten nyt lisätietoja järjestelmän asennuksesta.

$ dig example.comjohtaa pitkään päätelaitteeseen tulostettuun vasteeseen, tässä kuvattu oletuslähtö, josta olemme kiinnostuneita ANSWER SECTION.

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

Ja siellä mennään, voimme nähdä, että se example.compalauttaa Aennätyksen 93.184.216.34. Joskus verkkotunnuksissa on useampi kuin yksi Atietue, jos useampi kuin yksi verkkopalvelin voi tarjota tarvittavat tiedot.

Siellä on enemmän! Jos me kokeilla joitakin muita esimerkkejä, voimme pian nähdä, että toinen yhteinen ennätys näkyviin: 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

Lippun +shortavulla voimme nähdä selvästi muodostuneen polun:

$ dig www.skyscanner.net +short

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

CNAME

CNAMEEnnätys avulla verkkotunnus on käytössä aliaksena toisen kanoninen (tosi) verkkotunnus.

Kun DNS-palvelin palauttaa CNAMEtietueen, se ei palauta sitä asiakkaalle. Pikemminkin se etsii palautetun verkkotunnuksen uudelleen ja palauttaa puolestaan Atietueen IP-osoitteen. Tämä ketju voi jatkua monta CNAMEtasoa syvällä, mutta kärsii sitten pienistä suorituskykyosuista useista hauista ennen välimuistin tekemistä.

Yksinkertainen esimerkki tästä voisi olla, jos sinulla on palvelin, johon pidät kaikki valokuvat. Voit tavallisesti käyttää sitä photos.example.com. Saatat kuitenkin haluta myös sallia pääsyn kautta photographs.example.com. Yksi tapa tehdä tämä olisi mahdollista on lisätä CNAMEtietue, joka photographson photos. Tämä tarkoittaa, että kun joku vierailee, photographs.example.comhänelle annetaan sama sisältö kuin photos.example.com.

Kyselyn $ dig photographs.example.comavulla näemme:

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

On tärkeää huomata, että se CNAMEon se pala oikealla puolella. Vasen puoli on aliaksen nimi tai tarra.

Toinen yleinen käyttö on wwwaliverkkotunnuksessa. Ostettuasi example.comtodennäköisesti haluat myös, että kirjoittavat käyttäjät www.example.comnäkevät saman sisällön.

Tässä on syytä huomata, että example.comsitä voidaan kutsua kärjeksi, juureksi tai alastomaksi verkkotunnukseksi.

Yksi vaihtoehto olisi asettaa toinen Atietue, joka osoittaa samaan IP-osoitteeseen kuin example.com. Tämä on täysin pätevä, ja mitä todellinen example.comtekee, mutta se ei ole mittakaavassa hyvin. Mitä tapahtuu, jos sinun on päivitettävä example.comosoittava IP-osoite ? Sinun on myös päivitettävä se wwwaliverkkotunnukselle ja muille käyttämillesi muille.

Jos CNAMEtietuetta käytettiin aliaksen www.example.comosoittamiseen, example.comvain juurialue olisi päivitettävä, koska kaikki muut solmut osoittavat siihen.

CNAME-rajoitukset

Siihen aikaan, kun DNS-standardit kirjoitettiin, annettiin joitain sääntöjä niiden käytöstä. RFC 1912: n ja RFC 2181: n mukaan

  • SOAja NStietueiden on oltava läsnä juurialueella
  • CNAMEkirjanpito voi olla yksittäisinä kirjaa eikä sitä voi yhdistää muihin resurssi kirjaa (DNSSEC SIG, NXTja KEY RRkirjaa lukuun ottamatta)

Tämä sulkee pois CNAMEkäytön juurialueella, koska nämä kaksi sääntöä ovat ristiriidassa keskenään.

Tärkeää on tässä se, että tämä on sopimusraja, ei tekninen. On mahdollista käyttää CNAMEjuuressa juuria, mutta se voi johtaa odottamattomiin virheisiin, koska se rikkoo odotettua käyttäytymissopimusta.

Esimerkin tästä kertoo Cloudflare, joka kuvaa ongelmia, joita he ovat kohdanneet Microsoft Exchange -palvelimien kanssa sen jälkeen, kun he ovat käyttäneet a- CNAMEpääverkkotunnuksessaan:

Verkkotunnukset yleensä nimeävät palvelimet, jotka käsittelevät sähköpostinsa MX-tietueiden kautta. Ongelmana oli, että Exchange-palvelimet ... pystyivät noutamaan CNAME-juuritietueesta eivätkä sitten kunnioittamaan MX-tietueessa asetettua CNAME-tiedostoa. Et voi oikeastaan ​​syyttää Exchangea. Ne toimivat DNS-määrittelyn asettamien oletusten mukaisesti.

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.

Nämä virtuaaliset tietueet voivat istua juuressa muiden tietueiden rinnalla ilman pelkoa tahattomasta käyttäytymisestä. Riippuen palveluntarjoajan menetelmästä DNS-tarkkuudelle seuratessaan CNAMEketjua, heillä voi olla myös suorituskykyetuja edellisten hakujen välimuistiin tallentamisesta.

DNSimple-asennusta varten konfiguroimme sitten alla kuvatulla tavalla. Tällä ratkaisulla on kaikki verkkotunnuksen aliaksen edut, eikä mikään riskeistä käyttää sitä juuritasolla.

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

Kiitos lukemisesta! ?

Kuten aina, avaa mahdolliset korjaukset tai lisäkohdat.

Resurssit

  • Mikä on DNS-palvelin
  • Määritä DNS-nimipalvelin
  • DNS-yksinkertaiset tukisivut ja ALIAS-blogi
  • Cloudflare-tuki ja CNAME-blogi
  • dig Miten
  • Useita upeita Stack Overflow- tai StackExchange-viestejä
  • Hyvin kirjoitetut Wikipedia-merkinnät
  • Netlify-blogi 'www tai ei www'