Invalid DNSSEC signatures on empty responses to mixed-case queries

[Jacob Hoffman-Andrews]

In PowerDNS 4.0.3 and earlier, when signing an empty response, PowerDNS, operating as an authoritative resolver, would sign based on the mixed-case input, rather than downcasing before signing. This would lead any mixed-case query by a DNSSEC-validating recursive resolver to get a validation failure. Mixed-case queries are a common security measure to avoid DNS poisoning attacks (https://dyn.com/blog/use-of-bit-0x20-in-dns-labels/).

This bug went unnoticed for a long time because, for A records, if the response is empty, it doesn't matter whether you get a validation failure or an empty response; you can't resolve either way. However, when a certificate authority validates CAA records (https://tools.ietf.org/html/rfc6844), an empty response is important and meaningful: it means that there is no record restricting issuance, so issuance is okay.

Starting September 8, all public certificate authorities will by required by the CA/Browser Forum to check CAA before issuance.

The bug has been fixed in PowerDNS 4.0.4, and PowerDNS 4.0.4 is shipped in Ubuntu development (Artful Aardvark). Here's the fix: https://github.com/PowerDNS/pdns/pull/5377, and the backport from git master into the 4.0.x release series (which includes some unrelated fixes): https://github.com/PowerDNS/pdns/pull/5378.

[Impact]

After September 8, any domain names whose authoritative resolver is a version of PowerDNS with this bug will be unable to issue or renew Let's Encrypt certificates (and most likely certificates from other CAs), because the responses to CAA queries will fail to validate.

This thread also provides some context about the impact: https://community.letsencrypt.org/t/caa-servfail-changes/38298/2.

[Test Case]

Set up a DNSSEC-signed zone running PowerDNS as the authoritative resolver. Then attempt to look up any empty resource record set (e.g. TXT or CAA) using a recursive resolver that validates DNSSEC and uses mixed-case queries (DNS 0x20). https://unboundtest.com/ provides a convenient interface to query such a recursive resolver.

[Regression Potential]

If a regression manifests, it would most likely manifest in responses for DNSSEC zones that fail to validate in unusual ways, or in failed responses to mixed-case queries.

[Seth Arnold (seth-arnold)]

When 16.04 LTS was released, PowerDNS had not yet reached a full 4.0.0 release; a pre-release version was included into xenial with the understanding that at some point an update would be made to a point release. I filed bug 1652392 to suggest that this should happen but of course have not found time myself to prepare packages for testing.

So I suggest rather than backporting this specific fix we should instead focus on updating 16.04 LTS to include an actual released version of PowerDNS.

Thanks

[Robie Basak (racb)]

Upstream says this bug was fixed in 4.0.4. Zesty is on 4.0.3-1, so this bug presumably also affects Zesty (17.04)?

[Robie Basak (racb)]

> So I suggest rather than backporting this specific fix we should instead focus on updating 16.04 LTS to include an actual released version of PowerDNS.

I'd be happy to accept either approach. Backporting just this fix might be an easier thing to drive for a new contributor, and would fix the immediate problem. I wouldn't want to block progress by requiring the more difficult task.

[Brian Candler (b-candler)]

PDNS 4.0.0-alpha2 in Xenial is horribly broken(*) so IMO it seems a bit of a waste of effort backporting this specific fix, without also backporting the critical fixes from 4.0.0 alpha 3 and later, which in turn would be best done by going straight to 4.0.0 release (or 4.0.4+)

PDNS is a fine piece of software, and it's a shame that for many people their first experience will be using the Xenial package, which may put them off forever - it nearly did for me.

(*) at least with a SQL backend:
https://mailman.powerdns.com/pipermail/pdns-users/2016-May/024192.html

At the moment, it seems the only safe way to run pdns-server on Xenial is to use the packages from the origin repository: https://repo.powerdns.com/

[Brian Candler (b-candler)]

P.S. Changelogs for 4.0.0 alpha3, beta1, rc2 and release are here:
https://doc.powerdns.com/authoritative/changelog/4.0.html#powerdns-authoritative-server-4-0-0

[Robie Basak (racb)]

> ...IMO it seems a bit of a waste of effort backporting this specific fix, without also backporting the critical fixes from 4.0.0 alpha 3 and later, which in turn would be best done by going straight to 4.0.0 release (or 4.0.4+)

As I said, I'd be happy to consider either approach. I think it's up to whoever volunteers to do the work to decide which is easier.