On Sun, 8 Mar 2015, Paul Hoffman wrote:
My personal interpretation is that validating resolver is a synonym for
security-aware resolver. Do others agree? If not, how would you differentiate them?
I agree :)
Two other issues I noticed when trying to rewrite my draft to stick to
terms in this
Greetings again. Paul Wouters noticed an inconsistency in the terminology
draft, and upon investigation, I believe it is a problem (hopefully fixable)
with the definitions in RFC 4033. RFC 4033 and 4035 use the term validating
resolver in a few places. However, RFC 4033 never defines that. RFC
Moin!
On Sun, Mar 08, 2015 at 12:21:49PM -0700, Paul Hoffman wrote:
Greetings again. Paul Wouters noticed an inconsistency in the terminology
draft, and upon investigation, I believe it is a problem (hopefully
fixable) with the definitions in RFC 4033. RFC 4033 and 4035 use the term
Good folk,
On 8/03/2015 4:15 am, Olafur Gudmundsson ola...@cloudflare.com wrote:
Paul,
Marek and I agree with you to expand the scope to include all meta types
at Authoratitive servers.
And address your other points as well, thanks for the support.
Olafur
I've been vacillating(*) on this
Brian Dickson mailto:brian.peter.dick...@gmail.com
Sunday, March 08, 2015 2:55 PM
Hey, everyone,
Given the diagnostic value of any (and similarly RRSIG et al), I
would prefer deprecation of only the UDP version, via mechanisms that
are dig-friendly.
alas, in a post-snowden world, that's
On Sun, 8 Mar 2015, Brian Dickson wrote:
Given the diagnostic value of any (and similarly RRSIG et al), I would
prefer deprecation of only the UDP version, via mechanisms
that are dig-friendly.
A better description would be to require source IP verification,
so that eastlake-cookies are also
Moin!
On Sun, Mar 08, 2015 at 02:55:37PM -0700, Brian Dickson wrote:
Hey, everyone,
Given the diagnostic value of any (and similarly RRSIG et al), I would
prefer deprecation of only the UDP version, via mechanisms that are
dig-friendly.
I still fail to see the diagnostic value of it. IMHO
On Mar 8, 2015, at 6:23 PM, Olafur Gudmundsson o...@ogud.com wrote:
There is a new version in the works, expect it late tomorrow (monday)
It does not outlaw ANY per say, just says limit it to trusted parties.
I tries to define that resolver treat NOTIMP as long term signal that
resolver
Paul Wouters wrote:
On Sun, 8 Mar 2015, Brian Dickson wrote:
Given the diagnostic value of any (and similarly RRSIG et al), I
would prefer deprecation of only the UDP version, via mechanisms
that are dig-friendly.
A better description would be to require source IP verification,
so that
On Sun, 8 Mar 2015, Paul Vixie wrote:
again, the next revision of olafur's document will remove all mention of
amplification/reflection. that meme is dead.
So why are we proposing to ACL the ANY queries again?
If you put ANY queries under an ACL, it means you are limiting the ANY
query
Tony Finch wrote:
On 6 Mar 2015, at 22:53, Paul Vixie p...@redbarn.org wrote:
if you want to change how DNSSEC works, i'll listen. ...
... implementing RRSIG
is as hard as implementing ANY with regard to the aspect that you have
to use/look for more than one query type, which is different
Hey, everyone,
Given the diagnostic value of any (and similarly RRSIG et al), I would
prefer deprecation of only the UDP version, via mechanisms that are
dig-friendly.
E.g. return TC=1 (and minimal response) instead, to trigger TCP retry.
It throws out the bath water, but keeps the baby.
I am
12 matches
Mail list logo
