John C Klensin wrote:
If one were designing the architecture de novo today, in today's
environment, there would be a strong case for "no MX default", but the
sort of situation Carl mentions would also make a strong case for
separate "MX-forward-path" and "MX-reverse-path" (bounces) records.
I dunno. I get leery any time the specs assume that the guy running the
mail server and the guy running the DNS server are on speaking terms.
I've seen too many cases (even in smallish companies) where the
corporate mail server and DNS were run by one department, but web and
E-mail aware applications were run by another. Typically, the latter
group would be pre-allocated a "pool" of hostnames, A records, and PTR
records. When they added a new server, they'd just grab the next name
and number from the pool. If they had to differentiate in advance which
machines sent mail, and throw MX records into the mix too, they'd never
ship.
What they are being allocated today is a A record, PTR and
MX implicit.
They can achieve exactly the same thing by requesting a
pool of A, PTR and MX records.
Or eventually when they add a new host they will just get
the next KEY record from the pool and the host will add the
AAAA, A, MX ("0 ." by default) and PTR records for itself
using the KEY record and SIG(0) for the forward records and
TCP based athentication for the reverse record. 6to4 reverse
already uses TCP based authentication so the later is not
a big stretch of the imagination.
Mark
<csg>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews(_at_)isc(_dot_)org