PTR records in forward zone file.

Jim Reid jim at rfc1035.com
Fri Apr 27 08:11:33 UTC 2001


>>>>> "Fabiola" == Fabiola Caceres <fabiola at infi.net> writes:

    Fabiola> Hi I have a customer requesting me to add the following
    Fabiola> entry to teir zone file:

    Fabiola> ftp IN A 206.153.168.34
    Fabiola> 206.153.168.34.wichitaeagle.com. IN PTR ftp.wichitaeagle.com

    Fabiola> Because we don't host the reverse.  I thought I coudln't
    Fabiola> add PTR records to a forward zone files...

There's nothing magical about PTR records. Any resource record can go
in any zone, so putting the above PTR record into the zone file is
just fine. In fact it's needed to make reverse lookups work. What your
customer has asked for is perfectly sensible. The administrator of the
168.153.206.in-addr.arpa zone has already added:

  34.168.153.206.in-addr.arpa. IN    CNAME   206.153.168.34.wichitaeagle.com.

So a reverse lookup of 206.153.168.34 will result in a query for
34.168.153.206.in-addr.arpa which finds the above CNAME. But the
target of that CNAME doesn't exist yet because you've not added the
PTR record the customer asked to the wichitaeagle.com zone. It looks
like your customer seems to know more about DNS than you do. Which
could make life interesting. The above technique -- CNAMEs in reverse
zones -- is a variation on RFC2317: Classless in-addr.arp
Delegation. It's a very commonly used way of delegating small chunks
of reverse space that don't start or end on a /24 boundary.


More information about the bind-users mailing list