5.3 KiB
Common DNS issues
- Nameserver differences
One of the most common DNS issues that can occur is when the nameservers in the DNS zone point to a different server then the one in the DNS zone
NOTE: The nameservers can be differrent as long as they resolve to the same servers, i.e. whitelabel nameservers
An example of this would be the domain 'benjamyn.love' if the whois information shows
Domain Name: BENJAMYN.LOVE
Registry Domain ID: D59451093-CNIC
Registrar WHOIS Server: whois.synergywholesale.com
...
Name Server: NS1.BENJAMYN.LOVE
Name Server: NS2.BENJAMYN.LOVE
And the DNS zone on those nameservers had nameservers that point to a different set of servers like
$ dig NS +short benjamyn.love
ns1.ventraip.net.au.
ns2.ventraip.net.au.
This will cause the DNS zone to check the above nameservers for some DNS records which in most cases will point to the old server or the old server will not have any records and the DNS will fail to load
The easiest way to tell this is to use the dig command along with the whois command and look for inconsistancies
I highly recommand also doing a dig NS +short 'nameserver address' for each of the sets to make sure they resolve to the same servers
- I updated my A record and now my mail is broken
This one is quite common in cPanel setups that have the MX records use the root domain
The way to check for this one is to dig the MX record and see if the CNAME it is using is the root domain
$ dig MX +short benjamyn.love
10 benjamyn.love.
In the above example the mail is using the root A record so you would update the DNS zone to use mail.benjamyn.love as the MX record and then make sure the mail. subdomain resolves directly to the server and is not another CNAME to the root
- DNS zone is not propagating but all the nameservers are correct
DNS records are not syncing at all
This one can be a few different things, first off if the DNS zone is not propagating out at all double check the nameservers are correct :)
The next step would be to see if the DNS records exist on the nameserver directly, you can query the nameservers for a record directly using the following command
$ dig @ns1.benjamyn.love benjamyn.love +short
110.232.142.185
The '@address' tells dig what server to check when doing the DNS lookup, this can also be used to check propagation with public DNS servers like '1.1.1.1' and '8.8.8.8'
If it does return the expected value then you should just need to wait for DNS to propagate
If the old recrord is still returned the issue may be with the DNS zone on the server not syncing out correctly
On the server in question you need to look at the DNS zone directly, for bind/named these zones are kept in flat files on the system in the /var/named directory
The files are usually called domain.tld.db there is a command to check the validity of the DNS zone built into bind/named named-checkzone
$ named-checkzone test.com test.com.db
dns_master_load: test.com.db:19: ftp.test.com: CNAME and other data
zone test.com/IN: loading from master file test.com.db failed: CNAME and other data
zone test.com/IN: not loaded due to errors.
The command will let you know any syntax errors or errors with the validity of the DNS (in this case there is a CNAME record and another record type on the same record which is invalid)
$ cat test.com.db
$TTL 86400
@ IN SOA ns1.benjamyn.love. servers.benjamyn.love. (
...
;Name Server Information
@ IN NS ns1.benjamyn.love.
@ IN NS ns2.benjamyn.love.
;IP address of Name Server
...
;CNAME record
ftp IN CNAME fiels.test.com.
ftp IN A 127.0.0.1
You can see that the ftp subdomain has two entries and there is both an A record an a CNAME and this can cause the DNS zone to not sync out
DNS requests are returning old records
This is usually caused by the DNS record having an older serial in the SOA record then what is already on the nameserver or propagated out
If the serial in the SOA record is older on the nameservers the new DNS zone will not sync out to the nameserver and therefore will not sync out to the rest of the world
If the serial in the SOA record in older then the one that has already propagated the other nameservers will never accept the new record as the serial in the SOA is older
In both of these case the fixes are the same, we just need to update the serial in the SOA so it is higher then what is reported by public DNS/the nameservers
dig SOA benjamyn.love +short
ns1.benjamyn.love. servers.benjamyn.love. 2018122201 3600 1800 604800 43200
$ cat /var/named/benjamyn.love.db
$TTL 86400
@ IN SOA ns1.benjamyn.love. servers.benjamyn.love. (
2017122201 ;Serial
3600 ;Refresh
1800 ;Retry
604800 ;Expire
43200 ;Minimum TTL
)
You can see that the serial here is 2017122201 and the one reported by DNS is 2018122201, so to fix this up and make the proper DNS records resolve we just need to make the serial higher then what is reported from dig, the general format is 2019 'year' 02 'month' 26 'day' 01 'extra' 2019022601
We just need to edit the DNS zone and change the SOA serial to our new one 2019022601 and sync the DNS zone, this is usally done via a tool in WHM
$TTL 86400
@ IN SOA ns1.benjamyn.love. servers.benjamyn.love. (
2019022601 ;Serial
3600 ;Refresh
1800 ;Retry
604800 ;Expire
43200 ;Minimum TTL
)