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

[Rob Seastrom <rs () seastrom com>]

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.

-r

bmanning () vacation karoshi com writes:

> RFC 2182....
>
>
>
> On Mon, Mar 10, 2014 at 02:57:06PM -0400, Rob Seastrom wrote:
> > Larry Sheldon <LarrySheldon () 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 nanog@ 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