> 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-defi
> > > 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
anywh
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? I
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 a
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
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
> 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 "IETF version."
>
> We've done this fo
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 the
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 li
>>> 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
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 endors
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
anythin
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 fr
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 q
> 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.
15 matches
Mail list logo
