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

2017-03-28 Thread 神明達哉 
On Thu, Mar 16, 2017 at 12:11 AM, tjw ietf  wrote:

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

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

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

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

2017-03-20 Thread Paul Wouters 

On Mon, 20 Mar 2017, Tony Finch wrote:


Paul Wouters  wrote:


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.


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


Then clearly the section could use some clarification text :)

Paul

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

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

2017-03-20 Thread Tony Finch 
Paul Wouters  wrote:
>
> 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.

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

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

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

2017-03-20 Thread Paul Wouters 

On Mon, 20 Mar 2017, Jim Reid wrote:


The traditional understanding of ANY == ALL is well ingrained in developers.


[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 the data they're looking for.


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

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

2017-03-20 Thread Tony Finch 
Stephane Bortzmeyer  wrote:
>
> > "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".

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

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

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

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

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

2017-03-20 Thread Tony Finch 
Petr Špaček  wrote:
>
> I hope it clarifies that I have no objection to proposed behavior, just
> 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    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.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2017-03-20 Thread Petr Špaček 
On 17.3.2017 20:54, Tony Finch wrote:
> Petr Špaček  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?

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/lZDnD1kCZQ1Zvm0YF6wbWtg


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

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

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

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

2017-03-20 Thread Jim Reid 

> On 17 Mar 2017, at 07:34, Doug Barton  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.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2017-03-19 Thread Stephane Bortzmeyer 
On Fri, Mar 17, 2017 at 10:19:27AM -0700,
 Doug Barton  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. 

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

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

2017-03-17 Thread Jim Reid 

> On 17 Mar 2017, at 17:19, Doug Barton  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.

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

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

2017-03-17 Thread Tony Finch 
Petr Špaček  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    http://dotat.at/  -  I xn--zr8h punycode
South Fitzroy: Northeasterly 5 or 6, occasionally 7. Moderate or rough. Mainly
fair. Mainly good.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2017-03-17 Thread Tony Finch 
Doug Barton  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    http://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey: Cyclonic becoming southwest, 5 or 6. Rough, occasionally
very rough. Occasional rain. Good, occasionally poor.

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

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

2017-03-17 Thread Evan Hunt 
On Fri, Mar 17, 2017 at 10:19:27AM -0700, Doug Barton 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. I have never understood the DNS literati's 
> 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.

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

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 -- e...@isc.org
Internet Systems Consortium, Inc.

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

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

2017-03-17 Thread Doug Barton 


On 03/17/2017 03:22 AM, Havard Eidnes 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.


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.


Can you explain a bit more about this?


The traditional understanding of ANY == ALL is well ingrained in
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


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.



Therefore I'm entirely with Jim on this one: if an application
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.



ANY has historically primarily been a debugging aid and isn't really
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

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

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

2017-03-17 Thread Petr Špaček 
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. 
> 
> 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=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 

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

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

2017-03-17 Thread Havard Eidnes 
>>> 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.

> The traditional understanding of ANY == ALL is well ingrained in
> 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,
 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

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

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

2017-03-17 Thread Mark Andrews 

In message , Doug Barton wr
ites:
> 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:
> > 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
>
> 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?

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.

>  arameters-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
> > . 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
> >  is clear about
> > QTYPE=255 being "a request for *all* records" (emphasis mine). That
> > 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 ...

Or TC once the answer exceeds a threshold.

> Doug
>
> ___
> 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] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

2017-03-17 Thread Doug Barton 
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

On 03/17/2017 12:12 AM, Jim Reid wrote:



On 17 Mar 2017, at 06:54, Doug Barton  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.



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

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

2017-03-17 Thread Jim Reid 

> On 17 Mar 2017, at 06:54, Doug Barton  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.

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

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

2017-03-17 Thread Doug Barton 
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:

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


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?




).
  * 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
. 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
 is clear about
QTYPE=255 being "a request for *all* records" (emphasis mine). That
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

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

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

2017-03-16 Thread Richard Gibson 
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
   

   ).
   - 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
    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  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.
>
> 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=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
>
>
> ___
> 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] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

2017-03-16 Thread tjw ietf 
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=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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop