ietf-asrg
[Top] [All Lists]

Re: [Asrg] Re: 6. Proposals - rDNS and rMX

2003-11-28 21:39:17
On Sat, Nov 29, 2003 at 03:30:06AM +0100, Markus Stumpf wrote:
We don't see MTAmark as a concurring proposal to LMAP. Those two fit
together and complement themselves.

Agreed- I tried to say that too :-)


My guess is that the proposal wants to include wildcards
[etc]
Your guess is right ;-)
With your example there are more DNS queries involved, as one has to
lookup "mta.1" and "contact.mta.1" but with our proposal it can be
handled with one lookup, as a TXT query will be answered containing all
TXT records.
However you are right that this may often be unnecessary.

Right, considering that you don't always need to lookup the contact
address.

Plus the caching nature of DNS reduces the DNS traffic between any
mail servers that communicate frequently.  Extra queries sound like
(and are) more work - but the mere fact of extra work does not mean
it's unreasonable.  (You'd have to consider the current load and the
likelihood of the new load: if there is currently one DNS lookup per
connection, and you are adding one, the DNS load doubles.  But if
there are currently five lookups and you add one more 10% of the time,
the DNS load increases by a factor of about 2%, some of which goes
only as far as the local cache.  I am not trying to give numbers, just
suggesting that it's not obviously a severe penalty.)

My initial reaction is that I'd probably prefer a little more DNS
traffic if it meant a cleaner database.  (Everyone has opinions,
right?  anyway that's mine.)  Opinion aside, one question is what
would be the real burden imposed by an extra DNS lookup, contrasted
with the (IMHO) gain in data organization.



Or even:
  $ORIGIN 0.0.10.in-addr.arpa.
  ; defaults
  *.mta          IN  TXT  "no"
  *.contact      IN  TXT  "mailto:abuse(_at_)example(_dot_)com"
  ; specifics per IP
  1              IN  PTR  mail.example.com.
  1.mta          IN  TXT  "yes"
  1.contact      IN  TXT  "mailto:abuse-1(_at_)example(_dot_)com"
This will not work in case of e.g.
   $ORIGIN 0.10.in-addr.arpa.

whereas the wildcard example from our proposal would. You would have
to specify
   $ORIGIN 0.10.in-addr.arpa.
   *.mta.1          IN  TXT  "no"
   *.contact.1      IN  TXT  "mailto:abuse(_at_)example(_dot_)com"
   *.mta.2          IN  TXT  "no"
   *.contact.2      IN  TXT  "mailto:abuse(_at_)example(_dot_)com"

Yeah, I see what you mean.  But again what's the real burden?  How
many in-addr.arpa delegations are there where the same organization
that is delegated the in-addr.arpa zone corresponding to a /16 is the
same organization that is delegated the in-addr for a /24 ?  And for
them, how much of a problem is it to populate each of the
in-addr.arpa's for each /24 ?  If it's an issue, it's probably
somewhere down at the noise level.


which could be solved with BIND's COMPUTE statement, but that's specific
to BIND.

hmm, $generate maybe?  I think that's a hack that's better solved
by zone generation tools :-)

 
Anyway, I'll think about that over the weekend ;-)

Thanks,
-mm-

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg