In message <20160413135720.0504d...@pallas.home.time-travellers.org>, Shane Ker
r writes:
> Ray,
>
> At 2016-04-13 12:06:25 +0100
> Ray Bellis wrote:
>
> > On 13/04/2016 12:01, Shane Kerr wrote:
> >
> > > A third answer which falls outside of any of the current proposals is
> > > that there shoul
Also note we can do both _ta-/NULL and a EDNS option with
_ta-/NULL being the short term solution and the EDNS option
being a long term solution. Aggressive negative caching is potentially
going to have a impact on _ta-/NULL as all the _ta- labels
are going to be in the same NSEC
All,
First, thanks everyone for a very successful and productive WG meeting at IETF
95 last week— 2 sessions, 16 drafts on the agenda, plenty of good discussion.
We’ve got a couple of calls for adoption and WGLC to kick off in the next week
or two; we'll do that, as usual, in separate threads.
In message <88710f7e-4a46-4814-89a9-040a98a79...@verisign.com>, "Wessels, Duane
" writes:
>
> > On Apr 13, 2016, at 1:56 PM, Mark Andrews wrote:
> >=20
> >=20
> > In message , "Wessels,=
> Duane" writes:
> >>=20
> >>> On Apr 13, 2016, at 6:54 AM, Shane Kerr
> >> wrote:
> >>=20
> >>>=20
> >>> W
> On Apr 13, 2016, at 1:56 PM, Mark Andrews wrote:
>
>
> In message , "Wessels,
> Duane" writes:
>>
>>> On Apr 13, 2016, at 6:54 AM, Shane Kerr
>> wrote:
>>
>>>
>>> While the QNAME approach does feel a bit like a hack, I have to admit
>>> that it probably is slightly better. I can't even t
In message , "Wessels,
Duane" writes:
>
> > On Apr 13, 2016, at 6:54 AM, Shane Kerr
> wrote:
> >
> > Mark,
> >
> > At 2016-04-07 20:48:43 -0300
> > Mark Andrews wrote:
> >
> >> Warren. In both cases receiving a query with either a option or a
> >> qname encoding ids it is a indication that the
At Sun, 10 Apr 2016 10:18:11 -0400,
Tim Wicinski wrote:
> This starts a Call for Adoption for Aggressive use of NSEC/NSEC3
> draft-fujiwara-dnsop-nsec-aggressiveuse
>
> The draft is available here:
>
> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/
>
> Please review thi
> On Apr 13, 2016, at 6:54 AM, Shane Kerr wrote:
>
> Mark,
>
> At 2016-04-07 20:48:43 -0300
> Mark Andrews wrote:
>
>> Warren. In both cases receiving a query with either a option or a
>> qname encoding ids it is a indication that the IP address or the
>> clients behind the IP address have th
On Thu, 7 Apr 2016, John Levine wrote:
We could have written
“After observing CDS records for 15 days or 2 resigning cycles which ever is
longer, accept them and upload DS”
Is that better ?
It sets expectations
I think my users (the ones who know about DNSSEC) would not be happy
to hear that
On Wed, 13 Apr 2016, Shane Kerr wrote:
While the QNAME approach does feel a bit like a hack, I have to admit
that it probably is slightly better. I can't even think of useful
information that having both approaches would add
Yes, and if you use _trustanchor instead of _ta, you could also u
Mark,
At 2016-04-07 20:48:43 -0300
Mark Andrews wrote:
> Warren. In both cases receiving a query with either a option or a
> qname encoding ids it is a indication that the IP address or the
> clients behind the IP address have the trust anchor configured. You
> may receive a option without the
Ray,
At 2016-04-13 12:06:25 +0100
Ray Bellis wrote:
> On 13/04/2016 12:01, Shane Kerr wrote:
>
> > A third answer which falls outside of any of the current proposals is
> > that there should be a way to document what the capabilities of an
> > authority server are explicitly. If only there was
On 13/04/2016 12:01, Shane Kerr wrote:
> A third answer which falls outside of any of the current proposals is
> that there should be a way to document what the capabilities of an
> authority server are explicitly. If only there was a way to store
> meta-data about hosts in some sort of distribu
Evan,
At 2016-04-12 00:01:20 +
Evan Hunt wrote:
> On Mon, Apr 11, 2016 at 09:13:42PM +, Adrien de Croy wrote:
> > If we simply added a new QTYPE which permitted a server to respond with
> > all matching A and records then that would solve a lot of problems.
>
> As far as I've s
14 matches
Mail list logo