Niall O'Reilly
2020-Jul-05 08:47 UTC
[nsd-users] NSD seems to force PTR RDATA to lower-case
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
$
```
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20200705/18a1e010/attachment.htm>
Wouter Wijngaards
2020-Jul-06 14:33 UTC
[nsd-users] NSD seems to force PTR RDATA to lower-case
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 >