Subject: [DNSOP] Terminology issue #8: context

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 28 Jan 2017 13:22:37 -0800

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.

--Paul Hoffman

---

From: Ralph Droms <[email-masked]>
Date: Sun, 29 Jan 2017 08:26:24 -0500

> On Jan 28, 2017, at 4:22 PM, Paul Hoffman <[email-masked]> wrote:
> 
>> 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'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.

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.

- Ralph

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 29 Jan 2017 14:32:26 -0800

On 29 Jan 2017, at 5:26, Ralph Droms wrote:

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

---

From: Ralph Droms <[email-masked]>
Date: Sun, 29 Jan 2017 21:47:45 -0500

> On Jan 29, 2017, at 5:32 PM, Paul Hoffman <[email-masked]> wrote:
> 
> 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.)

Hm.  I hadn't noticed I used the words "resolving" and "resolution" without definition (either mine or elsewhere in the doc).  I'll also admit that I'm still framing this discussion in my head in terms of my PhD work of 30 years ago, when papers by Shoch and Saltzer were a little more current and we had a lot less operational experience cluttering the conversation.

Looking back more carefully at the other facets of a naming system, how about:

* Contexts in which the protocol is applied to get data from a name, and the way in which a context is specified for that application of the protocol

> 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.

Following the pointers to RFC 1123, it seems a stub resolver only performs DNS name resolution.  Not meaning to be pedantic, in my opinion there is another type of resolution mechanism in a client, which chooses between different naming systems and contexts, one of which is the global DNS (accessed through the stub resolver).  I understand that draft-ietf-dnsop-terminology-bis is about DNS terminology, but if we agree about that mechanism for choosing among naming systems, we should consider naming and defining it in draft-ietf-dnsop-terminology-bis.

> 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.

Thanks for the clarification...

- Ralph