Vraag Waarom kan een CNAME-record niet worden gebruikt aan de apex (alias root) van een domein?


Dit is een Canonical Question over CNAME's bij de apices (of wortels) van zones

Het is relatief algemeen bekend dat CNAME records aan de top van een domein zijn een taboe-praktijk.

Voorbeeld: example.com. IN CNAME ithurts.example.net.

In het beste geval kan de nameserver-software weigeren de configuratie te laden en in het ergste geval kan deze configuratie worden geaccepteerd en de configuratie voor example.com ongeldig worden gemaakt.

Onlangs liet ik een webhostingbedrijf instructies doorgeven aan een bedrijfseenheid die we nodig hadden om de top van ons domein te CNAME naar een nieuw record. Omdat ik wist dat dit een zelfmoordconfiguratie zou zijn wanneer het wordt gevoerd naar BIND, heb ik hen geadviseerd dat we niet zouden kunnen voldoen en dat dit in het algemeen advies voor een bunk was. Het webhostingbedrijf stelde zich op het standpunt dat het niet absoluut verboden is door standaard bepalende RFC's en dat hun software ondersteunt het. Als we de top niet zouden kunnen CNAME, was hun advies om helemaal geen toprecord te hebben en zouden ze geen omleidende webserver aanbieden. ...Wat?

De meesten van ons weten dat RFC1912 dringt erop aan dat A CNAME record is not allowed to coexist with any other data., maar laten we eerlijk zijn tegenover onszelf, dat RFC alleen Informatief is. Het dichtstbijzijnde dat ik ken bij een woordenstroom die de praktijk verbiedt, is van RFC1034:

Als een CNAME RR aanwezig is op een knooppunt, mogen geen andere gegevens zijn   aanwezig; dit zorgt ervoor dat de gegevens voor een canonieke naam en zijn aliassen   kan niet anders zijn.

Helaas ben ik lang genoeg in de industrie geweest om te weten dat "should not not" niet hetzelfde is als "must not", en dat is genoeg touw voor de meeste softwareontwikkelaars om zich mee op te sluiten. Wetende dat iets anders dan een beknopte link naar een slam dunk een verspilling van mijn tijd zou zijn, heb ik uiteindelijk het bedrijf weg laten komen met een uitbrander voor het aanbevelen van configuraties die algemeen gebruikte software zouden kunnen breken zonder de juiste openbaarmaking.

Dit brengt ons bij de Q & A. Voor een keer zou ik willen dat we het krijgen werkelijk technisch over de waanzin van apex CNAMEs, en niet rok rond het probleem zoals we meestal doen wanneer iemand op het onderwerp berichten. RFC1912 is off-limits, net als elke andere informatie-RFC die hier van toepassing is en waar ik niet aan heb gedacht. Laten we deze baby sluiten.


107
2017-07-19 10:53


oorsprong


RFC 1034 dateert al van vrij veel tijd en ervaring vóór RFC 2119. - Michael Hampton♦


antwoorden:


CNAME records waren oorspronkelijk gemaakt om meerdere namen toe te staan ​​die dezelfde bron voorzien van een alias voor een "canonieke naam" voor de resource. Met de komst van op naam gebaseerde virtuele hosting, is het in plaats daarvan gemeengoed geworden om ze te gebruiken als een generieke vorm van IP-adresaliasing. Helaas verwachten de meeste mensen die van een webhostingachtergrond komen CNAME records om aan te geven gelijkwaardigheid in de DNS, wat nooit de bedoeling was. De top bevat recordtypen die duidelijk zijn niet gebruikt bij de identificatie van een canonieke gastheerbron (NS, SOA), die geen aliased kan zijn zonder de norm op een fundamenteel niveau te overtreden. (in het bijzonder met betrekking tot zone bezuinigingen)

Helaas werd de oorspronkelijke DNS-standaard geschreven voordat de regelgevende instanties beseften dat expliciete woordenschat nodig was om consistent gedrag te definiëren (RFC 2119). Het was nodig om te creëren RFC 2181 om verschillende hoekgevallen te verduidelijken vanwege vage bewoordingen, en de bijgewerkte woordenstroom maakt het duidelijker dat een CNAME  kan niet worden gebruikt om apex-aliasing te bereiken zonder de norm te overtreden.

6.1. Zoneautoriteit

De gezaghebbende servers voor een zone worden opgesomd in de NS-records      voor de oorsprong van de zone, die samen met een start van autoriteit      (SOA) record zijn de verplichte records in elke zone.  Zo'n server      is gezaghebbend voor alle bronrecords in een zone die niet in zijn      een andere zone. De NS-records die aangeven dat een zoneafsnijding de      eigenschap van de onderliggende zone gemaakt, net als alle andere records voor de      oorsprong van die onderliggende zone of subdomeinen ervan. Een server voor een      zone mag geen gezaghebbende antwoorden bevatten voor vragen gerelateerd aan      namen in een andere zone, inclusief de records NS en misschien A      bij een zone cut, tenzij het ook een server voor de andere is      zone.

Dit stelt dat vast SOA en NS records zijn verplicht, maar er staat niets over A of andere typen die hier verschijnen. Het lijkt misschien overbodig dat ik dit dan citeer, maar het zal in een moment relevanter worden.

RFC 1034 was enigszins vaag over de problemen die kunnen ontstaan ​​wanneer een CNAME bestaat naast andere recordtypen. RFC 2181 verwijdert de dubbelzinnigheid en vermeldt expliciet de recordtypen die naast hen mogen bestaan:

10.1. CNAME-bronrecords

Het DNS CNAME ("canonical name") record bestaat om de      canonieke naam geassocieerd met een aliasnaam. Er kan er maar één zijn      zo'n canonieke naam voor een alias. Die naam zou in het algemeen moeten zijn      een naam die elders in de DNS voorkomt, hoewel er enkele zeldzaam zijn      toepassingen voor aliassen met de bijbehorende canonieke naam      niet gedefinieerd in de DNS. Een aliasnaam (label van een CNAME-record) kan,      als DNSSEC in gebruik is, gebruik dan SIG-, NXT- en KEY-RR's, maar wellicht geen      andere gegevens.  Dat wil zeggen, voor elk label in de DNS (elke domeinnaam)      precies een van het volgende is waar:

 + one CNAME record exists, optionally accompanied by SIG, NXT, and
   KEY RRs,
 + one or more records exist, none being CNAME records,
 + the name exists, but has no associated RRs of any type,
 + the name does not exist at all.

"alias name" verwijst in dit verband naar de linkerkant van de CNAME record. De lijst met opsommingstekens maakt het expliciet duidelijk dat een SOA, NS, en A records kunnen niet worden gezien op een knooppunt waar a CNAME verschijnt ook. Wanneer we dit combineren met paragraaf 6.1, is het onmogelijk om een CNAME om aan de top te bestaan ​​omdat het naast verplicht zou moeten leven SOA en NS Records.

(Dit lijkt het werk te doen, maar als iemand een korter pad heeft om te bewijzen, geef het alsjeblieft een gok.)


Bijwerken:

Het lijkt erop dat de meer recente verwarring vandaan komt De recente beslissing van Cloudflare om een ​​illegale CNAME-record aan de top van domeinen te definiëren, waarvoor ze A-records zullen samenstellen. "RFC compliant" zoals beschreven in het gelinkte artikel verwijst naar het feit dat de records die zijn gesynthetiseerd door Cloudflare goed zullen spelen met DNS. Dit neemt niet weg dat het een volledig aangepast gedrag is.

Naar mijn mening is dit een slechte dienst voor de grotere DNS-gemeenschap: het is in feite geen CNAME-record en het misleidt mensen om te geloven dat andere software gebrekkig is om het niet toe te staan. (zoals mijn vraag laat zien)


85
2017-07-19 10:53



Ik ben het eens met dit bewijs en ik denk niet dat dit tweestaps pad van bewijs bijzonder lang of ingewikkeld is. (1. de zone apex is gegarandeerd minimaal SOA + NS records, 2. CNAME records mogen niet samengaan met andere gegevens) - Håkan Lindqvist
Over het algemeen denk ik dat het een heel goede verklaring is. Als er iets aan zou kunnen worden toegevoegd, denk ik dat het mogelijk nog verder zou uitleggen wat een CNAME record betekent eigenlijk, want dat is waarschijnlijk het meest onbegrepen recordtype. Hoewel dat een beetje boven het puntje uitsteekt, denk ik dat dit een veelgestelde vraag is, een direct gevolg van het feit dat veel (de meeste?) Geen goed begrip hebben van CNAME. - Håkan Lindqvist
@Denis Dat kan niet volledig worden beantwoord in een opmerking. Het kortste antwoord is dat je de RFC's moet lezen (1034, 1035) en een goed inzicht hebt in wat verwijzingen zijn, wat het vereiste gedrag voor een verwijzing is (AUTORITEIT, SOA-recordaanwezigheid, enz.), En waarom dit type "referral-less" aliasing schendt veel verwachtingen van DNS-servers op functioneel niveau. En dat is om mee te beginnen. Die vraag is hier geen goed onderwerp, omdat het speculatief is en niet gebaseerd is op een probleem dat u zou tegenkomen bij het werken met een goed ontworpen DNS-server die voldoet aan de standaarden. - Andrew B
@DenisHowe in het kort: er bestaat niet zoiets als "een domein" zonder NS- en SOA-records. dat zijn de niet-optionele records. - hakamadare
@Ekevoo Men kan beweren dat de HTTP-implementaties hadden moeten worden overgenomen SRV in plaats daarvan zou dit ook een non-issue hebben gemaakt. Het probleem is niet beperkt tot wat hier wordt besproken; CNAME is, in tegenstelling tot wat veel mensen denken, geen goede match voor wat nodig is. Op het einde, als CNAME werkt niet zoals mensen verwachten (!) en kan niet met terugwerkende kracht opnieuw worden ontworpen en zoals HTTP-implementaties niet gebruiken SRV het lijkt waarschijnlijker dat de functionaliteit "alias" -stijl vaker voorkomt om tegemoet te komen aan HTTP (recordtype-specifieke alias die achter de schermen is geïmplementeerd in plaats van als een zichtbaar recordtype) - Håkan Lindqvist


Als u een hele zone omleidt, moet u DNAME gebruiken. Volgens RFC 6672,

De DNAME RR en de CNAME RR [RFC1034] veroorzaken een zoekopdracht naar      (potentieel) gegevens retourneren die overeenkomen met een andere domeinnaam      van de bevraagde domeinnaam. Het verschil tussen de twee      bronrecords is dat de CNAME RR de opzoeking van gegevens richt op      de eigenaar naar een andere enkele naam, terwijl een DNAME RR zoekopdrachten richt      voor gegevens op afstammelingen van de naam van de eigenaar naar overeenkomstige namen      onder een ander (enkelvoudig) knooppunt van de boom.

Neem bijvoorbeeld door een zone kijken (zie RFC 1034 [RFC1034],      Sectie 4.3.2, stap 3) voor de domeinnaam "foo.example.com" en a      DNAME-bronrecord is te vinden op "example.com" om aan te geven dat alles      vragen onder "example.com" worden doorgestuurd naar "example.net". De lookup      proces keert terug naar stap 1 met de nieuwe querynaam van      "Foo.example.net". Had de query-naam 'www.foo.example.com',      de nieuwe query-naam zou "www.foo.example.net" zijn.


0
2018-03-27 15:41



Dit is een verkeerde interpretatie. Raadpleeg de tweede regel van de tabel in RFC 6672 §2.2. Een apex-DNAME resulteert in geen overeenkomst voor querytypen anders dan DNAME bij de apex, d.w.z. resulteert niet in een feitelijke aliasing van een Apex A- of AAAA-record. - Andrew B
Een apex DNAME resulteert in nee redirection voor vragen over de apexnaam. Het is technisch niet correct om te zeggen dat dit zal resulteren in nee wedstrijd. U krijgt nog steeds een overeenkomst als u zoekt naar NS, SOA of andere RR-typen die feitelijk zijn aanwezig voor de apex-naam. Van RFC 6672: "Als er een DNAME-record aanwezig is in de zone apex, moeten er nog steeds de gebruikelijke SOA- en NS-bronrecords aanwezig zijn. Een dergelijke DNAME kan niet worden gebruikt om spiegel een zone volledig, omdat dat niet het geval is spiegel de zone top. " - Quuxplusone