Hi Anders! I think the CAA record generator for tinydns is buggy: a BIND9 zone transfer doesn't like a CAA record generated by this and served by tinydns. The encoding looks suspicious: \005issue without a \000? a char-string without length?
-
-
Indeed that generator produces the same output. But still, a BIND 9 AXFR client chokes on it... this definitely warrants more investigation.
-
Is this http://skarnet.org ? I can confirm that your nameservers are returning a bogus CAA record: 0A380569737375656C657473656E63727970742E6F7267 First two bytes are 0A38 instead of just 00 (or 80).
-
It's not, but http://skarnet.org uses the same CAA field generator, so the problem would apply there too. Thanks. The first byte should just be the flag, but what is the problem with the second one?
-
The second byte is pure garbage. Full record should be: 000569737375656C657473656E63727970742E6F7267 00 - flags 05 - length of tag 6973737565 - tag ("issue") C657473656E63727970742E6F7267 - value ("http://letsencrypt.org ")
-
Thanks. Going to dive into the code and understand what's happening.
-
You're welcome! Let me know what you find, so I can make a note on https://sslmate.com/caa/support if necessary.
-
Should be fixed now.
@anders94's generator writes \128 instead of \200 when setting the flag! The value is interpreted in octal, not decimal, so \128 was interpreted as \12 '8' (the 0A38 you saw). It's all a lot simpler than I feared.
- 3 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.