[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