7 Dub
2016
7 Dub
'16
0:15
----- Original Message -----
From: "Gert Doering" <gert(a)space.net>
To: "Anand Buddhdev" <anandb(a)ripe.net>
Cc: knot-dns-users(a)lists.nic.cz
Sent: Wednesday, April 6, 2016 6:25:41 PM
Subject: Re: [knot-dns-users] preserve case in labels?
Hi,
On Wed, Apr 06, 2016 at 09:50:53PM +0200, Anand Buddhdev wrote:
Well, protocol-wise, you're right. But this is about user expectations -
And what would you suggest to do if the user expectations are wrong?
And
"just doing it differently because you can" doesn't make it right
either... there's quite a strong argument to be made for "deliver data
the same way people have given it to you" - a SQL database that all of
a sudden would lowercase all names stored in it would also raise a few
eyebrows, no?
I disagree with you, because you're comparing apples and pears. SQL
servers and DNS servers are different things. Case doesn't matter in
DNS, and if a server wishes to lowercase all records, that's just fine. I can see the performance argument for looking up
QNAMEs (so, convert it
all to lowercase, then hash), but for delivering the right hand side,
that is, SOA strings, PTR records, there is no performance argument.
There is, the DNS compression works even further, check the next example with PTR record.
The "nic.cz" label in AUTHORITY SECTIONS is used (might be used) to compress
labels in the AUTHORITY SECTION.
The more I think about, the more I wonder whether it
really affects
compression for the PTR case - there is no label that appears twice in
the response. 10.0.30.195.in-addr.arpa goes in, "ns.Space.Net" comes
out - and whether that is "Space.Net" or "space.net" has no effect
on
compression. Right?
No, there's always a label in the QUESTION sections. And you want your compression
pointers to point into the QUESTION QNAME, so you don't have to repeat it in the
ANSWER section again --> that's at least a "length(QNAME)-2 octets"
saving every time:
$ dig +multi +dnssec +nord in PTR 1.204.31.217.in-AdDr.arpa. @c.ns.nic.cz
; <<>> DiG 9.10.3-P2 <<>> +multi +dnssec +nord in PTR
1.204.31.217.in-AdDr.arpa. @c.ns.nic.cz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14743
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;1.204.31.217.in-AdDr.arpa. IN PTR
;; ANSWER SECTION:
1.204.31.217.in-AdDr.arpa. 18000 IN PTR gw-s-01.nic.cz.
1.204.31.217.in-AdDr.arpa. 18000 IN RRSIG PTR 5 6 18000 (
20160420034307 20160406175503 16131 204.31.217.in-addr.arpa.
mkAOSpt8GtU3lCGPQIXL/mGtuAkUKH9KoMdPkU4VDtD+
G50vvaJTf5T1bgWR/KZ/QajvM8zmTwSm9hbAZjTjZsuF
53v5ytYtBITiWlexYBFVbcKGnWjubdenEZggpN3p1GuQ
ZJ73ABludQd4IvFKcLgmuFSUErJn2XALCeg+RS0= )
;; AUTHORITY SECTION:
204.31.217.in-AdDr.arpa. 18000 IN NS a.ns.nic.cz.
204.31.217.in-AdDr.arpa. 18000 IN NS b.ns.nic.cz.
204.31.217.in-AdDr.arpa. 18000 IN RRSIG NS 5 5 18000 (
20160419213245 20160406175503 16131 204.31.217.in-addr.arpa.
VIOgOYPgFhA+TZsNfpukHp/QGHSQLsftJ72g87RYdiPy
DDLqWdNMII5T6aCgSu4yiRJpM/Uel0WVabuHthtvv4RA
u1ECev7CpjkKdB6lFdDBnzRDG4mdHNniudRzWo+cnKzn
2iLBw2VKzUpvHj1fA+XoylM8BdmjNtP3uk1AO2c= )
;; Query time: 7 msec
;; SERVER: 2001:678:11::1#53(2001:678:11::1)
;; WHEN: Thu Apr 07 00:12:38 CEST 2016
;; MSG SIZE rcvd: 483
Also from the every viewpoint I can think you want a consistent behavior every time. See
how many labels are compressed for NXDOMAIN with DNSSEC:
$ dig +multi +dnssec +nord IN TLSA DNS.RoCkS. @master.dns.rocks
; <<>> DiG 9.10.3-P2 <<>> +multi +dnssec +nord IN TLSA DNS.RoCkS.
@master.dns.rocks
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38270
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;DNS.RoCkS. IN TLSA
;; AUTHORITY SECTION:
DNS.RoCkS. 3600 IN SOA master.DNS.RoCkS. ondrej.sury.org. (
1459702093 ; serial
86400 ; refresh (1 day)
7200 ; retry (2 hours)
3600000 ; expire (5 weeks 6 days 16 hours)
3600 ; minimum (1 hour)
)
DNS.RoCkS. 3600 IN NSEC *.dns.rocks. A NS SOA MX AAAA RRSIG NSEC DNSKEY
DNS.RoCkS. 3600 IN RRSIG SOA 8 2 3600 (
20160417164813 20160403164813 5670 dns.rocks.
CNUSPe/B+mdvXUnoCzK3unwI448ENztDvwY1lX8QEHxZ
ZGumfr0cKaljzzjN9SxgYnz9bWb7/WK14OkbLQqnecXe
DjzSYiZQUFFcaKn/nvzFBcK0uyDGNhnYPSYHe95C5E4Q
IRBWX0qlCXogDcyR6ZCvmWqZc7LB+mklrw9669c= )
DNS.RoCkS. 3600 IN RRSIG NSEC 8 2 3600 (
20160417154813 20160403154813 5670 dns.rocks.
szOpeShuFJ17SAptVdgqqy8fSsJVYmF6R0VfkWDxwrHC
ZtzoRQIkT3ZPI4PuqSUFQruIeNIpT8oovxl3nsy/TJ40
fNkka88knIkBSE9kIKWKso4XzPn6p84HWl0IteCMoLVk
ol9rjgQtYM59wB7wzjJkoV1u9EkSU3bzufGI2WA= )
;; Query time: 0 msec
;; SERVER: 2a01:5f0:c001:122:a8::75#53(2a01:5f0:c001:122:a8::75)
;; WHEN: Thu Apr 07 00:09:34 CEST 2016
;; MSG SIZE rcvd: 468
Note: NSEC records can't be compressed and the labels there are in canonically sorted
order.
O.
--
Ondřej Surý -- Technical Fellow
--------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.sury@nic.cz https://nic.cz/
--------------------------------------------