Hi all,
I presented today in Montréal about our proposal
draft-jabley-dnsop-zone-cut-to-nowhere.
https://datatracker.ietf.org/doc/draft-jabley-dnsop-zone-cut-to-nowhere/
Mark Andrews repeated his concern that I remember was mentioned at the mic in
Madrid. Mark, let me know whether I have got this right.
TL;DR I see Mark's point, I have tried to write the concern down so that we
have a clear shared picture of what it is, and I have dreamed up a couple of
ways to address it. I haven't yet talked to my co-authors so the hands that are
waving here are my personal hands.
Mark's Concern
Consider a zone cut to nowhere published in the EXAMPLE.COM zone for
CORP.EXAMPLE.COM. Then consider a stub resolver sending the query (QNAME =
CORP.EXAMPLE.COM) to a resolver A on the public Internet where the private
namespace CORP.EXAMPLE.COM is not available, which is configured to process
cache misses by sending queries to resolver B. So this is an example of a
chained resolver processing a query.
stub resolver ---> resolver A ---> resolver B ---> authoritative server
The authoritative server will return a referral of the form "CORP.EXAMPLE.COM.
IN NS ." Resolver B will not be able to follow that referral because there is
(intentionally) no child nameserver mentioned in it, and will return SERVFAIL
to resolver A. Resolver A will repeat the query to resolver B because SERVFAIL
invites retries. Mark's concern is that this retry behaviour is unnecessary and
potentially harmful.
Addressing Mark's Concern
1. Do nothing, this is not a concern we should worry about. This kind of junk
is all over the DNS, it's already happening with the existing (described) other
uses of hostname ".", not to mention misconfigurations where hostnames are used
but do not resolve properly; we are not going to eliminate all of these failure
modes by doing something different here.
2. Change signalling in zone data. Mark suggests a better response from the
authoritative server would be to return a referral from for the child that
includes the same NS set as the parent. This is clearly possible, but I think
it has the disadvantage that it is not as clear what the intention of the zone
administrator is. It also assumes that the NS set is coherent and doesn't
involve "enterprise DNS" trickery. I am also not sure I would predict that
existing deployed resolvers would interpret such a referral response in a way
that would not also result in SERVFAIL, e.g. following retries by resolver B to
all the listed authoritative servers. This just seems like it invites more
random weirdness, and that the weirdness will be harder to measure.
3. Change resolver behaviour. Resolver B SHOULD return a more useful signal
than SERVFAIL, maybe with an EDE or something. Resolver A SHOULD avoid retrying
if it receives such a signal. This would avoid the behaviour Mark is concerned
about in this draft, but would also clean up other uses of the hostname ".".
The camel is slightly sad, but perhaps it's worth it to avoid the cost of
retries for all the cases where "." is used in place of a real hostname to mean
"not provided".
4. This isn't a big enough problem to care about, all of 1 through 3 are
horrible, let's forget the whole idea.
Thoughts on this would be appreciated.
Joe
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
