Subject: [dbound] Fw: New Version Notification for draft-yao-dbound-dns-solution-00.txt

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 29 Sep 2015 17:06:23 +0800

Dear all,

       I submit a draft about dbound solution.
       any comments are welcome.

     thanks a lot.

Jiankang Yao

From: internet-drafts
Date: 2015-09-28 16:26
To: XiaoDong Lee; Jiankang Yao; Xiaodong Li; Jiankang Yao; Ning Kong; Ning Kong
Subject: New Version Notification for draft-yao-dbound-dns-solution-00.txt

A new version of I-D, draft-yao-dbound-dns-solution-00.txt
has been successfully submitted by Jiankang Yao and posted to the
IETF repository.

Name: draft-yao-dbound-dns-solution
Revision: 00
Title: Resource Record for DNS Administrative Boundaries
Document date: 2015-09-28
Group: Individual Submission
Pages: 11
URL:            https://www.ietf.org/internet-drafts/draft-yao-dbound-dns-solution-00.txt
Status:         https://datatracker.ietf.org/doc/draft-yao-dbound-dns-solution/
Htmlized:       https://tools.ietf.org/html/draft-yao-dbound-dns-solution-00

Abstract:
   Two DNS names may have the same DNS administrative boundaries for
   some services.  This document adds the function of lookup of domain
   name administrative boundary to domain name system, which describes a
   new method for using dbound resource record for judging domain name
   administrative boundaries.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 29 Sep 2015 15:25:07 -0400

>        any comments are welcome.
 [...]
> Htmlized:       https://tools.ietf.org/html/draft-yao-dbound-dns-solution-00

Thanks for working on this!

I did a quick read of this draft, and i think i am confused by it. :(

I have three main confusions that i would try to clear up before
thinking more deeply about the draft:

 Ancestry vs. Policy
 -------------------

This draft proposes a single mechanism that can work for zones scoped by
both ancestry and policy.  It's not clear that the same mechanism should
be used for both of these distinctions.  furthermore, your ancestry
mechanism appear to only support bilateral policy agreements -- A must
point to B and B must point to A.  The usual ancestral relationships are
that foo.bar.example and qux.bar.example both use bar.example as their
administrative boundary.  The proposal here, even if i'm
misunderstanding the part that appears to require bilateral policy, at
least requires an a DBOUND RR for each DNS record looked up.  This would
massively inflate the size of most zones.  A decision based on ancestry
might be much easier to find with simple up-walking approach: for
foo.bar.example, look for a DBOUND record for foo.bar.example, then if
that's NXDOMAIN, look for bar.example.

The consensus i heard in the room in Prague was that trying to solve
both ancestry and policy relationships with the same mechanism smells
overly complex.  Maybe it would be better to start with a proposal that
handles only one of them?

 Target Names: URL vs other DNS label?
 -------------------------------------

The URL approach seems very underspecified.  What sort of URLs should be
retrievable by an implementation?  what should an implementation do with
the retrieved data?

I think it would be better to just think about stating the existence of
some type of policy boundary in the DNS, without trying to spec out the
structure of all possible policies that could have boundaries in the
DNS.

 Expirations vs. DNS TTL (and RRSIG)
 ----------------------------------

DNS records already have a TTL (and DNSSEC records have the
inception/expiration of the RRSIG).  This draft introduces new
additional inception/expiration timestamps.  how do all these timestamps
interact with one another?

Other smaller notes from my read-through
----------------------------------------

 * the correct URL for the canonical web view of the PSL these days is
    probably:
    https://github.com/publicsuffix/list/blob/master/public_suffix_list.dat

 * IANA considerations include "Dbound Public Service" -- it's not clear
   how this relates to the rest of the draft

 * IANA considerations would probably need a registry of acceptable
   values for the Flag and Relation fields, or you should replace those
   fields with bits drawn from a bitmask.

 * section 4 describes "Relation" as "reserved for future use", but also
   describes more than one value.  These seem incompatible.

 * It's unclear how the variable-length service type field is delimited
   from the later fields of the record.

 * RFC 2119 language in section 5 seems wrong -- these SHOULDs do not
   apply to actions taken by implementations.

All the best,

   --dkg

---

From: "John Levine" <[email-masked]>
Date: 29 Sep 2015 19:55:14 -0000

>       I submit a draft about dbound solution.

This looks similar to the SOPA record that Andrew Sullivan proposed
about a year ago.

If I want to say, "all names under example.com are under the same
authority", how do I do that?  Do I have to put a DBOUND record at
every name that exists at and below example.com?

R's,
John