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

[Stephane Bortzmeyer]

On Fri, Nov 25, 2016 at 07:50:48PM -0500,
 tjw ietf  wrote 
 a message of 114 lines which said:

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

Since we'll apparently have one more iteration of the draft, one small
detail. The draft says:

> The HINFO RRTYPE is believed to be rarely used in the DNS at the
> time of writing, based on observations made both at recursive
> servers and authority servers.

If you have access to a passive DNS database, you can check by
yourself. Indeed, the vast majority of HINFO comes from Cloudflare
domains. In .fr (3 million domains), DNSDB found only 54
non-Cloudflare HINFO. My favorites are (a former employer):

iiel.iie.cnam.fr. IN HINFO "VS3100" "VMS-6.2"
wotan.iie.cnam.fr. IN HINFO "AlphaServer-1000" "OSF"

I strongly doubt there is really a VaxStation 3100 still in operation
:-)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[神明達哉]

Sorry for the delayed response.  I've been unusually busy for these
several weeks...

At Sat, 3 Dec 2016 12:44:47 -0500,
Olafur Gudmundsson  wrote:

> > I've read the 03 version of the document.  I do *not* think this is
> > ready for publication since I still believe we should not abuse HINFO
> > for this purpose as I argued a year ago:
> > https://www.ietf.org/mail-archive/web/dnsop/current/msg16118.html
> > (But other than that I think the document is quite well written).
>
> We have some implementation experience with this and the fact that we return a
> Record that is parsed and displayed in human readable format has proven 
> valuable in
> dealing with “interoperability” problems.
> A number of “abusers” of ANY queries have seen this read the draft and said
>- yep I should have a fallback
> or- asking for exactly what I need is better way
>
> So what other RFC1034/5 defined type are you willing to throw under the bus?

(If synthesizing an otherwise-non-existent type of RRset is non
debatable) personally, I'd rather propose introducing a new RR type
specifically for this purpose so it's guaranteed to not cause
conflict or confusion.  "human readability with currently available
tools (e.g., a currently distributed version of dig)" is a well-known
excuse in cases like this or TXT abusers, but at least for a standard
track IETF protocol I believe we should take a more long-term view;
once we define the new type it won't take too long until common tools
like dig, drill, etc will catch up.  Until then relatively skilled
users can google what 'TYPE259' means and finds it's returned as
defined in RFC83xx.


> > Some specific comments on the text:
> >
> > - Section 3
> >
> >   1.  A DNS responder can choose to select one or subset of RRSets at
> >   the QNAME.
> >
> >  'one or subset of RRSets' sounds a bit awkward to me, partly because
> >  'a subset of RRSets' should include 'one of RRSets' and can thus be
> >  redundant, and partly because 'subset of RRSets" might sound related
> >  to 'subset of an RRSet' (it's actually "a subset of set of RRSets").
> >  So I'd suggest changing this one of the following:
> >  - "one or a few of RRSets (but not all of them)"
> >  - "one or a few of RRSets"
> >  - "a subset of RRSets"
> >  I personally prefer the first most although it may be too verbose.
> >
> I  think the best way to address this to be consistent with Section 4 is to 
> say
> “one RRset” and be done with it

Works for me.  (But some others might want to avoid to be too
restrictive).
>
> > - Section 4
> >
> >   If the DNS query includes DO=1 and the QNAME corresponds to a zone
> >   that is known by the responder to be signed, a valid RRSIG for the
> >   RRSets in the answer (or authority if answer is empty) section MUST
> >   be returned.
> >
> >  Does this also apply to a synthesized HINFO (if so, by dynamically
> >  signing it?)?
> >
> Yes

Okay.  My objection to using HINFO in the first place aside, as long
as this hack is documented I think the doc should explicitly note it.

--
JINMEI, Tatuya

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

On 08-12-16 00:04, Stephane Bortzmeyer wrote:
> On Tue, Nov 29, 2016 at 09:10:02AM +0100,
>  Matthijs Mekking  wrote 
>  a message of 196 lines which said:
> 
>>> This is operational choice, if we call that out do we also call
>>> out that answer may depend on address, TSIG etc ?
>>
>> No, just TCP :)
> 
> Why not also when cookies are used? Like TCP, they protect against
> reflection attacks.

As Joe pointed out earlier, the document already does not prohibit you
from doing so. But some of us would like to have that explicitly called
out: that you can still implement this feature *and* do something else
under some conditions. The example given is allowing original behavior
when the transport protocol is TCP, but obviously it is not limited to
just that one example.

Best regards,
  Matthijs


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

The draft seems almost ready to go to the IETF. However, there are still 
a few areas that need work.


As others have discussed, the filename really has to change. Like it or 
not, RFCs get associated with the last draft name that produced it, and 
"refuse-any" is just wrong for this document.


The current title, "Providing Minimal-Sized Responses to DNS Queries 
with QTYPE=ANY", makes sense to DNS experts but probably not to anyone 
else. Proposed change: "Providing Minimal-Sized Responses to DNS Queries 
That Have a Query Type of 'ANY'". It's longer, but it will make much 
more sense to others.


The organization of the document makes it hard for an implementor to 
decide which text is about the first option (send back one or a subset 
of real RRs), which is about the second option (send back a synthesized 
HINFO), and which refers to both. This can be alleviated by reorganizing 
the existing text.
  - Move "This proposal specifies two different modes of behaviour by 
DNS..." and the two bullet points out of Section 3 and into the top of 
Section 4.
  - Split Section 4 into three subsections: "4.1 Select a Subset", "4.2 
Synthesize an HINFO Record", and "4.3 Topics Relevant to Either 
Deployment Option".

  - Move the text from Section 6 into the new Section 4.2.

On the topic of HINFO versus another RRtype, I think HINFO is fine. The 
fact that some servers use HINFO is a red herring: the answers described 
in this document only are returned for QTYPE=ANY, not for QTYPE=HINFO. 
Having said that, the following text from Section 6 seems wrong: 
"Authority-server operators who serve zones that rely upon conventional 
use of the HINFO RRTYPE MAY sensibly choose not to deploy the mechanism 
described in this document or select another type". A much more logical 
approach would be "Authority-server operators who serve zones that rely 
upon conventional use of the HINFO RRTYPE SHOULD choose to respond with 
a subset of the RRtypes, as described in Section 4.1".


The text "Except as described in this section, the DNS responder MUST 
follow the standard algorithms when constructing a response" is unclear 
unless you call out RFC 1035.


In Section 5, it is not clear why an initiator MAY cache the response. I 
believe it SHOULD cache the response as a normal DNS response.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Stephane Bortzmeyer  wrote:
>
> Why not also when cookies are used? Like TCP, they protect against
> reflection attacks.

My reason for deploying minimal-any was not for direct reflection
attacks, because RRL already deals with direct reflection attacks.

I wanted to avoid sending truncated UDP responses to legit resolvers.

When lots of legit recursive resolvers are being attacked with ANY queries
for one of my zones, I don't want them to hammer my authoritative servers
with TCP connections. So, minimal-any means they go away happy with a
small answer, and everything stays on UDP.

Eventually I expect legit resolvers to deploy cookies, and I still want
to send them small answers to avoid TCP when an ANY attack happens.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Forties, Cromarty, Forth: Southwest 5 or 6, decreasing 4 at times. Slight or
moderate, occasionally rough at first in Forties. Fair. Good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Stephane Bortzmeyer]

On Tue, Nov 29, 2016 at 09:10:02AM +0100,
 Matthijs Mekking  wrote 
 a message of 196 lines which said:

> > This is operational choice, if we call that out do we also call
> > out that answer may depend on address, TSIG etc ?
> 
> No, just TCP :)

Why not also when cookies are used? Like TCP, they protect against
reflection attacks.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

- Original Message -
> From: "神明達哉" <jin...@wide.ad.jp>
> To: "tjw ietf" <tjw.i...@gmail.com>
> Cc: "dnsop" <dnsop@ietf.org>
> Sent: Friday, 2 December, 2016 20:55:15
> Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

> - Section 3
> 
>   1.  A DNS responder can choose to select one or subset of RRSets at
>   the QNAME.
> 
>  'one or subset of RRSets' sounds a bit awkward to me, partly because
>  'a subset of RRSets' should include 'one of RRSets' and can thus be
>  redundant, and partly because 'subset of RRSets" might sound related
>  to 'subset of an RRSet' (it's actually "a subset of set of RRSets").
>  So I'd suggest changing this one of the following:
>  - "one or a few of RRSets (but not all of them)"
>  - "one or a few of RRSets"
>  - "a subset of RRSets"
>  I personally prefer the first most although it may be too verbose.


Just a nitpick about using "subset" in general - it should be either
"non-empty subset" (or something else) so I like "one or a few" more.

Cheers,
Ondrej

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

>So what other RFC1034/5 defined type are you willing to throw under the bus? 

Here's a few, all well defined and very dead, with what's in the rrdata:

MD (3) hostname
MF (4) hostname
MB (7) hostname that's interpreted as a mailbox
MG (8) hostname that's interpreted as a mailbox
MR (9) hostname that's interpreted as a mailbox

and of course

SINK (40) the kitchen sink

(I suspect Don intended SINK as an April 1 RFC, but whether or not he
did, it's got a type number.)

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

> On Dec 2, 2016, at 2:55 PM, 神明達哉  wrote:
> 
> At Fri, 25 Nov 2016 19:50:48 -0500,
> tjw ietf  wrote:
> 
>> 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.
> 
> I've read the 03 version of the document.  I do *not* think this is
> ready for publication since I still believe we should not abuse HINFO
> for this purpose as I argued a year ago:
> https://www.ietf.org/mail-archive/web/dnsop/current/msg16118.html
> (But other than that I think the document is quite well written).
> 

We have some implementation experience with this and the fact that we return a 
Record that is parsed and displayed in human readable format has proven 
valuable in 
dealing with “interoperability” problems. 
A number of “abusers” of ANY queries have seen this read the draft and said 
   - yep I should have a fallback
or- asking for exactly what I need is better way 

So what other RFC1034/5 defined type are you willing to throw under the bus? 
Paul Wouters accused us of doing in at the DNS-Oarc workshop in Montreal), 
these exchanges from the Q/A part of the presentation are enlightening
https://youtu.be/Gt9VUPDoZk0?t=1h24m53s



> As for renaming the file, I don't have a strong opinion, but we expect
> a bigger issue like HINFO can lead to more revisions, it would be good
> to rename it at this opportunity in order to avoid confusion for
> future readers.
> 

I’m hoping the version coming after this WGLC be advanced to the IESG/IETF LC 
so renaming at this point serves limited purpose. 

> Some specific comments on the text:
> 
> - Section 3
> 
>   1.  A DNS responder can choose to select one or subset of RRSets at
>   the QNAME.
> 
>  'one or subset of RRSets' sounds a bit awkward to me, partly because
>  'a subset of RRSets' should include 'one of RRSets' and can thus be
>  redundant, and partly because 'subset of RRSets" might sound related
>  to 'subset of an RRSet' (it's actually "a subset of set of RRSets").
>  So I'd suggest changing this one of the following:
>  - "one or a few of RRSets (but not all of them)"
>  - "one or a few of RRSets"
>  - "a subset of RRSets"
>  I personally prefer the first most although it may be too verbose.
> 
I  think the best way to address this to be consistent with Section 4 is to say 
“one RRset” and be done with it 

> - Section 4
> 
>   A DNS responder which receives an ANY query MAY decline to provide a
>   conventional response, or MAY instead send a response with a single
>   RRSet in the answer section.
> 
>  "a single RRSet" doesn't seem to be fully consistent of "one or
>  subset of RRSets" stated in the preceding section (see the previous
>  bullet).
> 
see above 

> - Section 4
> 
>   If the DNS query includes DO=1 and the QNAME corresponds to a zone
>   that is known by the responder to be signed, a valid RRSIG for the
>   RRSets in the answer (or authority if answer is empty) section MUST
>   be returned.
> 
>  Does this also apply to a synthesized HINFO (if so, by dynamically
>  signing it?)?
> 
Yes 

> - Section 6
> 
>   In the case where a zone that contains HINFO RRSets is served from an
>   authority server that does not provide conventional ANY responses.
> 
>  This may be just because of my English literacy, but on my first
>  read it was quite confusing to me; I first thought the second 'that'
>  was a relative pronoun, which would make this text an incomplete
>  sentence.  If there was a comma after 'server' that would be more
>  readable for me.

Joe and I will take a stab of making that clearer 

> 
> - Section 7: a minor typo, s/implimentations/implementations/
> 
>   not return all RRSIGS.  In the wild there are implimentations that
> 
Yep need to fix that 
Thank you for your excellent review. 

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Darcy Kevin (FCA)]

Your English literacy is fine. I believe sentences which are logically 
connected into one super-sentence have been accidentally severed into one 
sentence and one non-sentence.

That super-sentence would be:

"In the case where a zone that contains HINFO RRSets is served from an 
authority server that does not provide conventional ANY responses, it is 
possible that the HINFO RRSet in an ANY response, once cached by the initiator, 
might suppress subsequent queries from the same initiator with QTYPE=HINFO."

This is then followed by another, largely redundant sentence:

"The use of HINFO in this proposal would hence have effectively mask [sic] the 
HINFO RRSet present in the zone."

I suggest a rewording that collapses the whole paragraph into a single, tighter 
sentence:

"The HINFO RRset provided as an ANY response, as per this specification, when 
cached by the initiator, may suppress subsequent QTYPE=HINFO queries for the 
same QNAME, thus effectively masking, from that initiator, an explicit HINFO 
RRset present in the zone."


- Kevin

-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of 
Sent: Friday, December 02, 2016 2:55 PM
To: tjw ietf
Cc: dnsop
Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-refuse-any

At Fri, 25 Nov 2016 19:50:48 -0500,
tjw ietf <tjw.i...@gmail.com> wrote:

> 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.

I've read the 03 version of the document.  I do *not* think this is ready for 
publication since I still believe we should not abuse HINFO for this purpose as 
I argued a year ago:
https://www.ietf.org/mail-archive/web/dnsop/current/msg16118.html
(But other than that I think the document is quite well written).

As for renaming the file, I don't have a strong opinion, but we expect a bigger 
issue like HINFO can lead to more revisions, it would be good to rename it at 
this opportunity in order to avoid confusion for future readers.

Some specific comments on the text:

- Section 3

   1.  A DNS responder can choose to select one or subset of RRSets at
   the QNAME.

  'one or subset of RRSets' sounds a bit awkward to me, partly because
  'a subset of RRSets' should include 'one of RRSets' and can thus be
  redundant, and partly because 'subset of RRSets" might sound related
  to 'subset of an RRSet' (it's actually "a subset of set of RRSets").
  So I'd suggest changing this one of the following:
  - "one or a few of RRSets (but not all of them)"
  - "one or a few of RRSets"
  - "a subset of RRSets"
  I personally prefer the first most although it may be too verbose.

- Section 4

   A DNS responder which receives an ANY query MAY decline to provide a
   conventional response, or MAY instead send a response with a single
   RRSet in the answer section.

  "a single RRSet" doesn't seem to be fully consistent of "one or
  subset of RRSets" stated in the preceding section (see the previous
  bullet).

- Section 4

   If the DNS query includes DO=1 and the QNAME corresponds to a zone
   that is known by the responder to be signed, a valid RRSIG for the
   RRSets in the answer (or authority if answer is empty) section MUST
   be returned.

  Does this also apply to a synthesized HINFO (if so, by dynamically
  signing it?)?

- Section 6

   In the case where a zone that contains HINFO RRSets is served from an
   authority server that does not provide conventional ANY responses.

  This may be just because of my English literacy, but on my first
  read it was quite confusing to me; I first thought the second 'that'
  was a relative pronoun, which would make this text an incomplete
  sentence.  If there was a comma after 'server' that would be more
  readable for me.

- Section 7: a minor typo, s/implimentations/implementations/

   not return all RRSIGS.  In the wild there are implimentations that

--
JINMEI, Tatuya

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

>ready for publication since I still believe we should not abuse HINFO
>for this purpose ...

I have to agree.  I have DNS servers that send actual useful HINFO records.

If you're going to abuse an existing rrtype, an obvious candidate is
NULL (type 10) which has been experimental for 30 years and has never
been used for anything since some pre-RFC 1035 experiments.  

Or burn a code point and invent a NOTANY record.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[神明達哉]

At Fri, 25 Nov 2016 19:50:48 -0500,
tjw ietf  wrote:

> 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.

I've read the 03 version of the document.  I do *not* think this is
ready for publication since I still believe we should not abuse HINFO
for this purpose as I argued a year ago:
https://www.ietf.org/mail-archive/web/dnsop/current/msg16118.html
(But other than that I think the document is quite well written).

As for renaming the file, I don't have a strong opinion, but we expect
a bigger issue like HINFO can lead to more revisions, it would be good
to rename it at this opportunity in order to avoid confusion for
future readers.

Some specific comments on the text:

- Section 3

   1.  A DNS responder can choose to select one or subset of RRSets at
   the QNAME.

  'one or subset of RRSets' sounds a bit awkward to me, partly because
  'a subset of RRSets' should include 'one of RRSets' and can thus be
  redundant, and partly because 'subset of RRSets" might sound related
  to 'subset of an RRSet' (it's actually "a subset of set of RRSets").
  So I'd suggest changing this one of the following:
  - "one or a few of RRSets (but not all of them)"
  - "one or a few of RRSets"
  - "a subset of RRSets"
  I personally prefer the first most although it may be too verbose.

- Section 4

   A DNS responder which receives an ANY query MAY decline to provide a
   conventional response, or MAY instead send a response with a single
   RRSet in the answer section.

  "a single RRSet" doesn't seem to be fully consistent of "one or
  subset of RRSets" stated in the preceding section (see the previous
  bullet).

- Section 4

   If the DNS query includes DO=1 and the QNAME corresponds to a zone
   that is known by the responder to be signed, a valid RRSIG for the
   RRSets in the answer (or authority if answer is empty) section MUST
   be returned.

  Does this also apply to a synthesized HINFO (if so, by dynamically
  signing it?)?

- Section 6

   In the case where a zone that contains HINFO RRSets is served from an
   authority server that does not provide conventional ANY responses.

  This may be just because of my English literacy, but on my first
  read it was quite confusing to me; I first thought the second 'that'
  was a relative pronoun, which would make this text an incomplete
  sentence.  If there was a comma after 'server' that would be more
  readable for me.

- Section 7: a minor typo, s/implimentations/implementations/

   not return all RRSIGS.  In the wild there are implimentations that

--
JINMEI, Tatuya

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Niall O'Reilly]

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


signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

On 28-11-16 16:43, Olafur Gudmundsson wrote:
> 
>> On Nov 28, 2016, at 5:25 AM, Matthijs Mekking > > 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 ? 

No, just TCP :)



>> 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 ? 


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

>>
>> And I prefer `minimal-any` over `refuse-any`, agreeing with the logic
>> Ondrej provided.
>>
> 
> I do not care 
> 
>> Best regards,
>>  Matthijs
> thanks 
> Olafur
> 
>>
>> 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.
>>>
>>> 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
>>>
>>>
>>>
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org 
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 
> 

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

[Matthijs Mekking]

On 28-11-16 16:50, Tony Finch wrote:
> Olafur Gudmundsson  wrote:
> 
>> 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.
> 
> 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

> 
> Tony.
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Edward Lewis]

On 11/28/16, 10:43, "DNSOP on behalf of Olafur Gudmundsson" 
 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.



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On 28 Nov 2016, at 7:50, Tony Finch wrote:

> Olafur Gudmundsson  wrote:
>
>> 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.
>
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Olafur Gudmundsson  wrote:

> 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.

I think the spec should allow any of these behaviours.

Tony.
-- 
f.anthony.n.finch    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.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

> On Nov 28, 2016, at 5:25 AM, Matthijs Mekking  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 

> Best regards,
>  Matthijs
thanks 
Olafur

> 
> 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.
>> 
>> 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
>> 
>> 
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

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

On 28-11-16 13:57, Tony Finch wrote:

Matthijs Mekking  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 :-)


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


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.



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Tony Finch]

Matthijs Mekking  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    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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Matthijs Mekking]

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.

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



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Ondřej Surý]

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:ondrej.s...@nic.czhttps://nic.cz/
 

- Original Message -
> From: "tjw ietf" 
> To: "dnsop" 
> 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.
> 
> 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/ |
> 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
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop