<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
VĂcero názvĹŻ pro tentýž SMTP server pĹ™inášà navĂc ještÄ› problĂ©my s
certifikáty. Samozřejmě ne, pokud to bude wildcard certifikát a
pokryje všechny názvy, pĹ™ĂpadnÄ› bude obsahovat jako alternativnĂ
názvy všechny pouĹľĂvanĂ© (coĹľ ale moc obvyklĂ© nenĂ). ObecnÄ› je lepšĂ
mĂt jen jeden název, pro ten mĂt nastaven PTR záznam a vytvoĹ™en
certifikát.<br>
<br>
<div class="moz-cite-prefix"><br>
</div>
<blockquote cite="mid:55CDD9F0.70002@caletka.cz" type="cite">
<pre wrap="">Dne 14.8.2015 v 09:36 Stanislav Petr napsal(a):
</pre>
<blockquote type="cite">
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap="">
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:
<a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc1034#section-3.6.2">http://tools.ietf.org/html/rfc1034#section-3.6.2</a>
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
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Community-list mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Community-list@lists.vpsfree.cz">Community-list@lists.vpsfree.cz</a>
<a class="moz-txt-link-freetext" href="http://lists.vpsfree.cz/listinfo/community-list">http://lists.vpsfree.cz/listinfo/community-list</a>
</pre>
</blockquote>
<br>
</body>
</html>