SOA & MX, How to solve the problem?
- Thread starter wm20472
- Start date
# dig type provisionhk.com
------------------------------------------------------------
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> type provisionhk.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54319
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;type. IN A
;; AUTHORITY SECTION:
. 5 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2019112500 1800 900 604800 86400
;; Query time: 9 msec
;; SERVER: 202.130.97.65#53(202.130.97.65)
;; WHEN: Mon Nov 25 15:20:21 2019
;; MSG SIZE rcvd: 97
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35561
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;provisionhk.com. IN A
;; ANSWER SECTION:
provisionhk.com. 900 IN A 115.160.128.100
;; Query time: 13 msec
;; SERVER: 202.130.97.65#53(202.130.97.65)
;; WHEN: Mon Nov 25 15:20:21 2019
;; MSG SIZE rcvd: 49
------------------------------------------------------------
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> type provisionhk.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54319
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;type. IN A
;; AUTHORITY SECTION:
. 5 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2019112500 1800 900 604800 86400
;; Query time: 9 msec
;; SERVER: 202.130.97.65#53(202.130.97.65)
;; WHEN: Mon Nov 25 15:20:21 2019
;; MSG SIZE rcvd: 97
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35561
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;provisionhk.com. IN A
;; ANSWER SECTION:
provisionhk.com. 900 IN A 115.160.128.100
;; Query time: 13 msec
;; SERVER: 202.130.97.65#53(202.130.97.65)
;; WHEN: Mon Nov 25 15:20:21 2019
;; MSG SIZE rcvd: 49
You shouldn't use intodns to diagnose problems. This will lead you down a rabbit hole in which you spend hours attempting to correct things from a workable state into a "technically correct" state, which will do nothing to solve the problem that led you to use it in the first place. While it can and will identify legitimate issues, it will identify a lot of "problems" that do not break anything.
The only issue it identified that you should be worried about is the lack of a PTR record, which is set by your ISP. That should match your server hostname and should be a fully qualified domain name (ex. sub.domain.tld).
The only issue it identified that you should be worried about is the lack of a PTR record, which is set by your ISP. That should match your server hostname and should be a fully qualified domain name (ex. sub.domain.tld).
- Joined
- Jul 10, 2019
- Messages
- 303
The mailserver IP has no PTR record set:
j@9ub3:~$ dig mx +short provisionhk.com
10 mail.provisionhk.com.
j@9ub3:~$ dig a +short mail.provisionhk.com
115.160.128.100
j@9ub3:~$ host 115.160.128.100
Host 100.128.160.115.in-addr.arpa. not found: 3(NXDOMAIN)
j@9ub3:~$ dig -x 115.160.128.100 | grep PTR
;100.128.160.115.in-addr.arpa. IN PTR
j@9ub3:~$
The rDNS/PTR record is really important for bypassing spam filtering! This is a necessary record to have set. You can set the PTR for the IP to mail.provisionhk.com since it resolves back to the same IP (this is important).
You can ignore the 'one mailserver' warning unless you are willing to configure a backup mailserver (a different mailserver with a lower priority, which means a higher numerical value... ex. priority of 0 is a higher priority than a secondary MX record with a priority of 10).
Regarding the SOA expire value, per https://tools.ietf.org/html/rfc1912
Expire: How long a secondary will still treat its copy of the zone
data as valid if it can't contact the primary. This value
should be greater than how long a major outage would typically
last, and must be greater than the minimum and retry
intervals, to avoid having a secondary expire the data before
it gets a chance to get a new copy. After a zone is expired a
secondary will still continue to try to contact the primary,
but it will no longer provide nameservice for the zone. 2-4
weeks are suggested values.
So, change this value in the DNS zone for the domain.
NOTE: You may need to ask your hosting provider to update some of these settings for you depending on your access level.
j@9ub3:~$ dig mx +short provisionhk.com
10 mail.provisionhk.com.
j@9ub3:~$ dig a +short mail.provisionhk.com
115.160.128.100
j@9ub3:~$ host 115.160.128.100
Host 100.128.160.115.in-addr.arpa. not found: 3(NXDOMAIN)
j@9ub3:~$ dig -x 115.160.128.100 | grep PTR
;100.128.160.115.in-addr.arpa. IN PTR
j@9ub3:~$
The rDNS/PTR record is really important for bypassing spam filtering! This is a necessary record to have set. You can set the PTR for the IP to mail.provisionhk.com since it resolves back to the same IP (this is important).
You can ignore the 'one mailserver' warning unless you are willing to configure a backup mailserver (a different mailserver with a lower priority, which means a higher numerical value... ex. priority of 0 is a higher priority than a secondary MX record with a priority of 10).
Regarding the SOA expire value, per https://tools.ietf.org/html/rfc1912
Expire: How long a secondary will still treat its copy of the zone
data as valid if it can't contact the primary. This value
should be greater than how long a major outage would typically
last, and must be greater than the minimum and retry
intervals, to avoid having a secondary expire the data before
it gets a chance to get a new copy. After a zone is expired a
secondary will still continue to try to contact the primary,
but it will no longer provide nameservice for the zone. 2-4
weeks are suggested values.
So, change this value in the DNS zone for the domain.
NOTE: You may need to ask your hosting provider to update some of these settings for you depending on your access level.
Last edited: