PTR Record

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

"Ordinary" record types such as A, CNAME and MX are created in forward lookup
zones, whereas as PTR records are created in reverse lookup zones, right?

I created a forward lookup zone, create a new domain. Then I right-clicked
it and selected "Other New Records". It then presented a list of record types
I could add. Unfortunately, PTR was listed. Does it mean I can add PTR
records in a forward lookup zone? What would be the use of it?

Similarly, Windows 2000 DNS allows me to add records other than PTR type in
a reverse lookup zone. What would be the use of it?

Thank for helping me as a newbie.
 
The separation in Windows 2000 DNS of "forward" and "reverse" lookup zones
is a somewhat artificial -- presumably done to underscore to users that the zones
serve quite different purposes.

Nonetheless, to DNS, a zone is a zone, and you can put any RR you like
in any zone file.

There would be no point to a PTR record in a non-arpa zone I can think of,
as nothing would ever look there for it.

Steve Duff, MCSE, MVP
Ergodic Systems, Inc.
 
In
Steve Duff said:
The separation in Windows 2000 DNS of "forward" and "reverse" lookup
zones
is a somewhat artificial -- presumably done to underscore to users
that the zones
serve quite different purposes.

Nonetheless, to DNS, a zone is a zone, and you can put any RR you like
in any zone file.

There would be no point to a PTR record in a non-arpa zone I can
think of,
as nothing would ever look there for it.

Steve Duff, MCSE, MVP
Ergodic Systems, Inc.
Click to expand...

I agree Steve. I just created one and tried to query for it using nslookup,
no go. Useless!

:-)

Ace
 
"Ordinary" record types such as A, CNAME and MX are created in forward lookup zones, whereas as PTR records are created in reverse lookup zones, right?

Wrong.  One may have any type of resource record in either kind of "zone".

What would be the use of [a PTR resource record in a forward lookup "zone"]?

Not much in practice.  Some people do some silly aliasing tricks to allow them to have address->name and name->address mapping data side by side, for ease of hand-maintenance.  (Other DNS server softwares provide better ways of achieving this end, without the silly aliasing tricks.  And note that the graphical user interface for Microsoft's DNS server provides convenience features for keeping address->name mappings and name->address mappings the inverses of each other.)

Similarly, Windows 2000 DNS allows me to add records other than PTR type in a reverse lookup zone. What would be the use of it?


Quite a lot. 

For example:  A properly delegated reverse lookup "zone" will have NS and A resource record sets for the delegation information at the apex.  (A badly delegated reverse lookup "zone" will use out-of-bailiwick intermediate domain names in the delegation, won't have the A resource record sets, and will be effectively glueless.) 

For another example: An "opaque" reverse lookup "zone" will have A resource record sets alongside each of the PTR resource record sets, so that the IP address 10.1.2.3 (say) maps to the domain name 3.2.1.10.in-addr.arpa., which in turn maps back to the original IP address.  Other DNS server softwares, such as walldns, can be used to used to provide such opaque service more efficiently and with less effort.

For a third example: Non-leaf reverse lookup "zones" will, of course, contain further delegations, and thus NS and A resource record sets.
 
In
David said:
"Ordinary" record types such as A, CNAME and MX are
created in forward lookup zones, whereas as PTR records
are created in reverse lookup zones, right?

I created a forward lookup zone, create a new domain.
Then I right-clicked it and selected "Other New Records".
It then presented a list of record types I could add.
Unfortunately, PTR was listed. Does it mean I can add PTR
records in a forward lookup zone? What would be the use
of it?

Similarly, Windows 2000 DNS allows me to add records
other than PTR type in a reverse lookup zone. What would
be the use of it?
Click to expand...

A PTR record can be delegated to a Forward Lookup Zone, this is usually
easier if you do not have access to a reverse lookup zone and you want your
ISP to delegate reverse lookup to you for an IP address.
For an example this is how I had an ISP delegate a reverse lookup for a
client, it makes it easier for the client because he has access to a forward
zone but not a reverse zone and you only have one zone. Works pretty cool!

Asking NS2.SWBELL.NET. for 155.28.95.68.in-addr.arpa PTR record: Got CNAME
referral to NS2.SWBELL.NET. (zone 155.28.95.68.in-addr.wftx.net.) [from
151.164.11.218]

Notice how the PTR is delegated to the forward zone?

Asking NS2.SWBELL.NET. for 155.28.95.68.in-addr.wftx.net. PTR record:
Reports mail.wftx.net. [from 151.164.11.218]

Answer:
68.95.28.155 PTR record: mail.wftx.net. [TTL 3600s] [A=68.95.28.155]

It still answers with a PTR record!
 
After reading your comments, may I put this way:

A zone is just a zone. Any kind of RR can be put in a zone. However, whether
the RR can be searched is a different question entirely.

For "normal" RR (such as A, MX, CNAME), the query (generally) starts from
the root domain, then the TLD, then the subdomain underneath, and so on. The
"search space" is the tree with <root> as the root.

On the other hand, for "reverse" RR (PTR), the search space is entirely
different, which is a tree with arpa as the root, then in-addr as its child,
then with octets of IP addresses as descendants.

Because the search spaces are totally different, it is of little use to put
an PTR record in a forward lookup zone. It can be there, but without the
support of the underlying search space, that record will never be located.

David.
 
In
David said:
After reading your comments, may I put this way:

A zone is just a zone. Any kind of RR can be put in a
zone. However, whether the RR can be searched is a
different question entirely.

For "normal" RR (such as A, MX, CNAME), the query
(generally) starts from the root domain, then the TLD,
then the subdomain underneath, and so on. The "search
space" is the tree with <root> as the root.

On the other hand, for "reverse" RR (PTR), the search
space is entirely different, which is a tree with arpa as
the root, then in-addr as its child, then with octets of
IP addresses as descendants.

Because the search spaces are totally different, it is of
little use to put an PTR record in a forward lookup zone.
It can be there, but without the support of the
underlying search space, that record will never be
located.
Click to expand...

You are correct, you can put a PTR record in a forward lookup zone, before
it will be queried, it must be delegated by the parent in-addr.arpa server
for the reverse IP, as in my example. It works fine so long as it is
delegated this way.
 
There would be no point to a PTR record in a non-arpa zone I can think of, as nothing would ever look there for it.




As I said, some people do some silly aliasing tricks to allow them to have address-&gt;name and name-&gt;address mapping data side by side, for ease of hand-maintenance:




$ORIGIN 125.7.147.64.in-addr.arpa. @ IN CNAME 125.7.147.64.example.org. $ORIGIN example.org. steve IN A 64.147.7.125 125.7.147.64 IN PTR steve



As I also said, other DNS server softwares provide better ways of having the two mappings kept in a single place (consider the = record in djbdns, for example), and the GUI for Microsoft's DNS server provides convenience features for keeping address-&gt;name mappings and name-&gt;address mappings the inverses of each other, both without the silly aliasing tricks.  
 
For "normal" RR (such as A, MX, CNAME), the query (generally) starts from the root domain, then the TLD, then the subdomain underneath, and so on. The "search space" is the tree with as the root.

On the other hand, for "reverse" RR (PTR), the search space is entirely different, which is a tree with arpa as the root, then in-addr as its child, then with octets of IP addresses as descendants.

Because the search spaces are totally different, [...]

There isn't a concept of a "search space", and the roots of both trees are the same. How query resolution progresses is not affected by the resource record type.

The very simple fact is that domain names associated with "forward" lookups are in one part of the DNS namespace tree and domain names associated with "reverse" lookups are in another part. But there's nothing inherently "forward" and "reverse" about a lookup as far as the DNS namespace itself or DNS resource record types are concerned. All lookups are for a &lt;domain-name,class,type&gt; tuple.
 
KDGS> Notice how the PTR is delegated to the forward zone?

No; because it is aliased, not delegated.

This is the very trick that I was referring to.
 
Back
Top