Hello Everyone, Have a problem getting to our very own nameservers. Followed the Perfect Setup for Mandriva 2007, installed ISPConfig, and have read Traditional DNS HowTo, and How to run your own nameservers with ISPConfig and Go Daddy (also our registrar). When we have both our own nameservers, and Park servers at GoDaddy in our nameserver record, we are able to access all of our websites. Delete the Park nameservers, and leave just our own NS3 and NS4 servers, and the entirety of the net seems to lose us completely. Using Dig, we can access less and less over time. At first, we can get a good result with all sites. Later, Dig cannot even locate NS3 and NS4. NS3 and NS4 are also set up at GoDaddy as our Hosts. GoDaddy has suggested there may be a problem with server configuration, as DNS appears to be correct on thier end. Comcast Business services (cable modem with 5 IP'S) has no clue, and I'm losing hair again...... (Not a lot left here!) Would anyone have an idea why we cannot seem to transfer to our own nameservers after having followed all of Falko's good advice? We're new at this, and after three weeks of playing and searching, are totally lost right now. Below is the readout of a dig to our IP: ; <<>> DiG 9.3.2 <<>> @74.92.214.65 any sheltiehosting.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63915 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3 ;; QUESTION SECTION: ;sheltiehosting.net. IN ANY ;; ANSWER SECTION: sheltiehosting.net. 86400 IN SOA ns3.sheltiehosting.net. webmaster.sheltiehosting.net. 2007010305 28800 7200 604800 86400 sheltiehosting.net. 86400 IN NS ns4.sheltiehosting.net. sheltiehosting.net. 86400 IN NS ns3.sheltiehosting.net. sheltiehosting.net. 86400 IN MX 10 mail.sheltiehosting.net. sheltiehosting.net. 86400 IN A 74.92.214.65 ;; ADDITIONAL SECTION: ns3.sheltiehosting.net. 86400 IN A 74.92.214.65 ns4.sheltiehosting.net. 86400 IN A 74.92.214.66 mail.sheltiehosting.net. 86400 IN A 74.92.214.65 ;; Query time: 0 msec ;; SERVER: 74.92.214.65#53(74.92.214.65) ;; WHEN: Wed Jan 3 23:19:39 2007 ;; MSG SIZE rcvd: 203 And again: ; <<>> DiG 9.3.2 <<>> @74.92.214.65 any www.sheltiehosting.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8687 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.sheltiehosting.net. IN ANY ;; ANSWER SECTION: www.sheltiehosting.net. 86400 IN A 74.92.214.65 ;; AUTHORITY SECTION: sheltiehosting.net. 86400 IN NS ns3.sheltiehosting.net. sheltiehosting.net. 86400 IN NS ns4.sheltiehosting.net. ;; ADDITIONAL SECTION: ns3.sheltiehosting.net. 86400 IN A 74.92.214.65 ns4.sheltiehosting.net. 86400 IN A 74.92.214.66 ;; Query time: 0 msec ;; SERVER: 74.92.214.65#53(74.92.214.65) ;; WHEN: Wed Jan 3 23:26:29 2007 ;; MSG SIZE rcvd: 124 And our primary zone file (Which I THINK is correct..... ): $TTL 86400 @ IN SOA ns3.sheltiehosting.net. webmaster.sheltiehosting.net. ( 2007010305 ; serial, todays date + todays serial # 28800 ; refresh, seconds 7200 ; retry, seconds 604800 ; expire, seconds 86400 ) ; minimum, seconds ; NS ns3.sheltiehosting.net. ; Inet Address of name server 1 NS ns4.sheltiehosting.net. ; Inet Address of name server 2 ; MX 10 mail.sheltiehosting.net. sheltiehosting.net. A 74.92.214.65 mail A 74.92.214.65 www A 74.92.214.65 ns3 A 74.92.214.65 ns4 A 74.92.214.66 ftp CNAME www. ns3.sheltiehosting.net. TXT "v=spf1 ip4:74.92.214.65 ip4:74.92.214.66 ip4:74.92.214.67 ip4:74.92.214.68 ip4:74.92.214.69 a mx ptr include:yes ~all" mail.sheltiehosting.net. TXT "v=spf1 ip4:74.92.214.65 ip4:74.92.214.66 ip4:74.92.214.67 ip4:74.92.214.68 ip4:74.92.214.69 a mx ptr include:yes ~all" ;;;; MAKE MANUAL ENTRIES BELOW THIS LINE! ;;;; Any ideas that my one brain cell that's left can absorb? Thanks!
I'm getting this right now: Code: mh1:~# dig sheltiehosting.net ; <<>> DiG 9.2.1 <<>> sheltiehosting.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5225 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;sheltiehosting.net. IN A ;; ANSWER SECTION: sheltiehosting.net. 3600 IN A 68.178.232.100 ;; Query time: 1414 msec ;; SERVER: 81.169.163.104#53(81.169.163.104) ;; WHEN: Fri Jan 5 15:40:34 2007 ;; MSG SIZE rcvd: 52 mh1:~# dig ns sheltiehosting.net ; <<>> DiG 9.2.1 <<>> ns sheltiehosting.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21365 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;sheltiehosting.net. IN NS ;; ANSWER SECTION: sheltiehosting.net. 3594 IN NS PARK11.SECURESERVER.net. sheltiehosting.net. 3594 IN NS PARK12.SECURESERVER.net. ;; Query time: 2 msec ;; SERVER: 81.169.163.104#53(81.169.163.104) ;; WHEN: Fri Jan 5 15:40:40 2007 ;; MSG SIZE rcvd: 91 so I guess you have switched back to the GoDaddy nameservers? I think the problem could be with glue records: http://en.wikipedia.org/wiki/Dns#Circular_dependencies_and_glue_records
Hi Falko. Thanks for your response. Yes. Switched back to the park servers late last night. I've updated dns at GoDaddy to resemble the How To once again. A dig in an hour or two should yield a better result. .com and .org can also be used for dig. Have not deleted the park servers from those two. I can understand the concept of the glue record (though this is the first I have heard of such a thing), but how does it need to be formatted in order to avoid the circle? I am assuming that this needs to be part of the zone like an A or MX record. Or a change to an existing A record? Also attempting to figure out why any website on the server can only be seen locally for some reason. Outside of Comcast, or outside our immediate area, all requests for any website on the server time out in all browsers. An interesting twist is that requesting a site's https page will contact the appropriate page without a problem, but using normal http times out????? Is this related to the glue record issue? Yep, we're definately new to linux and servers in general, but we're trying hard. Lot's of confusion on dns out there! Thanks very much for your time, and all of your good advice! (About 8 hours later)... Spent some time on the phone with GoDaddy. They do have some folks there that are fairly savvy with dns that are also willing to work with someone whether using Linux or Windows. Nice to find that in a live body to talk to. We have moved the domain back to the parked servers to allow Verisign to update back to them to clear the current problem (glue record). The procedure seems to have changed by a small amount from the How To regarding DNS and GoDaddy just as thier interface has changed. We should know for certain about that in another 4 days or so after updating and distribution. If all goes well, and the changes I mentioned have in fact changed (according to my understanding now) I'll update this for everyone to see. It's much, much easier to create the chicken and the egg problem than one would think..... More later, and thanks Falko for filling in that one piece of information (glue record) that is not talked about much at all.
There has been one change at GoDaddy in regards to registering a name server. There is no need to change A records, or place your name server in the nameserver record with the park servers. Instead, fill out the information in the Host Summary. This will ask you for both the FQDN and IP of the server. You would then shortly recieve an email from GoDaddy that a new name server has been registered. Once the new information has been allowed to propagate, remove the park servers from the Name Server record, and replace with your newly registered name servers. That's it. No other changes required. Which brings me to a newly discovered problem. Using the wonderful tools at dnsstuff.com, I've discovered that our name servers (ns3 and ns4.sheltiehosting.net) are not responding to dns queries. Using DNS Report, DNS Timing, and DNS Lookup, all goes well until the final referral to our ns3 and ns4 servers. Then everything stops. No information is forthcoming from our servers. Looking at our named.conf files, we appear to be set up as a caching only name server. Not authorative. Could this be why our servers are not responding? Both servers can be pinged, and do respond to dig @ queries (glue records also appear in the Additional section).
Do you use Code: dig @[I]ip_address[/I] blabla or Code: dig @ns4.sheltiehosting.net blabla ? Try both. Do they give different results? What's in your named.conf?
Hi Falko, A Dig at ns3 or ns4 do not bring any results at all. Digging at the IP's bring up all the appropriate records. Perhaps things are just being slow propagating. I don't know. Checking NS3 and NS4 at Internic and Verisign show they are registered name servers. Just no results, and testing DNS at DNSStuff.com again this evening still shows the disconnect at our servers. Here's Named.conf: options { pid-file "/var/lib/named/var/run/named.pid"; directory "/var/lib/named/var/named"; auth-nxdomain no; /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ query-source address * port 53; }; // // a caching only nameserver config // zone "." { type hint; file "named.ca"; }; zone "0.0.127.in-addr.arpa" { type master; file "named.local"; }; zone "214.92.74.in-addr.arpa" { type master; file "pri.214.92.74.in-addr.arpa"; }; zone "sheltiehosting.net" { type master; file "pri.sheltiehosting.net"; }; zone "sheltiehosting.com" { type master; file "pri.sheltiehosting.com"; }; zone "sheltiehosting.org" { type master; file "pri.sheltiehosting.org"; }; //// MAKE MANUAL ENTRIES BELOW THIS LINE! //// Here's also named.conf.master from ISPConfig: options { pid-file "/var/lib/named/var/run/named.pid"; directory "{BINDDIR}"; auth-nxdomain no; /* * If there is a firewall between you and nameservers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ query-source address * port 53; }; // // a caching only nameserver config // zone "." { type hint; file "named.ca"; }; zone "0.0.127.in-addr.arpa" { type master; file "named.local"; }; <!-- BEGIN DYNAMIC BLOCK: named_reverse --> zone "{ZONE}.in-addr.arpa" { type master; file "pri.{ZONE}.in-addr.arpa"; }; <!-- END DYNAMIC BLOCK: named_reverse --> <!-- BEGIN DYNAMIC BLOCK: named --> zone "{DOMAIN}" { type master; file "pri.{DOMAIN}"; }; <!-- END DYNAMIC BLOCK: named --> <!-- BEGIN DYNAMIC BLOCK: named_slave --> zone "{DOMAIN}" { type slave; file "sec.{DOMAIN}"; masters { {MASTERS}; }; }; <!-- END DYNAMIC BLOCK: named_slave --> //// MAKE MANUAL ENTRIES BELOW THIS LINE! //// The only change I made to named.conf was to uncomment the query source port address. Otherwise, setup was done with the Perfect Setup for Mandriva 2007. No Firewall on the system other than the firewall within ISPConfig. Straight shot to the net.
So your named is working, but the problem is with resolving ns3 and ns4. I bet this is still the glue record problem. Wait another day, and if it doesn't work then, contact GoDaddy again.
Glue problem or something else? Falko. I want to make certain I'm understanding correctly what a glue record is, and how it relates to the .net root servers and ultimately allows access to our web pages. Below is a copy of the forward zone for sheltiehosting.net (the reverse zone has a PTR going to this record): $TTL 86400 @ IN SOA ns3.sheltiehosting.net. webmaster.sheltiehosting.net. ( 2007010702 ; serial, todays date + todays serial # 28800 ; refresh, seconds 7200 ; retry, seconds 604800 ; expire, seconds 86400 ) ; minimum, seconds ; NS ns3.sheltiehosting.net. ; Inet Address of name server 1 NS ns4.sheltiehosting.net. ; Inet Address of name server 2 ; ns3 MX 10 mail.sheltiehosting.net. sheltiehosting.net. A 74.92.214.65 mail A 74.92.214.65 www A 74.92.214.65 ns3.sheltiehosting.net A 74.92.214.65 ns4.sheltiehosting.net A 74.92.214.66 ftp CNAME www. ns3.sheltiehosting.net. TXT "v=spf1 ip4:74.92.214.65 ip4:74.92.214.66 ip4:74.92.214.67 ip4:74.92.214.68 ip4:74.92.214.69 a mx ptr include:yes ~all" mail.sheltiehosting.net. TXT "v=spf1 ip4:74.92.214.65 ip4:74.92.214.66 ip4:74.92.214.67 ip4:74.92.214.68 ip4:74.92.214.69 a mx ptr include:yes ~all" ;;;; MAKE MANUAL ENTRIES BELOW THIS LINE! ;;;; My understanding of a glue record is what is displayed above as an 'A' record showing NS3 and NS4 and the IP of those servers. Is this correct? A dig @(All 13).gtld-servers.net any sheltiehosting.net yield the same result (below). Response time only varies from 39 to 305msec.: ; <<>> DiG 9.3.2 <<>> @c.gtld-servers.net any sheltiehosting.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8852 ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;sheltiehosting.net. IN ANY ;; ANSWER SECTION: sheltiehosting.net. 172800 IN NS ns3.sheltiehosting.net. sheltiehosting.net. 172800 IN NS ns4.sheltiehosting.net. ;; AUTHORITY SECTION: sheltiehosting.net. 172800 IN NS ns3.sheltiehosting.net. sheltiehosting.net. 172800 IN NS ns4.sheltiehosting.net. ;; ADDITIONAL SECTION: ns3.sheltiehosting.net. 172800 IN A 74.92.214.65 ns4.sheltiehosting.net. 172800 IN A 74.92.214.66 ;; Query time: 53 msec ;; SERVER: 192.26.92.30#53(192.26.92.30) ;; WHEN: Wed Jan 10 19:50:43 2007 ;; MSG SIZE rcvd: 132 Again, my understanding is that the 'glue' is the ns3 and ns4 shown in the Additional Section above. Is this correct? Digging at the root servers also shows the same information for ns3 and ns4.sheltiehosting.net. Our nameservers. GoDaddy (I called today), nice as they are, and helpful as they try to be are no help at all with this particular problem. Based on everything I've read, and everything I've tried, we should be able to reach a web page on our servers. Yet we cannot. We cannot dig ns3 or ns4, yet glue records appear to be in place though we can dig @(IP) each of our nameservers. Unless I'm misunderstanding what, and where a glue record is, and is kept. I've tried very hard to trace the problem from both ends, looking toward the middle. Syntax, and all records appear to be in place as they should be in both our servers, and the root servers. One other thing. A traceroute to ns3 done at dnsstuff shows the destination as 74.92.214.65-colorado.hfc.comcastbusiness.net. I called Comcast (our provider), and asked if any server sending queries to our server would see the same information appended after the IP number as above. They did not know, but tried a traceroute of thier own. Thier query timed out two hops before getting to our IP twice. So it would appear as though there is a block of some kind within Comcast's network (or at least that particular server). At least that is my supposition. Thier DNS folks are supposed to contact me in the next day or two. I've also done digs at Comcast's own nameservers, and they bring up the appropriate records as my other digs. Since our zone records match those of GoDaddy and the root servers (including glue records) and digs done at both ends are the same, does my thought of Comcast blocking access to our server somewhere in thier system make sense? Could they have a bad dns entry of thier own that disrupts the information path? I'm very curious if I could be on to something, or if I'm merely blowing smoke! Thanks! I don't think I'm going crazy here.... no. That's wrong. I have kids. I lost my mind a long time ago! Well at least I'm getting a good education on server administration and dns! (With some help I might add......)
ns3 and ns4 are resolved now: Code: mh1:~# dig ns3.sheltiehosting.net ; <<>> DiG 9.2.1 <<>> ns3.sheltiehosting.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28905 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns3.sheltiehosting.net. IN A ;; ANSWER SECTION: ns3.sheltiehosting.net. 172800 IN A 74.92.214.65 ;; Query time: 63 msec ;; SERVER: 213.191.92.84#53(213.191.92.84) ;; WHEN: Fri Jan 12 11:06:09 2007 ;; MSG SIZE rcvd: 56 mh1:~# dig ns4.sheltiehosting.net ; <<>> DiG 9.2.1 <<>> ns4.sheltiehosting.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14304 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns4.sheltiehosting.net. IN A ;; ANSWER SECTION: ns4.sheltiehosting.net. 172794 IN A 74.92.214.66 ;; Query time: 9 msec ;; SERVER: 213.191.92.84#53(213.191.92.84) ;; WHEN: Fri Jan 12 11:06:15 2007 ;; MSG SIZE rcvd: 56 but when I ask them to resolve a domain for me, I get no answer: Code: mh1:~# dig @ns4.sheltiehosting.net sheltiehosting.net ; <<>> DiG 9.2.1 <<>> @ns4.sheltiehosting.net sheltiehosting.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45700 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.sheltiehosting.net. IN A ;; Query time: 3310 msec ;; SERVER: 145.253.2.75#53(ns4.sheltiehosting.net) ;; WHEN: Fri Jan 12 11:07:03 2007 ;; MSG SIZE rcvd: 40 mh1:~# dig @ns4.sheltiehosting.net google.de ; <<>> DiG 9.2.1 <<>> @ns4.sheltiehosting.net google.de ;; global options: printcmd ;; connection timed out; no servers could be reached mh1:~# dig @74.92.214.66 google.de ; <<>> DiG 9.2.1 <<>> @74.92.214.66 google.de ;; global options: printcmd ;; connection timed out; no servers could be reached mh1:~# dig @74.92.214.65 google.de ; <<>> DiG 9.2.1 <<>> @74.92.214.65 google.de ;; global options: printcmd ;; connection timed out; no servers could be reached This leads me to the assumption that BIND isn't running on ns3 and ns4, or that your firewall is blocking port 53 (TCP and UDP). This is the definition of a glue record (from Wikipedia): So on some nameserver (the delegating one) there is now stored the IP address of ns3 and ns4. Yes. That's the reverse record for the 74.92.214.65 IP address: Code: mh1:~# dig -x 74.92.214.65 ; <<>> DiG 9.2.1 <<>> -x 74.92.214.65 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30544 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;65.214.92.74.in-addr.arpa. IN PTR ;; ANSWER SECTION: 65.214.92.74.in-addr.arpa. 3600 IN PTR 74-92-214-65-Colorado.hfc.comcastbusiness.net. ;; Query time: 104 msec ;; SERVER: 213.191.92.84#53(213.191.92.84) ;; WHEN: Fri Jan 12 11:15:28 2007 ;; MSG SIZE rcvd: 102
I get the same information with one important difference. Ns3 and ns4 will resolve from outside the Comcast network (using another nameserver other than those assigned to us by Comcast). However, from a Linux machine here we get: dig ns3.sheltiehosting.net ;; Got SERVFAIL reply from 68.87.85.98, trying next server ; <<>> DiG 9.3.2 <<>> ns3.sheltiehosting.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41810 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns3.sheltiehosting.net. IN A ;; Query time: 1048 msec ;; SERVER: 68.87.69.146#53(68.87.69.146) ;; WHEN: Fri Jan 12 20:43:37 2007 ;; MSG SIZE rcvd: 40 dig ns4.sheltiehosting.net gets the same result. Using the same nameserver that you did (213.191.92.84) I get the identical results that you did today. A dig @ns1.comcastbusiness.net within the Comcast network gets us this information: dig @ns1.comcastbusiness.net any sheltiehosting.net ; <<>> DiG 9.3.2 <<>> @ns1.comcastbusiness.net any sheltiehosting.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9177 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;sheltiehosting.net. IN ANY ;; ANSWER SECTION: sheltiehosting.net. 172800 IN NS ns3.sheltiehosting.net. sheltiehosting.net. 172800 IN NS ns4.sheltiehosting.net. ;; AUTHORITY SECTION: sheltiehosting.net. 172800 IN NS ns4.sheltiehosting.net. sheltiehosting.net. 172800 IN NS ns3.sheltiehosting.net. ;; ADDITIONAL SECTION: ns3.sheltiehosting.net. 172800 IN A 74.92.214.65 ns4.sheltiehosting.net. 172800 IN A 74.92.214.66 ;; Query time: 2111 msec ;; SERVER: 208.39.158.1#53(208.39.158.1) ;; WHEN: Fri Jan 12 21:09:32 2007 ;; MSG SIZE rcvd: 132 A Dig @ns2.comcastbusiness.net gets the same result. Now a Dig @(IP): dig @74.92.214.66 any sheltiehosting.net ; <<>> DiG 9.3.2 <<>> @74.92.214.66 any sheltiehosting.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34636 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;sheltiehosting.net. IN ANY ;; ANSWER SECTION: sheltiehosting.net. 86400 IN SOA ns3.sheltiehosting.net. webmaster.sheltiehosting.net. 2007010702 28800 7200 604800 86400 sheltiehosting.net. 86400 IN A 74.92.214.65 sheltiehosting.net. 86400 IN NS ns4.sheltiehosting.net. sheltiehosting.net. 86400 IN NS ns3.sheltiehosting.net. ;; ADDITIONAL SECTION: ns3.sheltiehosting.net. 86400 IN A 74.92.214.65 ns4.sheltiehosting.net. 86400 IN A 74.92.214.66 ;; Query time: 3 msec ;; SERVER: 74.92.214.66#53(74.92.214.66) ;; WHEN: Fri Jan 12 20:49:47 2007 ;; MSG SIZE rcvd: 166 dig @74.92.214.65 any sheltiehosting.net ; <<>> DiG 9.3.2 <<>> @74.92.214.65 any sheltiehosting.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63260 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;sheltiehosting.net. IN ANY ;; ANSWER SECTION: sheltiehosting.net. 86400 IN SOA ns3.sheltiehosting.net. webmaster.sheltiehosting.net. 2007010702 28800 7200 604800 86400 sheltiehosting.net. 86400 IN NS ns3.sheltiehosting.net. sheltiehosting.net. 86400 IN NS ns4.sheltiehosting.net. sheltiehosting.net. 86400 IN A 74.92.214.65 ;; ADDITIONAL SECTION: ns3.sheltiehosting.net. 86400 IN A 74.92.214.65 ns4.sheltiehosting.net. 86400 IN A 74.92.214.66 ;; Query time: 0 msec ;; SERVER: 74.92.214.65#53(74.92.214.65) ;; WHEN: Fri Jan 12 20:50:26 2007 ;; MSG SIZE rcvd: 166 I understand your assumption, that it would certainly look like named is down, and port 53 on both ns3 and ns4 are blocked. However, named is running, and port 53 is open as evidenced. Both ns3 and ns4 have the same information. I haven't heard back from Comcast DNS as of yet, though I've tried to reach them (It will be Monday before I can try again. They work M-F 9-5 only). After the traceroutes I have done, and one other done by a Comcast Tech Support person, it would appear that something in one particular server enroute to us here has a problem. All traceroutes stop (time out) at the same server two hops before arriving here (originating outside the Comcast network). This is what we've asked them to look at. One interesting thing is that sheltiehosting.org and .com will resolve from inside and outside the Comcast network. Where .net will not. I'm almost to the point of changing the nameservers to a .com just to see if it makes a difference. I'm beginning to believe it just might. Thanks for the clarification on the glue records.
Are they also using ns3 and ns4.sheltiehosting.net as nameservers? In that case no glue record is needed because sheltiehosting.net is different from sheltiehosting.org and sheltiehosting.com. That seems to be the reason these domains are resolving.
That makes sense. Still waiting on a response from Comcast. It would appear there are at least one, possibly two servers enroute to us blocking udp and/or tcp packets. I'm looking forward to actually getting up and running here.....
Have you thought about buying a technical domain, i.e. a domain that you don't use for web hosting, emails, etc.? You could then use that for your nameservers (e.g. ns1.technicaldomain.com and ns2.technicaldomain.com). Thus you don't need that glue record anymore.
Problem solved! Finally managed to talk to the correct group at Comcast today. It was a five minute fix on thier end to one of thier network routers. We can now get through to our nameservers, and all sites are resolving. Everything works. Thanks for all your help Falko! I hadn't though of a technical domain, but I will keep that in the back of my mind should the need come up in the future. This was frustrating tracing all the various things down, but a good learning experience. I've got one windows machine left...... May get rid of it now. Linux I think is actually easier to deal with!
Matter of propagation, glued stuff ?? Hi All, By Request of my ISP I had to change the IP address of my NS1. I went to godaddy and changed the NS1 and the @ IPs in the A registers. I did this last saturday and waited for propagation as suggested. In this moment I´m in France and the IspConfig server is in Colombia. Well the fact is that I can see the sites from here ( sometimes ) but the people in Colombia can not see them (never) It could sound weird but the description is right, sometimes I see the sites, sometimes I can´t. I must add that there are sites in that server that I have not seen since I did the change. My dig test seems to be ok. Last thing I did was to check the ns1 propagation with an online tool, some of the servers still list my ns1 with the old Ip. In this moment I don't know what to do, as usual I came to you to find some light. Thanks in advance. ps. Falko, regarding your howto about having our own nameserver with goodady, the servernames of our ns1 and ns2 must be in the parked option or hosted here option ?
Did you change the glue records as well? Did you check your records on www.intodns.com ? I don't know the GoDaddy interface, I think it has changed since I wrote the tutorial, so I can't tell anything about it.
