Re: [dbound] Thoughts and comments on draft-levine-orgboundary-04

["John Levine" <[e-mail]>]

Thanks for taking a look.

>The last paragraph of section 2 says "Each domain publishes its own
>policies". I take this to mean its own boundaries, but would it be more
>appropriate to say "Each ADMD publishes its own boundaries"?

It's kind of a chicken and egg problem.  The domain publishes the boundaries
so you know where the ADMD's are.

>It seems slightly problematic to be dependent on a (potentially
>uncooperative) parent domain in order for child domains to be looped into
>the BOUND framework. Since SOA is an established mechanism within DNS
>management, would it make the mechanism more resilient to follow the SOA
>chain before branching off to look for BOUND records?

Zone boundaries have nothing do do with these boundaries.  There are
plenty of places where a single organization uses multiple zones for
its internal convenience and others where lots of logically unrelated
domain are in the same zone file and in a few cases the same record.
Consider for example all of the separate blogs at *.blogger.com.

Also, the DNS decided decades ago that the delegation authority flows
down from the root.  If you have a disagreement with your parent domain,
you fix that with money and lawyers, not technical kludges.

>As a security measure, the failure to lookup a terminating record with a
>NOLOWER bit set seems like its interpretation could be application
>dependent. In the case of cookies or certs, one may want individual name
>isolation, but in the case of DMARC, that would enable attacks rather than
>prevent them.

Sure.  Applications should pick defaults that make sense, and it's
clear the in some cases the safe default is the names are all
different while in others they're all the same.

>Section 3 (and 10) calls for the applications to be indicated as a lookup
>table managed by IANA. Why not just have defined application mechanisms
>which could be comma-separated in the record rather than an encoded numeric
>value?

You need a registry either way, to keep the application names or
numbers from colliding as people invent and start to use new ones.

>In section 5, paragraph 3, the draft reads "the record would indicate no
>boundaries. . ." but then the exemplar record is "*._bound.test IN BOUND 0
>0 .". Shouldn't that be "*._bound.test IN BOUND 1 0 ." to indicate no
>boundaries?

Doesn't really matter, although I suppose the 1 would save a lookup.

>In section 5, regarding the example with municipal boundaries, using
>toronto.on.ca, while wildcards work fine for resolving www.toronto.on.ca,
>would they also "do the right thing" for the same web site answering to "
>toronto.on.ca" or would they force the boundary up to the on.ca level? This
>hearkens back to the discussion in the next to last paragraph of section 2
>with abc.example.

In this case, toronto.on.ca is a boundary like on.ca and ca.  If you
had www.toronto.on.ca that would be an entity with the confusing name
"www" located in Toronto.

>In section 8, the text refers to "a parent publishing records that shadow
>part or all of the boundary record namespace for delegated subdomains,
>correct operation depends on the parent and subdomains agreeing about who
>publishes what" but does not propose any procedural guidance on what sort
>of division of publishing responsibilities might be reasonable

Hm, I thought it was obvious but maybe not.  If the delegated
subdomain is really independent, the parent shouldn't shadow it.  If
they disagree, see discussion about money and lawyers above.

>Section 10 (following from the discussion of how to implement as a series
>of TXT records in section 9) specifies this as a new RRTYPE. I share
>Murray's concerns based on the experience with the SPF RRTYPE that
>implementing a new RRTYPE would impede progress on a dbound solution even
>more so than our difficulties in achieving consensus on the problem
>statement :-)

Doesn't make a lot of difference to me either way.  In this case, any
name that contains _bound should only have DBOUND records so the
downside of using TXT is less than it was with SPF where the names
are unprefixed.

>Nits:
>
>   - Section 4, first sentence is missing an "and": ". . .takes a domain
>   name an application. . ."

Thx, will fix it if I ever revise it again.

R's,
John