On Tue, 10 Feb 2004 17:21:24 EST, Hector Santos said:
smtp.SENDER.vt.edu ip: 18.104.22.168
Compute how many of these you can get back in a single 512-byte DNS
response (hint - go back and look at WHY AOL round-robins their stuff
the way they do).
Compute the operational cost of having to drop back to TCP (if even feasible)
for more responses. It's quite possible that for vt.edu you'd get at least 400
or so responses back (that's just the ones I *know* about that are Unix/Linux
workstations that do their own SMTP handling).
This is a non-starter unless you find a way to do the query such that it
returns one packet or less of data (for multiple reasons). At least the SPF
draft lets us describe ours 2 /16s in one or two TXT records (not that I'm
totally thrilled with Meng's syntax either, but at least it has enough sense to
realize that wildcards (*.foo) and ranges (/16, /20) are a better bet than full
enumeration followed by searching through all the results.
Also, it would almost certainly end up making split-view DNS a requirement for
many sites that don't have it now. For instance, currently the entire world,
both on campus and off, has one consistent view of our A, MX, and PTR records
(with the exception of 5 machines that are actually *part* *of* our mail hub).
With your proposal, we'd either have to hand back a list of 400+ MX entries for
each piece of e-mail, or run split-view DNS just so our on-campus view didn't
leak to the outside world.
And given the number of PTR queries that arrive at the root nameservers for
1918 addresses, with 1918 *source* addresses on the packets, I doubt that
there's enough production clue out there to make split-view DNS a reality at
the average site.
Description: PGP signature