I would suggest there is also a third angle here:
On Jul 8, 2014, at 11:30 PM, "yzw_iplab"
mailto:yzw_ip...@163.com>>
wrote:
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)
Declan Ma wrote:
> 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,
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
On 8 jul 2014, at 08:22, David Conrad wrote:
> On Jul 7, 2014, at 10:02 PM, Patrik Fältström wrote:
>>> The main argument against slaving the root I've seen appears to me to be
>>> FUD: "people running resolvers are too stupid to configure slaving the root
>>> correctly so root data will go st
Patrik,
On Jul 7, 2014, at 10:02 PM, Patrik Fältström wrote:
>> The main argument against slaving the root I've seen appears to me to be
>> FUD: "people running resolvers are too stupid to configure slaving the root
>> correctly so root data will go stale!" (paraphrased).
>
> I am a bit disapp
On 8 jul 2014, at 02:55, David Conrad wrote:
> The main argument against slaving the root I've seen appears to me to be FUD:
> "people running resolvers are too stupid to configure slaving the root
> correctly so root data will go stale!" (paraphrased).
I am a bit disappointed that you David d
On Jul 7, 2014, at 4:36 PM, Paul Vixie wrote:
>>> that's why query minimization is the preferred solution to this problem.
>> This isn't either/or.
> are you proposing to solve problem A (junk queries at the root) and problem B
> (junk queries at tld's and pseudo-tld's) using different mechanisms
David Conrad wrote:
> Paul,
>
>
> ...
>> that's why query minimization is the preferred solution to this problem.
>
> This isn't either/or.
are you proposing to solve problem A (junk queries at the root) and
problem B (junk queries at tld's and pseudo-tld's) using different
mechanisms? why is th
Andrew,
On Jul 7, 2014, at 12:44 PM, Andrew Sullivan wrote:
> It's true that the draft sort of allows an operator to
> be master of its own fate. But it does require -- and indeed, the
> coherence (however loose) of the DNS requires -- that one fall back to
> asking a "real" root server in the e
Paul,
On Jul 6, 2014, at 9:14 PM, Paul Vixie wrote:
> there are far more errors encountered below .com or .de than by their
> siblings in the root. any argument in favour of wide scale slaving of the
> root zone begs the question, why not every tld and every pseudo-tld (such as
> no-ip.org)? t
Hi,
On Mon, Jul 07, 2014 at 12:27:36PM -0700, David Conrad wrote:
>
> This draft attempts to document a way in which organizations can
> choose to be the masters of their own fate when it comes to root
> name service instead of relying on a set of 12 (or 11, depending on
> your point of view) vol
Joe,
I was in the middle of a long, extremely eloquent point-by-point rebuttal when
I realized it was pointless: we're approaching the draft from completely
different directions and I strongly doubt anything I might say might change
your mind.
However, I did want to focus on one point. To qu
Hi Paul,
No oars - just a bit of a broken paddle.
On 7/07/2014 2:14 pm, "Paul Vixie" wrote:
>
>
>right now, root name servers are part of an explicit, hand-maintained
>NOTIFY tree. thus, all internet actions depending on root zone content
>have up-to-the-minute data if not up-to-the-second data
In message <53ba1e98.9030...@redbarn.org>, Paul Vixie writes:
>
> i am not joe, but i strongly +1'd his response on this thread, so i'm
> putting my oar back into the water now.
>
> Mark Andrews wrote:
> > In message , Joe Abley wri
> tes:
> >>
> >> 5.1. Pros
> >>
> >> o Junk queries / negative
i am not joe, but i strongly +1'd his response on this thread, so i'm
putting my oar back into the water now.
Mark Andrews wrote:
> In message , Joe Abley
> writes:
>>
>> 5.1. Pros
>>
>> o Junk queries / negative caching - Currently, a significant number
>>of queries to the root servers are
In message , Joe Abley writes
:
> Hi Paul, Warren,
>
> On 4 July 2014 at 16:50:08, Paul Hoffman (paul.hoff...@vpnc.org) wrote:
>
> > Greetings. Warren and I have done a major revision on this draft,
> narrowing the design
> > goals, and presenting more concrete proposals for how the mechanism
Moin!
On 05 Jul 2014, at 18:11, Joe Abley wrote:
> TL;DR: there are way more cons than pros to this proposal. The pros listed
> are weak; the cons listed are serious. I don't see a net advantage to the DNS
> (or to perceived performance of the DNS for any client) here. This proposal,
> if impl
Joe Abley wrote:
> Hi Paul, Warren,
>
> On 4 July 2014 at 16:50:08, Paul Hoffman (paul.hoff...@vpnc.org) wrote:
>
>> Greetings. Warren and I have done a major revision on this draft, narrowing
>> the design
>> goals, and presenting more concrete proposals for how the mechanism would
>> work.
Hi Paul, Warren,
On 4 July 2014 at 16:50:08, Paul Hoffman (paul.hoff...@vpnc.org) wrote:
> Greetings. Warren and I have done a major revision on this draft, narrowing
> the design
> goals, and presenting more concrete proposals for how the mechanism would
> work. We welcome
> more feedback,
Greetings. Warren and I have done a major revision on this draft, narrowing the
design goals, and presenting more concrete proposals for how the mechanism
would work. We welcome more feedback, and hope to discuss it in the WG in
Toronto.
--Paul Hoffman
Begin forwarded message:
> From: interne
55 matches
Mail list logo
