In message <3809dd3b-af63-492e-bc2d-e447ee4b3...@ogud.com>, Olafur Gudmundsson
writes:
>
> > On Mar 25, 2015, at 8:33 AM, Mark Andrews wrote:
> >
> >
> > In message
> , Tony Finch
> writes:
> >> John Dickinson wrote:
> >>>
> >>> I support this draft. One thing that jumped out to me was there
>
* Evan Hunt:
> Last night the dumb-idea fairy visited me as I was falling asleep, and
> suggested that another way to reduce the impact of ANY queries would be
> to pick *one* rrset and return just that. (Probably the numerically
> smallest rrtype present at the node, plus RRSIGs if any.)
Yes, th
On Mar 26, 2015, at 1:26 AM, Paul Vixie wrote:
> you make an excellent point. so, the spec might ask for repeatability,
> but not specify how that's to be achieved. it's still an information
> leak since the preferred type may have timed out of the cache, in which
> case an rdns would have to retu
A further thought...
My too-clever (not clever enough?) hack can cause problems downstream,
if you have
1. auth (DNSSEC) -> 2. cache (DNSSEC) -> 3. cache (insecure) -> 4. resolver
3 sends a DO=0 ANY query to 2
2 sends a DO=1 version of the query to 1
1 does ANY minimization and responds with
I like your proposed text so if there is no objection I suggest to
simply adopt it (and to close this particular point).
Thanks
francis.dup...@fdupont.fr
PS: for people who want to match the text here are the first 2 lines:
we should allow servers to use whatever timeout they want -- but we
* Tony Finch:
> What does 2 return to 3? It can't send a signed NSEC because DO=0.
ANY is special, you can get NSEC and RRSIG in responces with DO=0
(some implementations do that). With suitably aligned TTLs, I suppose
you can even end up with just a NSEC/RRSIG RRset pair.
NSEC3 is different be
At IETF this week it was decided to refocus the effort on the
edns-client-subnet draft on only documenting the existing behaviour of
deployed implementations.
To clarify some areas that were un/under-specified I am looking for
implementers of both recursive and authoritative servers at the
followi
On 26Mar15, David C Lawrence allegedly wrote:
> At IETF this week it was decided to refocus the effort on the
> edns-client-subnet draft on only documenting the existing behaviour of
> deployed implementations.
That's disappointing and somewhat at odds with the theme of the
on-list discussions sin
Mark Delany writes:
> On 26Mar15, David C Lawrence allegedly wrote:
> > At IETF this week it was decided to refocus the effort on the
> > edns-client-subnet draft on only documenting the existing behaviour of
> > deployed implementations.
>
> That's disappointing and somewhat at odds with the them
Ted Lemon wrote:
> On Mar 26, 2015, at 1:26 AM, Paul Vixie wrote:
>> you make an excellent point. so, the spec might ask for repeatability, but
>> not specify how that's to be achieved. it's still an information leak since
>> the preferred type may have timed out of the cache, in which case an
On Mar 26, 2015, at 4:28 PM, Paul Vixie wrote:
> what we should say in the spec is "determinative, and
> non-information-leaking", and let implementers scratch their heads about how
> to do that. we should not try to invent it here, or specify it in an ietf
> document.
I don't see how you can
Paul Vixie wrote:
> Ted Lemon wrote:
> > On Mar 26, 2015, at 1:26 AM, Paul Vixie wrote:
> >> you make an excellent point. so, the spec might ask for repeatability, but
> >> not specify how that's to be achieved. it's still an information leak
> >> since the preferred type may have timed out of t
On Thu, Mar 26, 2015 at 06:33:18PM -0500, Ted Lemon wrote:
> > what we should say in the spec is "determinative, and
> > non-information-leaking", and let implementers scratch their heads
> > about how to do that. we should not try to invent it here, or specify
> > it in an ietf document.
>
> I don
13 matches
Mail list logo
