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

[Wouter Wijngaards]

Hi Niall,

Yes, NSD lowercases the zone data.  It always has done that.  It does
this so that compares are not case insensitive any more in the code,
that is faster.

In any case you cannot (reliably) transfer it, because compression is
case insensitive.  And so is lookup of data.

If the user uses 0x20 type, change of case of the query to add entropy
to the question, then this may remove or overwrite the case of the
answer.  This could also happen if the user uses uppercase for the
query.  For example in your example if you dig for ...NO8.BE. likely
this will then also appear in the answer PTR data.

Also zone transfers use (a lot of) name compression.

It is not impossible to preserve case, although that makes packets
bigger.  I think BIND may do this for you or have an option.  But other
tools may not.

Best regards, Wouter

On 05/07/2020 10:47, Niall O'Reilly via nsd-users wrote:
> Hello, NSD Developers.
> 
> I'm seeing, to my surprise, that NSD seems to be forcing PTR RDATA
> to lower case when loading zone data from a file. Details follow
> further on below.
> 
> Data specified in mixed case as "SSID-ORselves" appears in a DNS
> response as "ssid-orselves". Packet capture seems to confirm that what
> I am seeing is not an artefact of the third-party test tool (dig) used.
> 
> This seems to be at odds with at least the spirit of both RFCs 1034 and
> 4343. It seems to me that transferring a zone from a master file to the
> database should (even SHOULD) follow as thoroughly as possible the
> same rules as apply to an over-the-wire transfer.
> 
> Perhaps I'm missing some configuration option, or just have a peculiar
> reading of the scriptures, but I think this behaviour is erroneous.
> 
> Best regards,
> 
> Niall O'Reilly
> 
> |$ uname -a FreeBSD sand.no8.be 12.1-RELEASE-p6 FreeBSD 12.1-RELEASE-p6
> GENERIC amd64 $ nsd -v NSD version 4.3.1 Written by NLnet Labs.
> Copyright (C) 2001-2006 NLnet Labs. This is free software. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE. $ grep -i '\.f\.ip6.* ssid'
> /usr/local/etc/nsd/no8.be.internal-zone
> *.0.2.e.d.3.f.6.2.7.8.0.0.b.1.d.f.ip6 IN PTR SSID-ORselves
> *.0.1.e.d.3.f.6.2.7.8.0.0.b.1.d.f.ip6 IN PTR SSID-ORguests $ echo
> ${SSH_CLIENT%% *} fd1b:87:26f3:de20:c4c:c229:aaf9:f66a $ dig @::1 +norec
> -x ${SSH_CLIENT%% *} ; <<>> DiG 9.16.4 <<>> @::1 +norec -x
> fd1b:87:26f3:de20:c4c:c229:aaf9:f66a ; (1 server found) ;; global
> options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status:
> NOERROR, id: 53140 ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 1,
> ADDITIONAL: 4 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp:
> 4096 ;; QUESTION SECTION:
> ;a.6.6.f.9.f.a.a.9.2.2.c.c.4.c.0.0.2.e.d.3.f.6.2.7.8.0.0.b.1.d.f.ip6.arpa.
> IN PTR ;; ANSWER SECTION: 3.f.6.2.7.8.0.0.b.1.d.f.ip6.arpa. 300 IN DNAME
> 3.f.6.2.7.8.0.0.b.1.d.f.ip6.no8.be.
> a.6.6.f.9.f.a.a.9.2.2.c.c.4.c.0.0.2.e.d.3.f.6.2.7.8.0.0.b.1.d.f.ip6.arpa. 300
> IN CNAME
> a.6.6.f.9.f.a.a.9.2.2.c.c.4.c.0.0.2.e.d.3.f.6.2.7.8.0.0.b.1.d.f.ip6.no8.be.
> a.6.6.f.9.f.a.a.9.2.2.c.c.4.c.0.0.2.e.d.3.f.6.2.7.8.0.0.b.1.d.f.ip6.no8.be.
> 300 IN PTR ssid-orselves.no8.be. ;; AUTHORITY SECTION: no8.be. 300 IN NS
> int-ns1.no8.be. ;; ADDITIONAL SECTION: int-ns1.no8.be. 300 IN AAAA
> 2001:bb6:572:b800::35:d int-ns1.no8.be. 300 IN AAAA
> fd1b:87:26f3:de00::35:d int-ns1.no8.be. 300 IN A 10.0.16.13 ;; Query
> time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Sun Jul 05 08:01:20 UTC
> 2020 ;; MSG SIZE rcvd: 359 $ |
> 
> 
> _______________________________________________
> nsd-users mailing list
> nsd-users at lists.nlnetlabs.nl
> https://lists.nlnetlabs.nl/mailman/listinfo/nsd-users
>