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 > <[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]
