Do you have recursive set to only be allowed by your IPs in your /etc/named.conf file to not allow your machine to be queried by other domains? Here's a discussion on how that might be the cause:
After installing updates - Server fails | Virtualmin
I can note that it is indeed the case that these IPs do not have PTR records, though, since if you try to dig 137.227.68.127 for example, there is not authoritative answer for a PTR:
Code:
$ dig -x 137.227.68.127
; <<>> DiG 9.6.0-APPLE-P2 <<>> -x 137.227.68.127
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39459
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;127.68.227.137.in-addr.arpa. IN PTR
;; Query time: 1540 msec
;; SERVER: 208.67.220.220#53(208.67.220.220)
;; WHEN: Mon Nov 21 13:47:09 2011
;; MSG SIZE rcvd: 45
I have reversed the 127.68.227.137.in.addr.arpa as that is the rDNS record, which means the real IP is actually 137.227.68.127 rather than the record listed as the PTR.
A working PTR (.in.addr.arpa) record would look like this on a dig:
Code:
$ dig -x 208.74.123.44
; <<>> DiG 9.6.0-APPLE-P2 <<>> -x 208.74.123.44
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9441
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;44.123.74.208.in-addr.arpa. IN PTR
;; ANSWER SECTION:
44.123.74.208.in-addr.arpa. 14400 IN PTR web4.cpanel.net.
It basically has an ANSWER SECTION that includes the PTR record, which is web4.cpanel.net. If you add
+short to the end of the dig, you will see that the first IP has no return while the cPanel IP shows web4.cpanel.net as the short return on the dig:
Code:
$ dig -x 208.74.123.44 +short
web4.cpanel.net.
