[nsd-users] NSD answer apparently depends on case-pattern of question
Niall O'Reilly
niall.oreilly at ucd.ie
Fri Oct 9 23:10:26 UTC 2015
On Fri, 09 Oct 2015 09:07:55 +0100,
Fredrik Pettai wrote:
>
> It’s not a bug, it’s a feature :)
>
> btw. I thought this was taken care of in Zonemaster already:
> https://github.com/dotse/zonemaster/issues/372
Thanks for the reference, Fredrik.
The problem I'm describing is related, but different. Issue 372 was
resolved by implementation of 0x20 testing in Zonemaster.
What is happening is that Zonemaster's 0x20 test is revealing
behaviour by NSD which appears
- to go beyond what is documented in
http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00 (the only
version I could find);
- not to be expected by Zonemaster's test;
- not to match my reading of RFCs 1034, 1035, and 4343;
- and not to match the default behaviour of BIND named (explained in
the article from ISC's Knowledge Base which I mentioned in an
earlier message).
Specifically, what NSD seems to be doing is copying the 0x20
"modulation" (my term, adopted on-the-fly for convenience) from the
query to the Question Section of the response (so far, so good:
that's required) and then propagating, by the use of shared
compression references, this modulation to the other sections of the
response.
Zonemaster is finding the modulation where it does not expect it,
and is therefore reporting an error.
Now, either Zonemaster is erroneously reporting correct (or at
worst, acceptable) behaviour as an error and thus has a bug, or else
NSD is behaving incorrectly and is the element which needs
correction.
My feeling is that the fault is with NSD, and that this should avoid
using shared compression references between Question and other
sections of the response for labels which differ between zone and
query data simply because of 0x20 modulation.
Best regards,
Niall O'Reilly
More information about the nsd-users
mailing list