> On 3 Apr 2018, at 1:10 pm, Mark Andrews wrote:
>
> Do we really want to test for AD? How many stub resolvers set DO or AD to
> elicit a AD response?
>
I’m not sure that we are on the same page here. The precondition is: "The AD
bit is to be set in the response” i.e. it is not a test on
Do we really want to test for AD? How many stub resolvers set DO or AD to
elicit a AD response?
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
DNSOP mailing
On Tue, Apr 3, 2018 at 12:13 AM, Paul Hoffman wrote:
> On 2 Apr 2018, at 17:05, George Michaelson wrote:
>
>> RFC4035 section 3.2 looks like it has usable words surely?
>
>
> Maybe I'm an idiot, but I see no definition of "validating resolver" there.
ok. So what is the 'resolver side' of a 'secur
On 2 Apr 2018, at 17:05, George Michaelson wrote:
RFC4035 section 3.2 looks like it has usable words surely?
Maybe I'm an idiot, but I see no definition of "validating resolver"
there.
not from those words, but in my personal opinion, Any resolver which
is able to understand and apply the
On 2 April 2018 at 09:56, Warren Kumari wrote:
>
> This is not clearly a modification to the intended consensus (yet),
> and currently feels unclear to me, so I'm going to give this another
> few days (~1 week) and then, probably, mark it Hold for Document
> Update. I'd still appreciate peoples'
RFC4035 section 3.2 looks like it has usable words surely?
not from those words, but in my personal opinion, Any resolver which
is able to understand and apply the semantic context of DNSSEC
signatures over RR should be considered a validating resolver.
However, a validating resolver may also be s
Some folks didn't feel all that great about this because it's not
defined in an RFC. Specific suggestions welcome.
Validating resolver:
A security-aware recursive name server, security-aware resolver, or
security-aware stub resolver that is applying at least one of the
definitions of valid
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : A Root Key Trust Anchor Sentinel for DNSSEC
Authors : Geoff Huston
Joa
On Sun, Apr 1, 2018 at 5:06 PM, Evan Hunt wrote:
> On Sun, Apr 01, 2018 at 01:33:17PM -0400, Warren Kumari wrote:
>> I'm also somewhat confused what the caching the wildcard answer
>> *means* - if I have *.example.com cached and then get a query for
>> foo.example.com I still need to query for it
On Mon, Apr 02, 2018 at 03:20:02AM -0700, internet-dra...@ietf.org wrote:
>
> A new version of I-D, draft-muks-dnsop-dns-squash-01.txt
> has been successfully submitted by Mukund Sivaraman and posted to the
> IETF repository.
>
> Name: draft-muks-dnsop-dns-squash
> Revision: 01
> Titl
On Sun, Apr 01, 2018 at 11:58:07PM +0530, Mukund Sivaraman wrote:
> Caching takes place not just by BIND, but Unbound as well and does not
> cause problems, so the stronger requirement is unnecessary and ought to
> be re-worded.
PowerDNS recursor will also happily cache a *.record but not do anyth
11 matches
Mail list logo