Patrik, My personal view is that, if the same (or an extremely similar) term is in use for the cases you enumerate, especially if most of those who use it think they are saying something precise, we are better off listing those cases and making the possible confusion clear. In particular, saying something that appears to point to one particular case and ignoring the others is likely to cause more problems than it solves. For this case, the current definition falls somewhere in between. Partially, I think, because it is a little vague it is not nearly as bad as saying "this is the definitive definition and the term always applies to this case" but not nearly as good as the sort of enumeration you suggest. best, john --On Thursday, August 16, 2018 08:11 +0200 Patrik Fältström <paf@xxxxxxxxxx> wrote: > On 15 Aug 2018, at 22:01, John C Klensin wrote: > >> In that regard, I find the document's definition of "split >> DNS" a little bit frustrating, as I have seen (multiple >> times) a distinction made between names (or a zone) that >> would clearly be part of the public DNS except that they are >> hidden from view and names that are part of a different >... > Is it the case that various alternatives should be enumerated? > > a. When a domain name is used for access to a service we might > have: > > a.1. The same DNS response regardless of who sends the query > (this is the default for DNS) > > a.2. Different responses depending on context (where query is > sent from etc), but still same service (this is CDN) > > b. When different services are accessed depending on context > (enterprise setup) > > b.1. A service is available or not depending on context, > implemented via DNS response or not (version of a.1) > > b.2. Different services are available depending on context, > implemented via different DNS responses > > c. The special case of (b) based on use of different root zone > > : > : > : > > Patrik
