widlcard entries not handeled correctly in 3.0 #389

Closed
Habbie opened this Issue Apr 26, 2013 · 9 comments

Projects

None yet

1 participant

@Habbie
Member
Habbie commented Apr 26, 2013

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 Habbie was assigned Apr 26, 2013
@Habbie Habbie closed this Apr 26, 2013
@Habbie
Member
Habbie commented Apr 26, 2013

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

@Habbie
Member
Habbie commented Apr 26, 2013

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
Member
Habbie commented Apr 26, 2013

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
Member
Habbie commented Apr 26, 2013

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

@Habbie
Member
Habbie commented Apr 26, 2013

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
Member
Habbie commented Apr 26, 2013

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

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

@Habbie
Member
Habbie commented Apr 26, 2013

Author: anon
Is this fix applied in 3.0.1?

@Habbie
Member
Habbie commented Apr 26, 2013

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

@Habbie
Member
Habbie commented Apr 26, 2013

Author: ahu
Fixed in commit 2368.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment