Make check-zone warn about TLSA record preventing wildcard match for www record

[xolphin]

We managed to make our website unavailable by simply adding a DANE record to our DNS. This made NSEC3 prove non-existence of our www record, which made everyone using DNSSEC unable to use our website. I believe this is a bug inside PowerDNS, I haven't found any reason why this behavior should happen. We are running PowerDNS 3.4.3 with MySQL backend and Poweradmin interface.

Before the problem occurred we had basic records in our DNS. We did not have a 'www' record, but instead we used wildcard entry (*.example.net) pointing to our webservers IP. The zone used NSEC3 and everything was working fine.

After entering a TLSA record to the zone (_443._tcp.www.example.net TLSA ), NSEC3 was suddenly proving non-existence of www.example.net. Making our website unavailable for everyone using DNSSEC or the Google DNS. Using 'pdnssec rectify-zone' did not help at all, and 'pdnssec check-zone' did not report any errors.

Adding a www.example.net entry did fix this problem eventually. I can't find any reason why this should be required as the wildcard already points to the same address.

The bug was successfully reproduced on another domain on another server as well.

[zeha]

As far as I understand it, this is RFC-mandated behaviour. (Wildcards are ignored when a label already exists, even if it's just for another type.)

[cmouse]

https://tools.ietf.org/html/rfc4592#page-10

3.2.  Step 3
   .... 
   Once one of the parts is chosen, the other parts are not considered
   (e.g., do not execute part 'c' and then change the execution path to
   finish in part 'b').  The process of label matching is also done
   independent of the query type (QTYPE).

[cmouse]

This issue is not really about DNSSEC at all. Your website would've died in any case once you added the record, even the record type does not matter. wildcards are only matched when no other label is found for the name.

[Habbie]

I'm sorry to say that indeed this is correct behaviour, and we cannot change it. NSD and BIND would do the same. PowerDNS was somewhat more flexible about this in the past, but we had to stop doing that because of DNSSEC. Note that, as @cmouse indeed points out while I'm typing this, the NOERROR would appear even to non-DNSSEC clients.

[Habbie]

@pieterlexis suggests that pdnssec check-zone could warn about this situation. Now treating this ticket as a feature request for that. Other suggestions welcome of course!

[pieterlexis]

While this is indeed RFC-mandated behavior, it is extremely non-obvious to people not intimately familiar with DNSSEC. I suggest we add a check to pdnssec check-zone that gives a warning when a situation like this occurs in the zone.

[xolphin]

I disagree that this is only a feature request, but I think I might have been unclear on what the problem is.

The NOERROR would appear even to non-DNSSEC clients.

That is not the case. I would have understand it it worked like that. If it worked like that I would not have filed a bug report and I would have spotted the problem very early.

What happens is that the correct wildcard IP address is being returned for everyone not using DNSSEC. At the same time NSEC3 proves non-existence of that same record.

So the problem is that NSEC3 is saying the record does not exist, but at the same time an IP is actually returned in the normal output. I think that is something that should not happen.

[Habbie]

Ok, that should not happen.

Questions:

1. did you run pdnssec rectify-zone?
2. did you perhaps remove the NULL record that then appeared at www?
3. can you demonstrate the issue?

[xolphin]

1. As stated in my initial message rectify-zone / check-zone was run.
2. I do not understand what this is, but I did not do anything besides adding the DANE record.
3. I introduced this problem at xolphin.be for you

Using dig on the primary nameserver returns an IP address, while at the same time NSEC3 proves non-existence of that record. Everything looks fine and all the DNSSEC tools tell that the domain is okay, but the www domain is gone for a lot of people now.

[Habbie]

Thank you for the demonstration :)

The NSEC3 denial that comes out is not the issue, this is in fact mandatory for any wildcard expansion - that denial proves that the wildcard expansion is -valid- because the name you asked for does not actually exist.

So, the question then is: why is the wildcard expanding even though you have _443._tcp sitting under it?

I notice that on the secondary nameservers, I see correct behaviour (i.e. no www A record). This still looks like rectify was not run on the primary (and/or there's a bug in rectify), while the secondaries got auto-rectified during their incoming AXFR (assuming you are using AXFR).

Can you provide a dump of the MySQL records table for this domain, perhaps from both the master and one of the secondaries?

[xolphin]

The secondary nameservers are not run by us, and are not running PowerDNS.

For this demonstration I did not run rectify-zone yet. I did just now, making the IP address disappear on the primary nameserver as well.

My statement that rectify-zone did not fix things might be incorrect. It looks like rectify-zone makes PowerDNS drop the IP address and return NXDOMAIN for non-DNSSEC clients. In my initial request I was anticipating the exact opposite (the IP being returned with DNSSEC valid). It was unclear to me that rectify-zone influenced non-DNSSEC records as well, I thought it only affected DNSSEC records.

[Habbie]

Then we are back at 'sorry, this is correct behaviour', I'm afraid

[xolphin]

The PowerDNS manual says that what rectify-zone does is: "Calculates the 'ordername' and 'auth' fields for a zone called ZONE"

I did not understand that rectify-zone was affecting non-DNSSEC data as well. It might be correct behavior, it is very confusing :).

[Habbie]

There's a longer description at https://doc.powerdns.com/md/authoritative/dnssec/#rules-for-filling-out-fields-in-database-backends

I can see how things are confusing :)

[xolphin]

That page says:

If you have a zone example.com, and a host a.b.c.example.com in it, rectify-zone (and the AXFR client code) will insert b.c.example.com and c.example.com in the records table with type NULL (SQL NULL, not 'NULL'). Having these entries provides several benefits. We no longer reply NXDOMAIN for these shorter names (this was an RFC violation but not one that caused trouble). But more importantly, to do NSEC3 correctly, we need to be able to prove existence of these shorter names.

If I read that correctly the non-existence of the shorter name shouldn't happen?

Besides that, it might be a good thing to state somewhere that rectify-zone has influence on non-DNSSEC data as well.

[Habbie]

The response you are getting is NOERROR, not NXDOMAIN. The NXDOMAIN only happened if there also was no wildcard.

If you have suggestions for where exactly in the docs to put more warnings, please let us know!

[xolphin]

I do not mean NOERROR / NXDOMAIN which I understand now. I mean:

NSEC3 proving non-existence of www.example.net./A

reported by http://dnsviz.net/. this contradicts

we need to be able to prove existence of these shorter names

[Habbie]

When you rectify, the NSEC3 proof of the non-existence actually goes away.

[xolphin]

I refreshed http://dnsviz.net and it is still proving non-existence. Are you sure?

[Habbie]

I see 'SECURE' 'No Data' for www.xolphin.be on dnsviz.net "Updated: 2015-04-17 10:20:34 UTC (4 minutes ago)"

[xolphin]

On the left side under DNSKEY/DS/NSEC status you can click open a window with 14 items. The third line there says:

NSEC3 proving non-existence of www.xolphin.be./A

[Habbie]

Ah, I see it, their text is a bit confusing. The NSEC3 it is talking about proves the -existence- of the name www, but also proves there is no data at www.