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/

_______________________________________________
Pdns-users mailing list
[email protected]
http://mailman.powerdns.com/mailman/listinfo/pdns-users

Reply via email to