Subject: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

From: tjw ietf <[email-masked]>
Date: Fri, 25 Nov 2016 19:50:48 -0500

All

The authors have addressed all the outstanding issues with this draft, and
the chairs feel this is ready for Working Group Last Call.

There has been one issue raised which we feel the working group may have
some opinion on this.

Ondrej Sury raised this point:

There's a small procedural thing - the last name of the draft
appears on both datatracker.i.o and tools.i.o.  I believe it
would be better to reupload the draft with name changed to

draft-ietf-dnsop-minimal-any

to prevent the people who might thing the name of the draft
bears any significance.  As this requires almost no effort
I think it would be better to this now than fend of the
questions "why is this refuse-any while it doesn't refuse
ANY" later.

The authors and the Chairs support this in principle, but the working group
should comment on this during the WGLC process.

---------
This starts a Working Group Last Call for
draft-ietf-dnsop-refuse-any

Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

Please review the draft and offer relevant comments. Also, if someone feels
the document is *not* ready for publication, please speak out with your
reasons.

*Also*, if you have any opinion on changing the document named from
'refuse-any' to 'minimal-any', please speak out.

This starts a two week Working Group Last Call process, and ends on 10
December, 2016

thanks
tim

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 28 Nov 2016 09:34:28 +0100 (CET)

I don't feel very strongly about renaming the draft.  I just find a little bit
confusing and I imagine I might not be the only one who might feel that way.

One way or another I have already reviewed -03 versions of the draft and I think
it is ready for publication.

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:[email-masked]    https://nic.cz/
 --------------------------------------------

----- Original Message -----
> From: "tjw ietf" <[email-masked]>
> To: "dnsop" <[email-masked]>
> Sent: Saturday, 26 November, 2016 01:50:48
> Subject: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

> All
> 
> The authors have addressed all the outstanding issues with this draft, and the
> chairs feel this is ready for Working Group Last Call.
> 
> There has been one issue raised which we feel the working group may have some
> opinion on this.
> 
> [ https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ |
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/ ]
> 
> Please review the draft and offer relevant comments. Also, if someone feels the
> document is *not* ready for publication, please speak out with your reasons.
> 
> *Also*, if you have any opinion on changing the document named from 'refuse-any'
> to 'minimal-any', please speak out.
> 
> 
> This starts a two week Working Group Last Call process, and ends on 10 December,
> 2016
> 
> thanks
> tim
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 28 Nov 2016 11:25:11 +0100

Hi,

I have read the draft and have two comments. Both of these have been 
called out before, but I don't see them addressed in this version (-03):

1. In case of a DNS responder selecting one or a subset of the RRsets at 
the QNAME, The draft does not give clear guidance on which RRset(s) to 
pick. In previous discussions there was yes nodding to provide text that 
the RRset picking should be determinative, even perhaps providing 
guidance on the selection method to use. Such text has not made it to 
the draft yet. I am not sure if adding a single line "the RRset 
selection method SHOULD be determinative" is sufficient, or if more text 
is wanted.

2. People expressed that they would like to see ANY over TCP stick to 
the original (undefined) behavior, that is to return all RRsets at the 
QNAME. Joe replied that this is still possible with this document 
because the mechanism is "a big giant MAY", but still I think it makes 
sense to call out explicitly that the behavior MAY differ depending on 
the transport protocol.

One more nit comment, I would like to see explicitly called out in 
section 7 that "DNS implementations are free to not return all RRSIGS 
*in case QTYPE=RRSIG*".

And I prefer `minimal-any` over `refuse-any`, agreeing with the logic 
Ondrej provided.

Best regards,
   Matthijs

On 26-11-16 01:50, tjw ietf wrote:
>
> All
>
> The authors have addressed all the outstanding issues with this draft,
> and the chairs feel this is ready for Working Group Last Call.
>
> The authors and the Chairs support this in principle, but the working
> group should comment on this during the WGLC process.
>
> ---------
> Please review the draft and offer relevant comments. Also, if someone
> feels the document is *not* ready for publication, please speak out with
> your reasons.
>

---

From: Tony Finch <[email-masked]>
Date: Mon, 28 Nov 2016 12:57:32 +0000

Matthijs Mekking <[email-masked]> wrote:
>
> 1. In case of a DNS responder selecting one or a subset of the RRsets at the
> QNAME, The draft does not give clear guidance on which RRset(s) to pick.

The code in BIND just picks an arbitrary RRset, without making any effort
to be clever.

It makes an ANY query to the back end, then adds the first RRset to the
response. The data from the back end doesn't have a deterministic order.
Doing better than this would (I think) require additional methods in the
rdataset API to get the size of the RRset. Unless we use a dumb heuristic
like smallest RR TYPE number :-)

> 2. People expressed that they would like to see ANY over TCP stick to the
> original (undefined) behavior, that is to return all RRsets at the QNAME.

BIND does this.

> One more nit comment, I would like to see explicitly called out in section 7
> that "DNS implementations are free to not return all RRSIGS *in case
> QTYPE=RRSIG*".

BIND also does this.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Bailey, Fair Isle, Faeroes, Southeast Iceland: Southerly or southwesterly
veering westerly, 5 or 6, increasing 7 or gale 8. Moderate or rough, becoming
very rough. Occasional rain, then showers later, wintry in Faeroes and
Southeast Iceland. Good, occasionally poor.

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 28 Nov 2016 14:25:59 +0100

Are we still creating standards based on "BIND does this"? :p

> like smallest RR TYPE number :-)

Fair enough for reasoning not to use a determinative mechanism, but in 
that case such considerations should be added to the document IMO.

Best regards,
   Matthijs

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 28 Nov 2016 10:43:19 -0500

> On Nov 28, 2016, at 5:25 AM, Matthijs Mekking <[email-masked]> wrote:
> 
> Hi,
> 
> I have read the draft and have two comments. Both of these have been called out before, but I don't see them addressed in this version (-03):
> 
> 1. In case of a DNS responder selecting one or a subset of the RRsets at the QNAME, The draft does not give clear guidance on which RRset(s) to pick. In previous discussions there was yes nodding to provide text that the RRset picking should be determinative, even perhaps providing guidance on the selection method to use. Such text has not made it to the draft yet. I am not sure if adding a single line "the RRset selection method SHOULD be determinative" is sufficient, or if more text is wanted.

There have been some discussion on this topic, It is fair to say that there are 3 camps 
a) answer with the smallest RRSET 
b) pick one at “random"
c) select bases on what is most useful (i.e. deterministic selection) 

I would be happiest to go with b)  and add text that says that. 
> 
> 2. People expressed that they would like to see ANY over TCP stick to the original (undefined) behavior, that is to return all RRsets at the QNAME. Joe replied that this is still possible with this document because the mechanism is "a big giant MAY", but still I think it makes sense to call out explicitly that the behavior MAY differ depending on the transport protocol.

This is operational choice, if we call that out do we also call out that answer may depend on address, TSIG etc ? 

> 
> One more nit comment, I would like to see explicitly called out in section 7 that "DNS implementations are free to not return all RRSIGS *in case QTYPE=RRSIG*”.

Current text: 
   RRSIG queries have the same potential as ANY queries of generating
   large answers as well as extra work.  DNS implementations are free to
   not return all RRSIGS.  In the wild there are implimentations that
   return REFUSE, others return single RRSIG, etc.

Proposed text: 
   RRSIG queries have the same potential as ANY queries of generating
   large answers as well as extra work.  DNS implementations MAY return some but not all RRSIGS when QTYPE=RRSIG. 
   In the wild there are implimentations that
   return REFUSE, others return single RRSIG, etc.

Is this better ? 

> 
> And I prefer `minimal-any` over `refuse-any`, agreeing with the logic Ondrej provided.
> 

I do not care 

>  Matthijs
thanks 
Olafur

---

From: Tony Finch <[email-masked]>
Date: Mon, 28 Nov 2016 15:50:27 +0000

> I would be happiest to go with b)  and add text that says that.

I think the spec should allow any of these behaviours.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: Northerly or northeasterly 4 or 5, occasionally 6 at first,
becoming variable 3 or 4, then becoming southeasterly 4 or 5 later in west.
Moderate, occasionally slight in east. Showers, occasionally thundery at
first. Good, occasionally poor at first.

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 28 Nov 2016 08:18:11 -0800

> I think the spec should allow any of these behaviours.

+1. It should list all three and say that any may be used.

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Mon, 28 Nov 2016 20:00:03 +0000

On 11/28/16, 10:43, "DNSOP on behalf of Olafur Gudmundsson" <[email-masked] on behalf of [email-masked]> wrote:

b) pick one at “random"

Please don't use the word random, not even in quotes, in this context.  I suspect that somewhere along the line that a code writer will interpret that to mean a random number generator is needed.

Other than being potentially confusing nomenclature, answering at "random" is essentially how a cache answers type=any queries today.

Come to think of it, deciding which set is the smallest (on the wire) might be more tie consuming than just answering with the whole set - depending on what bottleneck you fear most that might be a consideration.  And predictive might also take too much thinkin'.

Caution: old fart's meandering text follows:

While I long prefer an explicit notice that the ANY query is being "shut down" answering with one (honest) set is no worse than being dumb enough to rely on asking a cache for "ANY".  If anyone is asking an authoritative for "ANY" at a name, they either can figure out they didn't get an "whole answer" (and then trawl through the expected type codes) or, well, just go trawling to start with.

I have in mind a use case where I ask a zone apex for ANY.  I should see a SOA, NS set, etc.  If not I obviously have a partial answer and then go trawl for the types I expect to see at an apex.  The code doing this has been tested and works, even identifying when one operator turned off ANY and then started it back up a month later.

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 29 Nov 2016 09:06:52 +0100

> I think the spec should allow any of these behaviours.

I see that a) is just an example of c), to me they are the same class of
selection method.

If the spec should allow any of these behaviours, to me it makes sense
to add a paragraph that discusses the pros and cons for one and the other.

Best regards,
  Matthijs

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 29 Nov 2016 09:10:02 +0100

On 28-11-16 16:43, Olafur Gudmundsson wrote:
> 
>> On Nov 28, 2016, at 5:25 AM, Matthijs Mekking <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Hi,
>>
>> 1. In case of a DNS responder selecting one or a subset of the RRsets
>> at the QNAME, The draft does not give clear guidance on which RRset(s)
>> to pick. In previous discussions there was yes nodding to provide text
>> that the RRset picking should be determinative, even perhaps providing
>> selection method SHOULD be determinative" is sufficient, or if more
>> text is wanted.
> 

No, just TCP :)

>> *in case QTYPE=RRSIG*”.

Yes, although if I may make also an suggestion:

    RRSIG queries have the same potential as ANY queries of generating
    large answers as well as extra work. DNS implementations MAY
    choose to not return all RRSIG records when QTYPE=RRSIG.

Best regards,
  Matthijs

>> [email-masked] <mailto:[email-masked]>

---

From: "Niall O'Reilly" <[email-masked]>
Date: Tue, 29 Nov 2016 16:58:10 +0000

On 28 Nov 2016, at 20:00, Edward Lewis wrote:

> Please don't use the word random, not even in quotes, in this context.
  +1

  A good word might be "arbitrary" (NL: willekeurig).

  Niall