Odkazovaný thread na fóru Let's Encrypt ale popisuje trochu jinou situaci – majitelé domény hemsida.eu nemají na autoritativních serverech této domény vůbec zavedenu zónu hemsida.eu, ale pouze její subdomény.
Let's Encrypt pak při kontrole CAA záznamů se dotazuje na CAA záznam pro samotnou doménu, na což autoritativní servery odpoví návratovým kódem REFUSED, to vede Let's Encrypt k nevydání certifikátu. Pokud autoritativní server odpoví na CAA dotaz správně návratovým kódem NOERROR a prázdnou odpovědí, autorita certifikát bez problému vydá. Není tedy povinné mít CAA záznam, je jen povinné nemít zfušované DNS.
Mimochodem, takováto konfigurace DNS také efektivně brání minimalizaci dotazů podle RFC 7816.
Návratový kód SERVFAIL nebo REFUSED nikdy neznamenal a neznamená neexistenci dotazovaného záznamu, ale pouze chybu při jeho získávání. Pro certifikační autoritu je to tedy něco jiného než prázdná pozitivní odpověď a na základě této odpovědi by neměla pokrčit rameny a říct si, že tam CAA záznam tedy asi není.
Byť odkazovaná citace z pravidel CA/B fóra umožňuje za určitých okolností chybový kód jako prázdnou odpověď interpretovat, v LE se (imho správně) rozhodli takovou výjimku neimplementovat a vyžadovat slušně nastavené DNS.
Problém je, že v dokumentaci LE není nikde popsané, jak s CAA záznamy zacházejí – a podle toho vlákna jsou evidentně přísnější, než co vyžaduje RFC. Autorizace jména se zastaví i tehdy, když sice CAA záznam existuje v nadřazené doméně, ale na dotaz na CAA pro celé hostname server odpoví REFUSED nebo SRVFAIL odpoví server na dotaz na daný záznam.
Problém je, že v dokumentaci LE není nikde popsané, jak s CAA záznamy zacházejí
Aha, no najít https://letsencrypt.org/docs/caa/ to chce fakt fištróna. Hele, posledních pár let jsi kapku přetaženej, chtělo by to offline pauzu. :-P
Můžete napsat, ve kterém přesně odstavci je popsáno, jak v souvislosti s chybami vyhodnocují CNAME/DNAME záznamy a nadřazené zóny? Já bych se rád dozvěděl, zda když na dotaz na CAA nebo CNAME záznam dostanou SERVFAIL, zda se dotazují nadřazené domény nebo ne. Ale v tom dokumentu to nikde napsané nevidím.
Zajímavá otázka. Odpověď asi bude v kódu bouldera. Mě zaujala tato část, kde se zdá, že zatímco dříve SERVFAIL brali jako prázdnou odpověď, nově to chtějí dělat jen pro nějaký black list známých špatných implementací DNS, tak aby bylo možné obnovit dříve vydané certifikáty.
Ono by ten postup měl být správně uvedený už ve specifikaci, vždycky pokud je někde „pokud jsi našel odpověď, máš výsledek, pokud si nenašel odpověď, posuň se na další úroveň a opakuj dotaz“ by mělo být explicitně uvedeno, co se má dělat, když dojde k chybě – jestli se má vyhledávání ukončit s chybou, nebo jestli se má pokračovat na další úrovni.
To, že se se SERVFAIL zacházelo jako s NOERROR podle mne bylo docela časté, překvapuje mne, že LE najel hned na takhle tvrdou kontrolu jenom s vyjmenovaným whitelistem v kódu, bez nějaké přípravy. O problému evidentně věděli.
Moje chápání je takové, že jakákoli chyba celý proces zastaví a dál se nepokračuje, protože když si nemůžete být jistý existencí politiky na specifičtější části doménového jména, nedává smysl zkoušet hledat další politiku na obecnější části jména.
Takže nakonec celá diskuze je spíše o tom, co považovat za chybu a co za prázdná data. Přitom, jakou představuje Let's Encrypt závislost by asi nebylo správné přestat prodlužovat certifikáty, na druhou stranu, nic jiného nebude lidi motivovat k opravě chybné implementace DNS.
Hlavní problém vidím v tom, že to nutí starat se o CAA záznamy i ty, kteří to vůbec řešit nechtějí – přitom CAA záznamy měly být povinné pro autority, ale pro uživatele mělo být jejich zavedení zcela transparentní. Motivace k opravě je hezká věc, ale obvykle se zpřísnění podmínek dělá tak, že je vyhlášené přechodné období, během kterého je možné to otestovat. Vyřazení nedůvěryhodných certifikačních autorit z prohlížečů trvá měsíce, aby se všichni mohli připravit, a LE takovouhle věc nasadí bez varování. Mám podezření, jestli to není právě tím, jakou LE představuje závislost… Vždyť CAA záznamy nemají nic společného s bezpečností, je to jen pojistka certifikační autority proti chybám v procesech.