On Mon, Dec 29, 2014 at 5:22 PM, Brian Dickson
<brian.peter.dick...@gmail.com> wrote:
> I'm a big fan of this.
>
> These comments are meant to be constructive, and with the goal of improving
> the draft quality and/or quality of the underlying protocol.
>
> And, of course, I speak only for myself.
>
> In no particular order:
>
> - In section 3, it might be good to add a paragraph about the implications
> for HAMMER. Specifically, in addition to pre-fetching records that would
> otherwise expire, it is probably worth probing for the introduction of zone
> cuts where none previously existed (i.e. confirm their continued absence, or
> discover them.)
>
> - Another comment for Section 4 (other advantages), it may be worth
> mentioning improved look-up performance for TLD operators, which offsets the
> loss of query data. A 2-label QNAME query is optimal for finding the
> delegation owner name in a delegation-only TLD.
>
> - Another thing to possibly call out is the behavior of some name servers
> when the QNAME is an Empty Non-Terminal, e.g. a non-zone-cut with a child,
> but no RRs at the owner name. I seem to recall something along those lines
> but don't recall details, e.g. which software, version, etc., has this
> issue.
>
> Hope this is helpful.
... and below are some nits. I'd originally sent them off-list
(because they were just minor) but it was requested that I send them
onlist, so...
------
Below are some nits for draft-ietf-dnsop-qname-minimisation.
They are in Original, Proposed, Comment format.
Feel free to accept, reject or ignore them :-)
They were minor enough that I didn't try edit them in GitHub.
W
1. Introduction and background
The problem statement is exposed in
[I-D.bortzmeyer-dnsop-dns-privacy]. The terminology ("qname",
"resolver", etc) is also defined in this companion document. This
specific solution is not intended to completely solve the problem,
far from it. It is better to see it as one tool among a toolbox.
[O] specific solution is not intended to completely solve the problem,
far from it. It is better to see it as one tool among a toolbox.
[P] specific solution is not intended to fully solve the problem;
instead, it should be viewed as one tool amongst many.
It follows the principle explained in section 6.1 of [RFC6973]: the
less data you send out, the less privacy problems you'll get.
2. Qname minimisation
The idea is to minimise the amount of data sent from the DNS
resolver. When a resolver receives the query "What is the AAAA
record for www.example.com?", it sends to the root (assuming a cold
resolver, whose cache is empty) the very same question. Sending
"What are the NS records for .com?" would be sufficient (since it
will be the answer from the root anyway). To do so would be
compatible with the current DNS system and therefore could be easily
deployable, since it is an unilateral change to the resolvers.
If "minimisation" is too long, you can write it "m12n".
Bortzmeyer Expires April 25, 2015 [Page 2]
Internet-Draft Qname minimisation October 2014
To do such minimisation, the resolver needs to know the zone cut
[RFC2181]. There is not a zone cut at every label boundary. If we
[O] There is not a zone cut at every label boundary.
[P] Zone cuts do not necessarily exist at every label boundary.
[R] Readability
take the name www.foo.bar.example, it is possible that there is a
zone cut between "foo" and "bar" but not between "bar" and "example".
So, assuming the resolver already knows the name servers of .example,
when it receives the query "What is the AAAA record of
www.foo.bar.example", it does not always know if the request should
be sent to the name servers of bar.example or to those of example.
[RFC2181] suggests a method to find the zone cut (section 6), so
resolvers may try it.
Note that DNSSEC-validating resolvers already have access to this
information, since they have to find the zone cut (the DNSKEY record
set is just below, the DS record set just above).
It can be noted that minimising the amount of data sent also
partially addresses the case of a wire sniffer, not just the case of
privacy invasion by the servers.
[O] It can be noted that minimising the amount of data sent also
partially addresses the case of a wire sniffer, not just the case of
privacy invasion by the servers.
[P] Minimising the amount of data sent also, in part, addresses the
case of a wire sniffer as well the case of privacy invasion by the
servers.
[R] Readability.
One should note that the behaviour suggested here (minimising the
amount of data sent in qnames) is NOT forbidden by the [RFC1034]
(section 5.3.3) or [RFC1035] (section 7.2). Sending the full qname
to the authoritative name server is a tradition, not a protocol
requirment.
3. Operational considerations
The administrators of the forwarders, and of the authoritative name
servers, will get less data, which will reduce the utility of the
statistics they can produce (such as the percentage of the various
qtypes). On the other hand, it will decrease their legal
responsability, in many cases.
[O] responsability
[P] responsibility
[R] spelling
Some broken name servers do not react properly to qtype=NS requests.
As an example of today, look at www.ratp.fr (not ratp.fr), which is
delegated to two name servers that reply properly to "A www.ratp.fr"
queries but send REFUSED to queries "NS www.ratp.fr". This behaviour
is a gross protocol violation and there is no need to stop improving
the DNS because of such brokenness. However, qname minimisation may
[O] This behaviour is a gross protocol violation and there is no need
to stop improving
the DNS because of such brokenness.
[P] This behaviour is a gross protocol violation, and there is no
need to stop improving
the DNS because of such brokenness.
[R] Added comma before "and" to prevent run on sentence.
still work with such domains since they are only leaf domains (no
need to send them NS requests). Anyway, such setup breaks many
things (besides qname minimisation), it breaks negative answers as
the servers don't return the correct SOA. It also breaks anything
that depends on NS and SOA records existing at the top of the zone.
[O] Anyway, such setup breaks many
things (besides qname minimisation), it breaks negative answers as
the servers don't return the correct SOA. It also breaks anything
that depends on NS and SOA records existing at the top of the zone.
[P]Such setup breaks more than just qname minimisation. It breaks
negative answers, since the servers don't return the correct SOA, and
it also breaks anything dependent upon NS and SOA records existing at
the top of the zone.
[R] Grammar and readability
Another way to deal with such broken name servers would be to try
with A requests (A being choosen because it is the most common and
[O] choosen
[P] chosen
[R] spelling
hence the least revealing qtype). Instead of querying name servers
Bortzmeyer Expires April 25, 2015 [Page 3]
Internet-Draft Qname minimisation October 2014
with a query "NS example.com", we could use "A _.example.com" and see
if we get a referral.
Other strange and illegal practice may pose a problem: for instance,
[O] practice
[P] practices
there is a common DNS anti-pattern used by low-end web hosters that
also do DNS hosting that exploits the fact that the DNS protocol
(pre-DNSSEC) allows certain serious misconfigurations, such as parent
and child zones disagreeing on the location of a zone cut.
Basically, they have a single zone with wildcards like:
[ SNIP ]
4. Other advantages
The main goal of qname minimisation is to improve privacy, by sending
[O] privacy, by sending
[P] privacy by sending
[O] readability; no comma needed
less data. However, it may have other advantages. For instance, if
a root name server receives a query from some resolver for A.CORP
followed by B.CORP followed by C.CORP, the result will be three
NXDOMAINs, since .CORP does not exist in the root zone. Under query
>
> Brian Dickson
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
