> the netblock this comes out of is only a /19. some tier 1/2 providers > will filter on prefix lengths this long and you won't have quite the > visibility to the outside world that you think you do. I've never had reachability issues because I'm a /19. A 3rd DNS box wouldn't solve this problem anyways - if a site can't reach my network because they filter on that short of a prefix length, being able to resolve names from a 3rd box in another network doesn't really do them a whole lot of good. > as an aside, i haven't seen any AS paths for this network that didn't > have 4323 as the first external AS, so if you are multi-homed to > different providers you might want to see what options you've got for > getting your network(s) out there. > The other route is prepended to 'ell and back, your looking glass may only be showing you the most preferred routes. It is there. > time period and you've got options for mitigating this (HSRP, VRRP, > etc). but if you lose a switch or something nasty happens on this > segment you may have some issues which knock dns on its butt for a > while, in the meantime mail bounces, customers bitch, etc. > I do run HSRP. If a switch fails, I've got spares. I've got spare patch panels, 100-pairs, and ethernet cables too. There is very little that can break bad enough here to knock primary services off-line, that we can't fix in a VERY short time. Mail is queued at the sending site. Mail bounces after a number of days of delivery attempts - if we're down that long, our business is over anyways. This still doesn't address the fact that if our network is unreachable, DNS doesn't do a whole lot of good, since you won't be able to reach any of our services anyways. I completely agree that it's a good idea, but it's really not as important as it sounds. DNS does little good when the services you're trying to reach are unavailable. Realistically, like Nate said - the only real advantage I could get is having mail diverted to an off-site mailserver that I have control over. But again, mail should be queued for a number of hours before the user is even notified that the message hasn't been delivered yet, and queued for days before it bounces (RFC 2821). This is not the kind of outage you get with a failed switch - this is a big problem. Adam Maloney Systems Administrator Sihope Communications _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota http://www.mn-linux.org tclug-list at mn-linux.org https://mailman.real-time.com/mailman/listinfo/tclug-list