DNS Resolving issues. So for related just to Cox. But could be larger.

Rob Seastrom rs at seastrom.com
Mon Mar 10 21:29:17 UTC 2014

Thanks Bill.  Clearly my Google-fu was failing because of plugging in
anachronistic terms when searching for a document that is only barely
old enough to drive.


bmanning at vacation.karoshi.com writes:

> RFC 2182....
> On Mon, Mar 10, 2014 at 02:57:06PM -0400, Rob Seastrom wrote:
>> Larry Sheldon <LarrySheldon at cox.net> writes:
>> > On 3/7/2014 5:03 AM, Rob Seastrom wrote:
>> >
>> >> for decades.  i have a vague recollection of an rfc that said
>> >> secondary nameservers ought not be connected to the same psn (remember
>> >> those?) but my google fu fails me this early in the morning.
>> >
>> > Packet Switch Node?
>> >
>> > Not sure what would be in this context.
>> >
>> > Not on the same router?  How about two routers away with both THEM on
>> > the same router (a third one)?
>> A PSN or IMP was an ARPANET/MILNET "core" router.  Some sites had more
>> than one.  A reasonable carry-forward of the concept would be that
>> nameservers ought to be geographically and topologically diverse so as
>> to avoid fate-sharing.  Different upstreams, different coasts (maybe
>> different continents?), different covering prefixes, and certainly not
>> on the same IPv4 /32...  would be the intelligent thing to do
>> particularly if one wants to query [email protected] about operational hinkiness
>> and not be on the receiving end of derisive chuckles.
>> > Not on a host that does anything else?
>> >
>> > Both of those actually make some sense to me, the first from a single
>> > point of failure consideration, the second regarding unrelated
>> > failures (I have to re-boot my windows PC at least once a day, most
>> > days because Firefox, the way I use it, gets itself tangled about that
>> > often and a reboot is the quickest way to clear it).
>> Can't hurt to have authoritative nameservers on dedicated VMs
>> (enterprise guys running AD have my sympathies), but that's not what
>> we're talking about here.
>> -r

More information about the NANOG mailing list