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