[77558] in North American Network Operators' Group
Re: fixing insecure email infrastructure (was: Re: [eweek article]
daemon@ATHENA.MIT.EDU (Markus Stumpf)
Tue Jan 25 10:27:32 2005
Date: Tue, 25 Jan 2005 16:27:03 +0100
From: Markus Stumpf <maex-lists-nanog@Space.Net>
To: Mark Andrews <Mark_Andrews@isc.org>
Cc: nanog@merit.edu
In-Reply-To: <200501242241.j0OMf8m3026839@drugs.dv.isc.org>
Errors-To: owner-nanog-outgoing@merit.edu
On Tue, Jan 25, 2005 at 09:41:08AM +1100, Mark Andrews wrote:
> Lots. I'm sure that there are lots of ISPs/IAPs on NANOG
> that do RFC 2317 style delegations for their customers.
How many is lots?
And how often do the IP addresses of (outgoing) Mailservers change within
a subnet? None of ours has changed in the last 10 years and our
customers (mainly business customers) usually never change them, either.
> Every one of them would need to upgrade their servers to
> support DNAME. Their clients would also need to upgrade
> their servers to support DNAME as they should be stealth
> servers of the parent zone, to allow local lookups to work
> when the external link is down.
If MTAMARK requires DNAME then RFC 2317 style delegations would require
them, too. None of which is true.
1 CNAME 1.0/25.2.0.192.in-addr.arpa.
works exactly the same way
_send._smtp._srv.1 CNAME _send._smtp._srv.1.0/25.2.0.192.in-addr.arpa.
does. No special magic required. One can even use BINDs $GENERATE
statement for that.
Unless I am missing something I don't know of any RFC that prohibits that.
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"
