[DNSOP] draft-ietf-dnsop-refuse-any

[Paul Wouters]

draft-ietf-dnsop-refuse-any

Didnt this reach the end of WGLC ?

The draft expired.

Don't we all really still want this?

Paul

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any

[Joe Abley]

Hi Paul,

This draft is waiting for me to commit changes to and submit a revised draft.

My co-author and our esteemed chairs have been badgering me with full 
efficiency, and the delay is all my fault. I have some time this weekend so 
long as I don't have to deal with another metre of snow, and I aim to get it 
done before next week.


Joe

> On Feb 9, 2018, at 15:30, Paul Wouters  wrote:
> 
> 
> draft-ietf-dnsop-refuse-any
> 
> Didnt this reach the end of WGLC ?
> 
> The draft expired.
> 
> Don't we all really still want this?
> 
> Paul
> 
> ___
> 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] draft-ietf-dnsop-refuse-any

[Paul Wouters]

> On Feb 9, 2018, at 20:22, Joe Abley  wrote:
> 
> Hi Paul,
> 
> This draft is waiting for me to commit changes to and submit a revised draft.
> 
>  I aim to get it done before next week.

Awesome! Thanks!

Paul


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

Re: [DNSOP] draft-ietf-dnsop-refuse-any

[Tony Finch]

Paul Wouters  wrote:
> > On Feb 9, 2018, at 20:22, Joe Abley  wrote:
> >
> >  I aim to get it done before next week.
>
> Awesome! Thanks!

And from me too - I was wondering about this draft the other day,
so thanks Paul for prodding before I got a round tuit.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Fair Isle, Faeroes: Cyclonic, mainly south or southeast for a time, 5 to 7,
increasing gale 8 or severe gale 9 for a time. Very rough or high. Wintry
showers. Moderate or poor.

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any

[Joe Abley]

On 12 Feb 2018, at 06:30, Tony Finch  wrote:

> Paul Wouters  wrote:
>>> On Feb 9, 2018, at 20:22, Joe Abley  wrote:
>>> 
>>> I aim to get it done before next week.
>> 
>> Awesome! Thanks!
> 
> And from me too - I was wondering about this draft the other day,
> so thanks Paul for prodding before I got a round tuit.

For various reasons I didn't in fact get it done before this week, but it's 
definitely on the to-do list.


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

Re: [DNSOP] draft-ietf-dnsop-refuse-any

[tjw ietf]

The Badgering will continue!

We're waiting because the chairs feel we can do a short WGLC and have this
ready to go before London.

Thank you all for adding pressure.

Tim

On Mon, Feb 12, 2018 at 10:41 AM, Joe Abley  wrote:

> On 12 Feb 2018, at 06:30, Tony Finch  wrote:
>
> > Paul Wouters  wrote:
> >>> On Feb 9, 2018, at 20:22, Joe Abley  wrote:
> >>>
> >>> I aim to get it done before next week.
> >>
> >> Awesome! Thanks!
> >
> > And from me too - I was wondering about this draft the other day,
> > so thanks Paul for prodding before I got a round tuit.
>
> For various reasons I didn't in fact get it done before this week, but
> it's definitely on the to-do list.
>
>
> Joe
> ___
> 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] draft-ietf-dnsop-refuse-any and QTYPE=RRSIG

[Tony Finch]

Last weekend one of our authoritative name servers
(authdns1.csx.cam.ac.uk) suffered a series of DoS attacks which made it
rather unhappy. Over the last week I have developed a patch for BIND to
implement draft-ietf-dnsop-refuse-any which should allow us to handle
ANY flood attacks better. http://fanf.livejournal.com/140566.html

I still have a potential problem with RRSIG queries, which work a lot like
ANY queries. Cloudflare's approach is to simply refuse them, which makes a
lot of sense because RRSIG queries don't have the same interop concerns as
ANY queries. However, in an attack like the ones we had last weekend where
the queries arrived at our authoritative servers from lots of real
recursive servers, a refusal will cause retries and make the attack worse.

Would it be reasonable as an alternative to follow the refuse-any approach
and just return the RRSIG(s) for one RRset? If so, I think this suggestion
should be included in the draft.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Thames, Dover: Southwest 5 to 7, occasionally gale 8 later, perhaps severe
gale 9 later. Moderate, occasionally rough later. Occasional rain or drizzle.
Moderate or good, occasionally poor.

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

[DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Ray Bellis]

Having looked at this a few months ago when one of our partners was
(briefly) returning NOTIMP for ANY queries, I find myself wondering why
this isn't discussed in the draft?

The draft does talk about *new* RCODEs, but not existing ones.

My reading of RFC 1035 is that it would be a perfectly appropriate
response from a server that doesn't support ANY.

Unfortunately the retry semantics of DNS are not well specified and
therefore implementation differences may occur.  If as a result NOTIMP
is really not usable then IMHO this should also be documented.

Ray

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any and QTYPE=RRSIG

[Mark Andrews]

In message , Tony Fi
nch writes:
> Last weekend one of our authoritative name servers
> (authdns1.csx.cam.ac.uk) suffered a series of DoS attacks which made it
> rather unhappy. Over the last week I have developed a patch for BIND to
> implement draft-ietf-dnsop-refuse-any which should allow us to handle
> ANY flood attacks better. http://fanf.livejournal.com/140566.html
> 
> I still have a potential problem with RRSIG queries, which work a lot like
> ANY queries. Cloudflare's approach is to simply refuse them, which makes a
> lot of sense because RRSIG queries don't have the same interop concerns as
> ANY queries. However, in an attack like the ones we had last weekend where
> the queries arrived at our authoritative servers from lots of real
> recursive servers, a refusal will cause retries and make the attack worse.
> 
> Would it be reasonable as an alternative to follow the refuse-any approach
> and just return the RRSIG(s) for one RRset? If so, I think this suggestion
> should be included in the draft.
 
Yes, for both SIG and RRSIG.  They are not useful queries on their
own.  I am discounting the corner case of a non DNSSEC aware recursive
server in front of a validating client as that does not work reliably
with DNS loose coherency.

Mark

> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Thames, Dover: Southwest 5 to 7, occasionally gale 8 later, perhaps severe
> gale 9 later. Moderate, occasionally rough later. Occasional rain or drizzle.
> Moderate or good, occasionally poor.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any and QTYPE=RRSIG

[Tony Finch]

Mark Andrews  wrote:
> In message , Tony 
> Fi
> nch writes:
> >
> > Would it be reasonable as an alternative to follow the refuse-any
> > approach and just return the RRSIG(s) for one RRset? If so, I think
> > this suggestion should be included in the draft.
>
> Yes, for both SIG and RRSIG.

Thanks :-)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
South Biscay: Southerly veering southwesterly 5 to 7, occasionally gale 8.
Moderate or rough, occasionally very rough later in northwest. Rain later.
Good, occasionally poor later.

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any and QTYPE=RRSIG

[Ólafur Guðmundsson]

On Fri, Feb 5, 2016 at 10:10 PM, Tony Finch  wrote:

> Last weekend one of our authoritative name servers
> (authdns1.csx.cam.ac.uk) suffered a series of DoS attacks which made it
> rather unhappy. Over the last week I have developed a patch for BIND to
> implement draft-ietf-dnsop-refuse-any which should allow us to handle
> ANY flood attacks better. http://fanf.livejournal.com/140566.html
>
> I still have a potential problem with RRSIG queries, which work a lot like
> ANY queries. Cloudflare's approach is to simply refuse them, which makes a
> lot of sense because RRSIG queries don't have the same interop concerns as
> ANY queries. However, in an attack like the ones we had last weekend where
> the queries arrived at our authoritative servers from lots of real
> recursive servers, a refusal will cause retries and make the attack worse.
>
> Would it be reasonable as an alternative to follow the refuse-any approach
> and just return the RRSIG(s) for one RRset? If so, I think this suggestion
> should be included in the draft.
>
>
For all you care you an even return a forged RRSIG/SIG i.e. one that is
made up on the fly
just make sure it covers a non existing TYPE :-)

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Tony Finch]

Another question:

In order to minimize responses even further, I have made my code omit or
include signature records depending on whether DO=0 or DO=1. That is, and
ANY query with DO=0 gets one arbitrary unsigned RRset in response, and an
ANY query with DO=1 gets one arbitrary signed RRset.

Is this sensible, and if do should it be suggested by the draft?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fair Isle: Southerly becoming cyclonic 5 to 7, occasionally gale 8 at first in
east. Rough or very rough. Rain or showers. Good, occasionally poor.

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any and QTYPE=RRSIG

[Tony Finch]

Ólafur Guðmundsson  wrote:
>
> For all you care you an even return a forged RRSIG/SIG i.e. one that is
> made up on the fly just make sure it covers a non existing TYPE :-)

Make it an RRSIG covering an RRSIG with a private algorithm and you don't
even need to do any crypto :-) (Not entirely serious suggestion.)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Viking, North Utsire, South Utsire, Forties, Cromarty, Forth: Southerly or
southwesterly 6 to gale 8, occasionally severe gale 9 at first, decreasing 5
at times later. Rough or very rough, becoming high for a time except in
Cromarty and Forth. Rain or showers. Moderate or good, occasionally poor.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Evan Hunt]

On Sun, Feb 07, 2016 at 02:16:15PM +, Tony Finch wrote:
> Is this sensible, and if do should it be suggested by the draft?

Yes. I haven't looked in the draft recently, but I thought I mentioned that
when I originally described this trick.  Choose an arbitrary (preferably
determinate) rrset to return, and include its covering signature if it
exists and DO=1 so the response can validate.

eh

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Tony Finch]

Evan Hunt  wrote:
>
> Choose an arbitrary (preferably determinate) rrset to return, and
> include its covering signature if it exists and DO=1 so the response can
> validate.

Right.

My code currently just picks the first RRtype it gets from the backend
data store (or the type covered if the first RRtype is a signature type).
This is stable on a single server but different servers can return the
data in a different order.

Doing anything more determinate would require an extra loop over the data
to choose, before the loop that builds the response. (Actually I can
probably avoid two loops if I'm clever.) I didn't think I cared enough to
do that. However some answers from my zones (e.g. DNSKEY) are bigger than
512 bytes and so can cause truncation and TCP, so maybe I do care after
all.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Sole, Lundy, Fastnet: West gale 8 to storm 10, decreasing 6 to gale 8,
occasionally 11 at first except in Sole. Very high or phenomenal, becoming
very rough or high. Squally showers. Moderate or poor.

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Jared Mauch]

> On Feb 8, 2016, at 10:33 AM, Tony Finch  wrote:
> 
> Doing anything more determinate would require an extra loop over the data
> to choose, before the loop that builds the response. (Actually I can
> probably avoid two loops if I'm clever.) I didn't think I cared enough to
> do that. However some answers from my zones (e.g. DNSKEY) are bigger than
> 512 bytes and so can cause truncation and TCP, so maybe I do care after
> all.

Or just having the TCP implementation in BIND get improved as it’s clear there
are some more people pushing in this direction.  I’m looking at just putting
something like DNSDIST on my hosts to process TCP and balance it across
multiple daemons to do the query scale.

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Ólafur Guðmundsson]

On Sun, Feb 7, 2016 at 2:16 PM, Tony Finch  wrote:

> Another question:
>
> In order to minimize responses even further, I have made my code omit or
> include signature records depending on whether DO=0 or DO=1. That is, and
> ANY query with DO=0 gets one arbitrary unsigned RRset in response, and an
> ANY query with DO=1 gets one arbitrary signed RRset.
>
> Is this sensible, and if do should it be suggested by the draft?
>
>
Tony: the draft says right now:

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

   The RRSet returned in the answer section of the response MAY be a
   single RRSet owned by the name specified in the QNAME.  Where
   multiple RRSets exist, the responder MAY choose a small one to reduce

   its amplification potential.

Is that not sufficient ?

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Tony Finch]

Ólafur Guðmundsson  wrote:

> Tony: the draft says right now: [...]
>
> Is that not sufficient ?

The most relevant bit in the current draft is:

   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 section MUST be returned.

which does in fact imply that you can leave the RRSIGs out when DO=0
if you read it properly (which I evidently failed to do!) but it's
probably worth saying so explicitly.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Sole, Lundy, Fastnet: West gale 8 to storm 10, decreasing 6 to gale 8,
occasionally 11 at first except in Sole. Very high or phenomenal, becoming
very rough or high. Squally showers. Moderate or poor.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[bert hubert]

On Mon, Feb 08, 2016 at 10:37:09AM -0500, Jared Mauch wrote:
> Or just having the TCP implementation in BIND get improved as it’s clear there
> are some more people pushing in this direction.  I’m looking at just putting
> something like DNSDIST on my hosts to process TCP and balance it across
> multiple daemons to do the query scale.

With a ltle work btw dnsdist could proxy TCP/IP questions over UDP with
gigantic packet sizes. This would get you TCP/IP to the unwashed BCP38-free
masses but UDP in your home network.

Might that be a good idea?

Bert

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[Shane Kerr]

Bert,

At 2016-02-08 22:55:44 +0100
bert hubert  wrote:

> On Mon, Feb 08, 2016 at 10:37:09AM -0500, Jared Mauch wrote:
> > Or just having the TCP implementation in BIND get improved as it’s clear 
> > there
> > are some more people pushing in this direction.  I’m looking at just putting
> > something like DNSDIST on my hosts to process TCP and balance it across
> > multiple daemons to do the query scale.  
> 
> With a ltle work btw dnsdist could proxy TCP/IP questions over UDP with
> gigantic packet sizes. This would get you TCP/IP to the unwashed BCP38-free
> masses but UDP in your home network.
> 
> Might that be a good idea?

I guess so, but why not just nail up some persistent TCP connections
internally?

You should be able to keep a small pool for each backend server, so you
can handle significant concurrency (you shouldn't need that many
connections to an authoritative server, maybe something related to the
number of cores is reasonable, like 2x or 3x cores number of
connections).

Since the sessions are up, you won't pay any additional cost during
each query. In fact, you may even have fewer packets to a busy server,
since multiple messages can be collected into a single IP packet. One
of our developers (hi vorner!) found that proxying UDP into TCP was
actually faster than raw UDP (there are lots of details that may have
impacted this, but we can discuss it if you are curious).

Cheers,

--
Shane

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any and DO=0

[bert hubert]

On Mon, Feb 08, 2016 at 10:37:09AM -0500, Jared Mauch wrote:
> Or just having the TCP implementation in BIND get improved as it’s clear there
> are some more people pushing in this direction.  I’m looking at just putting
> something like DNSDIST on my hosts to process TCP and balance it across
> multiple daemons to do the query scale.

With a ltle work btw dnsdist could proxy TCP/IP questions over UDP with
gigantic packet sizes. This would get you TCP/IP to the unwashed BCP38-free
masses but UDP in your home network.

Might that be a good idea?

Bert

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

[DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

[Joe Abley]

Hi Richard, all,

I foolishly allowed Tim to pay for lunch and therefore have been tricked into 
doing actual work. There are a couple more of these inbound to the list, one 
for each of the e-mails containing points that were found not to have been 
addressed in -04. My goal is to identify some kind of consensus on each this 
week and the propose some actual text.

With reference to:

  https://mailarchive.ietf.org/arch/msg/dnsop/_W6ois9hFYlAWUmka21FX91910s

>- There is no mechanism for signaling section 4.1/ section 4.3 "partial
>response" behavior to clients (e.g., a new OPT record EDNS header flag
>bit
>
> 
>).

Correct. I presume you are suggesting that there should be one. I have not 
heard anybody else require such a thing, and new EDNS code points are thought 
by at least some to be thorny things to pass undigested through middleboxes so 
I think it's a non-trivial suggestion that would require a proposal that itself 
would need thorough review. That feels out of scope for this document, but 
perhaps something analogous to extended RCODEs in the sense that it's channel 
metadata.

I think it would be uncontroversial to note explicitly that the mechanism 
described in this document contains no such signalling, however. Let me know if 
that seems like a pragmatic solution.

>- Insisting that the HINFO OS field SHOULD be empty ("set to the null
>string") seems a little too strong; there's room in it for—and value
>from—a short explanation (e.g., as can be observed today:
>
> dns.cloudflare.com
> . 3789 IN HINFO "Please stop asking for ANY" "See
>draft-ietf-dnsop-refuse-any"). I'd prefer text like "The OS field
> of the HINFO
>RDATA SHOULD be short to minimize the size of the response, and MAY be
>empty or MAY include a summarized description of local policy."

I am happy with that text. Unless there are violent objections from the 
assembled throng, I will make that change.

>- "Conventional [ANY] response" is used but not defined.

I am not sure why it's ambiguous without a definition. To me that phrase seems 
pretty straightforward; if your core objection is that the DNS standards are 
not written down with great accuracy, yeah. The only definition I can think of 
really is something like "A response to a query that had QTYPE=ANY which 
follows convention" which just seems longer, not more clear. What did you have 
in mind?

>- "ANY does not mean ALL" is misleading—RFC 1035
><
> https://tools.ietf.org/html/rfc1035#section-3.2.3>
>  is clear about
>QTYPE=255 being "a request for *all* records" (emphasis mine). That
>said, the proposed *response* behavior is consistent with that RFC.

All records that the server constructing the response knows about?

All records that the server can fit into the response given the constraints of 
the available transport?

ALL THE RECORDS IN THE WHOLE WORLD! That was an obscure reference to Blackadder 
the Second that probably pleases nobody but me. ("Kill Bob!" "Never!")

I think to that point we can implicitly acknowledge between ourselves that less 
ambiguity would be nice, but that on the whole this text as-is at worst does no 
harm, and at best helps illustrate the philosophy of the approach being 
described.

Let me know how much of that you can live with :-)


Joe

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

[DNSOP] draft-ietf-dnsop-refuse-any: points from Stephane Bortzmeyer

[Joe Abley]

Salut Stephane, tout le monde,

With reference to:

  https://mailarchive.ietf.org/arch/msg/dnsop/wwQV0yUMdx1mwO8ig9UyNbMMMWI

> My personal nits, only editorial:
> 
> > "ANY Query" refers to a DNS meta-query
> 
> meta-query is not defined in this document, in RFC 1034, 1035 or
> 7719. Opinion: just "query".
> 
> > Below are the three different modes of behaviour by DNS responders
> > for names that exists that are used, listed in the order of
> > preference
> 
> Is it obvious for everyone that it is the decreasing order (most
> preferred first)?

Thanks for those suggestions -- I will apply a gentle sponging action to the 
text and make it shinier in all three cases.

> > Implementers SHOULD provide an option for operators to specify
> > behavior over TCP.
> 
> If this is because, with TCP, you have some certainty about the client
> address, and therefore do not risk reflection attacks, then I suggest
> to replace TCP by "transports that provide some guarantee about the
> authenticity of the source IP address, such as TCP or DNS cookies".

I think mentioning other future transports is sensible. I also take fanf's 
point that ability to believe that a source address is legitimate is not the 
only reason for wanting this behaviour. Perhaps the middle ground is to 
acknowledge that the approach is applicable to multiple transports, but that 
implementors SHOULD provide individual controls for each transport to 
accommodate the full range of desired behaviours?


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

[DNSOP] draft-ietf-dnsop-refuse-any: points from Petr Špaček

[Joe Abley]

Hi Petr, all,

With reference to:

  https://mailarchive.ietf.org/arch/msg/dnsop/lZDnD1kCZQ1Zvm0YF6wbWtg

> 1. The casse QTYPE=RRSIG should be made more prominent so it is
> understood and not misused as ANY. There are implementations like Knot
> Resolver which are work around missing RRSIG records in replies using
> QTYPE=RRSIG.
> 
> Personally I would rename the document from
>   Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY
> to
>   Providing Minimal-Sized Responses to DNS Queries
> that have QTYPE=ANY or QRTYPE=RRSIG
> 
> ... and extend Abstract as well:
>The Domain Name System (DNS) specifies a query type (QTYPE)
>"ANY" or "RRSIG". The operator of an authoritative DNS server might
>choose not torespond to such queries for reasons of local policy,
>motivated by security, performance or other reasons.
> 
> 2. Section Updates to RFC 1035 should use normative language, especially
> regarding RRSIG. Proposal follows:
>RRSIG queries have the same potential as ANY queries of generating
>large answers as well as extra work.  In the wild there are
>implementations that return REFUSE, others return single RRSIG, etc.
>It is RECOMMENDED returning a single RRSIG in this case.
> 
> 
> 3. Text about necessity of fallback in applications trying to use ANY
> query is burried under non-descriptive section name "Motivation". Given
> the confusion is caused among application developers, I would like to
> see it mentioned and explained again in section "Behaviour of DNS
> Initiators".
> 

I understand the points you're making, and I've read fanf's subsequent reaction 
to it (and your reaction to that).

I don't have any objection to any of those suggestions, and I'm quite happy to 
come up with text for them in the next rev of the draft (thanks for your 
suggestions in 1 and 2). If anybody else here has thoughts about specific text 
or violent objections to including QTYPE=RRSIG in general, please let me know 
(I looked in the mail archive but couldn't find any there).

The general approach I am picturing is one in which the issues for ANY and 
RRSIG are both described, but that implementors are free to address just one if 
they have particular circumstances that make that sensible. As we discuss (see 
Stephane's points) in the case of multiple transports, perhaps we can also 
recommend that implementors provide configuration options to allow 
administrators to deal with ANY, RRSIG, neither or both. That way we get 
flexibility that matches deployment, but we also get a reference for handling 
RRSIG in a predictable way.


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

Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Ólafur Guðmundsson]

This was the original proposal,
the drawback is that resolvers to not cache the answer, and to make things
worse they ask ALL NS addresses for listed domain
thus it acts as a DDoS against the domain in question.

Olafur


On Mon, Aug 7, 2017 at 7:14 AM, Ray Bellis  wrote:

> Having looked at this a few months ago when one of our partners was
> (briefly) returning NOTIMP for ANY queries, I find myself wondering why
> this isn't discussed in the draft?
>
> The draft does talk about *new* RCODEs, but not existing ones.
>
> My reading of RFC 1035 is that it would be a perfectly appropriate
> response from a server that doesn't support ANY.
>
> Unfortunately the retry semantics of DNS are not well specified and
> therefore implementation differences may occur.  If as a result NOTIMP
> is really not usable then IMHO this should also be documented.
>
> Ray
>
> ___
> 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] draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Ray Bellis]

On 07/08/2017 16:44, Ólafur Guðmundsson wrote:

> This was the original proposal, 
> the drawback is that resolvers to not cache the answer, and to make
> things worse they ask ALL NS addresses for listed domain 
> thus it acts as a DDoS against the domain in question.  

Indeed - I've since confirmed that BIND does this.

I think my point still stands that this behaviour should be documented
in the section that talks about a possible new RCODE and why that option
was rejected.

kind regards,

Ray

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Paul Vixie]

Ray Bellis wrote:

... returning NOTIMP for ANY queries, ...

...

My reading of RFC 1035 is that it would be a perfectly appropriate
response from a server that doesn't support ANY.


the RFC was treated as a general guideline by most implementers, and 
once the code for some client or server appeared to work, it was 
shipped. it is that code which constraints our work now, not the RFC.



Unfortunately the retry semantics of DNS are not well specified and
therefore implementation differences may occur.  If as a result NOTIMP
is really not usable then IMHO this should also be documented.


i think you'll find that NOTIMP causes try-next-server for many clients, 
but without poisoning, so if all servers return NOTIMP, then all those 
same servers will be tried again, without delay.


sometimes, withholding a response is the only way to keep the client out 
of this bombardment-mode. sometimes returning something poisonous like 
ANCOUNT=0 is nec'y. again, our guide today is how to get clients to do 
something constructive, ideally constructive for both them and us. it 
doesn't have to be true, and it doesn't have to be documented in an 
older RFC.


i agree that writing a new RFC whenever something like this is found to 
be necessary, and putting into that RFC more specific advice to client 
implementers so that the future might possibly improve, is a great idea.


--
P Vixie

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP?

[Paul Vixie]

Ray Bellis wrote:

... returning NOTIMP for ANY queries, ...

...

My reading of RFC 1035 is that it would be a perfectly appropriate
response from a server that doesn't support ANY.


the RFC was treated as a general guideline by most implementers, and 
once the code for some client or server appeared to work, it was 
shipped. it is that code which constraints our work now, not the RFC.



Unfortunately the retry semantics of DNS are not well specified and
therefore implementation differences may occur. If as a result NOTIMP
is really not usable then IMHO this should also be documented.


i think you'll find that NOTIMP causes try-next-server for many clients, 
but without poisoning, so if all servers return NOTIMP, then all those 
same servers will be tried again, without delay.


sometimes, withholding a response is the only way to keep the client out 
of this bombardment-mode. sometimes returning something poisonous like 
ANCOUNT=0 is nec'y. again, our guide today is how to get clients to do 
something constructive, ideally constructive for both them and us. it 
doesn't have to be true, and it doesn't have to be documented in an 
older RFC.


i agree that writing a new RFC whenever something like this is found to 
be necessary, and putting into that RFC more specific advice to client 
implementers so that the future might possibly improve, is a great idea.


-- P Vixie

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Petr Špaček

[Tony Finch]

Joe Abley  wrote:
>
> If anybody else here has thoughts about specific text or violent
> objections to including QTYPE=RRSIG in general, please let me know (I
> looked in the mail archive but couldn't find any there).

I think it's helpful to mention RRSIG explicitly since it isn't
immediately obvious that it's a stealth ANY query. (It becomes
apparent to implementers fairly rapidly tho!)

> As we discuss (see Stephane's points) in the case of multiple
> transports, perhaps we can also recommend that implementors provide
> configuration options to allow administrators to deal with ANY, RRSIG,
> neither or both. That way we get flexibility that matches deployment,
> but we also get a reference for handling RRSIG in a predictable way.

I think the draft should recommend a simple on/off switch and describe
sensible behaviour when it is on. Mainly because I think we know what
that sensible behaviour is, and I don't think it's a big enough feature
to deserve a lot of configuration and documentation complexity.

Having said that, the initiator side (section 5) needs a bit of work.
Something like,

   ANY queries SHOULD be sent using the same choice of transport as other
   queries (typically, try UDP first, and only use TCP if the response is
   truncated). As an exception, debugging and diagnostics tools MAY have
   a special case for ANY queries.

(bleeding-edge versions of `dig` use TCP for ANY)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Bailey: East becoming cyclonic, 6 to gale 8. Moderate or rough, becoming rough
or very rough. Rain or showers. Good, occasionally poor.

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

[Richard Gibson]

On Tue, Jul 25, 2017 at 4:52 PM, Joe Abley  wrote:

> >- There is no mechanism for signaling section 4.1/ section 4.3
> "partial
> >response" behavior to clients (e.g., a new OPT record EDNS header flag
> >bit
> > dns-parameters.xhtml#dns-parameters-13>
> >).
>
> Correct. I presume you are suggesting that there should be one. I have not
> heard anybody else require such a thing, and new EDNS code points are
> thought by at least some to be thorny things to pass undigested through
> middleboxes so I think it's a non-trivial suggestion that would require a
> proposal that itself would need thorough review. That feels out of scope
> for this document, but perhaps something analogous to extended RCODEs in
> the sense that it's channel metadata.
>

The need for such a signal also came up recently in
https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05#section-10
. But in this case particularly, middleboxes should be a complete
non-issue... anyone expecting QTYPE=ANY passthrough is already asking for
trouble.

I think it would be uncontroversial to note explicitly that the mechanism
> described in this document contains no such signalling, however. Let me
> know if that seems like a pragmatic solution.
>

I remain concerned about issuing incomplete responses to ANY queries
without indication of such, and predict that it will hinder operational
problem investigation and remediation (especially pertaining to IPv4/IPv6
issues). My preference has not changed, but an explicit acknowledgment of
the gap at least provides a reference for future improvement.

>- "Conventional [ANY] response" is used but not defined.
>
> I am not sure why it's ambiguous without a definition. To me that phrase
> seems pretty straightforward; if your core objection is that the DNS
> standards are not written down with great accuracy, yeah. The only
> definition I can think of really is something like "A response to a query
> that had QTYPE=ANY which follows convention" which just seems longer, not
> more clear. What did you have in mind?
>

How about updating document text to replace "conventional ANY queries"
(section 3) and "conventional response" (section 4.1) with "conventional
ANY response" and defining it in the Terminology section:

In this document, "conventional ANY response" refers to an ANY Response
that would be produced by the algorithm in section 4.3.2 of RFC 1034.
Conventional ANY responses can include include records from an arbitrarily
high number of RRSets, up to message truncation.

Also, it therefore appears that this draft needs to be noted as updating
RFC 1034.

>- "ANY does not mean ALL" is misleading—RFC 1035
> ><
> > https://tools.ietf.org/html/rfc1035#section-3.2.3>
> >  is clear about
> >QTYPE=255 being "a request for *all* records" (emphasis mine). That
> >said, the proposed *response* behavior is consistent with that RFC.
>
> All records that the server constructing the response knows about?
>
> All records that the server can fit into the response given the
> constraints of the available transport?
>
> ALL THE RECORDS IN THE WHOLE WORLD! That was an obscure reference to
> Blackadder the Second that probably pleases nobody but me. ("Kill Bob!"
> "Never!")
>
> I think to that point we can implicitly acknowledge between ourselves that
> less ambiguity would be nice, but that on the whole this text as-is at
> worst does no harm, and at best helps illustrate the philosophy of the
> approach being described.
>
> Let me know how much of that you can live with :-)
>

In light of the above, referencing RFC 1035 actually seems misleading...
the relevant definitions come from RFC 1034, and this draft is consistent
with it in acknowledging use of QTYPE=255 for *requesting* records of all
types, but inconsistent with it in specifying *responses* that
intentionally omit matching records.

On Tue, Jul 25, 2017 at 4:53 PM, Joe Abley  wrote:

> >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
>
> I agree. Perhaps "One or more of the RRSets at a QNAME". "... or a subset"
> seems wrong, actually; since some vestigial fragment of a set theory
> lecture in the depths of my pre-history is telling me that the empty set is
> always a valid subset.


Suggestion: "A DNS responder can choose to select one or more
nonempty matching RRSets". This works because existence is guaranteed by
the preceding text ("for names that exists that are used", probably better
phrased as "for QNAMEs with at least one nonempty RRSet"). And it has the
added benefit of correctly covering wildcard behavior.

I also discovered some incidental issues while confirming the above:
1. The draft should standardize on one of "RRSet" (capital S, 17 current
instances) or "RRset" (minuscule S, 7 current instances).
2. Section 4.1 appears to have some errors i

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

[Joe Abley]

On 26 Jul 2017, at 13:28, Richard Gibson  wrote:

> The need for such a signal also came up recently in 
> https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05#section-10
>  . But in this case particularly, middleboxes should be a complete 
> non-issue... anyone expecting QTYPE=ANY passthrough is already asking for 
> trouble.

We may be imagining different things by "middlebox" -- I think you're thinking 
of a resolver, whereas I'm thinking more broadly about stateful inspection, 
firewalls, ALGs, proxies, forwarders, etc. I think there's an entirely 
reasonable and observable expectation that QTYPE=ANY passthrough works in that 
broader sense. Mark's 
 was an 
easy-to-find example of trouble in the real world. 

>> I think it would be uncontroversial to note explicitly that the mechanism 
>> described in this document contains no such signalling, however. Let me know 
>> if that seems like a pragmatic solution.
> 
> I remain concerned about issuing incomplete responses to ANY queries without 
> indication of such, and predict that it will hinder operational problem 
> investigation and remediation (especially pertaining to IPv4/IPv6 issues). My 
> preference has not changed, but an explicit acknowledgment of the gap at 
> least provides a reference for future improvement.

OK. Your future tense is Cloudflare's past tense and I have not heard of an 
example of the kind of operational confusion that you're predicting there, but 
perhaps I'm just not listening in the right dark corners.

I will plan to add text to acknowledge the lack of signalling but not to change 
the mechanism to introduce any. People should throw rocks if that seems bad.

> How about updating document text to replace "conventional ANY queries" 
> (section 3) and "conventional response" (section 4.1) with "conventional ANY 
> response" and defining it in the Terminology section:
> In this document, "conventional ANY response" refers to an ANY Response that 
> would be produced by the algorithm in section 4.3.2 of RFC 1034. Conventional 
> ANY responses can include include records from an arbitrarily high number of 
> RRSets, up to message truncation.

OK, I'm fine with that.

> Also, it therefore appears that this draft needs to be noted as updating RFC 
> 1034.

Noted.

> In light of the above, referencing RFC 1035 actually seems misleading... the 
> relevant definitions come from RFC 1034, and this draft is consistent with it 
> in acknowledging use of QTYPE=255 for requesting records of all types, but 
> inconsistent with it in specifying responses that intentionally omit matching 
> records.

OK. I'll look at this again.

> I also discovered some incidental issues while confirming the above:
> 1. The draft should standardize on one of "RRSet" (capital S, 17 current 
> instances) or "RRset" (minuscule S, 7 current instances).

Noted. The RFC Editor is well-practiced at dealing with that kind of thing, but 
it doesn't help to give them less work ahead of time.

> 2. Section 4.1 appears to have some errors in grammar and use RFC 2119 terms, 
> and should be reworded (removals in strikethrough, additions in bold):

Strikethrough and bold, eh? OK. :-) Suggestions are good, many thanks!


Joe

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

[Richard Gibson]

On Wed, Jul 26, 2017 at 2:24 PM, Joe Abley  wrote:

>
> On 26 Jul 2017, at 13:28, Richard Gibson  wrote:
>
> > The need for such a signal also came up recently in
> https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-
> responses-05#section-10 . But in this case particularly, middleboxes
> should be a complete non-issue... anyone expecting QTYPE=ANY passthrough is
> already asking for trouble.
>
> We may be imagining different things by "middlebox" -- I think you're
> thinking of a resolver, whereas I'm thinking more broadly about stateful
> inspection, firewalls, ALGs, proxies, forwarders, etc. I think there's an
> entirely reasonable and observable expectation that QTYPE=ANY passthrough
> works in that broader sense. Mark's  proceedings/92/slides/slides-92-dnsop-7.pdf> was an easy-to-find example
> of trouble in the real world.
>

Yes, color me corrected on vocabulary but unconvinced on interference...
those slides seem to mostly demonstrate noncompliance by name servers
theirselves with respect to EDNS data in queries, whereas the data I'm
suggesting would only appear in responses.

I will plan to add text to acknowledge the lack of signalling but not to
> change the mechanism to introduce any. People should throw rocks if that
> seems bad.


That works. And I'm all out, so you're safe from me.

> 2. Section 4.1 appears to have some errors in grammar and use RFC 2119
> terms, and should be reworded (removals in strikethrough, additions in
> bold):
>
> Strikethrough and bold, eh? OK. :-) Suggestions are good, many thanks!
>

Ha! I'll use Markdown conventions in the future.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

[Joe Abley]

On 26 Jul 2017, at 14:50, Richard Gibson  wrote:

> Yes, color me corrected on vocabulary but unconvinced on interference... 
> those slides seem to mostly demonstrate noncompliance by name servers 
> theirselves with respect to EDNS data in queries, whereas the data I'm 
> suggesting would only appear in responses.

My recollection was that the machinery Mark was using wouldn't distinguish 
between problems caused by nameservers and problems introduced by middleware, 
but it *was* a while ago. Anyway, I'm not arguing so much as trying to explain 
myself, and...

> That works. And I'm all out, so you're safe from me.

... thanks for that.

> Strikethrough and bold, eh? OK. :-) Suggestions are good, many thanks!
> 
> Ha! I'll use Markdown conventions in the future.

That would be a significant sideprovement.


Joe "text/plain" Abley

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

[Tony Finch]

Joe Abley  wrote:
> On 26 Jul 2017, at 13:28, Richard Gibson  wrote:
> >
> > I remain concerned about issuing incomplete responses to ANY queries
> > without indication of such, and predict that it will hinder
> > operational problem investigation and remediation (especially
> > pertaining to IPv4/IPv6 issues).
>
> OK. Your future tense is Cloudflare's past tense and I have not heard of
> an example of the kind of operational confusion that you're predicting
> there, but perhaps I'm just not listening in the right dark corners.

The only minimal-any confusion I have experienced recently was when the
BIND 9.12 development version of `dig` started using TCP for ANY queries
which made me think minimal-any wasn't working properly :-) But I think
in most cases this change will reduce the confusion Richard is worried
about.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Portland, Plymouth: Westerly 4 or 5, increasing 6 at times in north. Moderate,
occasionally rough in west Plymouth. Showers. Good.

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

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Petr Špaček

[Petr Špaček]

On 26.7.2017 12:56, Tony Finch wrote:
> Joe Abley  wrote:
>>
>> If anybody else here has thoughts about specific text or violent
>> objections to including QTYPE=RRSIG in general, please let me know (I
>> looked in the mail archive but couldn't find any there).
> 
> I think it's helpful to mention RRSIG explicitly since it isn't
> immediately obvious that it's a stealth ANY query. (It becomes
> apparent to implementers fairly rapidly tho!)
> 
>> As we discuss (see Stephane's points) in the case of multiple
>> transports, perhaps we can also recommend that implementors provide
>> configuration options to allow administrators to deal with ANY, RRSIG,
>> neither or both. That way we get flexibility that matches deployment,
>> but we also get a reference for handling RRSIG in a predictable way.
> 
> I think the draft should recommend a simple on/off switch and describe
> sensible behaviour when it is on. Mainly because I think we know what
> that sensible behaviour is, and I don't think it's a big enough feature
> to deserve a lot of configuration and documentation complexity.

I agree with Tony that we know what that sensible behaviour is so, with
my implementor hat on, I would be perfectly happy with
implementation-specific behavior with no knobs at all. If you don't like
it, feel free to pick another implementation.

Petr Špaček  @  CZ.NIC

> 
> Having said that, the initiator side (section 5) needs a bit of work.
> Something like,
> 
>ANY queries SHOULD be sent using the same choice of transport as other
>queries (typically, try UDP first, and only use TCP if the response is
>truncated). As an exception, debugging and diagnostics tools MAY have
>a special case for ANY queries.
> 
> (bleeding-edge versions of `dig` use TCP for ANY)
> 
> Tony.

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

[DNSOP] draft-ietf-dnsop-refuse-any: points from 神明達哉

[Joe Abley]

JINMEI-san, all,

With reference to:

  https://mailarchive.ietf.org/arch/msg/dnsop/zy86pvg139PaKFXo-BO6SPUfh3k

> I've reviewed the 04 version.  I still do not think it's ready to move
> forward as it still abuses HINFO.  I understand some other people
> don't care about this point, and some others may even love the idea
> (those who are using it right now).  But I've also seen yet some other
> people have the same concern, so it shouldn't be only me.  I don't
> think we have a clear consensus on this point yet.

The draft at present doesn't require an implementer to abuse HINFO; it provides 
options to avoid doing so whilst still meeting the described objectives of the 
proposal. Since abusing HINFO is not mandatory, I presume you are objecting to 
the proposal sanctioning such shenanigans at all.

If I have that right (please correct me if I'm wrong) I don't think I am the 
right person to make the call, being just a lowly document scribe. If this 
remains a concern for you, I suggest that we defer that question to our chairs 
and ask them to gauge consensus. My own personal views of pragmatism vs. 
elegance shouldn't enter into it; this is a working group document.

> To be hopefully a bit more productive, I have a specific counter
> proposal: remove the mandatory text about the use of HINFO, e.g.,
> 
> - remove this bullet from section 4
>2.  A DNS responder can return a synthesised HINFO resource record.
>See Section 6 for discussion of the use of HINFO.
> - remove ', in which case...' from Section 4.2
>If there is no CNAME present at the owner name matching the QNAME,
>the resource record returned in the response MAY instead be
>synthesised, in which case a single HINFO resource record SHOULD be
>returned.
> 
> In fact, in terms of externally observable behavior, synthesizing
> HINFO is just one form of "selecting one RRset of the QNAME"; the
> HINFO is added and immediately removed at the time of answering the
> ANY query, so in that sense we don't have to bother to mention it with
> normative keywords.

This text suggests that my interpretation above is wrong, and what you are 
objecting to is just the way that the HINFO approach is described. I think the 
specification is more clear if we spell out the whole synth-HINFO approach in 
its entirety and don't try to subsume it into the "return a subset of { RRSets 
that there } u { RRSets that we just synthesised }".

Again, I am not entirely confident that I understand your concern, so both my 
reactions above might be nonsense. Please try again if it seems that I don't 
understand your point.

> Regarding the choice of HINFO in case of synthesizing, it may make
> sense to specify a particular type as part of normative spec if many
> other implementations are going to implement it.  But, as Section 8
> explains two major general purpose open source implementations, NSD
> and BIND 9, seem to only support the "subset" approach.  I suspect
> it's actually not feasible for those generic implementations to
> hardcode HINFO as long as their users could also use that type as
> "real zone data".  Some special purpose implementation with full
> control on what it configures, like in the case of Cloudflare, may
> freely explore the approach of synthesizing HINFO at their discretion.
> But I don't think it necessarily has to be a part of normative part of
> this spec, at least at this moment.

I am not sure I understand the benefit of not including it, given that it is 
observable behaviour for a large number of domains today (even if that is so 
due to the volume of domains hosted at a single operator). I think we do better 
service to operators and implementors by describing what is implemented. As you 
point out, Cloudflare's implementation may be less general-purpose than BIND9 
or NSD, and that might be a reason for the implementation choices to be 
different. Cloudflare is unlikely to be the last non-general implementation, 
however, so perhaps the mechanism most appropriate there will be relevant to 
others.

> I've also noticed a couple of other points I raised in my previous
> review (
> https://www.ietf.org/mail-archive/web/dnsop/current/msg18746.html
> )
> were not yet addressed.  These are (section numbers are for 03):
> 
> - 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

I agree. Perhaps "One or more of the RRSets at a QNAME". "... or a subset" 
seems wrong, actually; since some vestigial fragment of a set theory lecture in 
the depths of my pre-history is telling me that the empty set is always a valid 
subset.

> - 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" sta

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from 神明達哉

[神明達哉]

Hi, sorry for the delayed response.

At Tue, 25 Jul 2017 16:53:12 -0400,
Joe Abley  wrote:

>   https://mailarchive.ietf.org/arch/msg/dnsop/zy86pvg139PaKFXo-BO6SPUfh3k
>
> > I've reviewed the 04 version.  I still do not think it's ready to move
> > forward as it still abuses HINFO.  I understand some other people
> > don't care about this point, and some others may even love the idea
> > (those who are using it right now).  But I've also seen yet some other
> > people have the same concern, so it shouldn't be only me.  I don't
> > think we have a clear consensus on this point yet.
>
> The draft at present doesn't require an implementer to abuse HINFO;
> it provides options to avoid doing so whilst still meeting the
> described objectives of the proposal. Since abusing HINFO is not
> mandatory, I presume you are objecting to the proposal sanctioning
> such shenanigans at all.

(If I understand the subtle nuance of this text:-) I think your
understanding is correct.
>
> If I have that right (please correct me if I'm wrong) I don't think
> I am the right person to make the call, being just a lowly document
> scribe. If this remains a concern for you, I suggest that we defer
> that question to our chairs and ask them to gauge consensus. My own

Agreed - I think we have to agree to disagree here and I think neither
of us can convince the other.  It should better be left to the wg
decision.

> personal views of pragmatism vs. elegance shouldn't enter into it;
> this is a working group document.

> > To be hopefully a bit more productive, I have a specific counter
> > proposal: remove the mandatory text about the use of HINFO, e.g.,
> >
> > - remove this bullet from section 4
> >2.  A DNS responder can return a synthesised HINFO resource record.
> >See Section 6 for discussion of the use of HINFO.
> > - remove ', in which case...' from Section 4.2
> >If there is no CNAME present at the owner name matching the QNAME,
> >the resource record returned in the response MAY instead be
> >synthesised, in which case a single HINFO resource record SHOULD be
> >returned.
> >
> > In fact, in terms of externally observable behavior, synthesizing
> > HINFO is just one form of "selecting one RRset of the QNAME"; the
> > HINFO is added and immediately removed at the time of answering the
> > ANY query, so in that sense we don't have to bother to mention it with
> > normative keywords.
>
> This text suggests that my interpretation above is wrong, and what
> you are objecting to is just the way that the HINFO approach is
> described. I think the specification is more clear if we spell out
> the whole synth-HINFO approach in its entirety and don't try to
> subsume it into the "return a subset of { RRSets that there } u {
> RRSets that we just synthesised }".

(As I said above) I believe you interpreted my objection correctly.
This suggestion was an attempt of compromise, assuming people already
(ab)using HINFO want to continue their practice.

[...]

> I am not sure I understand the benefit of not including it, given
> that it is observable behaviour for a large number of domains today
> (even if that is so due to the volume of domains hosted at a single
> operator). I think we do better service to operators and
> implementors by describing what is implemented. As you point out,
> Cloudflare's implementation may be less general-purpose than BIND9
> or NSD, and that might be a reason for the implementation choices to
> be different. Cloudflare is unlikely to be the last non-general
> implementation, however, so perhaps the mechanism most appropriate
> there will be relevant to others.

I agree that being silent for existing deployment may not be ideal.
If we (wg) can reach a consensus that the HINFO-based approach is an
abuse, however, we can think of other way to address it.  For example,
we could mention it and clarify that it should be considered an abuse,
should be discouraged, and newer implementations should use other
approaches.  My suggestion was just based on the anticipation that we
can probably not reach this kind of consensus (especially about the
discouragement).

> > I've also noticed a couple of other points I raised in my previous
> > review (
> > https://www.ietf.org/mail-archive/web/dnsop/current/msg18746.html
> > )
> > were not yet addressed.  These are (section numbers are for 03):
> >
> > - 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
>
> I agree. Perhaps "One or more of the RRSets at a QNAME". "... or a subset" 
> seems wrong, actually; since some vestigial fragment of a set theory lecture 
> in the depths of my pre-history is telling me that the empty set is always a 
> valid subset.
>
> > - 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
>