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 > _______________________________________________ nsd-users mailing list [email protected] https://lists.nlnetlabs.nl/mailman/listinfo/nsd-users
