BIND 8.2.3 Classless Example

Jim D. Kirby jdkirby at bluebunny.com
Thu Feb 1 21:38:14 UTC 2001


Being somewhat non-advanced with DDNS, I would postulate that the only
benefit to this approach is to maintain the manual formatting of the static
zone file while allowing the dynamic zone file to be updated willy nilly by
DDNS/DHCP/AD/Whatever.  Are there other benefits here I am failing to
recognize?

jk

-----Original Message-----
From: Bob Vance [mailto:bobvance at alumni.caltech.edu]
Sent: Thursday, February 01, 2001 2:10 PM
To: bind-users at isc.org
Subject: RE: BIND 8.2.3 Classless Example



>The CNAME 'trick'/method is intended for cases where you need to >delegate
parts of a block to another authority.

Or not even *another* authority.
I use this trick to create another zone on my (same) server for the
dynamic reverse zone when using DHCP and DDNS.  This allows my dynamic
range to be a part of my normal, static IP network range.

IOW
zone "dynamic.in-addr.arpa."

gets updated by DHCP with PTRs like:

44.1.168.192.dynamic.in-addr.arpa.  IN  PTR   h44.dynamic.vance.

Then, in my "normal" reverse zone,
$ORIGIN 1.168.192.in-addr.arpa.
   ...
;;;; statics
1    IN  PTR    gateway.vance.
6    IN  PTR    ns.vance.
7    IN  PTR    linux2.vance.
   ...
;;;; dynamic range
$GENERATE 16-47 $ CNAME  $.1.168.192.dynamic.in-addr.arpa.


The above works on my local network, where I can be authoritative for
in-addr.arpa, if I want to :)

To be strictly correct, I suppose that I should delegate:
    dynamic.1.168.192.in-addr.arpa.
out of
    1.168.192.in-addr.arpa.

and then have:

$ORIGIN 1.168.192.in-addr.arpa.
   ...
$GENERATE 16-47 $ CNAME  $.1.168.192.dynamic.1.168.192.in-addr.arpa.

but I didn't like the "extra" "1.168.192." :)


-----------------------------------------------
Tks          |  BVance at sbm.com
BV           |  BobVance at alumni.caltech.edu
Sr. Tech. Consultant,    SBM
Vox 770-623-3430         11455 Lakefield Dr.
Fax 770-623-3429         Duluth, GA 30097-1511
===============================================

-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org]On
Behalf Of Mathias Körber
Sent: Thursday, February 01, 2001 4:54 AM
To: esiewick at my-deja.com; comp-protocols-dns-bind at moderators.isc.org
Subject: RE: BIND 8.2.3 Classless Example



> The essential answer is that ALL the CNAME RRs have to come first
> in a given zone file.  Then all the PTRs, with each "Classless"
> subnet anchored by an $ORIGIN.  I've pasted a functioanl example
> into a page at <http://www.digipro.com/Papers/bind-8.2.3.shtml>.

Hmm. May I ask why you think it necessary to publish CNAME records for
PTRs if you put the PTRs into the same zone anyway? You could just
publish the PTR record at the non-classless level if you manage the
parent domain anyway.

The CNAME 'trick'/method is intended for cases where you need to delegate
parts of a block to another authority.


>
> On bugs, "ndc reload" doesn't notice when A and PTR records are
> changed.  You'll get the OLD and the NEW PTR records.

Did you change the serial number of the zone?
Could you elaborate or show an actual example?



More information about the bind-users mailing list