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

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 >

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

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

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

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

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

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

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

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,

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

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

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

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

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

> 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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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