|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: fixing insecure email infrastructure (was: Re: [eweek article]
> 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? Does it really matter? Even if it was only one site the problem would still have to be addressed. I know that it is lots more than one because I've had to help lots of sites debug their RFC 3217 style delegation. > 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. Stablility has nothing to do with whether a site can just go and add the records or not without having to talk to their address provider. > > 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. RFC 2317 CNAMES the well known name. MTAMARK wants to add a prefix to the well known name. What happens when someone else decides to add yet another scheme and another and another. The point of RFC 2317 style delegations was to give control. You don't get control without switching to using DNAMES. You are still at the mercy of your address supplier when you want to make changes in your reverse in-addr.arpa space otherwise. Mark > \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" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected]
|