IPcheck Error / Hostname + DNS Problems, No resolving

adnz

Member
Jan 29, 2012
5
0
51
cPanel Access Level
Root Administrator
Hello folks, I seem to be running into trouble with my newly acquired dedicated server. I'd greatly appreciate some help getting this off the ground.

After reading many posts on the same errors, support docs, and I'm stuck without a resolving site. I would like to believe that I have all the info entered in correctly.

Below are the steps I've taken.


1 - Basic Config - Default server IP (x.x.x.x)

2 - Basic Config - nameservers
Created two unique names, assigned them to two free IP's.​
ns1.domain.com and ns2.domain.com - gave both an A record and two unique IP's assigned to my dedicated server.​


3 - Hostname - created a hostname: host.domain.com

4 - Resolvers - added primary and secondary (initially, GoogleDNS, then changed to OpenDNS)
208.67.222.222
208.67.220.220​


5 - Added DNS Zones. In total there are 4 zones.
host.domain.com
domain.com
ns1.domain.com
ns2.domain.com​


6 - Created DNS records at GoDaddy, assigned to domain name.
Added to host summary, ns1. and ns2. both assigned the same unique IP's​


7 - Restarted server. Since then, nothing is resolving. I've also received the cPanel warning error about hostname being invalid, although it seems to have stopped on its own. Hasn't happened in the past 12 hours.

So I checked hosts and resolv.conf for any potential problems. I'm not sure if the local lines are required.


/etc/hosts x.x.x.x = Default server IP
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
x.x.x.x host.domain.com host
/etc/resolv.conf
nameserver 208.67.222.222
nameserver 208.67.220.220
I'm sitting on my hands in confusion at the moment. If you have any tips, help, noticed any problems above, please let me know :(

Notes: Running on CentOS 5.7, NS = BIND, WHM 11.3.5 build6 (not that these are needed, but just in case)
 

JayFromEpic

Well-Known Member
Apr 2, 2011
218
8
68
Scottsdale
cPanel Access Level
Root Administrator
Twitter
Can you go ahead and double check your DNS records are correct. I have seen several instances where the script in cPanel to add the records automatically did not complete successfully.

Can you also check your /etc/nameserverips to make sure everything looks kosher.
 

adnz

Member
Jan 29, 2012
5
0
51
cPanel Access Level
Root Administrator
I have two lines that (as far as I know) seem correct. Same two assigned to the box that were used above, not from resolv.conf, but the server IP's.

x.x.x.x=ns1.domain.com
x.x.x.x=ns2.domain.com
 

Indianets

Well-Known Member
PartnerNOC
Jun 13, 2008
65
0
56
cPanel Access Level
Root Administrator
5 - Added DNS Zones. In total there are 4 zones.
host.domain.com
domain.com
ns1.domain.com
ns2.domain.com​
If you are able to resolve the domains from within your box, I would try this --

Backup all 4 zones. Remove ns1, ns2 , host zones and keep only domain.com zone.
Add subdomain records for ns1, ns2, host to the only zone instead.
Manually check all records especially A record for the domain.

rebuild dns config
restart named

I am not assuring this will resolve your problem. But conflicting IPs in multiple zones might create such issues. If this has no effect, reverse the process.

- Vijay
 

adnz

Member
Jan 29, 2012
5
0
51
cPanel Access Level
Root Administrator
At the moment it's not resolving correctly from the machine, it's leading me to a few domains at secureserver.net :eek:

Going to give it some more time, and see if that changes first.
 

JayFromEpic

Well-Known Member
Apr 2, 2011
218
8
68
Scottsdale
cPanel Access Level
Root Administrator
Twitter
Well how long ago exactly has it been since you created the host records on godaddy's website for the domain?

If you could give the domain name as well, it would help. I have a few tools I can use to diagnose some common issues.
 

adnz

Member
Jan 29, 2012
5
0
51
cPanel Access Level
Root Administrator
About 2 days ago. I just changed them over to OpenDNS yesterday.

After running some more tests on various sites (viewdns.info, etc) I was able to get these snippets of information.

All nameservers mentioned below are the same as above. (ns1.domain.com. and ns2.domain.com.) Sorry for the big block of quotes, I tried to make it easier to break down, even though they're mostly common sense answers.


Local Tests

Local nameservers answer authoritively - Error
The following nameservers do not answer authoritatively for your domain:

This means that these servers don't have a zone file for your domain and are simply looking up the details themselves! This is not a good thing!


Missing NS records at local servers - Error
It appears that the following nameserves listed at the parent servers are not listed at your local servers:

You should ensure that these nameservers are valid and working. If they aren't, it can cause odd behaviour including some people not being able to access your domain.


Nameservers allow TCP connections - Error
We couldn't connect to the following nameservers using TCP on port 53

Glue at local nameservers - Warning
Your local nameservers don't return IP addresses (glue) along with your NS records! This isn't a fatal error but means an extra lookup needs to be performed increasing the load time to your site. You can fix this by adding A records for each of the nameservers listed above.

SOA Tests
SOA primary nameserver listed at parent - Warning
The primary nameserver listed in your SOA record () is not listed at the parent servers! This could suggest a configuration issue with your SOA record.

SOA serial number format - Warning
Your SOA serial number () doesn't seem to be in the recommended format (YYYYMMDDnn - where nn is the revision number). This is still OK, however as long as you are keeping track of your SOA version details.
SOA Refresh value - Warning
Your SOA Refresh value () is outside of the recommended range of 1 hour (3600) to 1 day (86400). This value basically means 'how long can the secondary nameserver have out of date information after updating the primary nameserver?' and should be within the recommended range.
SOA Retry value - Warning
Your SOA Retry value () is outside of the recommended range of 1 hour (3600) to 4 hours (14400). This value determines how long your nameservers will wait to retry after a failed refresh attempt. If the value is too low (<3600) chances are it will fail over and over causing extra traffic use and load on the nameserver, if it is too high (>14400) you will have out of date information on one of your nameservers for longer than necessary.


WWW CNAME lookup - Error
You don't have a CNAME entry or an A record for your WWW record. This means that no-one will see your site when they visit.
 

cPanelTristan

Quality Assurance Analyst
Staff member
Oct 2, 2010
7,607
40
248
somewhere over the rainbow
cPanel Access Level
Root Administrator
It could be your firewall doesn't have UDP port 53 opened. If you are using the default RedHat firewall, it won't have that port opened and will deny traffic on it, which will not allow connections to resolve domains. As such, what is your firewall showing?

Code:
/usr/sbin/iptables -n -L
If you aren't using another firewall besides the default, try flushing it temporarily to see the results:

Code:
/sbin/iptables -F
At that point, try digging on hostname via the nameserver to see if it works:

Code:
dig +short @ns1.domain.com host.domain.com
If it does end up being that port 53 wasn't opened for UDP traffic, try opening it up by restarting the firewall (/sbin/iptables restart) and then running the following command:

Code:
/sbin/iptables -I RH-Firewall-1-INPUT -p udp -m udp --dport 53 -j ACCEPT
Of note, if you are running CSF or APF, do not issue a restart on the firewall but re-enable / re-start the firewall using their tools instead.
 

adnz

Member
Jan 29, 2012
5
0
51
cPanel Access Level
Root Administrator
Edit: However, subdomains are still not functioning. ie. www.domain.com
But there is a CNAME entry pointing to domain.com in the domain.com zone, so I'm not entirely sure why that would not redirect.

Original:
Thanks for all the help guys, as Tristan suspected, it was port 53 not being opened to UDP traffic -- it was opened for TCP however, and I knew that as soon as I saw the first line of your reply. I must have blindly skipped it when looking at the rules... how embarrassing :p

If someone else runs into a similar problem in the future, check to see if your DNS can actually reach the web before making posts about it :|
 
Last edited: