There used to be three major reasons I was opposed to it, and the proposal in the draft provides an approach to address one of them (how to tie in to the chain of trust).
The second is that in many cases internal zones are both large and updated dynamically. An internal zone with hundreds of thousands of records in it already doesn't need hundreds of thousands more, and if you have high dynamic update rates as well, it can put an incredible additional strain on an infrastructure perhaps to the point of requiring additional resources than would otherwise be required. The third, and most significant reason is that in most enterprise internal infrastructures I have come across the stub resolvers are directly querying the servers that are authoritative for the internal zones. In that scenario, signing those zones is completely pointless. Given that validation is being performed by the recursive server (which is also the authoritative server in these cases) not the stub resolver, there is nothing for the server to validate because it is already authoritative for the zone. That isn't to say that there are never use cases where there may be some benefit, as Scott pointed out in his response, but in most enterprise environments, it would add little or no value. With all that said, while I don't think signing internal zones is a good idea in the vast majority of cases, I do fully support validation and DNSSEC signing for external zones. Thanks, Ross On Sun, Nov 9, 2025 at 3:36 AM Ted Lemon <[email protected]> wrote: > Why is signing internal zones a bad idea? Seems like a good idea to me, > but I haven’t been able to do it at scale so maybe I’m missing something? > > On Sat, Nov 8, 2025, at 11:05 PM, Ross Gibson wrote: > > 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] > > > _______________________________________________ > 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]
