I think this is a good draft.
I do have one comment, based on experimenting with both encoding a /16 in DNS
zone files and the resulting lookups on those IP prefixes contained under it.
As this document progresses I would very much like to advocate that the WG
considers picking a single method
In message ,
"Steph
an Lagerholm" writes:
> Mark Andrews Thursday, April 12, 2012 6:10 PM:
>
> > > On 12.04.2012, at 14:21, Marc Lampo wrote:
> > > > > It holds an alternative possibility to overcome the problem
> > > > > - for operators of validating name servers - of failing domains
> > > > >
Mark Andrews Thursday, April 12, 2012 6:10 PM:
> > On 12.04.2012, at 14:21, Marc Lampo wrote:
> > > > It holds an alternative possibility to overcome the problem
> > > > - for operators of validating name servers - of failing domains
> > > > because of DNSSEC.
> > > >
> > > > The alternative is to
In message ,
"Steph
an Lagerholm" writes:
> Mark,
>
> On 12.04.2012, at 14:21, Marc Lampo wrote:
> > > It holds an alternative possibility to overcome the problem
> > > - for operators of validating name servers - of failing domains
> > > because of DNSSEC.
> > >
> > > The alternative is to have
Paul Wouters writes:
> On Wed, 11 Apr 2012, Shane Kerr wrote:
>
>> Disabling DNSSEC validation for broken domains seems completely
>> rational, at least for some types of brokenness.
>
> So someone will make a browser plugin to enable this. Let them.
In our validation work within firefox we deli
Joe Abley writes:
> On 2012-04-11, at 12:09, Wes Hardaker wrote:
>> NTA example.com Thu Apr 12 09:06:42 PDT 2012
>
> I realise this is just a thought experiment
Well, true it certainly is. And in fact the above thought experiment
wasn't meant to imply a resource record, but rather a config lin
On Thu, Apr 12, 2012 at 08:27:21AM -0600, Stephan Lagerholm wrote:
> Specifically in this case, you are assuming that the parent knows the
> algorithms used for the DS record. He would have to in order to
> validate. That might not always hold true. Additionally, the record is
> not 'yours', it is
Mark,
On 12.04.2012, at 14:21, Marc Lampo wrote:
> > It holds an alternative possibility to overcome the problem
> > - for operators of validating name servers - of failing domains
> > because of DNSSEC.
> >
> > The alternative is to have a parent regularly (no frequency defined)
> > check the coh
Moin!
On 12.04.2012, at 14:21, Marc Lampo wrote:
> It holds an alternative possibility to overcome the problem
> - for operators of validating name servers - of failing domains
> because of DNSSEC.
>
> The alternative is to have a parent regularly (no frequency defined)
> check the coherence of D
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/12/2012 02:09 PM, Marc Lampo wrote:
> Hello all,
>
> (This also concerns the other discussion about "Negative Trust
> Anchors", I'll post with that subject as well)
>
> -Original Message- From: Matthijs Mekking
> [mailto:matth...@nlnetl
Hello,
this is not a reply to any comment already made on this approach
of "negative trust anchors".
(I just posted a reply with RFC4641bis in the subject, about this)
It holds an alternative possibility to overcome the problem
- for operators of validating name servers - of failing domains
beca
Hello all,
(This also concerns the other discussion about "Negative Trust Anchors",
I'll post with that subject as well)
-Original Message-
From: Matthijs Mekking [mailto:matth...@nlnetlabs.nl]
...
> Not only that, also the entities on the authoritative side
> don't have influence on th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/12/2012 12:48 PM, Marc Lampo wrote:
> Hello Matthijs,
>
> Regarding 1 - "... no relationship ... validating ... "
>
> Suggestion (a phrase that does not hint at any possible
> "relationship") : This document holds no information that applies
>
Hello Matthijs,
Regarding 1 - "... no relationship ... validating ... "
Suggestion (a phrase that does not hint at any possible "relationship") :
This document holds no information that applies to the configuration
of validating recursive name servers (validators).
Ok regarding 2 : three stages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Marc,
Coming back to your review items, I only think point 1 is not decided
on yet. But I don't think this should stop progress.
You can find my responses in between lines.
Best regards,
Matthijs
On 04/03/2012 11:11 AM, Marc Lampo wrote:
> Hel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alfred,
I have no further comments on part (A). I have also adopted the
leftovers in part (B), with explanation in between lines.
Best regards,
Matthijs
On 04/11/2012 10:08 PM, Alfred � wrote:
> Matthijs, again thanks for your quick and detailed r
16 matches
Mail list logo
