DNS Resolving issues. So for related just to Cox. But could be larger.
Hi Everyone, 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? Sincerely, -- Mark Keymer CFO/COO Vivio Technologies
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. I'm not seeing anything majorly broken with your system except the SOA EXPIRE being ridiculously large. On 3/5/2014 午後 01:40, Mark Keymer wrote:
Hi Everyone,
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?
Sincerely,
"Paul S." <contact@winterei.se> writes:
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. -r
Thank you to the on and off lists replies. The DNS servers are not my choice to have them that way. But I will mention that to my client. It looks like Cox is now resolving things as it should be for this domain. Sincerely, Mark Keymer CFO/COO Vivio Technologies On 3/5/2014 4:52 AM, Rob Seastrom wrote:
"Paul S." <contact@winterei.se> writes:
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.
-r
On Wed, Mar 05, 2014 at 07:52:10AM -0500, Rob Seastrom wrote:
"Paul S." <contact@winterei.se> writes:
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.
-r
haven't you heard about "anycast"?? /bill
On 06/03/2014 12:14, bmanning@vacation.karoshi.com wrote:
On Wed, Mar 05, 2014 at 07:52:10AM -0500, Rob Seastrom wrote:
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.
-r
haven't you heard about "anycast"??
rs probably has. The owner of 199.73.57.122, probably not. Nick
Nick Hilliard <nick@foobar.org> writes:
haven't you heard about "anycast"??
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. -r
On Thu, Mar 06, 2014 at 08:07:55AM -0500, Rob Seastrom wrote:
Nick Hilliard <nick@foobar.org> writes:
haven't you heard about "anycast"??
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.
-r
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 the punchline here was "anycasting" the address across multiple names. nary a routing trick in sight or in play. 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. Back to my oubliette /bill
bmanning@vacation.karoshi.com writes:
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. -r
OP is actually the owner of it as per ARIN whois data. -- Paul On 3/6/2014 午後 09:41, Nick Hilliard wrote:
On 06/03/2014 12:14, bmanning@vacation.karoshi.com wrote:
On Wed, Mar 05, 2014 at 07:52:10AM -0500, Rob Seastrom wrote:
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.
-r
haven't you heard about "anycast"?? rs probably has. The owner of 199.73.57.122, probably not.
Nick
participants (5)
-
bmanning＠vacation.karoshi.com -
Mark Keymer -
Nick Hilliard -
Paul S. -
Rob Seastrom