I understand Mark's concern, and it certainly has some merit, because the last thing we need is to encourage more junk traffic on the infrastructure. If there were a way to provide something in the SERVFAIL response that could discourage the retries such as an EDE, that is worth exploring.
I have long supported using a specific internal subdomain as the root of an internal namespace (e.g., INT.EXAMPLE.COM), rather than having an internal/external split of the parent. I would often recommend customers put some placeholder record in place in the external zone (e.g. an A record to 127.0.0.1, perhaps with a comment as to why) to prevent another administrator from inadvertently using the name. The proposal of a delegation to nowhere would better indicate to others what is going on. It also happens to provide a way to more easily DNSSEC sign internal namespace without having to manage additional trust anchors. I must call out, though, I think signing internal zones is a terrible idea in most cases, and it is not something I would want to encourage administrators to do in the vast majority of cases. I would imagine some people might call out advertising what internal namespaces are in use externally as a security risk, but the proposal merely provides a mechanism for those who wish to do so, it doesn't mandate it, so in my mind that is OK. Thanks, Ross On Fri, Nov 7, 2025 at 12:50 PM Joe Abley <jabley= [email protected]> wrote: > 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] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
