So I can't understand why DNSStuff can not see it?
Learn to use and trust basic tools, not some 3rd-party GUI. Even broken nslookup as a query tool is more trustable than a huge web application. dig is the best DNS query tool.
First, delegation:
dig 175.163.65.in-addr.arpa soa +trace
; <<>> DiG 9.2.3 <<>> 175.163.65.in-addr.arpa soa +trace ;; global options: printcmd . 216585 IN NS f.root-servers.net. . 216585 IN NS g.root-servers.net. . 216585 IN NS h.root-servers.net. . 216585 IN NS i.root-servers.net. . 216585 IN NS j.root-servers.net. . 216585 IN NS k.root-servers.net. . 216585 IN NS l.root-servers.net. . 216585 IN NS m.root-servers.net. . 216585 IN NS a.root-servers.net. . 216585 IN NS b.root-servers.net. . 216585 IN NS c.root-servers.net. . 216585 IN NS d.root-servers.net. . 216585 IN NS e.root-servers.net. ;; Received 324 bytes from 81.255.84.69#53(81.255.84.69) in 12 ms
65.in-addr.arpa. 86400 IN NS dill.ARIN.NET. 65.in-addr.arpa. 86400 IN NS basil.ARIN.NET. 65.in-addr.arpa. 86400 IN NS henna.ARIN.NET. 65.in-addr.arpa. 86400 IN NS indigo.ARIN.NET. 65.in-addr.arpa. 86400 IN NS epazote.ARIN.NET. 65.in-addr.arpa. 86400 IN NS figwort.ARIN.NET. 65.in-addr.arpa. 86400 IN NS chia.ARIN.NET. ;; Received 192 bytes from 192.5.5.241#53(f.root-servers.net) in 228 ms
163.65.in-addr.arpa. 86400 IN NS NS1-AUTH.SPRINTLINK.net. 163.65.in-addr.arpa. 86400 IN NS NS2-AUTH.SPRINTLINK.net. 163.65.in-addr.arpa. 86400 IN NS NS3-AUTH.SPRINTLINK.net. ;; Received 124 bytes from 192.35.51.32#53(dill.ARIN.NET) in 4254 ms
175.163.65.in-addr.arpa. 86400 IN NS mail.stat.com. ;; Received 84 bytes from 206.228.179.10#53(NS1-AUTH.SPRINTLINK.net) in 114 ms
175.163.65.in-addr.arpa. 3600 IN SOA mail.stat.com. david.stat.com. 2004081402 7200 1800 1209600 1800
;; Received 120 bytes from 65.163.175.10#53(mail.stat.com) in 182 ms
Delegation is ok, and it can be double-checked. Ask sprint NS for the PTR:
# dig 10.175.163.65.in-addr.arpa ptr @NS1-AUTH.SPRINTLINK.net.
; <<>> DiG 9.2.3 <<>> 10.175.163.65.in-addr.arpa ptr @NS1-AUTH.SPRINTLINK.net. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42493 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION: ;10.175.163.65.in-addr.arpa. IN PTR
;; AUTHORITY SECTION: 175.163.65.in-addr.arpa. 86400 IN NS mail.stat.com.
... sprint doesn't have the answer, so it gives a referral to another NS. Ask that NS:
# dig 10.175.163.65.in-addr.arpa ptr @mail.stat.com.
; <<>> DiG 9.2.3 <<>> 10.175.163.65.in-addr.arpa ptr @mail.stat.com. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39246 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;10.175.163.65.in-addr.arpa. IN PTR
;; ANSWER SECTION: 10.175.163.65.in-addr.arpa. 14400 IN PTR stat.com.
... delegation is correct, and the auth NS is answering authoritatively. But having a PTR is insufficient. Does the PTR have a matching A record? :
# dig stat.com. a
; <<>> DiG 9.2.3 <<>> stat.com. a ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5748 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
;; QUESTION SECTION: ;stat.com. IN A
;; ANSWER SECTION: stat.com. 14400 IN A 65.163.175.10
yes. So everything checks out perfectly.
If other queriers are not getting correct answers, their problem is not due to DNS, but some kind of connectivity problem. Or maybe due to your (single) DNS not being up all the time. But right now, all NSs for the reverse zone and the PTR record are up and correct.
Some comments:
There's no such thing as propagation delay in DNS, no matter how many times unknowing, misleading people repeat the phrase "DNS propagation".
If stale records were cached, they'd be returned as answers from the caches, not timing out, not "Lost in DNS Space" doing "propagating".
PTR for a mail server or an MX IP should be something self-explanatory like mx1.domain.tld or smtp.domain.tld. Don't be shy about creating records in your DNS database.
It's always helpful if an NS is labelled as an NS, like ns1.domain.tld, instead of mail.stat.com. DNS is plumbing. You don't label the hot water knob "frank" or "uranus", you label it "hot", or color it red.
You have only NS for the zone. If you would have had two NSs authoritative for the zone, with the second NS (a slave) on another network, it might be more clear now that mail.stat.com is not always reachable while the other NS would probably be.
Len
_____________________________________________________________________ http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of sites
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
