On 26 Sep 2015, at 2:55, Terry Manderson wrote:
Thank you for writing this document and describing how it is done and
also the risks of doing this, and most importantly why it should not
be
done on a whim or by default.
I concur that this is not a new idea. In fact I implemented a similar
thing during my ISP days in the late 90's and it was certainly more
beneficial then due to the low change rate of the root zone, and the
absence of DNSSEC, along with slower network speeds, and less
instances
of anycasted root-serves. That said, the operational costs were the
same
and they have been well covered in the doc.
That's good to hear.
Can you please pay a little attention to the first sentence of the
security considerations? Its a doozy and I had to re-read it a couple
time to be clear on its meaning.
Earlier versions of the draft had shorter explanations, but folks wanted
us to be more and more precise. It's hard to write a security
consideration that says "if you do what we describe in this document but
not that one bit over there".
In the appendix, different locations to get the zone by AXFR are
specified. Have you considered highlighting that the zone can be
collected from authoritative points in other ways?
e.g.
- https://www.iana.org/domains/root/files (noting ftp and http
methods.
- https://http.l.root-servers.org (and plain http)
(and of course there may well be others, but I'll refrain from boiling
that ocean)
We considered it, but decided against it for a few reasons.
- As the first sentence says, if the zone you get comes with all the
DNSSEC records and it validates, it doesn't mater where you got it.
- Earlier drafts listed other places that we thought were fine, but late
in the process we discovered were not.
- We would really rather not say "authoritative" in this document. We
didn't say that the root servers were "authoritative", just convenient.
I would also like to see the observation made that no public AXFR
service
(that I am aware of) uses TSIG, so the fetching party is at the
general
risk exposure of non-TSIG AXFR. Not so much in terms of modifying data
in
the zone (as it's signed and the DNSSEC support on the recursive
resolver
is a MUST) but in a MiTM effort to simply withhold new versions of the
root zone in a DoS frame.
As Mark Andrews pointed out, TSIG doesn't help prevent MiTM blocking
updates.
--Paul Hoffman and Warren Kumari
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
