Subject: [dbound] ODUP - some clarifications

From: Casey Deccio <[email-masked]>
Date: Tue, 3 Nov 2015 07:02:02 -0500

I appreciate the feedback I received about my draft in tonight's dbound
working group meeting.  It was clear that clarification was necessary in
some places, which can be brought into the draft, but which I also present
here.

1.  Examples - Examples on the ODUP resolution process are lacking.  There
were several comments that indicated that the process was not understood.
This really isn't a guessing game.  The algorithm is laid out in
completeness in the appendix (more formally than it is in the
step-by-step), but really some examples would be helpful to demonstrate
this.  Some are provided in this email, in the context of other questions,
but certainly more will be added to the draft.

Also, there is nearly running code, in addition to the pseudo code written
into the draft), which I'll make available for further illustration and
example.

--------------

2. Performance - The performance is _not_ O(n**2) as was mentioned in the
meeting.  It is order O(n).  That's quite a difference :).  To illustrate,
we take the name a.b.c.  Here are the _worst-case_ resolution paths:

c._odup/TXT (NODATA)
b.c._odup/TXT (NODATA)
a.b.c._odup/TXT (NXDOMAIN or NODATA)
_odup/TXT

OR

c._odup/TXT (+org)
b._odup.c/TXT (NODATA)
a.b._odup.c/TXT (NXDOMAIN or NODATA)
_odup.c/TXT

OR

c._odup/TXT (+org)
b._odup.c/TXT (+org)
a._odup.b.c/TXT (NXDOMAIN or NODATA)
_odup.b.c

OR

c._odup/TXT (NODATA)
b.c._odup/TXT (+org)
a._odup.b.c/TXT (NXDOMAIN or NODATA)
_odup.b.c/TXT

So, worst case is n + 1 lookups, or O(n).  I don't know that the
performance is any different than that of qname minimization.

But if you replace any of the NODATA (only) responses with NXDOMAIN, steps
are skipped, resulting in fewer lookups.

Also, let's assume the client has a local copy of the policy-negative realm
(_odup zone).  It already knows the answer to any of the above lookups
whose names end with "_odup", so it starts from a lower point in the
resolution process, thus eliminating more lookups.

Now assume both a local copy and a "blank slate" (i.e., no one has deployed
any ODUP records outside of the _odup zone).  There are two lookups
required in the worst case scenario, regardless of name length.  For
example, assume the policy is delegated to the b.c zone with either:

b.c._odup "+org"

OR

c._odup "+bound"
(and b.c._odup doesn't exist in the negative policy realm)

The worst-case lookup scenario to find the policy for a.b.c is:

a._odup.b.c/TXT (NXDOMAIN or NODATA)
_odup.b.c/TXT

and the worst case to find the policy for b.c is simply:

_odup.b.c/TXT

--------------

3. There was a question about how names (particularly TLDs) with DNAMEs at
the zone apex are affected by this mechanism.  I don't know that there is
any impact at all; it should work as designed.  For example, given the TLD
foo, with a DNAME to bar, and a lookup for a.foo:

foo._odup/TXT (NODATA)
a.foo._odup/TXT (NXDOMAIN or NODATA)
_odup/TXT

OR

foo._odup/TXT (+org)
a._odup.foo/TXT CNAME (synthesized) to
    a._odup.bar/TXT (NXDOMAIN or NODATA)
_odup.foo/TXT CNAME (synthesized) to
    _odup.foo/TXT

--------------

4. _odup TLD?  Yes, that is what is proposed.  Note that both by name and
by definition, this is only a policy-negative realm.  That means that
policy directives other than "bound", "org" (lacking from -00 draft, but
necessary for exceptions to wildcards), and "-all" MUST NOT be used in the
policy-negative realm (see Section 5 for more detail).  Technically
speaking, there are no concerns here.  It works.

There are some non-technical questions that might be asked, some of which
were alluded to in the meeting (and I'm sure there will be others):

Q: If there is an _odup TLD, and there is policy under that TLD, how is
that different than having a third party manage policy?

A: I suppose the same question might be asked of traditional DNS namespace
delegation: if I have a domain example.com, why do I need the root or com?
The primary answer are the same to both: how do you know how to get there
without a starting place?  Just as with other TLDs, which are mostly about
delegation, this "TLD" is all about delegating policy--not (otherwise)
defining it.

Q: Why should a third party manage it?

A: It's no different than current behavior (with the possible exception of
*who*, but that's another question), in which Mozilla maintains the PSL.
The difference is that with the ODUP policy-negative realm, there's an
option to delegate policy definition to a subdomain (i.e., using "bound" or
"org"), thereby moving "the line" upward.  Also, see a later question about
its management.  If IANA has a hand in it, then it's more a "parent party"
than a "third party".  They are depended on anyway for DNS resolution.

Q: Who would manage it?

A: The proposal is that this would be managed by IANA, with joint help from
CA/Browser Forum.  The idea was have authority and expertise both in
conjunction with names directly associated with IANA, as well as consumer
applications, such as browsers.  This might also provide better continuity
with transition from the current PSL since Mozilla is the current
maintainer of that list.  It also helps mitigate the issue in which
non-negative policies (e.g., allowing cookies at a TLD) are instituted at
points in the namespace where they should not be (e.g., due to IANA
contract).  Other ideas are welcome.

Q: What about the names in the "Private domains" section of the PSL?

A: There are two major sections in the current PSL: "ICANN domains" and
"Private domains".  The _odup zone would initially be composed of the
so-called "ICANN domains" in the PSL.  Those classified as "Private" are
prime candidates of those that would publish ODUP policy in their own
organizational domain.  For example, the policy for
ap-northeast-1.compute.amazonaws.com (a "private" entry in the current PSL)
might be under _odup.amazonaws.com or _odup.compute.amazon.aws.com.

If you haven't read the draft in its entirety, I invite you to please read
it (or finish it) and comment.

Cheers,
Casey

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 9 Nov 2015 16:35:16 +0900

Hello Casey,

> we take the name a.b.c.  Here are the _worst-case_ resolution paths:

Below, you write OR, which I guess you intend to be exclusive. If that's 
true, then indeed we get O(n). But why and how can these cases be made 
exclusive?

Regards,   Martin.

---

From: Casey Deccio <[email-masked]>
Date: Mon, 9 Nov 2015 08:55:51 -0500

Hi Martin,

> true, then indeed we get O(n). But why and how can these cases be made

In short: by design :)

This is a top-down, policy designation mechanism.  Once you learn that one
organizational domain has designated another in the subdomain space, there
is no need to search further in that first domain space.  I've numbered the
examples below.

In number 1), because the first two responses are NODATA, there are no TXT
records and thus no ODUP statements, which means that there is nothing
telling us that there is an organizational domain or boundary below.  So
with each subsequent query we keep our qnames within the same
organizational domain (i.e., the root zone).  It doesn't make sense to look
for a policy at _odup.c/TXT because there is nothing telling us that the
domain name "c" is an organizational domain.  Doing so would be analogous
to attempting to identify and query the name servers for the DNS name
sub.example.com, when there is no delegation from example.com to
sub.example.com!

In number 2), we learn in the response to the first query (within the root
organizational domain), that "c" is an organizational domain.  Knowing
this, there is no reason to resolve b.c._odup/TXT or a.b.c._odup/TXT.
Doing so would be be like continuing to query example.com name servers for
sub.example.com, when we've learned that there is a delegation from
example.com to sub.example.com!  The qname of the third query is also
within the "c" organizational domain because of the NODATA response to the
second query (i.e., b._odup.c/TXT).

Does this help?

Regards,
Casey

1.

c._odup/TXT (NODATA)
> a.b.c._odup/TXT (NXDOMAIN or NODATA)
2.

> a.b._odup.c/TXT (NXDOMAIN or NODATA)
3.

> a._odup.b.c/TXT (NXDOMAIN or NODATA)
4.