Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Tony Finch]

Brian Dickson  wrote:
>
> Would it be feasible to limit the behavior of "refuse-any" returning
> "partial" UDP responses, to situations where EDNS with DO=1 is used?

No, this is a defence mechanism, so it needs to cope with uncooperative
clients.

> Older resolvers would need to have some method of getting answers, so
> maybe for those, use the TC=1 method?

There's no "need", partial answers to QTYPE=ANY interoperate fine.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: Southerly or southwesterly backing southeasterly at times, 4 or 5,
increasing 6 or 7 at times. Moderate or rough. Rain or showers. Moderate or
good.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Brian Dickson]

>
> Richard Gibson  wrote:
> > Because without such a signal, humans using ANY for legitimate diagnostic
> > purposes have no means of differentiating section 4.1/4.3 "subset"
> > responses from conventional responses where there just happen to be only
> a
> > small number of RRSets at the queried name, encouraging (or at least
> doing
> > nothing to dissuade) a conclusion that the response is in fact
> conventional
> > and complete.
> There are several ways to avoid this pitfall:
> Use TCP
> Look for an NSEC(3) record
> Query for the specific types you want to know about
> Tony.


I hope it's not too late to discuss additions to the I-D. Sorry for not
contributing sooner.

So, I have a question about EDNS and DNSSEC (and maybe when DO=1):

Suppose a zone is NOT signed, but the requestor uses EDNS (and maybe DO=1).

What would resolvers do if they received, in addition to normal RRs, one or
more NSEC or NSEC3 records, and no RRSIGs?

That would be one way to provide information about RRtypes at the owner
name, even if the zone was unsigned.

Would it be feasible to limit the behavior of "refuse-any" returning
"partial" UDP responses, to situations where EDNS with DO=1 is used? Older
resolvers would need to have some method of getting answers, so maybe for
those, use the TC=1 method?

Specifically:
 When a QTYPE=ANY is received, respond with some "arbitrary" choice of
RRTYPE, and add an unsigned NSEC or NSEC3 record to list RRTYPEs present.

In the case of SIGNED zone, returning a random RRtype and including the
NSEC/NSEC3 would be ideal for both signaling that "ANY" is not supported,
as well as what else to query for.

I think NSEC or NSEC3 could be used in an unsigned zone, and generated "on
the fly" with trival or empty values for "next owner", with the caveat that
it MUST NOT be used for generating negative or empty responses. But that is
a stretch, and probably not worth pursuing without some further
investigation into resolvers' handling of such unsigned responses inside
unsigned zones.

(This on-the-fly suggestion is a compromise to avoid the need for
NSEC/NSEC3 over unsigned zones, or forcing everything to be signed, which
is clearly not yet a reasonable suggestion.)

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Tony Finch]

Vernon Schryver  wrote:

> > From: Tony Finch 

>

> > One of the points of minimal-any is that the answer is not truncated
> > because you do not want clients to automatically retry over TCP.
> > This is
> > to handle situations where many third-party recursive servers
> > are under
> > attack using one of your names, so the recursive servers are hitting
> > your authoritative servers hard. RRL does not work in this case,
> > because
> > the clients are legitimate recursive servers. You want to give
> > them an
> > answer asap, that they can cache without hitting TCP.

>

> On the contrary, as that case is described, RRL works fine, and

> this minimal-any mechanism won't help the obvious attack situation

> in that might be intended.

>

> Each legitimate recursive server will ask once per some TTL and

> cache the rrsets that it gets. 



Not if the authoritative server is overloaded and has run out of TCP
sockets and is unable to answer the question. The recursive servers will
all then be perpetually retrying while the attack continues, so the
authoritative servers will never recover from overload.


> However, in that case how many legitimate recursive servers will

> send ANY requests to authorities?



In the case of this attack it was thousands.



Tony.

--

f.anthony.n.finch    http://dotat.at/  -  I xn--
  zr8h punycode



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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Mark Andrews]

In message <201702132243.v1dmhnkr062...@calcite.rhyolite.com>, Vernon Schryver 
writes:
> > From: Tony Finch 
> 
> > One of the points of minimal-any is that the answer is not truncated
> > because you do not want clients to automatically retry over TCP. This is
> > to handle situations where many third-party recursive servers are under
> > attack using one of your names, so the recursive servers are hitting
> > your authoritative servers hard. RRL does not work in this case, because
> > the clients are legitimate recursive servers. You want to give them an
> > answer asap, that they can cache without hitting TCP.
> 
> On the contrary, as that case is described, RRL works fine, and
> this minimal-any mechanism won't help the obvious attack situation
> in that might be intended.
> 
> Each legitimate recursive server will ask once per some TTL and
> cache the rrsets that it gets.  No single legitimate recursive
> server will make a lot of ANY requests per unit time.
> 
> An attack that might be intended involves many open recursive servers
> (perhaps open only local infected eyeball stubs) being hit for only a
> few requests each (or at least passing on only a few each request) for
> your names but many all together.
> 
> However, in that case how many legitimate recursive servers will
> send ANY requests to authorities?

Any with a empty cache for name when the query comes in and a qtype
255 in the request.

The hard part of a 255 request is just having cached negative
responses for individual types doesn't result in useful response
to the request.  You still need to recurse with qtype 255 to get
some data to return including NODATA for a ENT.

Mark

> Vernon Schryverv...@rhyolite.com
> 
> ___
> 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] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Vernon Schryver]

> From: Tony Finch 

> One of the points of minimal-any is that the answer is not truncated
> because you do not want clients to automatically retry over TCP. This is
> to handle situations where many third-party recursive servers are under
> attack using one of your names, so the recursive servers are hitting
> your authoritative servers hard. RRL does not work in this case, because
> the clients are legitimate recursive servers. You want to give them an
> answer asap, that they can cache without hitting TCP.

On the contrary, as that case is described, RRL works fine, and
this minimal-any mechanism won't help the obvious attack situation
in that might be intended.

Each legitimate recursive server will ask once per some TTL and
cache the rrsets that it gets.  No single legitimate recursive
server will make a lot of ANY requests per unit time.

An attack that might be intended involves many open recursive servers
(perhaps open only local infected eyeball stubs) being hit for only a
few requests each (or at least passing on only a few each request) for
your names but many all together.

However, in that case how many legitimate recursive servers will
send ANY requests to authorities?


Vernon Schryverv...@rhyolite.com

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Tony Finch]

Mark Andrews  wrote:

>

> We don't need any new signalling.  If the answer is truncated you

> set tc=1.  This works with all existing clients.



One of the points of minimal-any is that the answer is not truncated
because you do not want clients to automatically retry over TCP. This is
to handle situations where many third-party recursive servers are under
attack using one of your names, so the recursive servers are hitting
your authoritative servers hard. RRL does not work in this case, because
the clients are legitimate recursive servers. You want to give them an
answer asap, that they can cache without hitting TCP.


Tony.

--

f.anthony.n.finch    http://dotat.at/  -  I xn--
  zr8h punycode



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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Mark Andrews]

We don't need any new signalling.  If the answer is truncated you
set tc=1.  This works with all existing clients.

If there is only a single RRset + RRSIGs then you don't get tc=1
except for traditional space reasons.

Mark
-- 
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] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Wessels, Duane]

> On Feb 13, 2017, at 10:15 AM, Richard Gibson  wrote:
> 
> On Mon, Feb 13, 2017 at 1:02 PM, Wessels, Duane  wrote:
> Tools like dig, when asked to issue an ANY query over UDP can:
> 
> 1) fail with "ANY over UDP is deprecated", or
> 
> That's not true, though, and tools have no way of knowing whether or not such 
> a failure is appropriate without the very signal I'm requesting.

Deprecated may not be the best choice of wording, even though it was in the 
title of the original draft and got my hopes up.

However, the authors of dig and other tools, having read this new RFC, can 
decide that they will no longer support ANY over UDP and exit with an error 
message saying so and provide hints ("use +tcp") for how to make it work.

DW


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Richard Gibson]

On Mon, Feb 13, 2017 at 1:02 PM, Wessels, Duane 
wrote:

> Tools like dig, when asked to issue an ANY query over UDP can:
>
> 1) fail with "ANY over UDP is deprecated", or
>

That's not true, though, and tools have no way of knowing whether or not
such a failure is appropriate without the very signal I'm requesting.

2) warn with "ANY over UDP might give partial results", or
> 3) automatically use TCP


Regardless of anything else, those are both reasonable.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Ólafur Guðmundsson]

On Mon, Feb 13, 2017 at 9:50 AM, Richard Gibson  wrote:

> On Mon, Feb 13, 2017 at 12:38 PM, Robert Edmonds  wrote:
>
>> You think this would actually provide any sort of useful information? No
>> operator would understand what "MBZ: 0x" means without re-training,
>> and if you're re-training operators you may as well point them to this
>> document.
>
>
> I think it would be _very_ useful. People easily forget new information,
> but seeing unexpected data like that would provide the necessary trigger
> for remembering this document and e.g. retrying with +tcp.
>

Richard,

HINIFO is such a signal :-)
thus your request applies only to Send-one and Send-useful responses.
I do not think adding complexity will help at all.

 ... you want an overhead cost forever just because of "muscle memory"
learning curve for few people.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Richard Gibson]

On Mon, Feb 13, 2017 at 12:38 PM, Robert Edmonds  wrote:

> You think this would actually provide any sort of useful information? No
> operator would understand what "MBZ: 0x" means without re-training,
> and if you're re-training operators you may as well point them to this
> document.


I think it would be _very_ useful. People easily forget new information,
but seeing unexpected data like that would provide the necessary trigger
for remembering this document and e.g. retrying with +tcp.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Richard Gibson]

On Mon, Feb 13, 2017 at 11:46 AM, Tony Finch  wrote:

> OK. But does an EDNS flag help? What if you are using old tools?


If you are using old tools, then you don't get new conveniences (the same
is true of using OPT class to specify a maximum payload size exceeding 512
bytes, using the DO bit to request DNSSEC records, and using the COOKIE
option for authentication). But a flag would still be there, conveying
information even if any given client or tool isn't looking for it.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Tony Finch]

Richard Gibson  wrote:
>
> The pitfall comes from unexamined muscle-memory assumptions when inspecting
> a DNS response, so none of those methods avoid it. They're expecting people
> to remember that longstanding behavior has changed without providing any
> clue about it.

OK. But does an EDNS flag help? What if you are using old tools?

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey: Southeasterly 5 to 7, occasionally gale 8 in south. Rough,
becoming very rough for a time in south. Fair. Good.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Richard Gibson]

On Mon, Feb 13, 2017 at 8:03 AM, Tony Finch  wrote:

> There are several ways to avoid this pitfall:
>
> Use TCP
>
> Look for an NSEC(3) record
>
> Query for the specific types you want to know about


The pitfall comes from unexamined muscle-memory assumptions when inspecting
a DNS response, so none of those methods avoid it. They're expecting people
to remember that longstanding behavior has changed without providing any
clue about it.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Tony Finch]

Richard Gibson  wrote:

> Because without such a signal, humans using ANY for legitimate diagnostic
> purposes have no means of differentiating section 4.1/4.3 "subset"
> responses from conventional responses where there just happen to be only a
> small number of RRSets at the queried name, encouraging (or at least doing
> nothing to dissuade) a conclusion that the response is in fact conventional
> and complete.

There are several ways to avoid this pitfall:

Use TCP

Look for an NSEC(3) record

Query for the specific types you want to know about

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: East 7 to severe gale 9, occasionally storm 10 at first near welsh
coast, veering southeast 5 to 7. Moderate or rough. Mainly fair. Moderate or
good.

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Richard Gibson]

Because without such a signal, humans using ANY for legitimate diagnostic
purposes have no means of differentiating section 4.1/4.3 "subset"
responses from conventional responses where there just happen to be only a
small number of RRSets at the queried name, encouraging (or at least doing
nothing to dissuade) a conclusion that the response is in fact conventional
and complete.

On Fri, Feb 10, 2017 at 1:44 PM, Ólafur Guðmundsson 
wrote:

> Thank you for your comments
>
> Q: why do you think it is useful to complicate things with a EDNS0 flag ?
>
> Olafur
>
>
>
> On Thu, Feb 9, 2017 at 8:47 PM, Richard Gibson  wrote:
>
>> With full realization that this is coming very late in the game, we had a
>> great deal of internal conversation within Dyn about implementing
>> refuse-any, and came away unsatisfied with both the "subset" and "HINFO"
>> approaches—the latter because of reasons that have already been covered,
>> and the former for lacking in-band signaling of non-"conventional"
>> incompleteness to aid legitimate use.
>>
>> I believe there is sufficient cause to reserve a new OPT record EDNS
>> header flag bit
>> 
>> for indicating "partial response" (as distinct from "truncation"). It will
>> be safely ignored by current clients, but convey the desired information to
>> those in the know.
>>
>> P.S. Our discussion also raised some more minor points:
>>
>>- 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., 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."
>>- "Conventional [ANY] response" is used but not defined.
>>- "ANY does not mean ALL" is misleading—RFC 1035
>> is clear about
>>QTYPE=255 being "a request for *all* records" (emphasis mine). That
>>said, the proposed *response* behavior is consistent with that RFC.
>>
>>
>> On Thu, Feb 9, 2017 at 12:56 AM,  wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Domain Name System Operations of the
>>> IETF.
>>>
>>> Title   : Providing Minimal-Sized Responses to DNS
>>> Queries that have QTYPE=ANY
>>> Authors : Joe Abley
>>>   Olafur Gudmundsson
>>>   Marek Majkowski
>>> Filename: draft-ietf-dnsop-refuse-any-04.txt
>>> Pages   : 10
>>> Date: 2017-02-08
>>>
>>> Abstract:
>>>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>>>The operator of an authoritative DNS server might choose not to
>>>respond to such queries for reasons of local policy, motivated by
>>>security, performance or other reasons.
>>>
>>>The DNS specification does not include specific guidance for the
>>>behaviour of DNS servers or clients in this situation.  This document
>>>aims to provide such guidance.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-04
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> ___
>>> 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] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Ólafur Guðmundsson]

Thank you for your comments

Q: why do you think it is useful to complicate things with a EDNS0 flag ?

Olafur



On Thu, Feb 9, 2017 at 8:47 PM, Richard Gibson  wrote:

> With full realization that this is coming very late in the game, we had a
> great deal of internal conversation within Dyn about implementing
> refuse-any, and came away unsatisfied with both the "subset" and "HINFO"
> approaches—the latter because of reasons that have already been covered,
> and the former for lacking in-band signaling of non-"conventional"
> incompleteness to aid legitimate use.
>
> I believe there is sufficient cause to reserve a new OPT record EDNS
> header flag bit
> 
> for indicating "partial response" (as distinct from "truncation"). It will
> be safely ignored by current clients, but convey the desired information to
> those in the know.
>
> P.S. Our discussion also raised some more minor points:
>
>- 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., 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."
>- "Conventional [ANY] response" is used but not defined.
>- "ANY does not mean ALL" is misleading—RFC 1035
> is clear about
>QTYPE=255 being "a request for *all* records" (emphasis mine). That
>said, the proposed *response* behavior is consistent with that RFC.
>
>
> On Thu, Feb 9, 2017 at 12:56 AM,  wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Domain Name System Operations of the
>> IETF.
>>
>> Title   : Providing Minimal-Sized Responses to DNS
>> Queries that have QTYPE=ANY
>> Authors : Joe Abley
>>   Olafur Gudmundsson
>>   Marek Majkowski
>> Filename: draft-ietf-dnsop-refuse-any-04.txt
>> Pages   : 10
>> Date: 2017-02-08
>>
>> Abstract:
>>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>>The operator of an authoritative DNS server might choose not to
>>respond to such queries for reasons of local policy, motivated by
>>security, performance or other reasons.
>>
>>The DNS specification does not include specific guidance for the
>>behaviour of DNS servers or clients in this situation.  This document
>>aims to provide such guidance.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>>
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-04
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> ___
>> 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] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Richard Gibson]

With full realization that this is coming very late in the game, we had a
great deal of internal conversation within Dyn about implementing
refuse-any, and came away unsatisfied with both the "subset" and "HINFO"
approaches—the latter because of reasons that have already been covered,
and the former for lacking in-band signaling of non-"conventional"
incompleteness to aid legitimate use.

I believe there is sufficient cause to reserve a new OPT record EDNS header
flag bit

for indicating "partial response" (as distinct from "truncation"). It will
be safely ignored by current clients, but convey the desired information to
those in the know.

P.S. Our discussion also raised some more minor points:

   - 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., 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."
   - "Conventional [ANY] response" is used but not defined.
   - "ANY does not mean ALL" is misleading—RFC 1035
    is clear about
   QTYPE=255 being "a request for *all* records" (emphasis mine). That
   said, the proposed *response* behavior is consistent with that RFC.


On Thu, Feb 9, 2017 at 12:56 AM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
>
> Title   : Providing Minimal-Sized Responses to DNS Queries
> that have QTYPE=ANY
> Authors : Joe Abley
>   Olafur Gudmundsson
>   Marek Majkowski
> Filename: draft-ietf-dnsop-refuse-any-04.txt
> Pages   : 10
> Date: 2017-02-08
>
> Abstract:
>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>The operator of an authoritative DNS server might choose not to
>respond to such queries for reasons of local policy, motivated by
>security, performance or other reasons.
>
>The DNS specification does not include specific guidance for the
>behaviour of DNS servers or clients in this situation.  This document
>aims to provide such guidance.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Ólafur Guðmundsson]

This version addresses all the comments that the chair's determined needed
addressing.

Olafur


On Wed, Feb 8, 2017 at 9:56 PM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
>
> Title   : Providing Minimal-Sized Responses to DNS Queries
> that have QTYPE=ANY
> Authors : Joe Abley
>   Olafur Gudmundsson
>   Marek Majkowski
> Filename: draft-ietf-dnsop-refuse-any-04.txt
> Pages   : 10
> Date: 2017-02-08
>
> Abstract:
>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>The operator of an authoritative DNS server might choose not to
>respond to such queries for reasons of local policy, motivated by
>security, performance or other reasons.
>
>The DNS specification does not include specific guidance for the
>behaviour of DNS servers or clients in this situation.  This document
>aims to provide such guidance.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

Title   : Providing Minimal-Sized Responses to DNS Queries that 
have QTYPE=ANY
Authors : Joe Abley
  Olafur Gudmundsson
  Marek Majkowski
Filename: draft-ietf-dnsop-refuse-any-04.txt
Pages   : 10
Date: 2017-02-08

Abstract:
   The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
   The operator of an authoritative DNS server might choose not to
   respond to such queries for reasons of local policy, motivated by
   security, performance or other reasons.

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


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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