Re: [apps-discuss] [taugh.com-standards] Comments on draft-levine-orgboundary

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

>> 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.
>
>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).

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