Nerozumím, jaké změny externího API musíte neustále hlídat.
Chápu potřebu dát do DNS ověřovací token jen jednou, i když stejná potřeba může být i pro HTTP. Doufám, že současná metoda DNS-01 bude i nadále podporována. Protože na jednu stranu se zkracuje doba platnosti ověření domény, na druhou stranu se tímhle způsobem to ověření prodlouží na nekonečno.
Je dobře, že Let's Encrypt podporuje v DNS CAA záznamech rozšíření validationmethods, takže si každý může řídit, které metody validace povolí.
Pravděpodobně API jeho poskytovatele DNS, pro automatické nastavování záznamů.
To se opravdu děje, že by nějaký poskytovatel DNS měl API tak často a rychle staré verze přestal podporovat?
Já používám primárně DNS validaci certifikátů, protože to používám i pro weby, které nejsou vystavené do internetu – a nikdy jsem s tím nemusel řešit nějaký problém. A moc si nedovedu představit, jak by vznikl – průběžně aktualizuju webový server, který má ACME protokol implementovaný v sobě, včetně připojení na mnoho DNS poskytovatelů. Předpokládám, že případná změna API bude probíhat nějakou dobu, spíš roky nebo alespoň ne úplně málo měsíců, za tu dobu bude ta změna implementována do mnou používaného softwaru a dostane se ke mně v rámci běžných upgradů.
Pokud ACME klient dané API nepodporuje, nemusí někdo hlídat změny v tom API.
Pokud chcete webserver s podporou ACME a s podporou DNS Hurricane Electric, Caddy server by to měl umět.
Je škoda, že na takovéhle věci nevznikají standardní API (myslím standardní REST, ne že jedna knihovna naimplementuje 50 různých API a na druhé straně to vystrčí pod jedním API pro jeden konkrétní jazyk).
Ono nejde o vyber webservera; ale o to, ze dnes kazda krabicka chce certifikat, a ved predsa vie ACME, tak kde je problem. V tej krabicke si neviem vybrat implementaciu, je tam taka, aka je.
No problem je v tom, ze optimalizuju na urcitu cast providerov, na zvysok kaslat. Tiez by som bol najradsej, keby sa pouzivalo RFC2136 a smitec, ale presne to nie je v zaujme rozlicnych Cloudflarov a Googlov.
> Pokud ACME klient dané API nepodporuje, nemusí někdo hlídat změny v tom API.
Já to pochopil takhle:
- mám DNS u "Franta Vomáčka pneuservis a DNS"
- Franta poskytuje samodomo REST API pro nastavování DNS záznamů (už to je samo o sobě nadstandard, mnoho poskytovatelů v ČR pokud vím neposkytuje)
- já si do svého ACME klienta pro tohle dohackuju podporu
- poskytovatel API změní
- já to musím udržovat
> Je škoda, že na takovéhle věci nevznikají standardní API (myslím standardní REST
Nejmenuje se to AXFR/IXFR?
poskytovatel API změní
Já pořád vidím problém v tomhle – když někdo poskytuje divné API, často ho mění, neudržuje zpětnou kompatibilitu a nemá mechanismus informování o změnách.
A pak je samozřejmě otázka, proč hostovat DNS u někoho takového.
Nejmenuje se to AXFR/IXFR?
Ne. Jednak dneska API pro internetové služby znamená REST nebo a la REST přes HTTPS, ať se to někomu líbí nebo ne. Jednak je potřeba API, které pracuje se záznamy, ne s celou zónou. Uživatel toho API nechce řešit, že s tou zónou zároveň možná manipuluje někdo jiný. To ať si právě vyřeší poskytovatel toho API, jak požadavky na operace se záznamy převést na operace se zónou – se vším, co k tomu patří.
Znám to od nás z firmy i ze svého okolí. Prostě se kdysi dávno ustanovilo, že domény se kupují přes FORPSI/GoDaddy/Random jinou pochybnou službu bez pořádného API a od té doby to tak je. Že si DNS servery můžete delegovat jinam a i domény registrovat jinde, je prd platné, protože musíte přesvědčit ten kolos, že se to tak dneska nedělá.
Přiznám se, že tomu houby rozumím a viděl jsem to naposledy před 10+ lety. Používal jsem tehdy nástroj nsupdate, který podle manuálu prý používá protokol popsaný v RFC 2136. Jo, hned vidím, proč by to bylo na nic - asi to nemá rozumné šifrování, autentizaci a tak, což ten REST přes HTTPS řeší "v ceně".