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

From: tjw ietf <[email-masked]>
Date: Thu, 16 Mar 2017 03:11:26 -0400

All

During the first WGLC of draft-ietf-dnsop-refuse-any, several issues were
raised by the working group that needed to be addressed. The Authors
addressed the issues, but the changes are enough that there should be a
second Working Group Last Call on the changes.

This begins a Second WGLC for draft-ietf-dnsop-refuse-any.  The Document is
located here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/

However, the changes that were made since the last WGLC can be found here:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-refuse-any-03&url2=draft-ietf-dnsop-refuse-any-04

Please take a few moments to refer the changes and let the working group
know if the document is ready to move forward.   We're mostly looking for
remaining issues that have not been addressed.

This WGLC ends on Thursday 30 March 2017.

Thanks

tim/suzanne

---

From: Richard Gibson <[email-masked]>
Date: Fri, 17 Mar 2017 00:27:19 -0400

To re-raise my unaddressed points from the first Working Group Last Call:

   - 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
   <http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-13>
   ).
   - 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."
   - "Conventional [ANY] response" is used but not defined.
   - "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.

On Thu, Mar 16, 2017 at 3:11 AM, tjw ietf <[email-masked]> wrote:

> This begins a Second WGLC for draft-ietf-dnsop-refuse-any.  The Document
> is located here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-
> refuse-any/
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-refuse-
> any-03&url2=draft-ietf-dnsop-refuse-any-04
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Doug Barton <[email-masked]>
Date: Thu, 16 Mar 2017 23:54:06 -0700

I think this is a bad idea generally, and that RRL is a better solution 
to the amplification vector issue. But since the "War on ANY" doesn't 
show signs of abating ...

On 03/16/2017 09:27 PM, Richard Gibson 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

This is my chief concern. However much the purists don't like it, 
various things in the wild ask for ANY fully expecting that it means 
ALL. If something gets an ANY response that does not include the thing 
it really needs, how is it supposed to know that it needs to ask again?

>     <http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-13>).
>   * Insisting that the HINFO OS field SHOULD be empty ("set to the null
>     from—a short explanation (e.g., as can be observed
>     today: dns.cloudflare.com
>     <http://dns.cloudflare.com>. 3789INHINFO"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."

Agreed. I'd rather see this flipped, with auth servers encouraged to 
include a brief explanation, or even a URL that explains the issue.

>   * "ANY does not mean ALL" is misleading—RFC 1035
>     said, the proposed /response/ behavior is consistent with that RFC.

That may be true technically, but I doubt anyone but a serious DNS RFC 
purist would understand, or agree with that distinction.

Personally I have a lot of sympathy for the school of thought that says 
to send nothing back but the TC bit, and force the requestor to 
reconnect with TCP. But the "War on TCP" doesn't show any signs of 
abating either ...

Doug

---

From: Jim Reid <[email-masked]>
Date: Fri, 17 Mar 2017 07:12:00 +0000

> On 17 Mar 2017, at 06:54, Doug Barton <[email-masked]> wrote:
> 
> If something gets an ANY response that does not include the thing it really needs, how is it supposed to know that it needs to ask again?

If something is unable to unambiguously ask for the exact thing it really needs, that's their problem. It's not a concern for this WG or the DNS protocol.

---

From: Doug Barton <[email-masked]>
Date: Fri, 17 Mar 2017 00:34:44 -0700

Yes, I understand that is a popular opinion. However, I would argue that 
it is unhelpfully elitist.

The traditional understanding of ANY == ALL is well ingrained in 
developers. It is not at all unreasonable for them to assume that if the 
RR they wanted didn't come back in response to the ANY query that it 
does not exist; and I do not see anything in this draft that would help 
them understand that they need to requery (apologies if I missed it).

On this point alone the draft's claim of being backwards compatible is 
wrong on its face, and as a result is nearly certain to cause far more 
disruption than benefit.

Doug

---

From: Mark Andrews <[email-masked]>
Date: Fri, 17 Mar 2017 18:39:14 +1100

In message <[email-masked]>, Doug Barton wr
> it really needs, how is it supposed to know that it needs to ask again?

Well if you are asking a recursive server there is 20+ years of
implemention history where * doesn't give all possible records,
only which is cached.  Retrying with specific types is built into
applications which use *.  They would fail too often otherwise.

So at this point we are only talking about tools that only talk
directly to authoritative servers or look at the "aa" flag to
determine if they are talking to a authoritative server.

Now, there is really only one signal that will work with old software
and that is TC=1.  New software could just use TCP by default for *.

In terms of possible signals, other than TC=1, adding a EDNS
option/flag would require relaxing ban on adding a OPT record to a
non EDNS query.  One could use the last DNS header bit.

> >     string") seems a little too strong; there's room in it for-and value
> >     from-a short explanation (e.g., as can be observed
> >   * "ANY does not mean ALL" is misleading-RFC 1035

Or TC once the answer exceeds a threshold.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Havard Eidnes <[email-masked]>
Date: Fri, 17 Mar 2017 11:22:34 +0100 (CET)

>>> If something gets an ANY response that does not include the thing it
>>> really needs, how is it supposed to know that it needs to ask again?
>>
>> If something is unable to unambiguously ask for the exact thing it
>> really needs, that's their problem. It's not a concern for this WG or
>> the DNS protocol.
>
> Yes, I understand that is a popular opinion. However, I would argue
> that it is unhelpfully elitist.

I disagree.
This has to do with caching, so pretty fundamental to the DNS.

> developers.

If the query goes directly to an authoritative name server, that
has historically been the case, yes.

If, on the other hand, you have an application making DNS queries,
it typically uses a stub resolver, so sends all its queries via a
caching recursive resolver.  What you then get back as a response to
an "ANY" query will depend on what other queries has already been
resolved through that caching recursive resolver already, because in
that context ANY means "all the records you might already have in
the cache already for the given name".  And even further, the
different RRsets for the same name might have different TTLs, so
will expire from the cache at different times.  There is therefore
absolutely no guarantee that the result of quering a recursive
resolver and an authoritative name server with the same ANY query
will produce the same result -- a recursive resolver can't know that
it is "missing" records of certain types for the given query name.
Only in the cases where the recursive resolver has no cached entries
for the queried name, the ANY query would be passed on to the auth
servers, and historically that has managed to fetch e.g. all of A,
AAAA and MX in one transaction.  However, you haven't been able to
rely on that as the single method, so you need to code fallbacks to
query the individual record types you need if any of them don't turn
up as a result of an ANY query.  In other words, a godawful mess for
marginal gains.

The proposed draft would in effect invalidate the "optimization"
that the ANY query method might in some cases provide.  No big loss,
IMHO.

Therefore I'm entirely with Jim on this one: if an application
needs an MX record, it had better explicitly query for it.

ANY has historically primarily been a debugging aid and isn't really
suitable for use by applications.

Regards,

- Håvard

---

From: Petr Špaček <[email-masked]>
Date: Fri, 17 Mar 2017 13:13:59 +0100

Hello,

and sorry for being so late.

While reading the draft and related discussion I realized that the draft
has two important problems which were not obvious at first:

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 believe that it would greatly improve readability of the draft.
Petr Špaček  @  CZ.NIC

On 16.3.2017 08:11, tjw ietf wrote:
> 
> All
> 
> During the first WGLC of draft-ietf-dnsop-refuse-any, several issues
> were raised by the working group that needed to be addressed. The
> Authors addressed the issues, but the changes are enough that there
> should be a second Working Group Last Call on the changes. 
> 
> is located
> here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
> 
> know if the document is ready to move forward.   We're mostly looking
> for remaining issues that have not been addressed.  
> 
> This WGLC ends on Thursday 30 March

---

From: Doug Barton <[email-masked]>
Date: Fri, 17 Mar 2017 10:19:27 -0700

> This has to do with caching, so pretty fundamental to the DNS.

Can you explain a bit more about this?

> resolved through that caching recursive resolver already

Yes, I know how ANY queries work. :)

You are making the assumption that those using the ANY query are sending 
it to stubs, but there is no way of knowing whether that is true or not.

> needs an MX record, it had better explicitly query for it.

I'm aware that a lot of the animosity towards ANY has come from Dan's 
choice of using it to find records for qmail. I am not a Dan-fan 
generally, but on this topic he has made the excellent point that the 
query exists, and has well-defined semantics which meet the use case, so 
it's legal to use it. I have never understood the DNS literati's 
animosity towards that argument.

> suitable for use by applications.

That's a value judgement. I don't know how to configure my name server 
for that.

I find it astonishing that there is this overwhelming "We must preserve 
backwards compatibility at all costs!" sentiment on so many ridiculous 
topics in the DNS, and yet because people hate the ANY query (and 
particularly one software author's perceived misappropriation of it) SO 
MUCH y'all are willing to throw backwards compatibility out the door for 
something that it's absolutely clear will break deployed applications.

Doug

---

From: Evan Hunt <[email-masked]>
Date: Fri, 17 Mar 2017 18:58:00 +0000

> animosity towards that argument.

Dan's use case would not be harmed by refuse-any; qmail sends its queriers
to local resolvers, not to authority servers. It gets back whatever happens
to be cached, or the minimal answer, and in either case it'll re-query.
No harm done.

> something that it's absolutely clear will break deployed applications.

This is already deployed; it was introduced as "mimimal-any" in BIND
9.11.0 using the pick-one-RRset method, and cloudflare has been using the
HINFO method for over a year.  I haven't heard reports of anything being
broken.

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

---

From: Tony Finch <[email-masked]>
Date: Fri, 17 Mar 2017 19:38:29 +0000

Doug Barton <[email-masked]> wrote:

> I think this is a bad idea generally, and that RRL is a better solution to the
> amplification vector issue.

RRL and minimal-any address different problems.

My servers have been using RRL for many years and it works very nicely at
dealing with spoofed UDP attacks directed at my auth servers.

I implemented and deployed minimal-any to reduce TCP overload problems.
If many legitimate recursive servers are being abused as amplifiers, using
a name hosted by my authoritative servers, my auth servers can get
overloaded with too much TCP traffic.

With minimal-any, the recursive servers get answers over UDP, populate
their caches, and go away happy.

Cloudflare's reason for deploying minimal-any is also unrelated to RRL. On
their servers it is very expensive to assemble an ANY response. It is much
simpler and cheaper for them to satisfy queries with a synthetic response
than waste effort on a traditional full-fat answer.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey: Cyclonic becoming southwest, 5 or 6. Rough, occasionally
very rough. Occasional rain. Good, occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Fri, 17 Mar 2017 19:54:40 +0000

Petr Špaček <[email-masked]> wrote:
>
> 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.

Gosh! In what situations do you get missing RRSIGs? Is that not a sign
that either your upstream server doesn't support DO=1, or that you are
under attack from a malefactor / middlebox? Why not re-query a different
upstream server with the full query?

The BIND 9.11 minimal-any implementation treats RRSIG queries similarly to
ANY queries, so it only returns one RRset's RRSIGs (i.e. a subset of the
RRSIGs all with the same type-covered field).

Cloudflare's response to RRSIG queries is REFUSED. Negligible risk of
interop problems in this case, unlike ANY.

I think RRSIG is a diverting sideshow. It might merit a mention in the
abstract but I don't think it needs to be in the title.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
South Fitzroy: Northeasterly 5 or 6, occasionally 7. Moderate or rough. Mainly
fair. Mainly good.

---

From: Jim Reid <[email-masked]>
Date: Sat, 18 Mar 2017 04:13:08 +0000

> On 17 Mar 2017, at 17:19, Doug Barton <[email-masked]> wrote:
> 
> I'm aware that a lot of the animosity towards ANY has come from Dan's choice of using it to find records for qmail. I am not a Dan-fan generally, but on this topic he has made the excellent point that the query exists, and has well-defined semantics which meet the use case, so it's legal to use it.

The behaviour of qmail or whatever is irrelevant to this draft and the WG. Your introduction of personalities is both irrelevant and inappropriate too.

You seem to be advocating a further change or changes to the protocol. Changes that have much more complex implications and semantics:

"If something gets an ANY response that does not include the thing it really needs, how is it supposed to know that it needs to ask again?"

and

"I'd rather see this flipped, with auth servers encouraged to include a brief explanation, or even a URL that explains the issue."

If so, that's what I am objecting to. First, it's not needed. Second, it won't solve your perceived problem. Broken DNS implementations are not going to support your proposed potential protocol change and will continue to be broken. Third, the solution for these broken implementations already exists: just make explicit queries for the desired RRtypes instead of using ANY, just like they should have been doing anyway. It's that simple.

draft-ietf-dnsop-refuse-any is fine as-is. [Well, apart from the language nit at 4.3: "returning all of CNAME" should be "returning all CNAME".] Leave it alone. Let's get this RFC out the door. It's a pragmatic and timely solution to a real operational problem that needs to be fixed.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 19 Mar 2017 22:44:26 +0100

On Thu, Mar 16, 2017 at 03:11:26AM -0400,
 tjw ietf <[email-masked]> wrote 

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

IMHO, the document is both useful, and ready to move forward.

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

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 19 Mar 2017 22:50:11 +0100

On Fri, Mar 17, 2017 at 10:19:27AM -0700,
 Doug Barton <[email-masked]> wrote 
 a message of 63 lines which said:

> he has made the excellent point that the query exists, and has
> well-defined semantics

Well-defined, may be (but I do not think so, RFC 1035 is almost silent
on it), but not well-understood by many developpers.

> I find it astonishing that there is this overwhelming "We must
> preserve backwards compatibility at all costs!" sentiment on so many
> ridiculous topics in the DNS, and yet because people hate the ANY
> query (and particularly one software author's perceived
> misappropriation of it) SO MUCH y'all are willing to throw backwards
> compatibility out the door for something that it's absolutely clear
> will break deployed applications

Using QTYPE=ANY and expecting all the records in the answer does not
work TODAY (and even yesterday, see Evan Hunt and Mark Andrews'
messages). So, we break nothing.

---

From: Jim Reid <[email-masked]>
Date: Mon, 20 Mar 2017 07:57:05 +0000

> On 17 Mar 2017, at 07:34, Doug Barton <[email-masked]> wrote:
> 
> The traditional understanding of ANY == ALL is well ingrained in developers.

[Citation needed.] For bonus points, provide actual examples of commonly used code that have this misconception and the real operational (but self-inflicted) problems it causes for those applications.

> It is not at all unreasonable for them to assume that if the RR they wanted didn't come back in response to the ANY query that it does not exist; and I do not see anything in this draft that would help them understand that they need to requery (apologies if I missed it).

Why should this draft need to document stupid client behaviour or explain why it is stupid?

If you want to submit a draft that says "DNS clients shouldn't use the ANY QTYPE when they want to get a particular A/SRV/MX/whatever RRset returned" or even "DNS clients shouldn't use the ANY QTYPE", go ahead.

draft-ietf-dnsop-refuse-any is about something completely different. In case you hadn't noticed, the draft's about a server-side issue.

> On this point alone the draft's claim of being backwards compatible is wrong on its face, and as a result is nearly certain to cause far more disruption than benefit.

Nonsense! The draft isn't changing the protocol. It suggests how servers could handle one category of potentially harmful queries so that they cause less damage. Once deployed, the only thing this draft will disrupt is the impact of DDoS reflector/amplification attacks.

It's not going to make the slightest difference to idiot/lazy applications that make ANY queries instead of doing The Right Thing. They'll still be getting answers which might or might not contain the data they're looking for.

---

From: Petr Špaček <[email-masked]>
Date: Mon, 20 Mar 2017 12:08:53 +0100

> upstream server with the full query?

Tony, I agree with you. QTYPE=RRSIG is an attempt of drowning man to
catch at a straw. It will certainly not work realiably and Knot is using
it as solution of last resort if everything else failed.
Please do not get distracted by this.

My proposal is just about properly documenting QTYPE=RRSIG behavior so
it is very clear from first read. The goal is to avoid having the very
same discussion about under-defined behavior as we have around ANY today.

If there is another RFC saying that QTYPE=RRSIG is special then please
add a pointer to it. I might have missed that one. If there is none,
please clarify the draft.

I hope it clarifies that I have no objection to proposed behavior, just
to the way it is described. Thank you for understanding.

Proposals for clarification are here:
https://mailarchive.ietf.org/arch/msg/dnsop/lZDOOOOnD1kCZQ1Zvm0YF6wbWtg

> abstract but I don't think it needs to be in the title.

I'm certainly not insisting on title change. It just seemed as a cheap
way to advertise that the document touhes on QTYPE=RRSIG so I did not
see a reason for not mentioning it in the title.

-- 
Petr Špaček  @  CZ.NIC

---

From: Tony Finch <[email-masked]>
Date: Mon, 20 Mar 2017 14:31:00 +0000

> to the way it is described. Thank you for understanding.

No problem, your previous message explained your points very clearly.
I was just startled that RRSIG queries might ever be useful :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Shannon, Rockall, Malin: West 6 to gale 8. Very rough, occasionally rough in
Malin. Wintry showers. Moderate or good.

---

From: Tony Finch <[email-masked]>
Date: Mon, 20 Mar 2017 14:43:47 +0000

> 7719. Opinion: just "query".

There's precedent for "metatype" - cf. RFC 2136 section 3.4.1.2 - "check
the TYPE and if it is ANY, AXFR, MAILA, MAILB, or any other QUERY metatype"
also the IANA registry describes RRtypes 128-255 as "Q TYPEs, Meta TYPEs".

> authenticity of the source IP address, such as TCP or DNS cookies".

The reason I deployed minimal-any was to avoid oversized UDP responses, to
avoid fragmentation and truncation - not because of spoofing (RRL deals
with spoofing). Cookies don't do anything to help avoid oversized
responses, so I would still want to send a minimal-any response to a
cookie client.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Hebrides: West 6 to gale 8, occasionally severe gale 9 at first, backing
southwest 5 or 6 later. Rough or very rough, occasionally high at first. Rain
or wintry showers. Moderate or good.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Mar 2017 11:25:17 -0400 (EDT)

On Mon, 20 Mar 2017, Jim Reid wrote:

> [Citation needed.]

> draft-ietf-dnsop-refuse-any is about something completely different. In case you hadn't noticed, the draft's about a server-side issue.

Funny, how in this discussion about ANY there is already confusion about
what kind of ANY we are talking about. It seems that is all the
citation that is needed here :)

I can confirm that only DNS geeks understand the limitations of ANY and
its relation to what's in the cache or not. It is very prone to be
misunderstood by non DNS geeks.

> It's not going to make the slightest difference to idiot/lazy applications that make ANY queries instead of doing The Right Thing. They'll still be getting answers which might or might not contain…

That is correct. But it will confuse the human operators, especially:

 	If a DNS operator prefers to reduce the potential for information
 	leaks, they MAY choose to not to send large ANY responses.

However, I think that the abuse versus the gain here has been decided
many years ago, and whether or not we will state this in a document,
this kind of behaviour is going to happen or rather, has already
happened. So let's standarize it.

So below is my review of draft-ietf-dnsop-refuse-any-04. I'm still a bt
undecided over whether to use HINFO or allocate a new special RRTYPE.
One of my concerns is that attackers may try to find or create zones
that happen to have a real HINFO record in them, possibly tweaked to
their use, like an HINFO with different CPU/OS values and a zero TTL.

Section 4:

At section 4, item 3, it could give advise based on source-verified
transport, so that ANY queries received over TCP or with DNS-COOKIES
could include more data then potentially spoofed UDP packets. But perhaps
that is not worth it, because ANY queries shouldn't really be used by
applications, and humans will likely use dig without tcp or cookies
enabled. So I am fine with the current text as well. But I think it
would be cleaner if we no longer refer to UDP and TCP when we really
mean "source IP verified transport" when we say that.

In section 4.2:

I'm not sure what this is refering to:

 	understanding that a TTL that is too long might make policy changes
 	relating to ANY queries difficult to change in the future.

And:

 	In the case of DO=0, the RRSIG SHOULD be omitted.

Why is that not a MUST ? What is the use case for the "not SHOULD"
branch? And which DNSSEC RFC would need to be Updated: by this document
as well :)

In Section 4.3:

 	As in the first one if the zone is signed

is pretty ackward to read :P

 	In some cases it is possible to guess what the initiator wants

I'm not sure if I want any DNS RFC to claim it is ok to guess what the
client wants. Instead, I would write some text that either refers to
one of the efforts to ask for multiple types of records in one query,
or if we think those drafts aren't mature enough and might obsolete,
I would rewrite this section to:

 	Some implementations already reduce ANY query responses by
 	returning CNAME or the set of MX, A plus AAAA RRsets, and
 	filtering out any other existing RRsets at the QNAME. The
 	main drawback is that such a response can still result in
 	a useful amplification effect.

 	If the zone is signed and the query has the DO bit set, the
 	response MUST include RRSIGs for all RRsets returned.

Section 4.4:

I would change "TCP" to be "Source address verified transport" so it also
includes queries received with DNS COOKIES. I would also add a note
here about the real problem, which is that DDOS attacks not using
spoofing would still cause an amplification attack when using a source
address verified transport.

Section 5:

I would rewrite this to make the distinction between a caching resolver
and a stub client clearer. That is currently done indirectly with the
MAY keyword which I think is wrong. eg something like:

 	A caching resolver MUST cache the resulting RRsets of a QTYPE=ANY
 	query in the same way it caches non-ANY QTYPEs, and MUST use the
 	HINFO record similar to any other record for the purpose of
 	answering any further QTYPE=ANY requests from its cache.

 	A non-caching stub or resolver MUST process or replay the obtained
 	DNS reply to a QTYPE=ANY request similarly to a non-ANY QTYPE response.

Section 5 and Section 6:

I'm unclear why the document wants different caching resolver behaviour
based on the CPU value of the HINFO record. Why does it matter? I fear
it might allow attackers to use zones that cannot reply with the answer
needed to suppress further ANY queries. If it has anything in its cache,
it should just return that anyway as per normal QTYPE=ANY processing?
So I don't understand the warning for Section 6 either?

Section 7:

I would add a quick sentence about HINFO and the TC bit to the
introduction. The TC bit behaviour seems quite important, and I
think an implementer who reads a section names "Updates to RFC 1035"
might skip reading this thinking it is not that important.

 	and implementation of the guidance provided by this document is OPTIONAL.

This OPTIONAL use is again a bit confusing with the RFC2119 language
used. I'd prefer to see strong language like MUST/MUST NOT for
implementations of this document. Obviously the whole document is
optional to implement.

Section 8:

This should get a marker for the RFC Editor to remove this section as
per RFC 7942. At least I hope this was the intent :)

Section 9:

I find this section more describes the goal of the document, and not so
much the security considerations of the implementation of this draft.

I think this section should really only talk about implementation
concerns (which I don't know of any) or concerns about the ANY query
having turned into a "lie" (which I think has been considered and while
it is deemed to confuse some human operators for a little while, it is
not expected to have an operational effect on properly implementd or
inpromperly implemented consumers of ANY responses.

NITS:

- A few language issues which I'll send as xml diff to the authors

- Should it be "RRset" instead of "RRSet" ?

- "a small one(s)" reads a bit ackward.

- In 4.2, the "SHOULD" is a bit confusing as this is only one of 3
   methods suggested, so it feels more like a MAY? Or perhaps this
   is better rewritten without RFC2119 language?

Paul

---

From: Tony Finch <[email-masked]>
Date: Mon, 20 Mar 2017 17:39:56 +0000

> mean "source IP verified transport" when we say that.

The important distinction for me really is TCP vs UDP - I want to avoid
sending fragmented or truncated UDP responses to legitimate clients.
(Spoofing attacks are handled by RRL, not minimal-any.)
https://www.ietf.org/mail-archive/web/dnsop/current/msg19609.html
https://www.ietf.org/mail-archive/web/dnsop/current/msg19631.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Shannon, Rockall, Malin: West 5 to 7, occasionally gale 8 at first. Very
rough, occasionally rough in east Malin. Wintry showers. Good, occasionally
moderate.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Mar 2017 13:53:19 -0400 (EDT)

> https://www.ietf.org/mail-archive/web/dnsop/current/msg19631.html

Then clearly the section could use some clarification text :)

Paul

---

From: 神明達哉 <[email-masked]>
Date: Tue, 28 Mar 2017 07:44:45 -0700

> second Working Group Last Call on the changes.
[...]
> remaining issues that have not been addressed.

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.

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.

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

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

--
JINMEI, Tatuya