======= Reverse mapping ======= One of the most common uses of DNS is getting an IP number attached to a domain name (//forward lookups//), but there is a system for doing the reverse, getting a domain name from an IP number (//reverse lookups//), too. Reverse mapping for example is used by mail servers for tracking spammers by doing first a reverse lookup for the sender's IP number, and then a forward lookup for the returned domain name, or for diagnostic purposes, such as listing the active internet connections in nslookup. Reverse lookups are actually quite simple: we do a ''PTR''-type query for a special domain name composed from the IP number. If the IP number is ''a.b.c.d'', we do a ''PTR''-lookup for ''d.c.b.a.in-addr.arpa.''. For example, say we'd want to find the domain for ''66.35.250.210'', we'd do a query for the ''210.250.35.66.in-addr.arpa.'' domain. This might return something like the following: 210.250.35.66.in-addr.arpa. 2h PTR vhost.sourceforge.net. indicating that ''vhost.sourceforge.net.'' is a domain name for the IP number. ===== IPv6 reverse mapping ===== For IPv6, we have a similar situation in the ''ip6.int'' tree, except we get very long domain names, because every character in the IPv6 address gets its own DNS label, and short notations are not supported. For example, the IPv6 number ''1aef:a2::dead:beef'', is actually, in full: 1aef:00ae:0000:0000:0000:0000:dead:beef so its reverse-mapping domain name becomes: f.e.e.b.d.a.e.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.a.0.0.f.e.a.1.ip6.int. Just like for IPv6 forward mapping (see Using DNS for naming hosts), there is an alternate way of reverse-mapping as well, by means of the ''ipv6.arpa.'' domain name and ''DNAME'' records. Like the ''A6'' record though, this method is marked experimental and it is not supported by Posadis. ===== Short notation ===== Because especially IPv6 reverse-mapping domains can be bitches to type, Posadis introduces a short syntax for them: a dot followed by the address. For example, in all Posadis programs, ''210.250.35.66.in-addr.arpa.'' is the same as ''.66.35.250.210'', and f.e.e.b.d.a.e.d.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.a.0.0.f.e.a.1.ip6.int. is also known as ''.1aef:a2::dead:beef''. Take your pick. If you need a reverse-mapping zone name, such as ''250.35.66.in-addr.arpa.'', use ''.66.35.250.*'', or just ''.66.35.25''. ===== Delegation in ''in-addr.arpa.'' and ''ip6.int.'' ===== You may know that IP addresses have a kind of hierarchy in them. For example, all IP numbers ''a.b.c.d'' with the same value for ''a'' are in the same //A-class network//, and all IP numbers with the same value for ''a'' and ''b'' are in the same //B-class network//. From this, delegation of authority in ''in-addr.arpa.'' follows quite naturally. Unfortunately though, sometimes networks are also split within one label, for example, the ''66.35.160.0/25'' network refers to IP numbers ''66.35.160.0'' through ''66.35.160.127'' (//classless delegation//). So how do you delegate authority here? Well, there is no system for this, but [[http://www.faqs.org/rfcs/rfc2317.html|RFC 2317]] suggest setting up ''CNAME''s for all domain names pointing to delegated subdomains. Say we want to delegate ''66.35.160.0/25'' to one server, and ''66.35.160.128/25'' to another, we'd make the following zone: 0.160.35.66.in-addr.arpa. CNAME 0.0/25.160.35.66.in-addr.arpa. 1.160.35.66.in-addr.arpa. CNAME 1.0/25.160.35.66.in-addr.arpa. (...) 127.160.35.66.in-addr.arpa. CNAME 127.0/25.160.35.66.in-addr.arpa. 128.160.35.66.in-addr.arpa. CNAME 128.128/25.160.35.66.in-addr.arpa. (...) 255.160.35.66.in-addr.arpa. CNAME 255.128/25.160.35.66.in-addr.arpa. This way, we can let others control the ''0/25.160.35.66.in-addr.arpa.'' and ''128/25.160.35.66.in-addr.arpa.'' zones for their own IP number. Of course, this approach is only reasonable for ''/24'' or higher classless delegations: imagine managing a ''/17'' delegation: you'd need a zone with ''2^15'' such CNAME records...((There is a special RR type that can improve that situation, the ''DNAME'' record, but Posadis doesn't currently support it.)) ===== Reverse mapping for the internet ===== If you run an internet domain, you probably don't want to do reverse mapping: your ISP has probably already done that for you, and you should contact them if you want your reverse-mapping domain pointing somewhere else. Only if you have a complete C-class network or something like that hooked up to the internet you might consider having authority for the reverse mapping delegated to you. ===== Reverse-mapping for local networks ===== For local networks, you'd want to create two reverse-mapping zones. You always want one to have reverse mapping for ''localhost'', and one for the local IP numbers. The localhost reverse-mapping zone could be as simple as: $origin 0.0.127.in-addr.arpa. @ 2h SOA ns1.localnet. meilof@localnet. 1 2h 1h 1d 2h NS ns1.localnet. 1 PTR localhost. A simple local IP reverse mapping zone could be something like $origin 168.192.in-addr.arpa. @ 2h SOA ns1.localnet. meilof@localnet. 2004112801 2h 1h 1d 2h NS ns1.localnet. 1.1 PTR ns1.localnet. 2.1 PTR ns2.localnet. 3.1 PTR mail.localnet. 100.1 PTR client100.localnet. 101.1 PTR client101.localnet. and so forth. ===== The Posadis "revmap" module ===== Of note in this context is also the [[posadis:revmap]] module in Posadis 0.60.* and up. If you want to have working reverse-mapping for your network, and you don't care much about the details of the reverse mapping, you can use it to have reverse-mapping done automatically for you. Automatically generating ''PTR'' records is an approach that many ISPs use. ===== References ===== * [[http://www.webpronews.com/it/operatingsystems/wpn-22-20050104BasicDNSPTRRecordsandWhyYouCare.html|WebProNews.com: Basic DNS PTR Records and Why You Care]]