[nsd-users] NSD seems to force PTR RDATA to lower-case

[Wouter Wijngaards]

Hi Niall,

On 06/07/2020 20:41, Niall O'Reilly wrote:
> On 6 Jul 2020, at 15:33, Wouter Wijngaards via nsd-users wrote:
> 
>> Yes, NSD lowercases the zone data.  It always has done that.
> 
> Thanks for the information.

So, NSD is not case sensitive for domain names.  It is not a DNS server
that keeps upper and lower case in the data.  NSD supports 0x20 style
lookups where the upper/lowercase of the query qname is copied into the
answer.

> 
>> It does
>> this so that compares are not case insensitive any more in the code,
>> that is faster.
> 
> So when is RDATA an object of comparison?

You seem to want NSD to be case sensitive.  But it is not.  And it
lowercases the input.

You are of course right that RDATA is not the object of comparison for
query lookups, but it is when comparing duplicates for RRs and when
performing name compression.  Case sensitivity also plays a
(complicated) role in DNSSEC signatures (if you want more items for when
RDATA is an object of comparison).

You mean to argue that, case could be preserved because it is RDATA not
the domain name, but NSD uses the same routines and data structures to
handle it and does not have the upper/lowercase distinctions for this
RDATA piece.  Other RDATA pieces could have case support in NSD, as it
may be stored as a binary data segment in NSD, and not used, eg. also
not a compression domain name, or not stored as a domain-name in NSD's
internal structures, and also no additional data lookups based on the
rdata name.  But most names are compressable, not all recent ones and if
the binary format is awkward, NSD may have a binary segment for the
data, that could just as well be upper/lowercase preserving.  Case for
that may be the RRSIG zone name.  And we have had errors for that where
we had bugs because the zone name case changed in the upstream data
provision, and comparisons failed to check for equality.  So, in
retrospect, we may have been better off lowercasing that too.

> 
>> In any case you cannot (reliably) transfer it, because compression is
>> case insensitive.
> 
> This statement seems to be at odds with (Standards Track) RFC5936:
> "Hence, name compression in an AXFR message SHOULD be performed in a
> case-preserving manner"

Well, it both proves the 'not reliably' with the SHOULD, and says you
want case sensitive answers.  I am not sure without checking the code if
NSD performs case preserving compression for zone transfer, but I think
since it lowercases the input zone, that may not matter.

> 
>> And so is lookup of data.
> 
> I don't understand.
> The argument to DNS lookup is a tuple (name, class, type).
> RDATA is part of the result.

NSD stores the PTR rdata as pointers into the domain tree.  The items in
the domain tree are by that tuple, and lowercased.  And this is used for
name compression.

Best regards, Wouter

> 
> Best regards,
> Niall
>