Performing a DNS lookup with dig results in this answer:
;; question SECTION:
;5.123.168.192.in-addr.arp
A.
IN PTR
;; ANSWER SECTION:
5.123.168.192.in-addr.arpa. 600 IN PTR linuserv.example.net.123.168.192.in-addr.arpa.
;;AUTHORITY SECTION:
123.168.192.in-addr.arpa. 600 IN NS linuserv.example.net.
;; ADDITIONAL SECTION:
linuserv.example.net. 600 IN A 192.168.123.5
What might be wrong in the zone definition?
Nothing. All seems to be good.
A.
IN PTR
;; ANSWER SECTION:
5.123.168.192.in-addr.arpa. 600 IN PTR linuserv.example.net.123.168.192.in-addr.arpa.
;;AUTHORITY SECTION:
123.168.192.in-addr.arpa. 600 IN NS linuserv.example.net.
;; ADDITIONAL SECTION:
linuserv.example.net. 600 IN A 192.168.123.5
What might be wrong in the zone definition?
Nothing. All seems to be good.
B.
There’s no “.” after linuserv.example.net in the PTR record in the forward lookup zone file.
C.
There’s no “.” after linuserv in the PTR record in the forward lookup zone file.
D.
There’s no “.” after linuserv.example.net in the PTR record in the reverse lookup zone file.
E.
The “.” in the NS definition in reverse lookup zone has to be removed.
Explanation:
The output was generated by the following dig:
Dig PTR 5.123.168.192.in-addr.arpa
In the answer section the PTR entry has the default domain added to the actual domain name,
indicating that the PTR record in the reverse lookup zone file is specified incorrectly.
can anyone give a real-world example?
0
0
If you dig IN PTR of the google DNS Server (8.8.8.8) as follows:
dig IN PTR 8.8.8.8.in-addr.arpa
you will see, that the arpa address is missing after the actual domain name in the answer section.
A dot after linuserv.example.net in the PTR record of the reverse lookup zone file causes this misbehavior.
0
0