So I have a client who moved a domain specifically periodforgood.com to a new VPS with our company.
DNS has been updated and the TTL time is 4 hours so things should all be updated but something might still be wrong. Looking for help / confirmation that things look good. And better yet if someone from Cox and take a look.
Our client uses Cox for there home internet and sometimes the domain resolves and sometimes it does not. We found they have the following IP's in Cox's network that are being used to resolve domains.
68.105.28.11
68.105.28.12
68.105.29.12
After doing many nslookups via a remote session to there computer we found that the top 2 IP's never resolve the periodforgood.com domain and we found that the third one will about 20%-40% of the time resolve it.
We have gone to several DNS testing tools and all seems to be in order. If you dig or nslookup directly to the DNS servers that are used for the domain it seems to always respond.
I admit I might just be overlooking something myself and will feel dumb once someone points it out to me. But if you can point it out to me that would be great!
Also note that it looks like those DNS resolvers are blocked from outside lookups which is good. So maybe someone with some eyeballs inside or otherwise can help out?
For all it's worth, it might be Cox ignoring TTLs and enforcing their
own update times instead.
Wait 24-48 hours, and it should probably fix it all up.
Possibly.
I'm not seeing anything majorly broken with your system except the SOA
EXPIRE being ridiculously large.
Nowhere even close to ridiculously large. 3600000 (10000 hours, 41
days) is the historical example value in RFC 1035. It's a bit larger
than current recommended practices (2-4 weeks) but I wouldn't fault
anyone for using that value nor would I expect any nameserver software
to malfunction when confronted it. Besides, that value only matters
to secondary nameservers. Speaking of that...
;; ADDITIONAL SECTION:
ns1.nineplanetshosting.com. 172800 IN A 199.73.57.122
ns2.nineplanetshosting.com. 172800 IN A 199.73.57.122
I think OP ought to approach his hoster with a cluebat. Not just on
the same subnet but the same address? Really.
rs probably has. The owner of 199.73.57.122, probably not.
indeed. there are many pieces of evidence that this is not an anycast
prefix. proof is left as an exercise to those who can perform
traceroutes from multiple continents, run nmap -sP, log into
route-views, or do some combination of the above.
sorry for the poor attempt at humour...
it was ancient practice to hang many names (not cnames)
off a single IP address. all perfectly legal from a DNS POV.
sorry for the poor attempt at humour...
it was ancient practice to hang many names (not cnames)
off a single IP address. all perfectly legal from a DNS POV.
rs.example.org. in a 10.10.10.53
nick.example.com. in a 10.10.10.53
bbss.isc.org. in a 10.10.10.53
it's also a poor practice operationally and one that's been deprecated
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.
nevertheless, i direct our august audience to rfc 1537 section 6
(october 1993). it's entirely reasonable to bring up this
configuration misstep in the context of things acting hinky.
the punchline here was "anycasting" the address across multiple names.
nary a routing trick in sight or in play.
"When *I* use a word," Humpty Dumpty said, in rather a scornful tone,
"it means just what I choose it mean to neither more nor less."'
Lame I know.
as a tool to defeat the autobots who insist on "two nameservers"
for a delegation - its kind of a clever poke in the eye w/ a
sharp stick.
I hear the owners' manual for Fords tells you how to turn off the seat
belt alarm too. Clever in rather the same way.
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).
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.
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.