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] DNSOP Call for Adoption draft-vixie-dns-rpz

> > > I have proposed a method that would not change the RPZ response for a > > > non-DNSSEC client, but would add data for DNSSEC capable clients to be I forgot to mention what I think is a completely upward compatible "fix" for RPZ+DNSSEC that requires no protocol or implementation changes

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] DNSOP Call for Adoption draft-vixie-dns-rpz

> From: Barry Raveendran Greene > To: Paul Wouters > Paul - changes to existing practice is a _new_ document. You take the > existing, coded, and deployed specification in as an informational RFC. Then > you start a new working group document for the full

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

Paul - changes to existing practice is a _new_ document. You take the existing, coded, and deployed specification in as an informational RFC. Then you start a new working group document for the full “IETF version.” We’ve done this for many other protocols over the last several decades. Why

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] DNSOP Call for Adoption draft-vixie-dns-rpz

In message <78b1395e-32e3-5e63-00f1-251fa8eb7...@dougbarton.us>, Doug Barton wr ites: > On 03/13/2017 07:28 PM, Dave Crocker wrote: > > On 3/13/2017 1:28 PM, Viktor Dukhovni wrote: > >> Whether we like it or not, > >> publication of said existing practice by the IETF will be seen as > >> an

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On 03/13/2017 07:28 PM, Dave Crocker wrote: On 3/13/2017 1:28 PM, Viktor Dukhovni wrote: Whether we like it or not, publication of said existing practice by the IETF will be seen as an endorsement of that practice. This kind of assertion is frequently made, but never demonstrated with

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] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

william manning writes: > this is a useful and needed document.  I support its adoption by the WG.  As a > note to the authors, there was a proposed alternate to what became RFC 5011 > which addressed some of the same issues as the current draft. It might be > useful