CNAME-post

En post för kanoniskt namn (CNAME) är en typ av resurspost i DNS ( Domain Name System ) som mappar ett domännamn (ett alias) till ett annat (det kanoniska namnet).

Detta kan visa sig vara praktiskt när du kör flera tjänster (som en FTP-server och en webbserver , som var och en körs på olika portar) från en enda IP-adress. Man kan till exempel använda CNAME-poster för att peka ftp.example.com och www.example.com till DNS-posten exempelvis.com , som i sin tur har en A-post som pekar på IP-adressen. Sedan, om IP-adressen någonsin ändras, behöver man bara registrera ändringen på ett ställe i nätverket: i DNS A-posten till exempel.com .

CNAME-poster måste alltid peka på ett annat domännamn, aldrig direkt till en IP-adress.

Detaljer

DNS CNAME-poster specificeras i RFC 1034 och förtydligas i avsnitt 10 i RFC 2181.

CNAME-poster hanteras speciellt i domännamnssystemet och har flera begränsningar för deras användning. När en DNS-resolver stöter på en CNAME-post när den letar efter en vanlig resurspost, kommer den att starta om frågan med det kanoniska namnet istället för det ursprungliga namnet. (Om resolvern specifikt uppmanas att leta efter CNAME-poster, returneras det kanoniska namnet (höger sida) istället för att starta om frågan.) Det kanoniska namnet som en CNAME-post pekar på kan finnas var som helst i DNS, oavsett om det är lokalt. eller på en fjärrserver i en annan DNS-zon .

Till exempel, om det finns en DNS-zon enligt följande:

NAMN TYP VÄRDE ------------------------------------------------------------ --- bar.exempel.com. CNAME foo.example.com. foo.example.com. A 192.0.2.23

när en A-postsökning för bar.example.com utförs, kommer resolvern att se en CNAME-post och starta om kontrollen på foo.example.com och returnerar sedan 192.0.2.23.

Möjlig förvirring

Med en CNAME-post kan man peka ett namn som " bar.example.com " till " foo.example.com ." På grund av detta, under tillfällig diskussion bar.example.com. (vänster) sida av en DNS-post kan felaktigt identifieras som "CNAME" eller "en CNAME." Detta är dock felaktigt. Det kanoniska (sanna) namnet på " bar.example.com. " är " foo.example.com ." Eftersom CNAME står för Canonical Name, är den högra sidan det faktiska "CNAME"; på samma sida som adressen "A".

Denna förvirring nämns specifikt i RFC 2181, "Förtydliganden till DNS-specifikationen." Den vänstra etiketten är ett alias för den högra sidan (RDATA-delen), som är (eller borde vara) ett kanoniskt namn. Med andra ord, en CNAME-post så här:

bar.example.com. CNAME foo.example.com.

kan läsas som: bar.example.com är ett alias för det kanoniska namnet (CNAME) foo.example.com . En klient kommer att begära bar.example.com och svaret blir foo.example.com .

Restriktioner

CNAME-poster måste alltid hänvisas till ett annat domännamn, aldrig till en IP-adress.
Om en CNAME-post finns vid en nod bör inga andra data finnas närvarande; detta säkerställer att data för ett kanoniskt namn och dess alias inte kan skilja sig åt. (RFC 1034 avsnitt 3.6.2, RFC 1912 avsnitt 2.4) Undantaget är när DNSSEC används, i vilket fall det kan finnas DNSSEC-relaterade poster som RRSIG, NSEC, etc. (RFC 2181 avsnitt 10.1)
CNAME-poster som pekar på andra CNAME-poster bör undvikas på grund av deras bristande effektivitet, men är inte ett fel. Det är alltså möjligt att skapa olösliga loopar med CNAME-poster, som i:
```
 foo.example.com. CNAME bar.example.com.  bar.example.com.  CNAME foo.example.com.  
```
en CNAME-post kan inte finnas i zonens apex. RFC 1034 avsnitt 4.2.1 kräver en SOA-post vid zonens apex och RFC 1034 avsnitt 3.6.2 kräver att det inte finns några andra poster om en CNAME-post finns. Därför kan en CNAME-post inte visas i zonens spets.
CNAME-poster som betjänas av DNAME-poster kan orsaka rekursiva loopar i äldre resolvers. ^{[ förtydligande behövs ]}
MX- och NS-poster får aldrig peka på ett CNAME-alias (RFC 2181 avsnitt 10.3). Så till exempel får en zon inte innehålla konstruktioner som:
```
 example.com. MX 0 foo.example.com.  foo.example.com.  CNAME host.example.com.  host.example.com.  A 192.0.2.1  
```
Domäner som används i kommandona SMTP MAIL och RCPT kanske inte har en CNAME-post. I praktiken kan detta fungera, men kan ha olika beteende med olika e-postservrar och kan ha oönskade effekter.

DNAME-post

En DNAME-post eller Delegationsnamn-post definieras av RFC 6672 (original RFC 2672 är nu föråldrad). En DNAME-post skapar ett alias för ett helt underträd av domännamnsträdet. Däremot skapar CNAME-posten ett alias för ett enda namn och inte dess underdomäner. Liksom CNAME-posten fortsätter DNS-sökningen genom att försöka igen med det nya namnet. Namnservern syntetiserar en CNAME-post för att faktiskt tillämpa DNAME-posten på det begärda namnet – CNAME:n för varje nod i ett underträd har samma effekt som ett DNAME för hela underträdet.

Till exempel, om det finns en DNS-zon enligt följande:

foo.example.com. DNAME bar.example.com. bar.example.com. A 192.0.2.23 xyzzy.bar.example.com. A 192.0.2.24 *.bar.example.com. A 192.0.2.25

En A- postsökning för foo.example.com returnerar ingen data eftersom ett DNAME inte är ett CNAME och det inte finns någon A-post direkt på foo .

Däremot en sökning efter xyzzy. foo .example.com kommer att DNAME mappas och returnera A -posten för xyzzy. bar .example.com , vilket är 192.0.2.24; om DNAME-posten hade varit en CNAME-post, skulle denna begäran ha returnerat namn som inte hittades.

skulle en begäran om foobar.foo.example.com DNAME mappas och returnera 192.0.2.25.

ANAME-post

Flera hanterade DNS-plattformar implementerar en icke-standardiserad ALIAS- eller ANAME-posttyp. Dessa pseudoposter hanteras av DNS-administratörer som CNAME-poster, men publiceras och löses av (vissa) DNS-klienter som A-poster. ANAME-poster är vanligtvis konfigurerade att peka på en annan domän, men när de frågas av en klient, svara med en IP-adress. ANAME-posttyper genomgick standardisering, men det finns förmodligen många icke-överensstämmande implementeringar, så de kan göra vad som helst som ägaren av DNS-plattformen väljer, inklusive existerande i spetsen av en zon och existerande för domäner som tar emot e-post. En möjlig fördel med ANAME-poster jämfört med CNAME-poster är hastigheten; en DNS-klient kräver minst två frågor för att lösa en CNAME till en A-post till en IP-adress, medan endast en fråga är nödvändig för att lösa en ANAME till en IP-adress. Antagandet är att DNS-servern kan lösa A-posten och cachelagra den begärda IP-adressen mer effektivt och med mindre latens än vad dess DNS-klienter kan. ANAME-posttypen var ett utkast till standard som övervägdes av IETF, men det senaste utkastet gick ut i januari 2020.

Se även

externa länkar

RFC 1912 är fel – Meng Weng Wongs analys av CNAME-begränsningar
RFC 2219 – Användning av DNS-alias för nätverkstjänster