Subject: [Dbound] Starting point

From: Edward Lewis <[email-masked]>
Date: Tue, 11 Feb 2014 16:15:36 -0800

I've been thinking about this problem for quite a while.  I've never been a fan of making the zone delegation points apparent in the DNS but I do understand the need to draw a bounds around the set of zones under one management realm.

One of the parts of the DNS I've always had a hard time explaining to newcomers is the difference between a "zone" and a "domain" and anyone familiar with the DNS protocol can probably relate to that.  That two zones may be administered by the same person or by two independent organizations makes is all the more annoying.

The first aspect I'd like to nail down is - what's the purpose of exposing the "meaningful" zone cuts.  I get that there is value but, what's the goal.  For the sake of knowing whether solutions answer the need, it helps to know what is needed.

The second aspect to examine is whether this is in-band to the DNS, out of band, or if there is just a "hook" - a reference DNS RR type that points to another service.

Jumping to a conclusion, which I know is a mistake, is that I have a sneaking suspicion that this will need to be out of band.  In as much as the public suffix list is out of band, I believe (and I emphasize that word) that trying to put a definitive statement about a zone's "intentions" or "relation to its parent/child" will not be the best approach.  This comes from my wondering - "if this is about security, what if the zone's apex is lying."

I'll be interested to see how this develops.

---

From: "John Levine" <[email-masked]>
Date: 12 Feb 2014 01:18:08 -0000

These are all good questions.

>Jumping to a conclusion, which I know is a mistake, is that I have a sneaking suspicion that this will need to be out of
>band.

You're probably right for a variety of reasons, including that it
seems impractical to ask DNS operators to put a new RR at every name
for which they want to say it's inside or outside some boundary.

My I-D (at least some versions of it) has a strawman where the
boundary stuff is in the DNS but in a parallel hierarchy underneath
each TLD which makes it relatively easy to cover subtrees with
wildcards, to get coverage similar to what the PSL provides now.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 12 Feb 2014 08:58:46 +0100

> The first aspect I'd like to nail down is - what's the purpose of exposing the "meaningful" zone cuts.  I get that there is value but, what's the goal.  For the sake of knowing whether solutions an…

Ignoring the engineering that follows.

Ed,

You seem to focus on the managerial areas in the DNS (the zones, In
RR-terms starting at a SOA and ending at some delegation NS).

Is there a requirement to have even finer, or broader level of control?
Let me use the word sphere for that. Is there a requirement to work with
spheres that could be a subset of a zone or a set of various zones in
several domains?

I have no idea if or why one would need such concept, if we frantically
need to look for requirements then not, but if there are some obvious
used cases, then it is probably good to document those.

--Olaf

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Feb 2014 07:49:06 -0800

Let's say I'm focused on the architecture of the DNS (protocol) as opposed to the management of the DNS.  Within the protocol there is precedent to manage individual names (dynamic update can authorize changes to just a one name for a authenticated agent) but the protocol itself is ordinarily managed on the basis of zones.  The concept is that if a person wants to control a set of names they can come to me and I'd delegate a subdomain of mine to them - by creating a zone cut.  That's the DNS concept of allocating names - and I stress the DNS concept (as opposed to the only one "ever").

I say this to, first apologize for my DNS bias here, highlight that I'm thinking of the overall DBOUND issue from one perspective.  There are others - which may or may not want to group names in some fashion other than by zone.  Frankly, that was not on my mind.  Perhaps someone has a need to do that and that is implementable.

I too have nothing in my imagination regarding "spheres" (as Olaf called them) but perhaps there is someone that does.  In other words, I can't rule then in, but I also wouldn't rule them out "with prejudice" (meaning, "hey, no way!").  At a pre-BoF meeting stage I'd list this as an open question which - in my opinion and just that - wouldn't be something that gets addressed.  But perhaps there are users of the DNS that have workable stories built on them.

________________________________________
From: Dbound [[email-masked]] On Behalf Of Olaf M. Kolkman [[email-masked]]
Sent: Tuesday, February 11, 2014 11:58 PM
To: [email-masked]
Subject: Re: [Dbound] Starting point

Ed,

--Olaf

---

From: "John Levine" <[email-masked]>
Date: 12 Feb 2014 18:30:59 -0000

>spheres that could be a subset of a zone or a set of various zones in

There's certainly no requirement.  It might be someone's wish list,
but if we end up with something that requires that people create a
zone boundary if they want a dbound boundary, I don't think it'd be
the end of the world.

R's,
John

---

From: Joe Abley <[email-masked]>
Date: Wed, 12 Feb 2014 14:41:13 -0500

> The first aspect I'd like to nail down is - what's the purpose of exposing the "meaningful" zone cuts.  I get that there is value but, what's the goal.  For the sake of knowing whether solutions an…

I think what we're talking about is a different kind of boundary.

A zone cut is a protocol boundary.

I think the PSL represents examples of administrative boundaries (e.g. which are used to infer security boundaries for accepting cookies).

A single administrative realm (trying hard not to use the word domain, here) might contain multiple DNS zones, e.g. UK and CO.UK are separated by a protocol boundary/zone cut, but there's no administrative boundary between UK and CO.UK. There will be an administrative boundary between UK and ABLEY.UK however, just as there is between CO.UK and ABLEY.CO.UK, so this is not just a case of counting labels.

> The second aspect to examine is whether this is in-band to the DNS, out of band, or if there is just a "hook" - a reference DNS RR type that points to another service.

In general, I dislike mechanisms that require two sources of truth to be maintained in isolation, especially if each source of truth is maintained separately. It seems inevitable that such approaches wind up being incoherent.

Individual domain registries have the best chance of knowing the correct answer for where administrative boundaries lie. I use the phrase "domain registry" loosely, since I think it's wider than the usual EPP-server-operators.

The root zone registry operator knows precisely which dot in the label string indicates a hand-off of administrative control to Nominet for UK.

Nominet knows precisely which dot in the label string indicates a hand-off to a registrant, for names ending in UK.

That registrant is the best person to ask about any administrative boundary from the label they control down (e.g. CentralNIC might have something to say about UK.COM, Tumblr might have something to say about TUMBLR.COM to indicate that content associated with different subdomains is administered separately (so don't trust CAT.TUMBLR.COM to set a cookie for DOG.TUMBLR.COM).

This fanning out of points of authority sounds very much like the DNS, which makes me think that the best answer to your question (b) is to provide the signalling in the DNS. Whois is an example of publishing related data out of band with the DNS, and I would suggest that amongst whois' myriad problems is the difficulty in finding an appropriate whois server for a domain (hence the persistent call to define the semantics for things like _nicname._tcp SRV).

> for which they want to say it's inside or outside some boundary.

Joining in the gleeful descent of the rock-face of implementation, if the administrator of a DNS zone was able to assert:

 - the following subdomains are within this administrative realm
 - the following subdomains are outside this administrative realm

in such a way that the directions could be parsed in order, it might be possible to avoid (a) long lists of names and (b) trying to publish information at a zone cut in the parent (which we can't do), on the basis that everything in a single DNS zone is in the same administrative realm.

An extra facility

 - the following non-subdomains are within this administrative realm

with appropriate DNSSEC signing and validation might provide a means to do safe cross-site cookie handling, which might be a nice toy to find in the cereal box.

Joe