Date: Sun, 30 Jul 2000 11:35:09 +0930 From: Greg Lehey <grog@lemis.com> To: Evren Yurtesen <yurtesen@ispro.net.tr> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: reverse dns Message-ID: <20000730113509.D65178@wantadilla.lemis.com> In-Reply-To: <Pine.BSF.4.21.0007292346090.65152-100000@finland.ispro.net.tr>; from yurtesen@ispro.net.tr on Sat, Jul 29, 2000 at 11:49:14PM %2B0300 References: <Pine.BSF.4.21.0007292346090.65152-100000@finland.ispro.net.tr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, 29 July 2000 at 23:49:14 +0300, Evren Yurtesen wrote:
> I know that when somebody wants to resolv xyz.com this is first asked to
> root servers then to the dns server of the domain(which is found from the
> root servers)
>
> But I wonder if you want to lookup the name given for an IP address
> then how come the program knows which dns server to query?
Well, since I've just run into problems with this a few minutes ago
(all the name servers for the reverse lookup failed), I suppose I
should answer this one. Here's the text from "The Complete FreeBSD":
Reverse lookup
______________
/etc/hosts is a file, so it can allow you to perform lookup in either
direction. Not so with DNS: how can you know which name server is
authoritative for the domain if you don't know its name? You can't, of
course, so DNS uses a trick: it fabricates a name from the address. For the
address 223.147.37.4, it creates a domain name 37.147.223.in-addr.arpa and
looks up the name 4.37.147.223.in-addr.arpa. You'll note that the digits of
the address are reversed, and the last digit is missing, since it is
considered the host part of the address. This is one of the remaining cases
where the Internet address classes we discussed on page 484 still apply.
In order to resolve the names, we need another zone, then. That means
another file, which we'll call /etc/namedb/example-reverse. It's not quite
as bad as the forward file:
@ IN SOA freebie.example.org. grog.example.org. (
1996110801 ; Serial (date, 2 digits version of day)
86400 ; refresh (1 day)
7200 ; retry (2 hours)
8640000 ; expire (100 days)
86400 ) ; minimum (1 day)
IN NS ns.example.org.
IN NS ns1.example.org.
3 IN PTR bumble.example.org.
4 IN PTR wait.example.org.
5 IN PTR gw.example.org.
In this case, the SOA record is identical to that in
/etc/namedb/db.example.org, with two exceptions: instead of the zone name at
the beginning of the line, we have the @ symbol, and the serial number is
different: you don't normally need to update reverse lookup domains so often.
This @ symbol represents the name of the zone, in this case 37.147.223.in-
addr.arpa.. We'll see how that works when we make the /etc/named/named.root
file below. We also use the same name server entries. This time they need
to be fully qualified, since they are in a different zone.
Finally, we have the PTR (reverse lookup) records. They specify only the
last digit (the host part) of the IP address, so this will be prepended to
the zone name. The host name at the end of the line is in fully-qualified
form, since it's in another zone. For example, in fully-qualified form, the
entry for wait could be written:
4.37.147.223.in-addr.arpa. IN PTR wait.example.org.
Greg
--
When replying to this message, please copy the original recipients.
For more information, see http://www.lemis.com/questions.html
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000730113509.D65178>