On 29 Jan 2017, at 5:26, Ralph Droms wrote:
On Jan 28, 2017, at 4:22 PM, Paul Hoffman <paul.hoff...@vpnc.org>
wrote:
On 28 Jan 2017, at 12:28, Ralph Droms wrote:
I've submitted three issues to the doc repo:
Issue #8:
https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/8
<https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/8>
Add "context" as a facet in the definition of a naming system. A
naming system needs a context in which to perform resolution of a
name. As an example, "locally served DNS zones" (see Issue #10) use
the DNS resolution mechanism through a local context rather than
through the global root.
Is that "context" or "possible contexts"? That is, if you consider
1034/1035 as a naming scheme, it seems like there could be "the
global context" (the root servers that everyone assumed then) and "a
local context" (hosts.txt) or even a mixed context ("first try to
resolve in hosts.txt but then go to the root servers if you get an
NXDOMAIN", or even the reverse of that). Some naming schemes might
have other interesting mixes of context.
But I agree that something like this is a common, and
commonly-ignored, facet that would be useful to list.
I see your point about "possible contexts". I was thinking of what's
needed for the evaluation of one specific name. Another way to
describe the facet is what are the possible contexts.
How about:
* Contexts that can be used for resolving a name and obtaining its
associated data, and the way in which a context is specified for
resolution of a name
I'm OK with that for now, but hope that, after we have a definition for
"resolve", that we can remove the "and obtaining its associated data"
because that's part of resolving. (Maybe. Hopefully.)
I'd like to discuss your example a little. In my opinion, hosts.txt
lookup and DNS are two different naming systems. They happen to share
the same name syntax but use different resolution methods. The client
name resolution code gets handed a name from an app, and then uses one
or more naming systems - in sequence, if more than one - to resolve
the name. In your example, the client code might go to the hosts.txt
naming system first and then the DNS naming system.
Client code often goes to a stub resolver (which we do define in 7719).
A stub resolver might use the sequence I gave above; in fact, we know of
ones that do. So a naming system might go through different mechanisms
when doing resolution.
But I'm quite naive about the details and it may be common practice to
consider both hosts.txt and DNS server resolution part of the DNS
naming system.
Fortunately, it is not common on the Internet with respect to the global
DNS. Unfortunately, when it does happen, it causes collisions to have
negative consequences when names (not just new TLDs) are added to the
DNS.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
