Understanding PTR Records

D

dkovacevic

I am testing Postfix and Dovecot for my own learning. I have two boxes set up, one with IP 192.168.1.240 which answers authoritatively for “example.org” and the other with IP 192.168.1.227 which answers authoritatively for “test.com”.

One of the many things that can be done to improve the general security of an email server is to not accept SMTP connections (and email) from servers with IP addresses that do not match the PTR record for that IP.

I've run into a snag in attempting to test this feature (PTR lookup). Specifically, when executing host 192.168.1.240 on that same system (240), the request times out with no servers reached.

/etc/resolv.conf points to a recursive DNS server running dnscache[cmd] (IP 192.168.1.225). That server has its [file]/etc/resolv.conf[/file] pointing to itself. The list of query servers on 225 stored in file [file]/usr/local/etc/dnscache/root/servers/@[/file] include:

192.168.1.227
192.168.1.240

Running [cmd]tcpdump -K dst port 53 produces these interesting results:

Code: 
14:04:10.564747 IP 192.168.1.240.33676 > 192.168.1.225.domain: 38981+ PTR? 240.1.168.192.in-addr.arpa. (44)
14:04:10.565007 IP 192.168.1.225.42630 > 192.168.1.240.domain: 58549 PTR? 240.1.168.192.in-addr.arpa. (44)
14:04:11.066710 IP 192.168.1.240.13156 > 192.168.1.225.domain: 16896+ PTR? 225.1.168.192.in-addr.arpa. (44)
14:04:11.066967 IP 192.168.1.225.6838 > 192.168.1.240.domain: 47840 PTR? 225.1.168.192.in-addr.arpa. (44)
14:04:11.585699 IP 192.168.1.225.63960 > 192.168.1.227.domain: 63139 PTR? 240.1.168.192.in-addr.arpa. (44)
14:04:12.087749 IP 192.168.1.225.20815 > 192.168.1.227.domain: 49748 PTR? 225.1.168.192.in-addr.arpa. (44)

The strange thing is that 192.168.1.240 is configured with a PTR record for itself. So, when 225 asked 240 for the PTR record for 240, I would have expected 240 to provide; instead, 240 then asks 225 for ITS PTR record. I'm going to guess that this is a security mechanism.

My question is this: what would be the best way to go about simulating the Internet via DNS with my three boxes?

Less importantly- why is it that tinydns refused to answer the PTR query in the first place?
 
For the PTR records to work you have to have an authoritative server for the matching domain, in this case 1.168.192.in-addr.arpa. If your server is not authoritative for this domain the resolver tries the forwarders for answers.
 
Pretty much what @kpa said.

Typically your ISP will "own" the DNS space for your netblock and you may have to ask them to register the PTR records for you - or they may provide a web UI for you to manage the PTR records for the IP addresses you use yourself.

In your situation (LAB, not live on Internet), you'll need to configure an authoritative reverse zone on your DNS for the IP subnet you want to resolve.
 
Last edited by a moderator:
What I failed to understand about PTR records is that they are tied to IP address blocks. Specifically, to 256 sized blocks, for which a workaround was devised for allowing these records to be split across 256 sized blocks (when the Internet started to expand).

I know enough about PTR records now that I believe I can work with my ISP to assign the correct entries for my mx / ns servers when the time comes. I am not going to mess about with subnets in order to get PTR records working in my example set up.
 
PTR records can be delegated in sizes smaller than a /24. I delegated 'PTR blocks' as small as a /29 to DSL clients so they could manage their own PTR records. RFC 2317 describes a way of delegating (control of) classless PTR records.
 
You must log in or register to reply here.
Back
Top