[I added dns-privacy to the cc list, since that seems like a relevant
forum for this discussion.]
On Mon, 07 Jul 2014 11:04:56 -0700, Paul Vixie wrote:
>Matthäus Wander wrote:
>
>...
>
>I didn't mean to imply that a DTLS solution can be universally deployed.
>
>
>because the dns is a
Zhiwei,
Your proposal seems reasonable. But we can not separate the
recursive-level and authorative-level, as you call it by the way, since the DNS
is an integrated one. If both of the two solutions are feasible, we need to
figure out how and to what extent, both solutions could collabo
Hi, all,
There are currently two solutions proposed to distrbute the DNS root service
more widely.In my opinion, we should work on this issue following the two steps:
1) we should discuss their feasibility from technological aspects. the
technological requirements of them should be gathered and l
On 9/07/2014 5:17 am, "David Conrad" wrote:
>On Jul 8, 2014, at 9:17 AM, Joe Abley wrote:
>> Perhaps a way forward here is to reign in the current effort and
>>constrain it to the best way of using a local copy of the root zone on a
>>resolver today, with no protocol or specification changes t
On 8 jul 2014, at 20:30, David Conrad wrote:
> On Jul 7, 2014, at 11:39 PM, Patrik Fältström wrote:
>> One could say the discussion is a typical non-constructive IETF discussion
>> which too many are.
>
> Seems like it has been (mostly) a constructive discussion to me.
Now yes, I completely
On Jul 8, 2014, at 3:17 PM, David Conrad wrote:
> On Jul 8, 2014, at 9:17 AM, Joe Abley wrote:
>> Perhaps a way forward here is to reign in the current effort and constrain
>> it to the best way of using a local copy of the root zone on a resolver
>> today, with no protocol or specification c
On Jul 8, 2014, at 9:17 AM, Joe Abley wrote:
> Perhaps a way forward here is to reign in the current effort and constrain it
> to the best way of using a local copy of the root zone on a resolver today,
> with no protocol or specification changes to resolvers. Once we've identified
> the best s
On Jul 8, 2014, at 9:17 AM, Joe Abley wrote:
> Perhaps a way forward here is to reign in the current effort and constrain it
> to the best way of using a local copy of the root zone on a resolver today,
> with no protocol or specification changes to resolvers. Once we've identified
> the best s
William,
On Jul 8, 2014, at 7:28 AM, William F. Maton Sotomayor wrote:
> How can I as a user ensure that what Google does in the name of moi, can be
> verified to be an untampered copy of the root zone?
The same way you can do so now: you validate the response yourself.
> How do I know if my I
Paul,
On Jul 8, 2014, at 7:18 AM, Paul Hoffman wrote:
> None of the above relates to Joe's big issue, which is that implementing the
> draft doesn't help anyone much. To me, that's a much more valid (and
> measurable) criticism than anything on the list above.
I believe section 5.1 discusses t
Patrik,
On Jul 7, 2014, at 11:39 PM, Patrik Fältström wrote:
> One could say the discussion is a typical non-constructive IETF discussion
> which too many are.
Seems like it has been (mostly) a constructive discussion to me.
>>> Once again, this is such a large issue that I would prefer a bit
On Jul 8, 2014, at 10:28 AM, William F. Maton Sotomayor
wrote:
>
> On Tue, 8 Jul 2014, Olafur Gudmundsson wrote:
>
>>
>> On Jul 8, 2014, at 7:40 AM, ? Roy Arends wrote:
>>
>>> Hiya,
>>>
>>> I really like this idea. Many ISPs already do this, (including some high
>>> profile public recurs
On Jul 8, 2014, at 12:33 PM, Tony Finch wrote:
> Olafur Gudmundsson wrote:
>>
>> this document seems “bind” specific that it assumes that the recursive
>> resolver can be both authoritative and recursive which is not a
>> requirement.
>
> You can't implement this draft's validation and fallba
George Michaelson wrote:
> whats the issue with the cycle time to validate whats in a blob you fetch,
> against fetching the elements inside that blob on demand and processing
> them?
Time is not the issue.
Ralf seemed to be suggesting that lazy validation is OK, where you simply
slave the root
On Jul 8, 2014, at 9:15 AM, Jim Reid wrote:
> FWIW I wonder if "MUST validate" is good enough when there's no mention of
> the One True Trust Anchor which presumably should be used for that.
If a message (in this case, an RRset) is signed with a public key, the
validator needs to use that exac
Olafur Gudmundsson wrote:
>
> this document seems “bind” specific that it assumes that the recursive
> resolver can be both authoritative and recursive which is not a
> requirement.
You can't implement this draft's validation and fallback requirements just
by configuring BIND, so I think all name
On Jul 8, 2014, at 9:00 AM, Patrik Fältström wrote:
> Note that I only listed a hand full of issues I immediately think of that I
> think needs to be compared and evaluated. Like Suzanne wrote. In some cases
> there is no difference between an auth server and cache, in other cases there
> migh
whats the issue with the cycle time to validate whats in a blob you fetch,
against fetching the elements inside that blob on demand and processing
them?
what do you think DNS implementors do with the DS/DNSKEY validations they
perform along the FQDN each time? do you think they always throw away a
Hi Roy!
On 8 July 2014 at 7:40:22, 🔒 Roy Arends (r...@dnss.ec) wrote:
> I really like this idea. Many ISPs already do this, (including some high
> profile public
> recursives, like Google and OpenDNS), because it simply makes sense: It
> reduces latency
> for the end user, reduces outbound
On 8 Jul 2014, at 16:40, Tony Finch wrote:
> Jim Reid wrote:
>> On 8 Jul 2014, at 16:14, Tony Finch wrote:
>>
>>> simply slaving the root zone doesn't give you any good way to detect
>>> or recover from a corrupted zone transfer.
>>
>> If that's a credible threat/risk, there are ways to mitig
Roy Arends wrote:
>
> I would also like to see some facilitation around this as well: a notify
> service of new versions, a zone distribution service (xfer service),
> possibly out of ICANN or VeriSign.
Does it need a notification service when the zone update period (every 12
hours ish) is much l
George Michaelson wrote:
> are you saying that to pre-validate signed materials along a trust chain
> outside some immediate context (x) is inherently invalid? whats the limit
> on x? seconds? microseconds?
I'm sorry I can't parse that.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Viking: Va
Paul Hoffman wrote:
>
> Just to be clear: you are saying that what we actually say to in the
> draft doesn't have the "too late" issue you refer to above, correct?
Right.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Dover, Wight: Variable 4 becoming northwest 4 or 5, occasionally 6 later.
Sli
Note that I only listed a hand full of issues I immediately think of that I
think needs to be compared and evaluated. Like Suzanne wrote. In some cases
there is no difference between an auth server and cache, in other cases there
might be.
> On 8 jul 2014, at 16:18, Paul Hoffman wrote:
>
>> O
On Jul 8, 2014, at 8:45 AM, Tony Finch wrote:
> Paul Hoffman wrote:
>> On Jul 8, 2014, at 8:14 AM, Tony Finch wrote:
>>>
>>> I think that is too simplistic: simply slaving the root zone doesn't give
>>> you any good way to detect or recover from a corrupted zone transfer. By
>>> the time norma
are you saying that to pre-validate signed materials along a trust chain
outside some immediate context (x) is inherently invalid? whats the limit
on x? seconds? microseconds?
don't all cacheing resolves cache common path trust checks under the TTL of
the elements along the path anyway?
On Wed,
Paul Hoffman wrote:
> On Jul 8, 2014, at 8:14 AM, Tony Finch wrote:
> >
> > I think that is too simplistic: simply slaving the root zone doesn't give
> > you any good way to detect or recover from a corrupted zone transfer. By
> > the time normal DNSSEC validation has detected any problems it is
Jim Reid wrote:
> On 8 Jul 2014, at 16:14, Tony Finch wrote:
>
> > simply slaving the root zone doesn't give you any good way to detect
> > or recover from a corrupted zone transfer.
>
> If that's a credible threat/risk, there are ways to mitigate it. Perhaps
> v2 of this draft could discuss thes
On Jul 8, 2014, at 8:14 AM, Tony Finch wrote:
> Ralf Weber wrote:
>>
>> I think if we think of the resolver having another auth root server at
>> localhost the logic is easier to understand makes much more sense as
>> DNSSEC protections would kick in even if someone managed to inject a bad
>> z
Moin!
On 08 Jul 2014, at 17:14, Tony Finch wrote:
> Ralf Weber wrote:
>>
>> I think if we think of the resolver having another auth root server at
>> localhost the logic is easier to understand makes much more sense as
>> DNSSEC protections would kick in even if someone managed to inject a bad
On 8 Jul 2014, at 16:14, Tony Finch wrote:
> simply slaving the root zone doesn't give you any good way to detect or
> recover from a corrupted zone transfer.
If that's a credible threat/risk, there are ways to mitigate it. Perhaps v2 of
this draft could discuss these.
FWIW in playing with DN
Ralf Weber wrote:
>
> I think if we think of the resolver having another auth root server at
> localhost the logic is easier to understand makes much more sense as
> DNSSEC protections would kick in even if someone managed to inject a bad
> zone.
I think that is too simplistic: simply slaving the
On Tue, 8 Jul 2014, Olafur Gudmundsson wrote:
On Jul 8, 2014, at 7:40 AM, ? Roy Arends wrote:
Hiya,
I really like this idea. Many ISPs already do this, (including some high
profile public recursives, like Google and OpenDNS), because it simply makes
sense: It reduces latency for the end
On Jul 7, 2014, at 10:02 PM, Patrik Fältström wrote:
> - Recovery process when bad data end up in the resolver (cache v.s. auth)
That's the "cache has gone stale" issue that David raised. It is dealt with in
the current draft. There is no other way for "bad data" to be in the cache
other than
Colleagues,
We have two drafts on the general topic of wider distribution for the root
zone, and the draft agenda says we'll devote some time to both of them.
The drafts discuss different methods, which may or may not be complementary,
each having strengths and weaknesses to consider. It's no
On Jul 8, 2014, at 7:40 AM, 🔒 Roy Arends wrote:
> Hiya,
>
> I really like this idea. Many ISPs already do this, (including some high
> profile public recursives, like Google and OpenDNS), because it simply makes
> sense: It reduces latency for the end user, reduces outbound traffic
> overhea
Hiya,
I really like this idea. Many ISPs already do this, (including some high
profile public recursives, like Google and OpenDNS), because it simply makes
sense: It reduces latency for the end user, reduces outbound traffic overhead,
eliminates an attack vector.
This specific document shouldn
37 matches
Mail list logo
