Go Back   HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials > Linux Forums > HOWTO-Related Questions

Do you like HowtoForge? Please consider supporting us by becoming a subscriber.
Reply
 
Thread Tools Display Modes
  #1  
Old 4th January 2007, 07:35
wiremeister wiremeister is offline
Junior Member
 
Join Date: Sep 2006
Posts: 23
Thanks: 0
Thanked 1 Time in 1 Post
Default GoDaddy DNS How To and ISPConfig

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!
Reply With Quote
Sponsored Links
  #2  
Old 5th January 2007, 15:41
falko falko is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 41,701
Thanks: 1,900
Thanked 2,743 Times in 2,577 Posts
Default

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#Cir...d_glue_records
__________________
Falko
--
Download the ISPConfig 3 Manual! | Check out the ISPConfig 3 Billing Module!

FB: http://www.facebook.com/howtoforge

nginx-Webhosting: Timme Hosting | Follow me on:
Reply With Quote
  #3  
Old 5th January 2007, 16:31
wiremeister wiremeister is offline
Junior Member
 
Join Date: Sep 2006
Posts: 23
Thanks: 0
Thanked 1 Time in 1 Post
Default

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.

Last edited by wiremeister; 6th January 2007 at 01:32.
Reply With Quote
  #4  
Old 6th January 2007, 15:25
falko falko is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 41,701
Thanks: 1,900
Thanked 2,743 Times in 2,577 Posts
Default

Quote:
Originally Posted by wiremeister
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.
Yes, please report back.
__________________
Falko
--
Download the ISPConfig 3 Manual! | Check out the ISPConfig 3 Billing Module!

FB: http://www.facebook.com/howtoforge

nginx-Webhosting: Timme Hosting | Follow me on:
Reply With Quote
  #5  
Old 8th January 2007, 02:59
wiremeister wiremeister is offline
Junior Member
 
Join Date: Sep 2006
Posts: 23
Thanks: 0
Thanked 1 Time in 1 Post
Default

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).

Last edited by wiremeister; 8th January 2007 at 03:23.
Reply With Quote
  #6  
Old 8th January 2007, 23:36
falko falko is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 41,701
Thanks: 1,900
Thanked 2,743 Times in 2,577 Posts
Default

Quote:
Originally Posted by wiremeister
and do respond to dig @ queries (glue records also appear in the Additional section).
Do you use
Code:
dig @ip_address blabla
or
Code:
dig @ns4.sheltiehosting.net blabla
?
Try both. Do they give different results?

What's in your named.conf?
__________________
Falko
--
Download the ISPConfig 3 Manual! | Check out the ISPConfig 3 Billing Module!

FB: http://www.facebook.com/howtoforge

nginx-Webhosting: Timme Hosting | Follow me on:
Reply With Quote
  #7  
Old 9th January 2007, 02:46
wiremeister wiremeister is offline
Junior Member
 
Join Date: Sep 2006
Posts: 23
Thanks: 0
Thanked 1 Time in 1 Post
Default

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.

Last edited by wiremeister; 9th January 2007 at 02:49.
Reply With Quote
  #8  
Old 9th January 2007, 16:05
falko falko is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 41,701
Thanks: 1,900
Thanked 2,743 Times in 2,577 Posts
Default

Quote:
Originally Posted by wiremeister
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.
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.
__________________
Falko
--
Download the ISPConfig 3 Manual! | Check out the ISPConfig 3 Billing Module!

FB: http://www.facebook.com/howtoforge

nginx-Webhosting: Timme Hosting | Follow me on:
Reply With Quote
  #9  
Old 11th January 2007, 06:14
wiremeister wiremeister is offline
Junior Member
 
Join Date: Sep 2006
Posts: 23
Thanks: 0
Thanked 1 Time in 1 Post
Default 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......)

Last edited by wiremeister; 11th January 2007 at 07:20.
Reply With Quote
  #10  
Old 12th January 2007, 11:16
falko falko is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 41,701
Thanks: 1,900
Thanked 2,743 Times in 2,577 Posts
 
Default

Quote:
Originally Posted by wiremeister
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.
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):

Quote:
Name servers in delegations appear listed by name, rather than by IP address. This means that a resolving name server must issue another DNS request to find out the IP address of the server to which it has been referred. Since this can introduce a circular dependency if the nameserver referred to is under the domain that it is authoritative of, it is occasionally necessary for the nameserver providing the delegation to also provide the IP address of the next nameserver. This record is called a glue record.
So on some nameserver (the delegating one) there is now stored the IP address of ns3 and ns4.


Quote:
Originally Posted by wiremeister
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.
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
__________________
Falko
--
Download the ISPConfig 3 Manual! | Check out the ISPConfig 3 Billing Module!

FB: http://www.facebook.com/howtoforge

nginx-Webhosting: Timme Hosting | Follow me on:
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 03:39.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.