New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid DNSSEC signatures for empty responses with DNS 0x20 #5546

Closed
jsha opened this Issue Jul 21, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@jsha

jsha commented Jul 21, 2017

At Let's Encrypt, we use an Unbound recursive resolver with DNSSEC validation enabled, and DNS 0x20 (use-caps-for-id in unbound). We've gotten reports of problems from a couple of users who have PowerDNS as their authoritative resolvers:

https://community.letsencrypt.org/t/powerdns-cant-find-why-caa-servfails/38127
https://community.letsencrypt.org/t/help-diagnosing-caa-failures-ns1-cyso-nl/38461

Specifically, it seems that DNSSEC validation fails when a mixed-case query is made and the response is empty. There's some plausible speculation on our forum and on the unbound-users mailing list that this is because PowerDNS is signing a response containing the mixed-case qname, rather than downcasing before signing.

Caching seems to play a confounding role: If a downcased CAA query was sent first, the signed, cached response will validate, and subsequent mixed-case queries will get that valid response until it expires.

@Habbie

This comment has been minimized.

Member

Habbie commented Jul 21, 2017

Hello @jsha, thank you for your report! This was fixed in git master by #5377, which was backported to 4.0.x in #5378 and then released as 4.0.4. In other words, affected users running 4.0.3 or lower should upgrade to 4.0.4 and try again. Users running master should not be affected today.

Will leave this open for a bit in case somebody has conflicting experiences.

@jsha

This comment has been minimized.

jsha commented Jul 21, 2017

Thanks for the prompt response! I'll convey this to the affected parties and see if upgrading helps.

@rgacogne rgacogne added the auth label Jul 21, 2017

@jsha

This comment has been minimized.

jsha commented Jul 21, 2017

I've gotten one report from an affected party that upgrading to 4.0.4 fixed it. Closing. Thanks again. As an FYI I've requested Ubuntu backport the fix into Xenial, and a helpful community member has filed a similar bug for Debian.

@jsha jsha closed this Jul 21, 2017

@hlieberman hlieberman referenced this issue Jul 24, 2017

Merged

Backports to rel/auth-4.0.x #5378

2 of 7 tasks complete
@Habbie

This comment has been minimized.

Member

Habbie commented Oct 10, 2017

Those PR numbers were wrong. The backport is b91cfe5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment