Vlákno názorů k článku DKIM podpisy pro důveryhodnější e-mail od anonym - V článku je uveden příklad, kdy se generuje...
-
V článku je uveden příklad, kdy se generuje klíč o délce 2048. Tady bych upozornil, že dns servery mívají maximální size limit 255 bytes 255 znaků, víc do jednoho txt záznamu vložit nejde. Proto nezbývá, než generovat klíč o velikosti 1024.
Zdar Max
PS: teď jsem dokončil nasazení SPF, DKIM, ADSP, DMARC na všech našich firemních doménách ... -
Ten, co splňuje rfc1035. Jinak třeba z reálu, dns servery pipni.cz neumožňují delší klíč (nedávno to právě řešila jedna firma, kde jsem nasazoval Kerio Connect, který vygeneroval 2048 klíč a i když webmgmt říkal, že je dns nastaveno, tak nebylo a byl právě problém s neošetřením délky záznamu, aspoň myslím, že to tak nějak bylo, sám jsem to nenastavoval).
Dále, nezkoušel jsem to (teď ho nikde nemám), ale údajně bind by se také tento rfc měl držet, viz :
https://kb.isc.org/article/AA-00356/0/Can-I-have-a-TXT-or-SPF-record-longer-than-255-characters.htmlNeříkám, že je to dobře, nebo špatně, jen říkám, bacha na to, reálné nasazení 2048 klíče může být někdy problém.
Zdar Max
-
Ondřej CaletkaZlatý podporovatelDíky, o tomhle omezení jsem nevěděl. Nicméně jsem prohledal RFC 1034 a nikde jsem nenašel zmínku o limitu délky TXT RR. Jediný limit 255 znaků je limit délky doménového jména.
V každém případě tohle je daň za to, že si implementátoři zvolili znovupoužití existujícího RR, místo aby zadefinovali RR vlastní, podobně jak to udělalo třeba DANE.
-
Dan (neregistrovaný)
Ano, zmiňované omezení na TXT/SPF záznam je pravdivé (RFC 1035 sekce 3.3). Důvod je prostý, textový řetězec obsahuje na začátku 1bajtovou délku. Nicméně TXT záznam může obsahovat libovolný počet takových textových řetězců (s omezením na celkovou délku dat záznamu 2^16 bajtů).
Většina DNS serverů toto omezení dodržuje, ale například v Knot DNS plánujeme zavést automatické rozsekání delších textových řetězců při vstupu ze zónového souboru. Není to sice dokonalé řešení problému, ale někteří uživatelé po tom volají.
-
Ondřej CaletkaZlatý podporovatel
Aha, tak opravuji. Skutečně RFC 1035 v sekci 3.3 definuje limit jednoho character string záznamu na 256 B s tím, že jeden bajt určuje délku. Ovšem
TXTzáznam obsahuje jeden nebo několik character string a RFC 6376 určuje, že pro DKIM se mají všechny řetězce spojit bez jakékoli mezery. Mělo by tedy stačit do TXT záznamu na některá místa vložit" "pro rozdělení záznamu na víc kratších řětězců. -
Ano,
pomocí multiple string lze takto řešit i delší SPF záznam, ostatně obdobně je to popisováno i v linku, co jsem dával ohledně bindu - rfc4408 z roku 2006.
Osobně jsem ale nezkoušel, jaká je ohledně těchto rfc aktuální podpora (hlavně u reálných nasazení). Osobně jsem tedy k tomu to řešení byl zdrženlivý a raději použil 1024 klíč s tím, že tomu dám ještě rok a pak se uvidí.
Zdar Max -
Antonimous (neregistrovaný)
Panove, sorry, ale tahle cast diskuze mne primo nadzvedla.
Stacilo se podivat na zoubek opendkim-genkey, aby se zjistilo, ze se jedna o perlovy skript, kde se naleza nasledujici kod:
276: $len = length($keydata);
...
281: if ($len < 250)
...
286: else
287: {
288: print $txtout substr($keydata, $cur, 250);
...Jinymi slovy, tento "problem" byl jiz vyresen primo u zdroje.
(facepalm)
Uff...A ted' vazne, uspesne pouzivame klice o delce > 1024 v bindu, powerdns a knotu.
-
Filip JirsákStříbrný podporovatelCelá ta předchozí diskuse řeší to, jak se to dělá správně podle standardů. Váš komentář řeší jenom to, jak to dělá jeden nástroj - což vypovídá pouze o tom, jak to řeší ten jeden nástroj. Bez té předchozí diskuse by byl váš komentář úplně k ničemu, spolu s ní přidává malý střípeček do mozaiky.
-
Ondřej CaletkaZlatý podporovatel
U mě na Debianu Wheezy s opendkim 2.6.8-4 je
opendkim-genkeyshellový skript, který délku TXT záznamu nijak neřeší.Chcete-li někdo testovat interoperabilitu, právě jsem instaloval 2048bitový klíč na automatické odpovídače serveru nebezi.cz a doesnotwork.eu. Já jsem zatím žádný problém neobjevil a nemyslím si, že by to byl reálný problém, vzhledem k tomu, že způsob nakládání s TXT záznamy je pro DKIM definován od samého počátku a konzistentně s praxí u SPF.
