6 Dub
2016
6 Dub
'16
15:28
Hi,
we're using knot DNS (2.0.2) on one of our primaries, to balance out
"BIND is used everywhere". So far, we're quite happy, but today I got
a complaint from our hostmaster team - triggered by a warning from DENIC
that "our SOA records are inconsistent".
Turns out they are, if you look at uppercase/lowercase...
$ dig +short @ns.space.net space.net soa
ns.space.net. hostmaster.space.net. 2016040601 28800 3600 864000 1800
$ dig +short @ns3.dns.space.net space.net soa
ns.Space.Net. hostmaster.Space.Net. 2016040601 28800 3600 864000 1800
first one is knot, second is BIND, and the "mixed case" spelling is
what the zone master (hidden primary) is distributing.
(I understand that DNS is not case-significant, but we're using upper
case in DNS labels because we like it that way...)
Looking at labels inside the zone (dig axfr) shows that knot is lowercasing
*everything*, not only the SOA records.
So, I started looking whether there is a switch that can change knot's
behaviour to just leave the labels alone, and do not lowercase everything.
Google did not find anything, neither did "man knotd" or "man
knot.conf".
So, is there a hidden switch or compile-time feature to achieve this?
thanks in advance,
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
6 Dub
6 Dub
15:36
Hi Gert,
no, we don't have such option. DENIC should fix their interface as their checks are
broken.
DNS is indeed case insensitive and Knot DNS does the unification for performance reasons.
One of the other values of unifying the case is a DNS compression making the DNS responses
smaller. You wouldn't be able to use DNS compression if you have inconsistent case
through the zone.
Cheers,
--
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/
--------------------------------------------
----- Original Message -----
From: "Gert Doering" <gert(a)space.net>
To: knot-dns-users(a)lists.nic.cz
Sent: Wednesday, April 6, 2016 10:28:17 AM
Subject: [knot-dns-users] preserve case in labels?
Hi,
we're using knot DNS (2.0.2) on one of our primaries, to balance out
"BIND is used everywhere". So far, we're quite happy, but today I got
a complaint from our hostmaster team - triggered by a warning from DENIC
that "our SOA records are inconsistent".
Turns out they are, if you look at uppercase/lowercase...
$ dig +short @ns.space.net space.net soa
ns.space.net. hostmaster.space.net. 2016040601 28800 3600 864000 1800
$ dig +short @ns3.dns.space.net space.net soa
ns.Space.Net. hostmaster.Space.Net. 2016040601 28800 3600 864000 1800
first one is knot, second is BIND, and the "mixed case" spelling is
what the zone master (hidden primary) is distributing.
(I understand that DNS is not case-significant, but we're using upper
case in DNS labels because we like it that way...)
Looking at labels inside the zone (dig axfr) shows that knot is lowercasing
*everything*, not only the SOA records.
So, I started looking whether there is a switch that can change knot's
behaviour to just leave the labels alone, and do not lowercase everything.
Google did not find anything, neither did "man knotd" or "man
knot.conf".
So, is there a hidden switch or compile-time feature to achieve this?
thanks in advance,
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
17:27
Hi Ondrej,
On Wed, Apr 06, 2016 at 03:36:11PM +0200, Ond??ej Surý wrote:
no, we don't have such option. DENIC should fix
their interface as their checks are broken.
I never said that DENIC's checks are very *useful* (or that we're worried
about it) - but that's how I came to know about it.
DNS is indeed case insensitive and Knot DNS does the
unification for performance reasons.
One of the other values of unifying the case is a DNS compression making the DNS
responses smaller. You wouldn't be able to use DNS compression if you have
inconsistent case through the zone.
Well, we do have consistent casing - uppercase S and N, it's just that
knot is the odd one here, causing recursors to see mixed-case or
lowercase-only results, depending on which authority they are asking.
I'm a bit frustrated to hear that, because "not interfere with the stuff
I put into a zone file, unless I authorize software to do it" is indeed
important to us - so it's "back to bind" time for now.
I can see the compression argument (and surprisingly it seems to reflect
in the traffic volume of the machine - though that might be due to other
optimizations in knot, not just case folding) - but since the difference
between bind and knot is only about 10-20 Gbytes per month, this is not
an issue of utmost importance for us.
(The "lookup performance" issue I can also see, but this should not
affect "responses shipped" - like in a SOA or PTR record)
thanks for clarification,
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
19:34
Hi Gert,
----- Original Message -----
From: "Gert Doering" <gert(a)space.net>
To: "Ondřej Surý" <ondrej.sury(a)nic.cz>
Cc: "Gert Doering" <gert(a)space.net>et>, knot-dns-users(a)lists.nic.cz
Sent: Wednesday, April 6, 2016 12:27:25 PM
Subject: Re: [knot-dns-users] preserve case in labels?
Hi Ondrej,
On Wed, Apr 06, 2016 at 03:36:11PM +0200, Ond??ej Surý wrote:
Recursors don't care about the casing in neither the ANSWER, AUTHORITY nor ADDITIONAL
sections. They might care in the QUESTION section in case 0x20 as additional antispoofing
measure is used, but that works in Knot.
no, we don't have such option. DENIC should
fix their interface as their checks
are broken.
I never said that DENIC's checks are very *useful* (or that we're worried
about it) - but that's how I came to know about it.
DNS is indeed case insensitive and Knot DNS does
the unification for performance
reasons.
One of the other values of unifying the case is a DNS compression making the DNS
responses smaller. You wouldn't be able to use DNS compression if you have
inconsistent case through the zone.
Well, we do have consistent casing - uppercase S and N, it's just that
knot is the odd one here, causing recursors to see mixed-case or
lowercase-only results, depending on which authority they are asking. I'm a bit frustrated to hear that, because
"not interfere with the stuff
I put into a zone file, unless I authorize software to do it" is indeed
important to us - so it's "back to bind" time for now.
Sorry to hear that, but there's a lot of other software that convert the data into
canonical form, and in DNS the wire format is purely aesthetic issue, as most the DNS
responses are consumed by stub resolvers and not humans. And since we are over 1M
responses per second (with SO_REUSEPORT) I think the approach works quite well for us.
I can see the compression argument (and surprisingly
it seems to reflect
in the traffic volume of the machine - though that might be due to other
optimizations in knot, not just case folding) - but since the difference
between bind and knot is only about 10-20 Gbytes per month, this is not
an issue of utmost importance for us.
Definitely the main difference is the minimal responses we sent, as the modern resolvers
will ignore most of the unsolicited extra information for security reasons.
(The "lookup performance" issue I can also
see, but this should not
affect "responses shipped" - like in a SOA or PTR record)
Shrug. Just because BIND has been doing something for years, that doesn't necessarily
makes it right. And in the end when you are under DDoS attack you will care more about
the DNS server performance than the CaMeL casing you put into the zone. Just
sayin'...
Have a nice day,
--
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/
--------------------------------------------
19:49
Hi,
On Wed, Apr 06, 2016 at 07:34:06PM +0200, Ond??ej Surý wrote:
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?
(The
"lookup performance" issue I can also see, but this should not
affect "responses shipped" - like in a SOA or PTR record)
Shrug. Just because BIND has been doing something for years,
that doesn't necessarily makes it right. And in the end when you
are under DDoS attack you will care more about the DNS server
performance than the CaMeL casing you put into the zone. Just
sayin'...
I can't see why lowercasing the *response* would make performance better...
Lowercasing the record that's being looked up - definitely so.
Anyway. Thanks for providing Knot - it's good to have the option, even if
it is not what makes *us* happy today.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
21:43
On the contrary, it's important to preserve the case of the QNAME from the DNS query
in the DNS response and not the case in the zone. At least it helps the modern resolvers
to establish additional defenses against DNS poisoning attacks.
E.g. your BIND installation is either too old or misconfigured and doesn't honor 0x20
bit, see the ISC presentation on the topic:
https://indico.dns-oarc.net/event/20/session/2/contribution/12/material/sli…
$ dig @ns3.dns.space.net SpAce.NEt soa
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @ns3.dns.space.net
SpAce.NEt soa
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30443
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;SpAce.NEt. IN SOA
;; ANSWER SECTION:
space.net. 14400 IN SOA ns.Space.Net. hostmaster.Space.Net. 2016040611 28800 3600 864000
1800
;; Query time: 27 msec
;; SERVER: 2001:608:0:f0f::f#53(2001:608:0:f0f::f)
;; WHEN: Wed Apr 6 19:31:59 2016
;; MSG SIZE rcvd: 95
vs. correct DNS compression with 0x20:
$ dig IN A eArth.rfC1925.org @master.dns.rocks
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> IN A eArth.rfC1925.org
@master.dns.rocks
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4655
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;eArth.rfC1925.org. IN A
;; ANSWER SECTION:
eArth.rfC1925.org. 3600 IN A 89.187.142.75
;; Query time: 30 msec
;; SERVER: 2a01:5f0:c001:122:a8::75#53(2a01:5f0:c001:122:a8::75)
;; WHEN: Wed Apr 6 19:33:19 2016
;; MSG SIZE rcvd: 51
You can compare this to more servers in workbench.sidnlabs.nl:
$ for server in nsd nsd4 bind9 bind10 knot powerdns; do echo -n "$server: "; dig
+noall +answer IN AAAA AaAa.types.wb.sidnLabS.nl. @$server.sidnlabs.nl; done
nsd: AaAa.types.wb.sidnLabS.nl. 60 IN AAAA 2001:7b8:c05::80:4
nsd4: AaAa.types.wb.sidnLabS.nl. 60 IN AAAA 2001:7b8:c05::80:4
bind9: aaaa.types.wb.sidnlabs.nl. 60 IN AAAA 2001:7b8:c05::80:4
bind10: AaAa.types.wb.sidnLabS.nl. 60 IN AAAA 2001:7b8:c05::80:4
knot: AaAa.types.wb.sidnLabS.nl. 60 IN AAAA 2001:7b8:c05::80:4
powerdns: AaAa.types.wb.sidnLabS.nl. 60 IN AAAA 2001:7b8:c05::80:4
All servers except bind9
Cheers,
--
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/
--------------------------------------------
----- Original Message -----
From: "Gert Doering" <gert(a)space.net>
To: "Ondřej Surý" <ondrej.sury(a)nic.cz>
Cc: "Gert Doering" <gert(a)space.net>et>, knot-dns-users(a)lists.nic.cz
Sent: Wednesday, April 6, 2016 2:49:36 PM
Subject: Re: [knot-dns-users] preserve case in labels?
Hi,
On Wed, Apr 06, 2016 at 07:34:06PM +0200, Ond??ej Surý wrote:
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?
(The
"lookup performance" issue I can also see, but this should not
affect "responses shipped" - like in a SOA or PTR record)
Shrug. Just because BIND has been doing something for years,
that doesn't necessarily makes it right. And in the end when you
are under DDoS attack you will care more about the DNS server
performance than the CaMeL casing you put into the zone. Just
sayin'...
I can't see why lowercasing the *response* would make performance better...
Lowercasing the record that's being looked up - definitely so.
Anyway. Thanks for providing Knot - it's good to have the option, even if
it is not what makes *us* happy today.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
23:06
Hi,
On Wed, Apr 06, 2016 at 09:43:54PM +0200, Ond??ej Surý wrote:
On the contrary, it's important to preserve the
case of the QNAME from the DNS query in the DNS response and not the case in the zone. At
least it helps the modern resolvers to establish additional defenses against DNS poisoning
attacks.
E.g. your BIND installation is either too old or misconfigured and doesn't honor 0x20
bit, see the ISC presentation on the topic:
https://indico.dns-oarc.net/event/20/session/2/contribution/12/material/sli…
$ dig @ns3.dns.space.net SpAce.NEt soa
TBH, I don't really care about the QNAME in the response. This is protocol
stuff which people don't *see*, unless they are actually looking for it.
I care about the *answer*:
;; ANSWER SECTION:
space.net. 14400 IN SOA ns.Space.Net. hostmaster.Space.Net. 2016040611 28800 3600 864000
1800
^^^^^^^^^^^^ this!
the QNAME I already know...
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
23:40
On 06/04/16 23:06, Gert Doering wrote:
Hi Gert,
TBH, I don't really care about the QNAME in the
response. This is protocol
stuff which people don't *see*, unless they are actually looking for it.
I care about the *answer*:
Why? Why do you need/want the case to be preserved? There's no technical
reason for it.
Anand
21:50
On 06/04/16 19:49, Gert Doering wrote:
Hi Gert,
See above. The Knot/NSD response is 15 bytes smaller than the BIND
response, because of the compression that Knot/NSD can do. Putting out
fewer bytes per response on the wire allows Knot/NSD to fill more
responses into the same pipe.
I will quite happily take this performance improvement over
case-preserving aesthetics.
Regards,
Anand
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.
Note that NSD also behaves like Knot. It lowercases all labels when
loading a zone. It will preserve the case of the query when returning
responses, but any in-zone labels will have the same case, allowing it
to compress the response. For example, the space.net/NS query from BIND
is 314 byes, whereas from Knot and NSD, it is 289 bytes.
And in the end
when you
are under DDoS attack you will care more about the DNS server
performance than the CaMeL casing you put into the zone. Just
sayin'...
I can't see why lowercasing the *response* would make performance better...
23:25
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 -
whether it's a SQL server, LDAP, or DNS, in the end it's a lookup service
that is there to serve what the user put in there, and shouldn't modify
it.
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.
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?
Now, for queries returning a name server set, or a MX set, it makes a
difference - but only if the original casing is actually different
("ns.space.net, ns2.Space.Net, ns3.SPACE.NET"). If all labels use
the same capitalization, the argument is not very strong again.
See above. The Knot/NSD response is 15 bytes smaller than the BIND
response, because of the compression that Knot/NSD can do. Putting out
fewer bytes per response on the wire allows Knot/NSD to fill more
responses into the same pipe.
I will quite happily take this performance improvement over
case-preserving aesthetics.
Querying for 10.0.30.195.in-addr.arpa, both server variants return 79 bytes
(according to "dig"), no matter the spelling (and with PTRs, it's actually
the most annoying part - the SOA is just what hit me today).
Consider me not very much convinced.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
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. Note that NSD also behaves like Knot. It lowercases
all labels when
loading a zone. It will preserve the case of the query when returning
responses, but any in-zone labels will have the same case, allowing it
to compress the response. For example, the space.net/NS query from BIND
is 314 byes, whereas from Knot and NSD, it is 289 bytes.
Glad you point this out, because that would have been my next candidate
for testing. But this is actually an interesting statement - is this
only for "in-zone" labels, so PTR data would be left alone?
Knot also lowercases PTR responses...
And in the end when you
are under DDoS attack you will care more about the DNS server
performance than the CaMeL casing you put into the zone. Just
sayin'...
I can't see why lowercasing the *response* would make performance better...
7 Dub
7 Dub
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/
--------------------------------------------
12 Dub
12 Dub
11:16
Hello Gert,
On 6.4.2016 23:25, Gert Doering wrote:
Well, protocol-wise, you're right. But this is
about user expectations -
whether it's a SQL server, LDAP, or DNS, in the end it's a lookup service
that is there to serve what the user put in there, and shouldn't modify
it.
We had a really long discussions about this topic.
Domain name handling in DNS is just mess. Some of the names can be
compressed. Some can't be compressed. And some even can be only
decompressed but not compressed (because of legacy code). And it's
similarly complicated for letter-case preservation. The names are
treated case-insensitively, however the case has to be still preserved
in some situations. For instance in RDATA of some (just some) record
types. That is needed for DNSSEC.
One thing is performance. Another thing is security. We just decided to
sanitize the data coming into the server. Zone files, zone transfers,
dynamic updates, ... everywhere. It's much easier to work with
normalized inputs. We just know what to expect. And we don't have to
handle the exceptions whenever we touch the data.
We've put a lot of effort into testing this. And we are pretty sure that
our implementation is compliant, fast, and secure.
I understand your concern. And I'm sorry, but we won't change this.
Cheers,
Jan
3092
days inactive
3098
days old
11 comments
4 participants
participants (4)
-
Anand Buddhdev -
Gert Doering -
Jan Včelak -
Ondřej Surý