Non-Octet Boundary Delegation (RFC 4183)

[Станислав]

Thank you Simon, thank you Andris.

Andris, problem is that in that case I will need to use "nslookup
68.27.133.10.ptr-pa.lan.orga.ru instead of "nslookup 10.133.27.68" to
get DNS record. Ideas?

Regards,
Stas

On Thu, Sep 22, 2011 at 5:04 AM, Andris Kalnozols <andris at hpl.hp.com> wrote:
>> ginermail at gmail.com> wrote:
>>
>> I've tried to use "zone 0-25.0.16.172.in-addr.arpa." for a reverse
>> zone but it didn't work.
>>
>> Stas
>>
>> On Thu, Sep 22, 2011 at 12:02 AM, Alex Bligh <alex at alex.org.uk> wrote:
>> >
>> >
>> > --On 21 September 2011 23:38:02 +0400 Станислав <ginermail at gmail.com> wrote:
>> >
>> >> Could anyone tell me if ISC DHCP supports Non-Octet Boundary
>> >> Delegation? It supports by ISC BIND as I see but I've not managed to
>> >> find the same information related to the DHCP server.
>> >
>> > Support in what sense? DHCP doesn't deal with delegation of domain
>> > names. It is fully CIDR compliant, if that's what you mean.
>
>
> To follow up Simon's later post with a real-life example, here
> are some excerpts from the BIND and DHCP configuration files
> we use at our site that may be relevant to your situation which,
> if correctly understood, deals with the issue of the ISC DHCP
> server being able to do dynamic DNS updates of PTR records that
> map to an `in-addr.arpa' space smaller than a /24 network.
>
> The inline comments should explain things.
> This setup works for us but if the experts on this mailing list
> find issues with it, I'm sure to learn from them.
>
> ------
> Andris
>
>
> BIND named.conf
> ===============
>
> key "hostmaster" {
>        algorithm hmac-md5;
>        #
>        # Keep the secret TSIG key in a separate file
>        # which has read access that is more restricted
>        # than this publicly readable file.
>        #
>        include "/etc/bind/keys/hostmaster.secret";
> };
> key "dhcp-pa" {
>        algorithm hmac-md5;
>        include "/etc/bind/keys/dhcp-pa.secret";
> };
>
> ......
>
> zone "ptr-pa.hpl.hp.com" {
>        type master;
>        file "db.ptr-pa.hpl";
>        update-policy {
>                grant hostmaster subdomain ptr-pa.hpl.hp.com ANY;
>                grant dhcp-pa wildcard *.ptr-pa.hpl.hp.com PTR TXT DHCID;
>        };
> };
>
>
> DHCP dhcpd.conf
> ===============
>
> ddns-update-style interim;
> allow client-updates;           # allow clients to update their own "A" records
> option fqdn.rcode2      255;    # tell clients that PTR DNS updates are deferred
>
> # Keep the secret TSIG key for making secure DNS updates
> # in a separate file which has read access that is more
> # restricted than this publicly readable file.
> #
> include "/etc/dhcp/keys/dhcp-pa";
>
> # The ISC DHCP server is currently limited in the way in which
> # the owner field of a PTR resource record can be manipulated
> # before sending a dynamic DNS update.  The server always sends
> # *all four* of the reversed octets of the IP address appended
> # by either ".in-addr.arpa." (the default) or the contents of
> # the "ddns-rev-domainname" server option.
> # While this is fine for "in-addr.arpa" zones that represent
> # network spaces from /8 to /24, the most significant three
> # octets become redundant for sub-class-C zones with standard
> # naming schemes such as "16-31.147.9.15.in-addr.arpa".
> # For example, the owner name of the PTR record for a client
> # assigned an IP address of 15.9.147.17 would be:
> #
> #   17.147.9.15.16-31.147.9.15.in-addr.arpa.
> #
> # instead of the more commonly seen:
> #
> #   17.16-31.147.9.15.in-addr.arpa.
> #
> # Since RFC-2317 naming schemes are totally arbitrary, this
> # site has chosen to map all dynamic updates of sub-class-C
> # "in-addr.arpa" zones (/25 to /32) to a single domain,
> # "ptr-pa.hpl.hp.com".  The following server option must be
> # declared in all scopes with dynamic IP address ranges
> # that represent a subnetwork of size /25 to /32 and, of
> # course, where DDNS updates are desired:
> #
> #   ddns-rev-domainname  "ptr-pa.hpl.hp.com.";
> #
> # NOTE: This remapping of sub-/24 address space from the
> #       "in-addr.arpa" domain requires the CNAME linkage
> #       specified in RFC-2317.  For example, the following
> #       CNAMEs in the "147.9.15.in-addr.arpa" DNS zone are
> #       generated to remap the PTR records for 15.9.147.16/28
> #       on a BIND name server:
> #
> #         $GENERATE 16-31  $  CNAME  $.147.9.15.ptr-pa.hpl.hp.com.
> #
> zone ptr-pa.hpl.hp.com. {
>        primary 15.0.48.4;
>        key     dhcp-pa;
> }
>
> subnet 15.9.147.0 netmask 255.255.255.224 {
>
>        option routers           15.9.147.1;
>        option broadcast-address 15.9.147.31;
>        if (static) {
>                ddns-updates off;
>        } else {
>                ddns-rev-domainname   "ptr-pa.hpl.hp.com.";
>        }
>        range    15.9.147.16    15.9.147.23;    # allocated by `lpans1'
>        # range  15.9.147.24    15.9.147.30;    # allocated by `lpans2'
>        include "/etc/dhcp/internal_services";
>        include "/etc/dhcp/standard_lease_times";
> }
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>