Subject: [apps-discuss] Comments on draft-levine-orgboundary

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 21 Jul 2013 01:37:34 -0700

Hi there,

Similar to draft-sullivan-domain-policy-authority, I'm interested in this
stuff from the email authentication angle.

I've offered off-list to develop this with John in terms of the text.  Here
I'm just talking about the mechanism itself.

The mechanism provided here is fairly straightforward, but there's one
limitation in particular.  You use this as an example:

A query to _ob.ca might yield a response that indicates boundaries at the
federal, provincial, and municipal levels, such as "ob=1 ca on.ca
toronto.on.ca".  The issue I can see is that in fact there are domains in
.ca, domains in .on.ca (and the other twelve), and domains in the
municipal-level domains which as I recall number in the thousands in
Canada.  It would be impossible to enumerate them all in a reply to _ob.ca,
certainly without switching to TCP or having some kind of indirection.
Might it be better to have a reply syntax that can indicate "stuff can be
registered here and up to n levels below"?

For example, maybe this would work:

ob=1 ca on.ca+1 bc.ca+1 ...

This allows domains in ca, on.ca, bc.ca, and the rest of the province
domains, and one level down from each of those (and would fit in a UDP
reply), while maybe this:

ob=1 ca on.ca/1 bc.ca/1 ...

...allows domains in ca, and then one below on.ca and bc.ca and the
province domains but not directly in them.

It also doesn't handle all of the use cases as Andrew's document does.  The
one in particular that's of interest is the "two related domains" use case
that's popped up lately in the DNS groups.  It would be great to tackle
that as well, but that may be wishful thinking here.

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 21 Jul 2013 09:16:12 -0400

> registered here and up to n levels below"?

Unfortunately, that doesn't work.

   aaa.foo.ontario.ca and bbb.foo.ontario.ca are the same entity

   aaa.toronto.ontario.ca and bbb.toronto.ontario.ca are not

This argues for going back to the wildcard hack, with records like

  *.ontario._ob.ca TXT "ontario.ca"
  *.toronto.ontario._ob.ca TXT "toronto.ontario.ca"

These have lousy DNS cache behavior, but the closest encloser rule means 
that you can find the cut point for any domain with one UDP lookup.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 21 Jul 2013 12:42:19 -0700

> that you can find the cut point for any domain with one UDP lookup.

Is there any hope that we could encourage implementers to cache these in
the application, since they're likely to change only rarely anyway?

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 21 Jul 2013 18:26:46 -0400

> the application, since they're likely to change only rarely anyway?

The lousy cache behavior is that every different name is a different 
lookup, even if it comes from the same wildcard, e.g., foo.com, 
www.foo.com, bar.com, www.bar.com, etc.  Repeated queries for the same 
name cache just fine, give or take the cache being too small.

The question is whether the rate at which hosts look for these things will 
be high enough to matter.  It seems unlikely they'd be as frequent as rDNS 
queries, and those cache just as badly.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 21 Jul 2013 18:10:23 -0700

> queries, and those cache just as badly.

Couldn't application level caching with some knowledge of this system
reduce the lousy caching?  For example, if through this system you can
learn that .com is a point below which all domains are in their own OB, you
don't need to look up _ob.com anymore (or at least not for a really long
time).

-MSK

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2013 01:24:18 -0000

>don't need to look up _ob.com anymore (or at least not for a really long

That takes us back to my other plan, where _ob.com was a large text
record that had all the info in it.

I suppose we might have a flag for "nothing interesting below here",
so that if you fetch the record for foo.bar._ob.com, it has the flag
set so you know you can reuse that for any subsequent lookup in *.com,
but the record for foo.on._ob.ca does not have the flag, since there
are cut points below that.  Or it could have a pointer to where to
download the whole table for .ca for sites that are big enough to do
local caching.

Of course, this assumes that you believe that there actually isn't
anything interesting below .com.  If you look at the current public
suffix list, they don't.

It's a mess.  My impression is that the DNS is robust enough that it's
not worth a lot of effort to try to cut down query rates unless you
know that the query rate is totally absurd.  That's why I'm not
working on the B-tree DNSBL stuff any more, even with address hopping
the DNS can likely tolerate a query per e-mail, particularly since the
busiest clients generally made side deals to provide local mirrors.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 21 Jul 2013 22:40:14 -0400

>   aaa.toronto.ontario.ca and bbb.toronto.ontario.ca are not

To be clear if slightly pedantic about the example, the current
registration rules don't permit the first case any more.  Also as I
understand it, case (2) sort of depends on what you mean by "same
entity".  Everything of the form [municipality].[province].ca under
the current rules must be a department of the municipality.  You can't
register (for instance) somecompany.toronto.on.ca.  This is under the
CIRA rules for the delegation of [municipality].[province].ca.

Now, none of that obviates your basic point, which is that this
pattern is still possible.  But that argument, it seems to me, leads
almost inexorably to the conclusion that you almost certainly need to
descend the tree; and once you've gone that far the overall opt-in
model I've argued for starts to look like it makes more sense.  (I
still appreciate the problem of having to maintain a record for every
name beneath one of these policy cuts.)

> These have lousy DNS cache behavior, but the closest encloser rule
> means that you can find the cut point for any domain with one UDP
> lookup.

Ok, but I'm not sure the cut point is the thing that makes the
difference.  For instance, there is no zone cut at dyndns.org, but
that name is (and certainly should be) administratively separate from
everything beneath it.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 21 Jul 2013 22:43:25 -0400

> anything interesting below .com.  If you look at the current public

Yes, this is what has worried me too.  Brian Dickson raised this issue
at length to me off list; I was hoping he'd chime in some more here.

> know that the query rate is totally absurd.

Or at least, if the DNS is the right place to put this data, then it
had _better_ be robust enough for that.  Certainly, there are lots of
people on the Internet today with 30s TTLs on their zones.  (Much
below 30 and you start to get wildly unpredictable behaviour.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2013 02:57:47 -0000

>>   aaa.foo.on.ca and bbb.foo.on.ca are the same entity
>> 
>>   aaa.toronto.on.ca and bbb.toronto.on.ca are not
>

That may be the current rule, but I know someone whose domain is
<something>.montreal.qc.ca.  There are of course plenty of other
ccTLDs with irregular registration boundaries, e.g., trieste.it is a
geographic delegation point while triste.it is a registration.

>descend the tree;

You can use my grosse hackque with the wildcards, where the closest
encloser rule finds the deepest relevant delegation point.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 21 Jul 2013 22:47:18 -0700

> geographic delegation point while triste.it is a registration.

Back when there was a committee of ISPs approving .ca domains, what level
in the .ca tree you got depended on the breadth of your business.  The
default was to register your entity in your municipality unless you could
show incorporation or operations in a wider scope.  There are undoubtedly
numerous domains created under that rule that still exist.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Jul 2013 10:08:51 -0400

> encloser rule finds the deepest relevant delegation point.

I really need to spend some more time working out scenarios of that,
because I'm not entirely sure it works in every case.  I'm not
entirely sure it _doesn't_, either, but I'm a little nervous about it.
I think the draft could benefit from some more examples in this area.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2013 17:33:36 -0000

>entirely sure it _doesn't_, either, but I'm a little nervous about it.

Please do, but given how simple the closest encloser rule is, I'd
be surprised if it didn't work the way I claimed.

>I think the draft could benefit from some more examples in this area.

Easy enough, give or take the paucity of officially designated
example domains.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 22 Jul 2013 13:37:37 -0400

> be surprised if it didn't work the way I claimed.

I'm not worried about the closest encloser rule.  I'm worried about
wildcard behaviour.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2013 23:08:21 -0000

[ off list ]

>I'm not worried about the closest encloser rule.  I'm worried about

Um, the closest encloser rule is wildcard behavior.  It's defined in
RFC 4592.

If you're worried that the name servers that will serve *.on._ob.ca
and the like won't properly implement closest encloser, I suppose that
might be a problem, but I don't ever recall seeing a problem report
like that.

R's,
John