It's helpful to realize that there's really nothing different between a "forward" zone and a "reverse" zone. The former *generally* contains A (address records) and latter *generally* contains PTR records, but, both zones can and do carry other record types (SOA and NS, obviously, but CNAMEs, etc., also) -- it's all just DNS data. The magic is in what the DNS clients do when they request a lookup. Viz.: To get an IP address, when presented with a "name", a DNS client does an "A"-record lookup on the name given, and this causes the nameserver to look in what we call the "forward zone" for an "A" record, but it's only because that's what the client asked for. E.g., when a client asks for "a.b.c.com", the server ultimately looks in his "b.c.com" zone data and we happen to call this the "forward zone". But, when trying to look up a *name*, when presented with an IP address, say "a.b.c.d", (which we call "reverse" lookup) (e.g., an 'rlogin' server trying to find out the name of the client machine from which the login is occurring so that he, the 'rlogin' server, can check that name in the ".rhosts" file ), the DNS client (which is the 'rlogin' server code in this example :) requests a lookup for a "PTR" record, "d.c.b.a.in-addr.arpa." . (Note that the above is generally hidden in library calls, e.g., gethostbyname and gethostbyaddr on Unix. ) All of that should pretty well be known, even by a newbie. But, two major, non-obvious-to-the-newbie things, I think, that help clear up the non-octet-reverse delegation are: 1. valid CNAMEs can point to records *outside* the current zone foo.bar.com. IN A 1.2.3.4 fubar.bar.com. CNAME yyy.yahoo.com. 2. PTRs can have CNAMEs as well ! 4.3.2.1.in-addr.arpa. IN PTR foo.bar.com. 5.3.2.1.in-addr.arpa. CNAME fandoo.bar.com. 6.3.2.1.in-addr.arpa. CNAME 6.subxx.3.2.1.in-addr.arpa. (where fandoo.bar.com. and 6.subxx.3.2.1.in-addr.arpa. would be PTR records in the bar.com and subxx.3.2.1.in-addr.arpa zones, respectively. ) Your ISP is generally authoritative for the class C from which he has parsimoniously given you a few addresses. So he can handle the reverse PTRs for you -- if he wants to!! If you are hosting your DNS, even though your ISP's kindly agreed to be a secondary for your "forward" domain, he's not gonna want to be bothered changing or adding PTR records while you can't decide on a good name for one of your boxes. So you really want to handle the reverse yourself. However, the ISP doesn't want to delegate to you the *whole* class C in-addr.arpa domain (since there are other clients therein :). However, he *can* delegate a *sub-domain* of the class C in-addr.arpa to you, (since he's authoritative for the parent). Then he can put CNAMEs in his parent pointing to the PTRs in the sub-domain he delegated to you! So, he is still authoritative for 3.2.1.in-addr.arpa, but has delegated to you, say "hoohah.3.2.1.in-addr.arpa", which is a valid sub-domain of "3.2.1.in-addr.arpa" . Then he has 1.3.2.1.in-addr.arpa. CNAME 1.hoohah.3.2.1.in-addr.arpa. ... 6.3.2.1.in-addr.arpa. CNAME 6.hoohah.3.2.1.in-addr.arpa. (or 1 CNAME 1.hoohah.3.2.1.in-addr.arpa. ... 6 CNAME 6.hoohah.3.2.1.in-addr.arpa. since the ORIGIN, ".hoohah.3.2.1.in-addr.arpa. " will be appended to those non-dot-terminated names. And, probably done with a $GENERATE 1-6 $ CNAME $.hoohah.3.2.1.in-addr.arpa. ) You are authoritative for "hoohah.3.2.1.in-addr.arpa" (since the ISP delegated it to you) and in the zone master file for that domain, you have: 1.hoohah.3.2.1.in-addr.arpa. IN PTR www.bar.com. 4.hoohah.3.2.1.in-addr.arpa. IN PTR foo.bar.com. (or 1 IN PTR www.bar.com. 4 IN PTR foo.bar.com. ) or whatever. It doesn't really matter that you don't have the other records. When a DNS client wants to do a reverse lookup on 1.2.3.4, he will do a PTR request for 4.3.2.1.in-addr.arpa. It will be found that the ISP is authoritative for 3.2.1.in-addr.arpa and he will be queried for 4.3.2.1.in-addr.arpa. But the CNAME will point to 4.hoohah.3.2.1.in-addr.arpa for which you are authoritative and you'll be queried for it and will return "foo.bar.com". Voila! Of course, the ISP will probably not call the sub-domain "hoohah", but "0-7" or "sub-0-7" or "subnet-0" or "0/29" or something more meaningful. I'm sure that the gurus will find and fill holes in the above, but it should clarify things for you a bit. ------------------------------------------------- Tks | <mailto:[EMAIL PROTECTED]> BV | <mailto:[EMAIL PROTECTED]> Sr. Technical Consultant, SBM, A Gates/Arrow Co. Vox 770-623-3430 11455 Lakefield Dr. Fax 770-623-3429 Duluth, GA 30097-1511 ================================================= -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alexandra Sent: Friday, January 19, 2001 9:50 PM To: [EMAIL PROTECTED] Subject: How to configure bind with less than a block of ip's? I'm trying to get a handle on DNS and Bind in order to run my own name server. After reading chapter 4 in the cricket book, various tutorials on the internet, and the ask Mr. DNS forum my mind is somewhat less tortured. My question concerns PTR records. The example in the DNS and Bind book is fine and dandy if you happen to have at the very least a class C network at your disposal. Me, Joe Littlefish, on the other hand plan on only having a handful of IP addresses allocated to me by my yet to be decided upon ISP. So if I have the IP addresses 192.249.249.17 through 192.249.249.28 I can't very well have one file that say's: 249.249.192.in-addr.arpa IN SOA bla bla bla Do I need to set up one file for every ip number??? Also, how do most ISP's delagate just a portion of a block of ip's to me since it's not an octet. Trying to make sense out of RFC2317 I 'm guessing this is what the ISP does: the db record would have an A record and PTR record ie littlefish.com. A 192.249.249.17 192.249.249.17.in-addr* PTR** littlefish.com *why isn't it 192.249.249.17.in-addr.arpa.??**What's PTR? the same as IN PTR? The ISP's in-addr.arpa file would look like this: 249.249.192.in-addr.arpa IN SOA ....... 17 CNAME 17.249.249.192.in-addr.A.domain* I left this in it's original state from RFC 2317 I don't get what should be appended in place of "A.domain" would it be 17.249.249.192.in-addr.littlefish.com???? It's a bit confusing. There's CNAMES in the rev file and PTR records in the forward file. Any help clarifying any of this would be appreciated. My main concern though is what I need to do. Is it as simple as me making a rev file for each of my ip addresses? ie 249.249.192.17.in-addr.arpa through 249.249.192.28.in-addr.arpa . or is it simpler only involving 1 rev file? Thanks, Scott _________________________________ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]