Subject: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-refuse-any-01.txt

From: "Joe Abley" <[email-masked]>
Date: Mon, 12 Oct 2015 17:20:57 -0400

New text added following review by Evan Hunt (on this list) and David 
Lawrence (at dns-oarc in Montréal, I think).

Forwarded message:

> From: [email-masked]
> To: Marek Majkowski <[email-masked]>, Joe Abley 
> <[email-masked]>, Olafur Gudmundsson <[email-masked]>
> Subject: New Version Notification for 
> draft-jabley-dnsop-refuse-any-01.txt
> Date: Mon, 12 Oct 2015 14:19:42 -0700
>
>
> A new version of I-D, draft-jabley-dnsop-refuse-any-01.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
>
> Name:		draft-jabley-dnsop-refuse-any
> Revision:	01
> Title:		Providing Minimal-Sized Responses to DNS Queries with 
> QTYPE=ANY
> Document date:	2015-10-12
> Group:		Individual Submission
> Pages:		16
> URL:            
> https://www.ietf.org/internet-drafts/draft-jabley-dnsop-refuse-any-01.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-jabley-dnsop-refuse-any/
> Htmlized:       
> https://tools.ietf.org/html/draft-jabley-dnsop-refuse-any-01
> Diff:           
> https://www.ietf.org/rfcdiff?url2=draft-jabley-dnsop-refuse-any-01
>
> Abstract:
> The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
> The operator of an authoritative DNS server might choose not to
> respond to such queries for reasons of local policy, motivated by
> security, performance or other reasons.
>
> The DNS specification does not include specific guidance for the
> behaviour of DNS servers or clients in this situation.  This document
> aims to provide such guidance.
>
>
>
>
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

---

From: Bob Harold <[email-masked]>
Date: Tue, 13 Oct 2015 13:30:42 -0400

>> aims to provide such guidance.
In general, the draft looks good to me.  Minor changes suggested:

Section 4 includes:
"1.  A DNS responder may choose to search for an owner name that matches
the QNAME and, if that name owns multiple RRs, return just one of them."

I think "RRs" should be "RRSets", as in section 5.

Section 5:
"mulitple" -> "multiple"

-- 
Bob Harold

---

From: Paul Vixie <[email-masked]>
Date: Tue, 13 Oct 2015 10:38:44 -0700

Bob Harold wrote:
>
> ...
>
> Section 4 includes:
> "1.  A DNS responder may choose to search for an owner name that
> matches the QNAME and, if that name owns multiple RRs, return just one
> of them."
>

strong +1.

-- 
Paul Vixie

---

From: "Joe Abley" <[email-masked]>
Date: Tue, 13 Oct 2015 13:39:01 -0400

> I think "RRs" should be "RRSets", as in section 5.

Thanks for the review, fixed for the next rev.

Joe

---

From: Evan Hunt <[email-masked]>
Date: Tue, 13 Oct 2015 18:28:05 +0000

Hi Joe,

I think you need some more text in the description of pick-one-rrset,
something like:

  A DNS responder which receives an ANY query MAY decline to provide
  a complete response, and MAY instead choose to return only one of
  the the RRsets present at the node specified in QNAME, and the
  associated RRSIGs if any.

  If this approach is chosen, the following limitations apply:

   - If there is an NS, CNAME, or DNAME RRset present, then the
     responder MUST return those RRsets. (Note that DNAME can
     coexist with NS; if this is the case, both RRsets MUST be
     returned.) *

   - Otherwise, when multiple RRsets exist, the responder SHOULD
     select an RRset to return using a deterministic mechanism,
     so that subsequent queries of type ANY to the same server will
     continue to receive the same data so long as the contents of
     the node remain unchanged.  For example, the responder MAY
     choose the smallest RRset, in order to reduce the amplification
     potential of a type ANY query.

   - The responder MUST NOT choose to return an RRset of type RRSIG,
     but MUST include the covering RRSIG RRs for whichever RRset is
     chosen.

I'd suggest breaking this into a separate subsection of section 5.

I would also mention in security considerations that synthesizing
responses from a signed zone requires the private signing key to be online
and available to every responder; offline signing, or signing on the master
server only, are not possible.

* I'm not completely certain DNAME needs to be mentioned in the first
  bullet point, but I'm concerned there may be unintended consequences
  if it's present but omitted.)

--
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Evan Hunt <[email-masked]>
Date: Tue, 13 Oct 2015 20:54:27 +0000

Belated thought: In the text about synthesized responses, I think you
should specifically mention that if the responder would normally have
returned a delegation, a CNAME, a DNAME, or an NXDOMAIN, then it MUST
still do so.

That's implied by the final paragraph of section 5, but IMHO it ought
to be explicit.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 13 Oct 2015 22:10:39 +0100

>   associated RRSIGs if any.
Fine

>      coexist with NS; if this is the case, both RRsets MUST be
Having DNAME and NS below a zone apex is non-sensical as both are
"delegation records" i.e.
NS says where to find more specific name,
DNAME how to write a more specific name to another name.

NS and DNAME can co-exist at zone apex, and if the ANY query is for
the apex then it should not matter which RRset is returned from the APEX is
returned.
If this is a delegation point I think the server SHOULD return a referral,
i.e. NS record in Authority section.

For names where there is a CNAME either the CNAME is the only RRset or
there is a NSEC/NSEC3 RRset
I think for backwards compatibility CNAME should be returned in this case.

> This is an over specific recommendation and can not be enforced,
think about the case where an operator uses any-cast and different software
running on
various servers.
IMHO there is nothing wrong with picking always the same one or return
random one,
I think returning NSEC in answer section is fine for online signed zones if
there is no HINFO record, with the
exception of names where there is CNAME.
Similarly if there is a HINFO record it MAY take precedence over any other
records by the selection algorithms.

>      but MUST include the covering RRSIG RRs for whichever RRset is
Fine.

> server only, are not possible.

Is reference to RFC4770 security considerations good enough  ?

>   if it's present but omitted.)

see above.

Olafur

---

From: Evan Hunt <[email-masked]>
Date: Tue, 13 Oct 2015 22:00:57 +0000

> DNAME how to write a more specific name to another name.

It's legal, though.

> the apex then it should not matter which RRset is returned from the APEX is

That's why I qualified this point -- I'm not certain anything would
break if you chose to omit a DNAME; I'm just concerned that something
might.

In any case, I do think an ANY query for a zone apex should always
return the NS.

> i.e. NS record in Authority section.

Agreed.

> I think for backwards compatibility CNAME should be returned in this case.

Agreed here too.

> think about the case where an operator uses any-cast and different software

It doesn't need to be enforced, I suggested it as a SHOULD. I think
it's better if the same server (physical server, that is, not anycast
address) behaves consistently and predictably. I don't care what
selection algorithm is used by any implementation, I just don't
think randomness is desirable.

Choosing the smallest RRset, as you suggested, is a perfectly fine
option.

> records by the selection algorithms.

Good point.

> Is reference to RFC4770 security considerations good enough  ?

Sorry, which RFC?  "vCard Extentions for Instant Messaging" doesn't
seem likely to be what you meant here, but my brain is failing to
figure it out from context.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 14 Oct 2015 09:49:59 +0100

On Tue, Oct 13, 2015 at 11:00 PM, Evan Hunt <[email-masked]> wrote:

> On Tue, Oct 13, 2015 at 10:10:39PM +0100, Ólafur Gušmundsson wrote:
>
>
Sorry for the typo : RFC4470

  Minimally Covering NSEC Records and DNSSEC On-line Signing

Olafur

---

From: Evan Hunt <[email-masked]>
Date: Wed, 14 Oct 2015 15:21:12 +0000

>   Minimally Covering NSEC Records and DNSSEC On-line Signing

Ah, thanks. Yes, the first and second points mentioned in the security
considerations there are both applicable.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 20 Oct 2015 09:47:52 +0000

I have a strong objection to this document.

In the introduction is it said:

"The DNS specification [RFC1034] [RFC1035] does not include specific
   guidance for the behaviour of DNS servers or clients in this
   situation.  This document aims to provide such guidance."

It is true that the original documents did not give specific rules for
"ANY".   But the original documents rarely gave specific rules for any
features of the DNS.

Over the years many implementations and operations set-ups have handled
ANY queries.  Up until recently they have all done so consistently and in
a manner in conflict with this document.  When an authoritative server
received a ANY query for a domain name, all of the RRsets available for
the name were included in the response.  In recursive servers, whatever
sets were in hand were returned, if none, a lookup was done to gain as
many records as came available.

I don't see the justification (that being scant documentation) for
re-defining the expectation of what happens in response to an ANY query as
being sufficient to redefine actions.  Merely relying on the paucity of
words in an original definition, and claiming "any" does not mean "all"
is, to me, "just playing with words."

OTOH, I appreciate the concern over ANY queries.  And in May one DNS
operator ceased behaving as was the long-term tradition (without notice).

I propose two criteria for breaking from tradition.  One is sufficient
notice (not necessarily from the operator, an RFC on this would do),
meaning that there is a defined notice to "fallback" to another approach.
Two is a response that is explicitly signaling that the source is not
going to answer ANY queries in the traditional manner.  In my opinion,
co-opting a rarely used record is akin to co-opting the TXT record, a
practice that has been traditionally frowned upon.

There are private types available.  While these do not have an explicit
signal of "why" they do not co-opt an otherwise defined record.

Gaining a new RR type is not difficult, not in the wake of the SPF vs. TXT
record debacle that has played out over the past decade or so.

In designing a protocol, it is important that the two communicating end
points have appropriate expectations and that is what my complaint is
centered upon.  Co-opting a record without warning disrupts legacy
implementations - in this case especially needlessly as there has been
little if any diversion in implmentations despite the scant words in the
RFCs.  Co-opting also causes future implementations some uncertainty in
diving whether the "old" meaning of the record is intended or if the
"newer" meaning is intended.

On 10/12/15, 23:20, "DNSOP on behalf of Joe Abley" <[email-masked]
on behalf of [email-masked]> wrote:

>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop