Dotaz: DNS reverzní zónový záznam

[kibo]

Zdravím Guru

boot...
má otázka se bude týkat správného vložení záznamu do reverzního souboru zóny DNS.

login...
pokud do webového prohlížeče zadám url http://example.com je naprosto běžné, že se dostanu na webové stránky webového serveru s názven www.example.com.

http://example.com == http://www.example.com

Kromě toho, že toto chování musím nastavit v Apache serveru (ale to nás teď nezajímá), je nutné nastavit toto chování v zonovém souboru DNS serveru.

V knize o DNS, kterou jsem četl doporučují 2 možnosti.

1. možnost

$ORIGIN example.com.
@     IN     A     192.168.0.1
www   IN     CNAME example.com.

2. možnost

$ORIGIN example.com.
@     IN     A     192.168.0.1
www   IN     A     192.168.0.1

V prvním případě by reverzní zonový soubor (jedno zda na mém stroji, nebo na stroji vlastníka IP rozsahu) vypadal takto:

$ORIGIN 128.16.172.in-addr.arpa.
1	IN	PTR		example.com.

Ooops...
A ve druhém?

$ORIGIN 128.16.172.in-addr.arpa.
1	IN	PTR		www.example.com.

nebo

$ORIGIN 128.16.172.in-addr.arpa.
1	IN	PTR		example.com.

Přece nemůžu mít v zonovém souboru 2 záznamy se stejnou IP adresou. A nebo můžu? Jak potom bude vypadat reverzní zonový soubor? V reverzním zonovém souboru si potom vyberu jednu možnost?

Out of memory...
Možná jsem jen někde něco špatně pochopil. Můžete mi prosím poradit, jak se tento problém řeší, jak ho řešíte vy, co je správné, co je špatně? Budu Vám moc vděčný za vysvětlení.

Zdraví linuxák Tom

Odpovědi

[NN]

Reverzni zaznam je pro kazdou IP pouze a jenom jeden ,ale doprednych "aliasu" muzes mit na jednu IP kolik chces..

NN

[Jesus Jimenez]

Mnozstvi reverznich zaznamu NENI omezeno. Jen je doporuceno (z logickych duvodu) pouzivat pouze jeden.

[vdusek]

Mnozstvi reverznich zaznamu NENI omezeno. Jen je doporuceno (z logickych duvodu) pouzivat pouze jeden.

Děkuji, ale to je jedině cesta do pekel...

[Jesus Jimenez]

No vsak vam rikam, ze je logicke pouzivat pouze jeden :)

[Michal Kubeček]

Jen je doporuceno (z logickych duvodu) pouzivat pouze jeden.

Kde a kým je to doporučeno?

[Jesus Jimenez]

Kdyz napisu, ze _se_obecne_nedoporucuje_ mit vice PTR zaznamu, budete spokojenejsi?

[timeos]

Reverzny zaznam sem nemusite tahat vobec. Predstavte si hostingovy server kde bezi x webov na y domenach druhej urovne pre zakaznikov... aky by ste zvolili reverzny zaznam tam? ... je uplne jedno aky je reverz a v principe nijak nesuvisi s virtualhostmi a sluzbami beziacimi na danom stroji.

reverz sa hlavne oplati pouzivat/menit ak prevadzkujete postovy server pre vacsiu "doveryhodnost". pri webovych sluzbach je to vacsinou jedno... klienti si to nezvyknu pozerat :)

[Michal Kubeček]

Zkuste si, prosím, přečíst pár RFC, než začnete šířit podobné rady.

[timeos]

Nehnevajte sa, ale vasa reakcia moc vseobecna na to, aby som vedel co mam v tych rfc hladat. Na co konkretne ste narazali? Pokial viem, nieje nijaky priamy suvis medzi webovou sluzbou a nastavenim reverznych zaznamov pre server na ktorom sluzba bezi.

[Filip Jirsák]

Ona není ani žádná souvislost mezi webovou službou a doménovým jménem. Nastavení DNS vůbec nesouvisí s tím, zda dané doménové jméno pak budete používat pro web, SSH připojení nebo cokoli jiného. DNS není podpůrná služba pro e-mail nebo web, není to tak, že aby vám fungoval poštovní server nebo webový server, musíte nejdřív něco správně nastavit v DNS. DNS slouží pro překlad jmen na IP adresy (a opačně) a je to obecná síťová záležitost. Teprve pokud máte správně nastavené DNS, můžete názvy používat na vyšší úrovni (třeba pro e-mail). A to „správně nastavené DNS“ zahrnuje třeba správné vazby mezi dopřednými a reverzními záznamy a vůbec existenci některých záznamů.

[timeos]

Vsak tomu ja rozumiem (na co je DNS a jeho pouzitie), mojim prispevkom som chcel povedat to, ze reverz nemusi nijak suvisiet s menom http virtualhostu a moze to byt uplne iny nazov (ano, reverzny nazov by mal mat aj priamy preklad na IP adresu). Stale vsak nerozumiem, co vlastne odporuje tomu, co ste v prispevku napisali vy resp p. Kubecek voci tomu, co som napisal ja. Ze kazde priame (type A) DNS meno by malo mat svoj reverz? To myslite vazne? Kto to tak robi? A preco by to tak bolo dobre (konkretny dovod z praxe)?

DNS pouzivam uz dost dlhu dobu a zatial sa nestalo ze by kvoli mojim "best practices" nieco nefungovalo.

[Michal Kubeček]

Ze kazde priame (type A) DNS meno by malo mat svoj reverz?

Ano, přesně tak. A co víc, nejen že by adresa měla mít nějaký reverz, ale ty reverzy by měly odpovídat A záznamům.

To myslite vazne?

Naprosto. A nejen my, ale i autoři specifikací.

Kto to tak robi?

Ten, kdo není prase a kdo bezdůvodně neporušuje specifikace protokolů a služeb, které používá.

DNS pouzivam uz dost dlhu dobu a zatial sa nestalo ze by kvoli mojim "best practices" nieco nefungovalo.

Kvůli takovým a podobným "best practises" typu "dělají to tak všichni" je vlastně malý (nebo spíš velký) zázrak, že DNS ještě vůbec nějak funguje.

[timeos]

Ok, berem co ste napisali, ak je to v tych specifikaciach tak napisane, tak by sa to tak malo robit, ja som to doteraz tak nerobil. V mojom pripade platilo pri Ackovych zaznamoch robit vztach n:1 (viac men na jednu IP) a v pripade pointerov 1:1.

Kvůli takovým a podobným "best practises" typu "dělají to tak všichni" je vlastně malý (nebo spíš velký) zázrak, že DNS ještě vůbec nějak funguje.

Toto je si myslim dost prisilny nazor, ze je to zazrak. Jediny rozdiel oproti tomu, ako by to malo byt spravne u mna je mapovanie priamych a reverznych zaznamov. Pricom obe zony sa do urcitej miery tvaria nezavisle a to, ci ich spravne namapujem/nenamapujem predsa ziadny vplyv na funkcnost DNS ako takeho. Dolezitejsie na funkcnost maju vplyv podla mna skvor zalezitosti napr. spravneho delegovania alebo korektneho vytvarania zaznamov a pod.

Ale ako som uz pisal, akceptujem co ste napisali a skusim popremyslat nad napravou.

[Michal Kubeček]

Jediny rozdiel oproti tomu, ako by to malo byt spravne u mna je mapovanie priamych a reverznych zaznamov.

Ignorování (nebo dokonce sabotování) reverzního lookupu není jediný problém. Další problém je např. v tom, že DNS bylo navrženo jako hierarchická jmenná služba a v jejím návrhu se rozhodně nepočítalo s tím, že ji komerční praxe zploští do podoby, kdy má doména cz momentálně asi 700000 poddomén druhé úrovně a tento počet dál nezadržitelně roste (kolik jich je pod com, se raději ani neodvažuji podívat). I těch nedodržených specifikací by se našlo podstatně víc, např.

  mike@lion:~> host www.microsoft.com
  www.microsoft.com is an alias for toggle.www.ms.akadns.net.
  toggle.www.ms.akadns.net is an alias for g.www.ms.akadns.net.
  g.www.ms.akadns.net is an alias for lb1.www.ms.akadns.net.
  lb1.www.ms.akadns.net has address 207.46.170.123
  lb1.www.ms.akadns.net has address 207.46.170.10

[Filip Jirsák]

mojim prispevkom som chcel povedat to, ze reverz nemusi nijak suvisiet s menom http virtualhostu

Ne nemusí souviset, on s ním nijak nesouvisí, a nic z DNS ani nesouvisí s ničím z HTTP (tak, že by na tom DNS záviselo). DNS je na nižší vrstvě, a i kdyby žádné HTTP neexistovalo, DNS bude existovat dál a bude mít spoustu využití. Dívat se na to způsobem „internet je web a všechno na internetu slouží tomu, aby fungoval web“ není dobrý nápad.

Internet nefunguje tak, že si každý něco spatlá, a ono to nějakým zázrakem dohromady funguje. Funguje naopak díky společným standardům. Tedy takový byl původní záměr, dnes často opravdu nějak funguje jenom díky tomu, že to nějakým zázrakem funguje dohromady, i když kde kdo přistupuje ke standardům způsobem „to myslíte vážně?“ a „kdo to tak dělá?“

[vdusek]

$ORIGIN example.com.
@             IN     A     192.168.0.1
www-multihost IN     A     192.168.0.1
www           IN     CNAME www-multihost

A reverz už uděláš v pohodě

192.168.0.1 IN PTR www-multihost.example.com.

[Michal Kubeček]

Pominu-li, že váš zápis reverzního záznamu je zcela nesmyslný, tak to stejně není korektní, pokud nepřidáte i

  1.0.168.192.in-addr.arpa.   in   ptr   example.com.

[vdusek]

OK, omlouvám se, nenapsal jsem to v syntaxi zónového souboru. Takže

1.0.168.192.in-addr.arpa. in ptr www-multihost.example.com.

[vdusek]

A přidávat

1.0.168.192.in-addr.arpa. in ptr example.com.

mi moc smysluplné nepřijde

[Michal Kubeček]

Vám nepřijde smysluplné dodržovat RFC?

[Sten]

@             IN     A     192.168.0.1
www           IN     CNAME @

je lepší řešení, protože potom stačí pro tuto doménu jenom jenom PTR

[Michal Kubeček]

První varianta je v pořádku, aby byla v pořádku i druhá, bylo by potřeba tam ty PTR záznamy mít oba (tj. násobný záznam).

[vdusek]

http://en.wikipedia.org/wiki/Reverse_DNS_lookup

Multiple pointer records

While most rDNS entries only have one PTR record, DNS does not restrict the number. However, having multiple PTR records for the same IP address is generally not recommended, unless there is a specific need. For example, if a web server supports many virtual hosts, there may be one PTR record for each host and some versions of name server software will allocate this automatically. Multiple PTR records can cause problems, however, including triggering bugs in programs that only expect single PTR records and, in the case of a large web server, having hundreds of PTR records can cause the DNS packets to be much larger than normal.

[Michal Kubeček]

Na Wikipedii je kouzelné, že když budu chtít, za pět minut vám z ní ocituji pravý opak toho, co z ní teď citujete vy. Zkuste to raději podpořit citací z RFC.

in the case of a large web server, having hundreds of PTR records can cause the DNS packets to be much larger than normal.

A on vás snad někdo nutí mít v takovém případě stonásobný reverzní záznam? Zvolte jedno jméno, kterému dáte A záznam a které bude hodnotou reverzního; zbytek dejte jako aliasy na to hlavní (kanonické) jméno. Reverzní záznam pak nebude násobný a všichni budou spokojeni. Tedy kromě ignorantských SEO konzultantů, kteří se obětem snaží tlačit do hlavy, že jak web není dostupný i přes http://firma.cz/, tak jsou sto let za opicemi.

[vdusek]

A psal jsem snad výše něco jiného?

$ORIGIN example.com.
@             IN     A     192.168.0.1
www-multihost IN     A     192.168.0.1
www           IN     CNAME www-multihost
www2          IN     CNAME www-multihost

a reverz

1.0.168.192.in-addr.arpa. in ptr www-multihost.example.com.

[Michal Kubeček]

Ale to je něco jiného. Vy máte dva A záznamy se stejnou hodnotou, ale reverz dává pouze jedno jméno. Správně je buď

                            a     192.168.0.1
  www-multihost             cname example.com.
  www                       cname example.com.
  www2                      cname example.com.

  1.0.168.192.in-addr.arpa. ptr   example.com.

nebo

                            a     192.168.0.1
  www-multihost             a     192.168.0.1
  www                       cname www-multihost
  www2                      cname www-multihost

  1.0.168.192.in-addr.arpa. ptr   example.com.
  1.0.168.192.in-addr.arpa. ptr   www-multihost.example.com.

[vdusek]

Trvám na svém původním návrhu.

Podle Vašeho návrhu by bylo komplikované nastavit fungování více různých domén na jedné IP adrese

$ORIGIN example.com.
@             IN     A     192.168.0.1
www-multihost IN     A     192.168.0.1
www           IN     CNAME www-multihost
www2          IN     CNAME www-multihost

$ORIGIN example2.com.
@             IN     A     192.168.0.1
www           IN     CNAME www-multihost.example.com.
www2          IN     CNAME www-multihost.example.com.

$ORIGIN example3.com.
@             IN     A     192.168.0.1
www           IN     CNAME www-multihost.example.com.
www2          IN     CNAME www-multihost.example.com.

a

1.0.168.192.in-addr.arpa. in ptr www-multihost.example.com.

[Michal Kubeček]

Všechno, co píšete, je pořád nekorektní. Jakmile má nějaké jméno záznam s určitou hodnotou, měl byste reverzním lookupem příslušné adresy dostat (mimo jiné) toto jméno. Ve vašem příkladu je problém hlavně ve zbytečném požadavku přiřazovat adresy i jménům samotných domén. Což je přesně to, co jsem měl na mysli zmínkou o SEO konzultantech (protože jiný důvod to nemá).

Ideální řešení je ale samozřejmě úplně jiné: přechod na IPv6. Pak se totiž překládání desítek až stovek jmen na jednu adresu stane zbytečným a odpadne i řada dalších problémů, které to přináší (např. při použití HTTPS).

[Michal Kubeček]

Navíc nechápu, za jakým účelem tam pořád přidáváte to jméno www-multihost.example.com. Všechny CNAME záznamy mohou mít jako hodnotu rovnou example.com.

[vdusek]

Nahraď si example.com za poskytovatel.com

a

example2.com za zakaznik1.com, example3.com za zakaznik2.com

[f.]

Polopate receno, kazdy A zaznam ma mit PTR zaznam a kazdy PTR zaznam ma mit A zaznam. Jedina cesta je mit A i PTR jak pro domenu, tak pro jeden z hostu v domene, ale tato cesta se nedoporucuje. Ale koho dnes trapi nejake doporuceni a RFCcka..

[Michal Kubeček]

Co se tím změní? Tak jako tak budou zákazníci na stejné adrese jako vy.

[vdusek]

Kdysi platilo a doporucuji dodnes RFC, ze kazda IP ma mit jeden IN A a odpovidajici stejny PTR. Z duvodu SEO optimalizace je nutne pridat pridat "hack" pro zaznam domena IN A. Doporucuji ale tento zaznam nedavat do reverzu.

Je zapotrebi myslet na to, ze server, kde prezentace bezi, by mel na DNS dotazy dostavat odpoved dle doporuceni RFC (1:1 - IN A x PTR)

[root@lovius ~]# nslookup

> www.upce.cz
www.upce.cz     canonical name = cms.upce.cz.
Name:   cms.upce.cz
Address: 195.113.124.150

> cms.upce.cz
Name:   cms.upce.cz
Address: 195.113.124.150

> 195.113.124.150
150.124.113.195.in-addr.arpa    name = cms.upce.cz.

A zde SEO "hack":

> upce.cz
Name:   upce.cz
Address: 195.113.124.150

[AraxoN]

Vy píšete tak, hore v diskusii zase inak. Čo má robiť chudák správca webového serveru, kde ku jednej IP sú stovky virtualhostov, aby dostál všetkým RFC a zároveň požiadavkám klientov?

[timeos]

no presne :) Ak je to server, kde su virtualhosty z jedinej domeny druhej urovne (example.com), tak (ak som to pochopil spravne), treba mat jeden Ackovy zaznam, a kazdy virtualhost by bol vedeny ako CNAME ackoveho zaznmu. A len Ackovy zaznam by mal svoj reverz.

ak je vsak jeden stroj hostingom pre www.example.com a www.example.org, tak by som chcel vediet, ako by to malo byt spravene "koser". Tiez CNAME na uplne ine FQDN?

[Michal Kubeček]

ak je vsak jeden stroj hostingom pre www.example.com a www.example.org, tak by som chcel vediet, ako by to malo byt spravene "koser". Tiez CNAME na uplne ine FQDN?

Ano. Neexistuje žádný důvod, proč by hodnotou CNAME záznamu nemohlo být jméno z jiné domény.

[Michal Kubeček]

Pokud chce dodržovat RFC, pak existuje velmi jednoduchý způsob, jak si ověřit, kdo z nás má pravdu: přečíst si je. Nebo se spolehnout na to, že už to udělal někdo před ním, a použít např. sleuth.

[f.]

Nejcasteji se pouziva vyse popsany SEO "hack" s tim, ze se udela A zaznam i pro host v dane domene, co porusi RFC. Je moznost udelat pro oboji PTR zaznam, ale to uz jak bylo nahore zmineno, se nedoporucuje. To ze se vymyslela ta blbost s tim, ze napisete http://domena.tld a funguje to proste zpusobilo to, ze to zarove koser a bezproblemove udelat nejde. Reseni na to, aby to ale chodilo samozrejme existuji a jiz byly tady zminena.

[vdusek]

Myslím, že píšu stále to samé. Pokud ne, omlouvám se a už naposledy:

$ORIGIN provider.com.
@             IN     A     192.168.0.1
www-multihost IN     A     192.168.0.1
www           IN     CNAME www-multihost.provider.com.


$ORIGIN zakaznik1.com.
@             IN     A     192.168.0.1
www           IN     CNAME www-multihost.provider.com.

$ORIGIN zakaznik2.com.
@             IN     A     192.168.0.1
www           IN     CNAME www-multihost.provider.com.

a

1.0.168.192.in-addr.arpa. in ptr www-multihost.provider.com.

kde řádky začínající @ jsou SEO "hack"

[Michal Kubeček]

Píšete sice pořád to samé, ale tím spíš se nic nemění na faktu, že (1) je to nekorektní, (2) pomocné jméno www-multihost je úplně zbytečné a nic nepřináší.

Řádky začínající zavináčem pak nejsou žádný "SEO hack", ale obyčejný A záznam jako kterýkoli jiný; zavináč jen znamená "jméno domény, pro kterou je zónový soubor určen". Když tam nenapíšete nic nebo tam to jméno napíšete celé (i s tečkou na konci, pochopitelně), bude to fungovat úplně stejně.

[vdusek]

Předchozí zápis mi přijde logičtější, ale co třeba:

$ORIGIN provider.com.
@             IN     A     192.168.0.1
www           IN     CNAME provider.com.


$ORIGIN zakaznik1.com.
@             IN     A     192.168.0.1
www           IN     CNAME provider.com.

$ORIGIN zakaznik2.com.
@             IN     A     192.168.0.1
www           IN     CNAME provider.com.

a

1.0.168.192.in-addr.arpa. in ptr provider.com.

[Michal Kubeček]

Opravdu nevím, co sledujete tím, že pořád dokola opakujete stejné konstrukce, jako byste očekával, že se jednou spletu a řeknu vám, že je to v pořádku. Není to v pořádku, protože tam máte tři A záznamy se stejnou hodnotou a reverz ukazuje jen na jedno z těch tří jmen. Je ale samozřejmě na vás, jestli to chcete mít v souladu se specifikacemi nebo jestli na specifikace budete kašlat, jako to dělá drtivá většina provozovatelů podobných služeb.

[vdusek]

Nápodobně, ale používám konstrukce, které vyhovují RFC a zároveň řeší SEO "hack".

Vy jste ještě neuvedl nic, co by mne přesvědčilo, že moje konstrukce jsou chybné.

Další diskuse s Vámi skutečně nemá cenu.

Možná někdo navrhne lepší řešení, než to moje, a já se rád poučím.

[Jendа]

Tobě nepřijde divné, že

A? zakaznik1.com. → 192.168.0.1

ale přitom

PTR? 1.0.168.192.in-addr.arpa. → provider.com.

?

Možná někdo navrhne lepší řešení, než to moje, a já se rád poučím.

OK, zkusím to.

$ORIGIN provider.com.
@             IN     A     192.168.0.1
www           IN     CNAME provider.com.


$ORIGIN zakaznik1.com.
@             IN     A     192.168.0.1
www           IN     CNAME provider.com.

$ORIGIN zakaznik2.com.
@             IN     A     192.168.0.1
www           IN     CNAME provider.com.

reverzy:
1.0.168.192.in-addr.arpa. in ptr provider.com.
1.0.168.192.in-addr.arpa. in ptr zakaznik1.com.
1.0.168.192.in-addr.arpa. in ptr zakaznik2.com.

Snad jsem to napsal dobře.

[vdusek]

Už jsem to psal výše - http://en.wikipedia.org/wiki/Reverse_DNS_lookup

Btw - co je z toho jednoznačná DNS odpověď pro reverzní dotaz serveru na jeho adresu?

[Jendа]

K té Wikipedii - vždyť to tam píšou:

While most rDNS entries only have one PTR record, DNS does not restrict the number. However, having multiple PTR records for the same IP address is generally not recommended^[kým?] unless there is a specific need.

Což teď je, protože ti na jednu IP adresu míří víc dopředných záznamů.

For example, if a web server supports many virtual hosts, there may be one PTR record for each host and some versions of name server software will allocate this automatically.

Tohle přesně máš, takže máš mít jednu PTR pro každou doménu.

Nějaký problém?

Btw - co je z toho jednoznačná DNS odpověď pro reverzní dotaz serveru na jeho adresu?

A musí být jednoznačná? Prostě má rozhraní víc rovnocenných názvů.

[Heron]

Jestli by nebylo nejlepší (i z jiných důvodů) dát každému zákazníkovi jeho vlastní adresu.

Ty bys měl klid, protože by jsi měl jeden PTR, SEO kreténi (snad) také a Michal by tu nemusel dokola popisovat věci z RFC (které bych ti doporučoval na místo odkazů na wiki).

[Michal Kubeček]

dle doporuceni RFC (1:1 - IN A x PTR)

1:1 nikde v RFC doporučováno není, naopak, je tam důkladně popsáno, jak řešit "multihomed host", tj. situaci, kdy se jedno jméno překládá na více adres. Opačný případ, kdy se více jmen překládá na stejnou adresu, tam takto podrobně rozebrán není, ale ani jsem si tam nevšiml ničeho, co by to zakazovalo nebo nedoporučovalo. Takže chcete-li trvat na svém tvrzení, že RFC to doporučují, poprosil bych o konkrétní citaci nebo odkaz.

[vdusek]

http://www.rfc-archive.org/getrfc.php?rfc=1034

For example, suppose a name server was processing a query with for USC- ISIC.ARPA, asking for type A information, and had the following resource records:

    USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU

    C.ISI.EDU       IN      A       10.0.0.52

Both of these RRs would be returned in the response to the type A query, while a type CNAME or * query should return just the CNAME.

Domain names in RRs which point at another name should always point at the primary name and not the alias. This avoids extra indirections in accessing information. For example, the address to name RR for the above host should be:

    52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU

rather than pointing at USC-ISIC.ARPA. Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error.

[Michal Kubeček]

A jak to souvisí s tím, o čem jsme se bavili? To, co jste ocitoval, pouze říká, že uděláte-li alias, reverz má mít jako hodnotu kanonické jméno, ne alias.

[mucholapka]

Jen drobne upresneni: podle RFC1912 ke kazdemu PTR zaznamu _MUSI_ (a ne mel by) existovat odpovidajici A zaznam: "PTR records must point back to a valid A record