134 lines
5.3 KiB
Markdown
134 lines
5.3 KiB
Markdown
# 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
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
$ 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](/Commands/dns#dig) command along with the [whois](/Commands/dns#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
|
|
|
|
```bash
|
|
$ 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
|
|
|
|
```bash
|
|
$ 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`
|
|
|
|
```bash
|
|
$ 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)
|
|
|
|
```dns
|
|
$ 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
|
|
|
|
```bash
|
|
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
|
|
|
|
```bash
|
|
$TTL 86400
|
|
@ IN SOA ns1.benjamyn.love. servers.benjamyn.love. (
|
|
2019022601 ;Serial
|
|
3600 ;Refresh
|
|
1800 ;Retry
|
|
604800 ;Expire
|
|
43200 ;Minimum TTL
|
|
)
|
|
``` |