Re: DNS Resolving issues. So for related just to Cox. But could be larger.
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)? 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). -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
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
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
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
participants (3)
-
bmanning＠vacation.karoshi.com -
Larry Sheldon -
Rob Seastrom