|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: ATTBI refuses to do reverse DNS?
In the referenced message, Daniel Senie said: > > At 05:29 PM 6/18/02, Stephen Griffin wrote: > >The lack of clue tends to be on the providing in-addr side of things. > >I think it is a great thing to refuse connections from ips without > >in-addr, in the same way it is great to refuse mail from domains that > >don't provide postmaster addresses. > > > >It is a means through which one can influence the laziness of others. > >Simply disregarding what others do, only legitimizes the laziness, and > >continues us along the road of everyone doing the absolute minimum. > > While I believe people SHOULD be providing INADDR service, the people hurt > by refusing connections are rarely the ones who have any influence. Just as > Network Address Translation is not a security solution, neither is checking > INADDR. Now if you check INADDR over Secure DNS, you might start having > some level of information to trust. Who said anything about security? Some level of security may be a nice side-effect, but I wouldn't rely solely on ip addresses or dns for security. When used in conjunction with other things, it can certainly be just another tool in the bag to further weed out the chaff. Not something which provides proof-positive of good, but something that provies proof-positive of bad. > >Simply accepting the connections seems to be a "path of least resistance" > >which befits a pointy-hair more than an engineer. > > Well, this engineer also has customers to take care of. Those customers > cannot easily influence ATT Broadband or ATT Wireless to do things "right". > So, I choose to keep having customers rather than closing down my business > over others not having INADDR. Who, other than ATT themselves, has an easier time influencing ATT, than ATT customers? Do you: 1) Filter out RFC1918 addressed packets at your borders? 2) Filter long prefixes at your borders? 2a) Filter prefixes longer than RiR allocation boundaries? 3) Filter reserved, RFC1918, etc prefixes at your borders? 4) Perform RPF facing your customers? 5) Reject mail from open relays? 6) Reject mail from domains lacking postmaster/abuse role accounts? Any of these things is likely to make you lose a statistically low percentage of your customer-base. All of them are good for everyone in the long-run. The only one that is questionable is #6, but only because few people reject based upon this criteria. As the number increases, the overall clue gets dispersed, and the unfortunate collateral damage is reduced. An engineer would likely be looking to implement at least some of them. Someone who isn't interested in implementing any of them, I have a tough time considering to be an engineer. At least not in the idealogical sense. They would seem more to be a pointy-hair seeking to maximize short-term gains at any cost. At what point _do_ you draw a line in the sand and stop accepting the continual degradation in quality? Or should we resign ourselves to the Microsoft Mission, with ubiquitous crap that no one is willing to sacrifice for quality? > >You neglect to include the option of the customer changing to an ISP > >that provides in-addr. > > Please explain how a customer changes to another broadband vendor, or > another CDPD vendor. Despite your company's presence in a limited number of > markets, there are MANY people out there with only one choice (if they're > lucky) for broadband. I'd be more likely to lose a customer than get them > to change ISPs. I would guess it would start with them looking at the businesses which provide service in their area. If all they want is the lowest cost provider, I would ponder the following: Cheap, Fast, Good, pick any two. There certainly are alternatives to Cheap, Fast, !Good providers. They may just be Cheap, !Fast, Good, or !Cheap, Fast, Good.
|