6 Dub
2016
6 Dub
'16
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