[vpsFree.cz: community-list] KB: vysvětlení reverse DNS
Ondřej Caletka
ondrej at caletka.cz
Fri Aug 14 14:07:12 CEST 2015
Dne 14.8.2015 v 09:36 Stanislav Petr napsal(a):
> Takze se bojim ze spis to melo vypadat tak ze podpora vpsfree nevi co je
> to PTR, ze kazda adresa muze mit vice PTR zaznamu, a v takovem pripade
> je potreba zejmena hlidat aby celkova velikost odpovedi nepresahla 512B,
> protoze nektere SW implementace maji problem s EDNS u reverznich
> prekladu (RFC6891).
Ano, adresa skutečně může mít víc PTR záznamů, to zakázané není, ale
prakticky je to dost na nic, protože drtivá většina aplikací, které
zjišťují reverzní záznam, nedokáží zpracovat víc než jednu odpověď. Pak
to vypadá třeba takhle:
$ ping php.sh.cvut.cz
PING php.sh.cvut.cz (147.32.30.201) 56(84) bytes of data.
64 bytes from dvbgrab.siliconhill.cz (147.32.30.201): icmp_seq=1 ttl=58
time=1.40 ms
64 bytes from televize.siliconhill.cz (147.32.30.201): icmp_seq=2 ttl=58
time=0.664 ms
64 bytes from autodesk.siliconhill.cz (147.32.30.201): icmp_seq=3 ttl=58
time=0.671 ms
64 bytes from menza.siliconhill.cz (147.32.30.201): icmp_seq=4 ttl=58
time=0.649 ms
64 bytes from cryptofest.sh.cvut.cz (147.32.30.201): icmp_seq=5 ttl=58
time=0.637 ms
64 bytes from hudebny.sh.cvut.cz (147.32.30.201): icmp_seq=6 ttl=58
time=0.709 ms
64 bytes from volby.sh.cvut.cz (147.32.30.201): icmp_seq=7 ttl=58
time=0.674 ms
64 bytes from sit.siliconhill.cz (147.32.30.201): icmp_seq=8 ttl=58
time=0.661 ms
64 bytes from mucirna.sh.cvut.cz (147.32.30.201): icmp_seq=9 ttl=58
time=0.685 ms
64 bytes from zapisy.siliconhill.cz (147.32.30.201): icmp_seq=10 ttl=58
time=0.746 ms
64 bytes from volby.siliconhill.cz (147.32.30.201): icmp_seq=11 ttl=58
time=0.767 ms
64 bytes from jobs.siliconhill.cz (147.32.30.201): icmp_seq=12 ttl=58
time=0.684 ms
…
Rozhodně bych tohle nebral jako nejlepší současnou praxi. Naopak, server
by měl mít jedno kanonické jméno, tedy takové, které má A a AAAA
záznamy. Na toto jméno by měl vést reverzní záznam. Ostatní jména (např.
jména webových služeb, který daný server provozuje), by měla být řešena
jako aliasy (CNAME záznamy) na kanonické jméno. Tuhle praxi popisuje už
RFC1034:
http://tools.ietf.org/html/rfc1034#section-3.6.2
Pravda, trochu nám to nabourává nemožnost úmístit CNAME záznam do apexu
zóny, takže pokud chcete webovou službu funkční i bez úvodního www., je
nutné přidat do apexu A a AAAA záznamy. To by měla být ale jediná
příležitost, kdy duplikovat A a AAAA záznamy k jedné adrese.
MX záznam by pak měl vždy ukazovat na kanonické jméno nameserveru, který
by se taktéž kanonickým jménem měl představovat v SMTP komunikaci.
Rozhodně bych nedoporučoval používat tzv. vanity MX, tedy vícero názvů
pro tentýž SMTP server.
Možná by tohle chtělo taky zapracovat do nějakého KB článku :)
--
Ondra
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4307 bytes
Desc: Elektronicky podpis S/MIME
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20150814/bb8d2abc/attachment-0002.bin>
More information about the Community-list
mailing list