On Tue, 8 Jul 2014, Olafur Gudmundsson wrote:
On Jul 8, 2014, at 7:40 AM, ? Roy Arends <r...@dnss.ec> 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 overhead,
eliminates an attack vector.
(possibly some more questions or variations for the draft to consider)
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?
How do I as a user know if there's a stale copy of the root zone being
slaved^H^H^H^H^H^H^H supplied by my ISP? (is not being able to reach
wyle.e.coyote.acme enough to give me that hint?)
How do I know if my ISP, etc. are running a local copy of the zone? Can I
call RSACC to complain about an outage?
(In other words, what are the mechanisms for someone to figure this out
before calling the helpdesk, or, should the draft say to call if you
suspect something is wrong? They'd probably do it anyways...maybe. Yes,
I'm rhetorical here, DNSSEC etc for mitigation, etc.)
Roy
Roy
you hit the nail on the head, this is a no brainer as a BCP.
The contents of this draft may or may not be right at this point but we need a
BCP that explains how to do this and the pitfalls to be aware off.
BCP or informational (cautionary tales)?
For an DNS resolution provider that elects to there are two ways to do it,
forward zone
local authoritative zone.
both should be allowed, this document seems ?bind? specific that it assumes
that the recursive resolver can be both authoritative and recursive which is
not a requirement.
There is no need that every recursive resolver at a Resolution Provider have a
copy of the root zone only that the resolvers know the ?local root servers?.
I see mentions of 'Resolution Provider'. Is this a BCP for only them, or
can anyone join the local auth zone party at their own risk/pleasure, at
which point it's informational or still BCP? What is the litmus test?
In my mind this is not that far off from Anycast root servers i.e. additional
server placed closer to the query generators.
The big difference is in management and control.
There were good intentions behind the Cymru bogon list. Every once in a
while, we start to see complaints of former bogons being unreachable
because they're no longer bogons. Is there a similar risk for that here
and should it be identified?
The root server operators believe (correctly) that they provide valuable
service and are critical to the operation of the internet, They also believe
that having
close control over all root servers is essential.
A number of people over the years have said that the current model is not the
only possible way to provide the same service just as well,
further diversification of root server services is enabled by DNSSEC.
The open question is does the promotion of this type of service create any NEW
attacks agains the CONTENT of the root zone,
i.e. would this have made the it possible/easier for Turkey to restrict access
to Google and Twitter?
The technical question that needs to be answered what is the safest way to
distribute the root zone and locally validate it before making it available on
the
?local root servers?. In my mind the answer Notify and incremental XFR with
stronger protections.
I think the answer is NO thus I support the promotion of a BCP on ?locally
provided root servers?.
Olafur
On 04 Jul 2014, at 21:50, 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, and hope to discuss it in the WG in
Toronto.
--Paul Hoffman
Begin forwarded message:
From: internet-dra...@ietf.org
Subject: I-D Action: draft-wkumari-dnsop-dist-root-01.txt
Date: July 3, 2014 at 2:17:46 PM PDT
To: i-d-annou...@ietf.org
Reply-To: internet-dra...@ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : Securely Distributing the DNS Root
Authors : Warren Kumari
Paul Hoffman
Filename : draft-wkumari-dnsop-dist-root-01.txt
Pages : 9
Date : 2014-07-03
Abstract:
This document recommends that recursive DNS resolvers get copies of
the root zone, validate it using DNSSEC, populate their caches with
the information, and also give negative responses from the validated
zone.
[[ Note: This document is largely a discussion starting point. ]]
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-dist-root/
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-wkumari-dnsop-dist-root-01
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop-dist-root-01
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
wfms
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
