Subject: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Tue, 15 Dec 2015 21:35:19 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-dnsop-qname-minimisation-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-qname-minimisation/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I like the general approach here.  I agree with Alvaro that it'd be good
to be clearer about what the experiment is -- for the purpose of knowing
when it's been satisfied and when we can consider having this a standard
or a BCP.

I found the document to be a difficult read because of the language. 
I'll try to suggest things that I think will improve some places, but, in
general, the RFC Editor will have to do a lot of editing.

The Introduction is a bit abrupt, and starts out by giving an over-broad
pointer to the dprive problem statement (and using an odd word: exposed).
 I suggest this opening instead:

OLD
   The problem statement is exposed in [RFC7626].  The terminology
   ("QNAME", "resolver", etc) is also defined in this companion
   document.  This specific solution is not intended to fully solve the
   DNS privacy problem; instead, it should be viewed as one tool amongst
   many.

NEW
   QNAME minimisation attempts to address one aspect of the general
   DNS privacy problem [RFC7626], and should be considered as one tool
   among many that will address different aspects.  Some terminology
   used herein ("QNAME", "resolver", etc) is also defined in the
   problem statement document.

END

The "it" in the next sentence ("It follows the principle") should
probably also be replaced by "QNAME minimisation"; the sentence is
otherwise unclear.

-- Section 3 --

   For instance, some authoritative name servers embedded in load
   balancers reply properly to A queries but send REFUSED to NS queries.
   This behaviour is a gross protocol violation, and there is no need to
   stop improving the DNS because of such brokenness.

We do better when we avoid this kind of invective in our standards specs,
and when we support statements with references.  I suggest eliminating
the words "gross" and "brokenness", and to instead include a reference to
a section of a specification that says why this behaviour is incorrect. 
Like this:

NEW
   For instance, some authoritative name servers embedded in load
   balancers reply properly to A queries but send REFUSED to NS queries.
   This behaviour violates the DNS protocol (see Section ??? of [RFC??],
   and improvements to the DNS are impeded if we accept such behaviour
   as normal.
END

   Another way to deal with such broken name servers would be to try
   with QTYPE=A requests

Again: please lose "broken" and try to describe things more calmly.  And
"to try with QTYPE=A requests"... to try *what* with QTYPE=A requests? 
"Try" seems to want a direct object here, and I don't see one.

   See also section 3 of [I-D.vixie-dnsext-resimprove] for the other bad
   consequences of this brokenness.

Again: "brokenness"...

   Other strange and non-conformant practices may pose a problem:

"Other practices that do not conform to the DNS protocol standards may
also pose problems."

   there
   is a common DNS anti-pattern

Is "anti-pattern" a common term that I'm just not familiar with?  That's
likely, of course.  But if not, please replace it.  And probably remove
"serious" later in the sentence.

   (It is not known why they don't just wildcard all of "*." and be done
   with it.)

What's the point of this sentence?  Can't it just be removed?  We really
shouldn't write standards that sound like rants... please.

   This lets them turn up many web hosting customers without having to
   configure thousands of individual zones on their nameservers.

What does "turn up" mean here?

-- Section 6 --

   However, it may have other advantages.

I suggest changing "However, it may have" to "It may also have", to give
this a more positive tone.

   Thus in this common case the total number of upstream
   queries under QNAME minimisation would be counter-intuitively less
   than the number of queries under the traditional iteration (as
   described in the DNS standard).

I think changing "be counter-intuitively" to "actually be" works much
better here.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 17 Dec 2015 11:15:26 +0100

On Tue, Dec 15, 2015 at 09:35:19PM -0800,
 Barry Leiba <[email-masked]> wrote 
 a message of 125 lines which said:

> I found the document to be a difficult read because of the
> language. [...] We do better when we avoid this kind of invective in
> our standards specs, [...] We really shouldn't write standards that
> sound like rants...

Interesting. I don't remember these issues about tone being raised in
the working group. What do you think?

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 17 Dec 2015 06:28:53 -0500

> the working group. What do you think?

Stephane

I remember suggesting some edits to make the document say things a bit 
more polite, but 1) I seemed to have missed this; but 2) the document is 
listed as Experimental for now, with the idea there would be a more 
formal document that reached Proposed Standards.

tim

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 27 Dec 2015 22:44:02 +0100

>    and improvements to the DNS are impeded if we accept such behaviour

Does anyone has an idea of the reference to use to replace the "???"

For me, such a behavior is so obviously wrong that I cannot think of a
precise chapter-and-verse to quote...

---

From: "John Levine" <[email-masked]>
Date: 28 Dec 2015 02:32:26 -0000

>precise chapter-and-verse to quote...

I don't see why it's not valid behavior.  REFUSED means "The name
server refuses to perform the specified operation for policy reasons."
If my policy is not to tell you about NS records, that's my policy.
It may be a stupid policy that causes downstream problems, but it's my
right to be stupid.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Sun, 27 Dec 2015 22:02:08 -0500 (EST)

> It may be a stupid policy that causes downstream problems, but it's my

Being listed as nameserver while unconditionally refusing all NS queries
leads to a guaranteed failure with DNSSEC as there would not be a signed
NS RRset published anywhere. It's much more than being stupid, it is a
blatant protocol violation and definitely NOT valid behaviour.

Where to point to is indeed tricky. Maybe one could point to
https://tools.ietf.org/html/rfc1035#section-3.3.11

 	The NS RR states that the named host should be expected to have a zone
 	starting at owner name of the specified class.

I would interpret that to mean that a parental NS glue record signifies
that the RDATA target must point to something that has that zone at the
owner name. Thus the NS queries at that target should return proper
results for NS queries (to itself)

Paul

---

From: "John Levine" <[email-masked]>
Date: 28 Dec 2015 03:20:23 -0000

>NS RRset published anywhere.

Yes, we agree it could have bad results.

>results for NS queries (to itself)

Unless, of course, the target doesn't like you and refuses your
queries for policy reasons.  Maybe they don't want you to be able to
tell if there are delegated subzones, or they just think you're ugly.
It's still their policy, so they can refuse the queries.

The language in section 4.1.1 of RFC 1035 that defines the refused
RCODE is simple, and in a quick look at other RFCs that update 1035, I
didn't see anything that updates the definition.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Sun, 27 Dec 2015 22:31:52 -0500 (EST)

On Sun, 28 Dec 2015, John Levine wrote:

> queries for policy reasons.

Note that I said "unconditionally refusing all NS queries". Conditionally
refusing queries based on query source behaviour is off-topic.

The section in question of the draft under discussion talks about the
specific case where a load balancer is returning REFUSED because it
did not implement NS queries, and that such behaviour is a violation
of the RFC. Not implementing NS queries on an authoritative nameserver
results in a DNS implementation that indeed violates the RFC. The question
was, which part of which RFC is the best reference to point to.

Paul

---

From: Shumon Huque <[email-masked]>
Date: Sun, 27 Dec 2015 23:01:11 -0500

> was, which part of which RFC is the best reference to point to.

I certainly agree that unconditionally refusing NS queries is a bad idea.
Whether or not it is explicitly forbidden by current DNS protocol specs,
I'm not so certain about. I'd love to be corrected if anyone can point to
explicit text.

The statement Paul excerpts from RFC 1035 does not to my mind preclude
REFUSED responses to explicit NS queries; it merely states what is expected
of the named host in terms of the zone that it serves. Resolvers normally
obtain NS records not by explicit queries, but indirectly as part of data
included in referral responses. Even with DNSSEC, I think a validating
resolver could function properly without ever needing to issue explicit NS
queries (with the exception of priming queries which are directed at only
the root servers).

Query-name minimization (with query type hiding) obviously changes this
requirement.

-- 
Shumon Huque

---

From: Paul Vixie <[email-masked]>
Date: Sun, 27 Dec 2015 20:05:17 -0800

On Sunday, December 27, 2015 10:31:52 PM Paul Wouters wrote:
> of the RFC.

strictly speaking, rfc's are guidelines, not to be violated or not, but only sometimes to be 
followed. an rfc guides sender behaviour and receiver interpretation. sometimes the 
receivers don't follow the interpretation guidelines, and so it is with REFUSED. REFUSED is 
considered by initiators to pertain to the specific <qname,qtype,qclass,clientIP,serverIP> and 
are not therefore dispositive toward the originating application. "not dispositive" means the 
iteration will continue, trying other serverIP's if any are known, and eventually returning 
SERVFAIL to the originating application if all servers known for this closest encloser refuse or 
fail or time out. in that sense REFUSED is underspecified since these semantics are the same 
as if the server returned SERVFAIL, except the time domain. that is, SERVFAIL pertains to the 
<qname,qtype,qclass,clientIP,serverIP,$now> and as such, a SERVFAIL response should only 
be cached for a limited period. REFUSED is "forever".

> Not implementing NS queries on an authoritative nameserver

"violates" is the wrong rubric. the signal is ambiguous as specified and even more ambiguous 
as widely implemented. so, first mover advantage was abused, and you fight now as and 
where and when you are, not as and where and when you might wish to have been. in today's 
world, the safest interpretation is not "what the framers intended" but "how the world 
actually works." and that means treating REFUSED as a synonym for SERVFAIL but with longer 
cache retention.

do not, therefore, treat the REFUSED coming out of these load balancers as dispositive, and 
regard it as being specific to <qname, qtype, qclass, clientIP, serverIP> such that varying any 
member of that tuple could be expected to produce a non-REFUSED answer.

"DNS: You will never find a more wretched hive of slop and ambiguity. We must be cautious." 
(Obi-Wan Mockapetris)

see also:

http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/

-- 
P Vixie

---

From: "John Levine" <[email-masked]>
Date: 28 Dec 2015 04:33:29 -0000

>refusing queries based on query source behaviour is off-topic.

Perhaps the target doesn't like anyone.  Here's the entire discussion
of "refused" from RFC 1034, for the benefit of people who haven't read
it lately:

                5               Refused - The name server refuses to
                                perform the specified operation for
                                policy reasons.  For example, a name
                                server may not wish to provide the
                                information to the particular requester,
                                or a name server may not wish to perform
                                a particular operation (e.g., zone
                                transfer) for particular data.

(It really is the entire discussion, the word "refused" appears
nowhere else.)

>did not implement NS queries, ...

We know what the draft says.  That case sure sounds to me like it does
"not wish to perform a particular operation for particular data",
where the operation is a query and the data is NS records.  Yeah, it's
generally a bad idea, but so what?

If anyone thinks this isn't a valid use of refused, a citation to the
RFC that updates this part of RFC 1035 would be a good place to start.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 28 Dec 2015 04:40:20 -0000

>Does anyone has an idea of the reference to use to replace the "???"

Given that it doesn't seem to be a protocol violation, I'd suggest this:

    For instance, some authoritative name servers embedded in load
    balancers reply properly to A queries but send REFUSED to NS queries.
    This behavior causes a variety of problems, such as invalid negative
    answers, that are so severe that it is unreasonable to expect clients
    to interoperate with them reliably and so there is no point in trying to
    work around them.

R's,
John

---

From: Paul Vixie <[email-masked]>
Date: Sun, 27 Dec 2015 20:59:07 -0800

> >Does anyone has an idea of the reference to use to replace the "???"

i think "violates" is the wrong verb above, and that there is no "???" referent that can make it 
right.

>     to interoperate with them reliably and so there is no point in trying to

"For interoperability reasons, many DNS initiators treat REFUSED as a synonym for SERVFAIL. 
All senders of the REFUSED signal should keep this in mind."

-- 
P Vixie

---

From: "John R Levine" <[email-masked]>
Date: 28 Dec 2015 00:00:44 -0500

> All senders of the REFUSED signal should keep this in mind."

OK with me.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 28 Dec 2015 09:43:01 -0500

> On Dec 27, 2015, at 11:40 PM, John Levine <[email-masked]> wrote:
> 
>>> NEW

For the longest time in the DNS world there have been different  standards of conduct for the different functional elements.
Publishers can get a away with gross misconduct, while resolvers are expected to find the answer at all cost. 

I agree with your statement as the first step in calling out authorities that if they are “not nice” there is no need to try to return the answer.
In 1999 or 2000 we started seeing LoadBalancers that returned NXDOMAIN for any query other than A for a name. 
At the time the bind-9 team argued about what to do, I still think that the behavior selected was the wrong one i.e. ignore NXDOMAN for AAAA query and ask for A. 

IMHO a resolver that does not like the answers it is getting from a authority has full right to stop trying to find the answer and return SERVFAIL. 
I understand that operators of said resolver will get complaints that important cat pictures are unavailable,……

I think for all practical purposes this situation is a great example of the “Prisoners Dilemma” as there is no way to educate the people writing the crap software as they are insulated by multiple layers of protection. 

Olafur

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Dec 2015 05:34:14 +1100

In message <[email-masked]>, Olafur Gudmundsson writes:
> >>>   This behaviour violates the DNS protocol (see Section ??? of RFC??,
> For the longest time in the DNS world there have been different
> standards of conduct for the different functional elements.
> I agree with your statement as the first step in calling out authorities
> that if they are not nice there is no need to try to return the answer.
> At the time the bind-9 team argued about what to do, I still think that
> the behavior selected was the wrong one i.e. ignore NXDOMAN for AAAA
> query and ask for A.

Named doesn't ignore the NXDOMAIN.  The only type where NXDOMAIN
is handled seperately is for DS.  If named learns that AAAA returns
NXDOMAIN the next A lookup will return NXDOMAIN.

Named does treat a server as broken on a per type basis so REFUSED /
SERVFAIL etc. for one type does not impact on lookupd of other types.

> IMHO a resolver that does not like the answers it is getting from a
> authority has full right to stop trying to find the answer and return
> SERVFAIL.
> I understand that operators of said resolver will get complaints that
> important cat pictures are unavailable,
>
> I think for all practical purposes this situation is a great example of
> the Prisoners Dilemma as there is no way to educate the people writing
> the crap software as they are insulated by multiple layers of protection.
>
> Olafur
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Dec 2015 11:30:32 -0800

On Monday, December 28, 2015 09:43:01 AM Olafur Gudmundsson wrote:
...> In 1999 or 2000 we started seeing LoadBalancers that returned NXDOMAIN for
> any query other than A for a name. At the time the bind-9 team argued about
> what to do, I still think that the behavior selected was the wrong one i.e.
> ignore NXDOMAN for AAAA query and ask for A.

i agreed with you and still do. the operators consuming BIND9 didn't and still don't.

> SERVFAIL. I understand that operators of said resolver will get complaints
> that important cat pictures are unavailable,……

i would love it if operators would want the best long term outcome, and would tolerate short 
term pain in order to inflict tough love elsewhere in the economy. however, just as comcast 
didn't like being the only operator whose DNSSEC validation was causing nasa.gov not to 
resolve during a high-profile landing on some asteroid somewhere, it's also the case that no 
operator can afford to take phone calls and trouble reports from large numbers of customers 
at once.

> I think for all practical purposes this situation is a great example of the
> “Prisoners Dilemma” as there is no way to educate the people writing the
> crap software as they are insulated by multiple layers of protection.

i agree with this analysis.

arguably, the moment we all agreed that DNSSEC's only purpose was to cause more 
resolution failures more often for more and new reasons, we ought to have said it can't be 
deployed and shouldn't be designed at all. i'm glad we did the foolish thing and kept going, 
though.

-- 
P. Vixie

---

From: Jared Mauch <[email-masked]>
Date: Mon, 28 Dec 2015 14:36:11 -0500

> On Dec 28, 2015, at 2:30 PM, Paul Vixie <[email-masked]> wrote:
> 
> arguably, the moment we all agreed that DNSSEC's only purpose was to cause more resolution failures more often for more and new reasons, we ought to have said it can't be deployed and shouldn't be designed at all. i'm glad we did the foolish thing and kept going, though.
> 

This reiterates to me the need for me to complete the backend tooling for diagnosing DNS resolver issues.  Having something that detects if a server is doing minimization will be helpful to understand client behaviors.

- Jared