DNS issue or caching issue?
Greetings,
I'm not sure where the problem resides but its getting to the point that I need to ask some better hands on what I should do to fix my issue. I am running a web server and I am hosting our own domain. I can get to the site by name or IP.. My problem is that when I enter the domain name it finds it but it doesn't pull the refreshed page in the browser. (It takes forever to resolve host and loads the pageafter some time) . I dont know why it takes so long to resolve host and refresh the page When I enter the IP addrress of my domain, it pulls the updated page from the web server instantly. I am the authority of the domain so its pointing to my DNS. I have a local domain with 2 records so it should find it by name or IP. I don't think its a caching issue because it sometimes works and sometimes doesn't. Can anybody give me some insite on what I am missing on this. I am running Mandrake Linux 9.1 and bind 9.2.2 Thank you. |
Moved: This thread is more suitable in Linux-Networking and has been moved accordingly to help your thread/question get the exposure it deserves.
|
Long timeouts like you describe can typically be associated with DNS lookup timeouts. Especially the reverse lookups. A couple of things to try:
1) To start, does your name server properly return the name and IP address for your domain? Using dig: # dig @xx.xx.xx.xx www.mydomain.com a # dig @xx.xx.xx.xx -x yy.yy.yy.yy Where xx.xx.xx.xx is the IP address of your DNS server and yy.yy.yy.yy is the IP address returned from the first dig response. Replace www.mydomain.com with your web servers DNS name. Also, try the above without specifying the @xx.xx.xx.xx to insure that your systems resolver libs are properly configured. 2) Using dig, see if the connecting web browsers IP address can be looked up. Example: If the connecting IP address is 202.4.5.6, then issue: # dig -x 202.4.5.6 BTW: is apache configured to perform a reverse lookup for all connecting IPs? |
Thanks for the reply,
Here are the results of my dig: dig flagstaff.k12.az.us a ; <<>> DiG 9.2.2 <<>> my domain.name a ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28662 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;my.domain.name. IN A ;; ANSWER SECTION: my.domain.name. 38400 IN A xxx.xxx.x.xx ;; AUTHORITY SECTION: my.domain.name. 38400 IN NS my.domain.name. ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Oct 1 17:01:29 2004 ;; MSG SIZE rcvd: 67 So the answer is yes. I can get to my domain . When I tried to trace my IP number this is what I got: IP address: xxx.xxx.x.xx (my domain name) No host name is associated with this IP address or no reverse lookup is configuredanks for the reply. This is a zone I have in my named.conf file: zone "51.0.246.in-addr.arpa" { type master; file "/var/named/51.0.246.zone"; }; I am not sure why it says I have no reverse lookup configured? Thanks for your help.. |
Quote:
To continue with your DNS debugging efforts, try dig or nslookups at both ends of the connection. i.e. your web server and from the connecting system. See if there is a long delay associated with each IP/Name on either system. If all query times are short, then chances are the problem your having is not DNS related. Quote:
Also, has your ISP delegated SOA to your name server for this zone? Most ISP's don't. A good way to check is to use the +trace option for dig. Example: dig +trace -x xx.xx.xx.xx where xx.xx.xx.xx is one of the IP addresses in the above zone. If all else fails, I have found running tcpdmp on my server can help pinpoint where delays are occuring. |
PTR records shoud have no impact on browsing. PTR are reverse lookups used most often for email verification.
The issue has to be in DNS, I agree about that. What is the name of the domain to which your webserver responds, flagstaff.k12.az.us? If you don't feel confortable giving it out, do you use the same domain internally as externally? I see that flagstaff.k12.az.us resolves to: 207.246.0.51. The authroitative server for it shows as: NS1.INFOMAGIC.NET It also shows itself as its own authoritative answer. Now, your clients are probably also using the same webserver, so they are trying to go to 207.246.0.51. I assume that this server sits in a DMZ somewhere and you have certain ports on the public address forwarded to this server instead of giving the acutal server a true public address. If that is true, when you say you can put the IP address of the server in the client's address line it works fine... are you putting in the public address or the private address? If you are using the private address, does it work if you use the public address (207.246.0.51). If it works with the local address but not the public, it's that your firewall is having issues with an internal client requesting an address/port that is internal to the firewall. If the domain is correct, then I see it is for a public school district. Do you use a proxy server to filter your client's connections? If so, the issue could be with your proxy server? The clients are often setup to bypass the proxy for local addresses. So, it would work just fine if you put in a local IP address of the server, but would not work if you use the domain since it resolves to an external address. I guess that is enough speculation for now... MrKnisely **Update** I see that your "Technical Services" link goes to http://10.3.97.27/Help_desk/techweb.html I guess I answered one of my questions... ;o) |
Well. My DNS seems to be doing what it needs to. What does it mean when it says my site has no reverse lookup? I can get to my domain either by IP or name. I was running a proxy squid cache server but I removed it after suspecting that it was causing problems. Besides nobody was pointing to it. Now all traffic is going through a cicso cache engine before it goes out to the internet for lookup.
For some reason, the IE browser will not pull in the new page. There was never a problem getting to my domain by IP or name. It was only in our subnet that pages would not refresh at times. Other times it was fine. Thanks again. |
Reverse lookup, or PTR records, are used by mailservers to verify that the IP address from which an email is sent truely maps to the domain it says it is from. For example, if you check the PTR for 63.165.168.254, you will see that it maps to mtbt.net.
nslookup set type=ptr 63.165.168.254 Now, if your email server got an email from 63.165.168.254 and the from address was user@mtbt.net, it would do a reverse lookup on mtbt.net to verify that it maps to mtbt.net domain. Many mailservers do this type of a lookup to help fight spam. You can use PTR for more than just email, but that's the main use... and some email servers don't even use PTR at all. Hope that helps! MrKnisely |
All times are GMT -5. The time now is 02:25 AM. |