widlcard entries not handeled correctly in 3.0

[Habbie]

Thank you for looking into the wildcard feature and updating it in 3.0!

Now NS records are resolved before * records, but apparently not in an 100% correct way - as it seems, the resolution is still not fully conform RFC or as in bind.

If I have the following records on my PDNS server:

*.tld A 168.0.0.1 dom.tld NS ns.a.com dom.tld NS ns.b.com

...and on ns.a. and b.com we have: dom.tld A 195.0.0.0.1 sub.dom.tld CNAME dom.tld

dom.tld is resolved correctly, but sub.dom.tld (no matter if defined as CNAME or totally undefined) is resolved to 168.0.0.1 instead of 195.0.0.0.1

If an NS record is present for a sub.dom.tld, no further (wildcard) answers should be given out by PDNS - rather a servfail should result.

Thank you for PowerDNS and or your great work!

[Habbie]

Attachment '' (wildcard-versus-referral.patch) https://gist.github.com/5466712

[Habbie]

Author: anon just reformatted for better readability:

If I have the following records on my PDNS server:

  *.tld A  168.0.0.1 
dom.tld NS ns.a.com 
dom.tld NS ns.b.com

...and on ns.a. and b.com we have:

    dom.tld A     195.0.0.0.1 
sub.dom.tld CNAME dom.tld

dom.tld is resolved correctly, but sub.dom.tld (no matter if defined as CNAME or totally undefined) is resolved to 168.0.0.1 instead of 195.0.0.0.1

If an NS record is present for a sub.dom.tld, no further (wildcard) answers should be given out by PDNS to queries for A records - rather a servfail should result.

[Habbie]

Author: anon We can confirm the bug reported above.

We want to use PowerDNS Authoritative Server since years, but unfortunately have to stick w. bind due to this. We had great hopes and expected 3.0 to work correctly, but unfortunately it does not until today.

RFC1034 says: '''Wildcard RRs do not apply: When the query name or a name between the wildcard domain and the query name is know to exist. For example, if a wildcard RR has an owner name of "*.X", and the zone also contains RRs attached to B.X, the wildcards would apply to queries for name Z.X (presuming there is no explicit information for Z.X), but not to B.X, A.B.X, or X.'''

We are looking forward to seeing this issue fixed, so we can finally use your great piece of code.

[Habbie]

Author: peter Please test this patch. It will go into SVN shortly if no problems appear to arise.

[Habbie]

Author: anon Thank you for the Update! :)

Never used patch before - here's the output:

debian:~# patch < wildcard-versus-referral.patch          
patching file expected_result
patching file description
patching file command
patching file test.com
Hunk #1 FAILED at 16.
1 out of 1 hunk FAILED -- saving rejects to file test.com.rej
patching file named.conf
Hunk #1 FAILED at 11.
1 out of 1 hunk FAILED -- saving rejects to file named.conf.rej
patching file packethandler.cc
Hunk #1 FAILED at 1305.
Hunk #2 FAILED at 1317.
2 out of 2 hunks FAILED -- saving rejects to file packethandler.cc.rej

pdns was restarted after applying (?!) the patch, result is pretty much the same:

sub.dom.tld still resolves to 168.0.0.1

May I suppose, I failed to properly apply the patch. :) Does this patch patch the source files which need to be re-compiled thereafter or does it work w. the already compiled version? We always used you .deb's

Any instructions appreciated, thank you!

[Habbie]

Author: peter Try: patch -p0 < wildcard-versus-referral.patch

After applying, note that you also need to build PowerDNS.

[Habbie]

Author: anon Is this fix applied in 3.0.1?

[Habbie]

Author: peter No - 3.0.1 is 3.0 plus one security fix. No other changes.

[Habbie]

Author: ahu Fixed in commit 2368.