[Pdns-users] Ignoring wildcard due to TXT record

[Peter van Dijk]

Hello Marten,

On Dec 13, 2012, at 13:17 , Marten Lehmann wrote:

> the odd thing is:
> 
> when we have a wildcard for the TXT record as well, subdomains are resolved correctly:
> 
> *.domain.com TXT "some text"
> *.domain.com A 1.2.3.4
> 
> This returns 1.2.3.4 for sub.domain.com for type A and "some text" for TXT.

This is not odd, this is conforming to spec. Step 3c finds the *, then on the * it finds the requested QTYPE, and it returns this.

>> http://www.ietf.org/rfc/rfc1034.txt - 4.3.2, step 3.c spells out what we
>> have to do.
> 
> To me this looks inconsistent. Wildcards are virtually useless if the resolver is that broken, even if a RFC from 1987 might describe it that way.

It's not inconsistent. It's well-defined and not broken. That it does not do what you (and many others!) would like or expect is, to put it bluntly, not very relevant :(

> Besides that, the RFC does not go into record types at this point. It leaves it totally open to the implementation if step 3.c is tied to the requested record type or all records. If I query for an A record of sub.domain.com, then the resolver doesn't find "the corresponding label" for type A so it should look for a wildcard of type A then. It would find it in my case, so everything would be fine. What PowerDNS does instead is to stop, even if "the corresponding label" is only for a different type (TXT in this case).

The RFC does not go into record types at this point, because at this point, the traversal is purely about names. 3.c does not leave looking at the record type open; step 3 explicitly says "Start matching down, label by label".

> Is it possible to change the behaviour somehow? We really can't go into thousands of domains that rely on the 2.9 behaviour which now would be required to add additional A records.

These changes in PowerDNS were done to conform with the RFC, and to align with other implementations. Furthermore, within DNSSEC validation, deviations actually break validation. As such, it would be hard for us to make this optional, and it would make it unwise for anyone to revert to the old behaviour, as that would make it impossible for them to deploy DNSSEC.

I have a few suggestions:
(a) duplicate your wildcard on every name that exists explicitly; you could probably script this or even make it happen with SQL triggers
(b) like a, but based on SQL views. Not trivial but probably doable.
(c) handle your wildcard with a scripted backend, like pipebackend or luabackend.

Options (b) and (c) will most likely make DNSSEC impossible for you.

I'm sorry we cannot be of more assistance, but this change cannot be reverted.

Kind regards,
-- 
Peter van Dijk
Netherlabs Computer Consulting BV - http://www.netherlabs.nl/