Tim Wicinski <[email protected]> writes:
> This starts a Working Group Last Call for draft-ietf-dnsop-7706bis
Up front: as you know, I support this document fully being the driver
behind localroot.isi.edu that's mentioned in the document. That being
said, I do want to raise a few points/suggestions:
1. "... because negative answers are sometimes cached for a much shorter
period of time."
I'd like to suggest amending that with "time and because many queries
received at the roots are for leaked or garbage strings as well as
some many that are generated algorithmic by applications attempting
to detect NXDOMAIN rewriting". In particular, the vast vast majority
of the junk is not from low negative caching, but from the fact that
each queries are frequently different random garbage strings and the
vast majority of those are generated by Chromium based products (and
probably others at this point too).
2. The next paragraph talks about the benefits being weak for true
responses, due to caching, but as the root becomes more and more flat
as new gTLDs are added (with another round likely "soon"), this
statement will become more and more false.
3. Though the document has "relaxed" the specification to not require a
loopback address/interface, this is still functionally a no-op since
it still requires only serving data from the localhost. That's not
really relaxing it much; it just means functionally the same thing
with a slightly wider view of how to implement it.
4. In the second to last paragraph in the introduction, it might be
worth adding 'Some resolver software supports being both an
authoritative server and a resolver but separated by logical "views",
allowing a local root to be implemented within a single process'.
And you could even list the appendixes, where most of the example
configuration actually makes use of this notion.
5. In section 3, there are broken sentences:
"In a system that is using a local authoritative server for the root
zone. if the contents of the root zone cannot be refreshed before
the expire time in the SOA, the local root server MUST return a
SERVFAIL error response for all queries sent to it until the zone can
be successfully be set up again."
I think this is meant to be
"In a system that is using a local authoritative server for the root
zone, if the contents of the root zone cannot be refreshed before
the expire time in the SOA, the local root server MUST return a
SERVFAIL error response for all queries sent to it until the zone can
be successfully be set up again."
6. regarding the next paragraph: "In a resolver that is using an
internal service for the root zone. if the contents of the root zone
cannot be refreshed before the expire time in the SOA, the resolver
MUST immediatly switch to using non-local root servers."
You're prescribing implementation choices here, not the goal: the
goal is to prevent resolvers from returning stale data (though....
with serve-stale in effect too.......). There are two immediately
obvious choices for how to do this: 1) switch to non-local root
service, as you state. or 2) return SERVFAIL from the resolver.
E.G., I'm not sure existing implementations, including the config in
the appendix, follow this MUST. To aggrevate this issue further: I'm
not sure how a resolver would *know* that the data is stale from the
local root it is querying (there are hints of this later, but I have
issues with that too; see below). Functionally, this text is
mandating an architecture that is not likely implemented today and is
not likely to be implemented in the future (I'm guessing, but happy
to be proven wrong).
Wouldn't it be better to state simply "Resolvers MUST NOT return
stale data." But again, I'm not sure how to implement that without
requiring a very specific binding between the resolver and the local
root server, which is rather special-case. You have already
prescribed that the local root server itself should return SERVFAIL
and I think that's really all you need to, or can, prescribe.
7. In the last paragraph in 3, it requires the administrator to check
whether or not the SOA is fresh and shows a potential mechanism for
doing that. But, even that is subject to fail unfortunately. Again,
you're trying to get the resolver to be intelligent with data that it
doesn't have access to. That requirement should be put into the
local root server instead, and again is covered by having it return
SERVFAIL on out-of-compliance data. The resolver half of the
deployment can not test this easily, but the (potentially
pseudo-)authoritative server can. That's what the requirement should
be aimed at.
8. The security considerations talk about limiting damage from broken
deployments to "any other system that might try to rely on an altered
copy of the root.". I think, however, that the damage may be seen by
any client that depends on the resolver making use of a local root
server when the local root server becomes problematic. IE, if the
resolver is serving an enterprise and its localhost accessible local
root has a problem, the entire enterprise will have a problem.
9. In appendix A, can you please add "localroot.isi.edu" as a domain
from which you can AXFR the zone too? It's mentioned in the next
section.
10. For A.1, second paragraph about LocalRoot, can you replace with the
following text (assuming you agree with it):
The LocalRoot project (<https://localroot.isi.edu/>) is a service
that embodies many of the ideas in this document and is operated in
cooperation with USC/ISI's root server. It distributes the root
zone by AXFR, but also offers DNS NOTIFY messages when the LocalRoot
system sees that the root zone has changed, providing potentially
faster updates to local root implementations. It additionally
provides secured AXFR transfers, which helps defeat issues with
unsigned glue records being potentially modified in transit (see
Section 2).
11. For B.1, example config for Bind 9.12 - why is this not bind 9.11 (too)?
It's still a viable platform and is supported till 2021 Q4.
(also, it would be worth adding localroot.isi.edu to that and other
similar configs as well)
12. For B.3 (bind 9.14 with mirror): it's worth adding a note that by
using the mirror implementation you're actually using less upstreams
because it won't include the ICANN xfr (or localroot) sources.
13. B.3 says "when it is released" referencing 9.14. It was released
early this year I believe.
Phew. Sorry! But I do hope these are helpful, and again: I certainly
support this document going forward.
--
Wes Hardaker
USC/ISI
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
