On 12/08/2010 10:14 PM, John Levine wrote:
If you start encoding response codes in the A records, you'll break
lookups for older clients, and I don't see any advantage compared to
my hack.
Any disadvantage compared to your hack?
The lookup for the _granularity record will be cached well on systems
like mine that don't keep state between SMTP sessions and have to
check it on each session.
Would that break lookups for older clients any less that encoding
granularity variables in A records would? Either way a client that
doesnt know to look for it or expect it, likely wont.
It's followed by the lookup for the
truncated reversed IP, which will also cache well, whether or not
there's a record, since it's the same lookup for all addreses within a
grain, and modern caches remember NXDOMAIN responses, too.
Unless the client ignores or doesnt check granularity and gets royally
foobar'd in the process.
It would be nice to have variable granularity, i.e. CIDR ranges, but I
don't see any cache-able way to do that simpler than what DNSSEC does.
Right, unless caching can be bypassed altogether without bombarding the
authoritative servers, ie requiring clients to fetch zones via rsync and
authoritatively serve locally.
Both could be supported without breaking existing implementation too badly.
A client could have the option of using DNSSEC or fetching via rsync.
Doing neither, and using a non-validating resolver would result in the
cache blowups and authoritative server bombardment until access is revoked.
--
Joe Sniderman
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg