DHCP DDNS and BIND on non /24 reverse delegation

[Kevin Darcy]

M. Yu wrote:

> Hello list,
>
> We've been allocated a /25 IP block by our provider and they are delegating
> reverse DNS lookup for it by making us specify
> 128/25.177.110.64.in-addr.arpa in named.conf with allow-update set for DDNS.
> I created the host file with no entry in it except for the SOA and NS RRs.
> Now comes the problem.  When I recently checked the host file, it seems that
> DDNS has wreaked havoc all over it by assuming that all entries there
> belonged to a /24 (it sticks a $ORIGIN there) which is wrong since we're
> only authoritative for the upper /25 of our IP block.

Hmmm.... So you're saying named is writing a zonefile that contains something
like

$ORIGIN 177.110.64.in-addr.arpa
200    IN    PTR    foo.example.com.

??? But, if the zone is defined something like

zone "128/25.177.110.64.in-addr.arpa" {
    type master;
    file "128/25.177.110.64.in-addr.arpa";
    allow-update { whomever; };
};

, then it will never accept updates into this zone which rightfully belong in
the "177.110.64.in-addr.arpa" zone, and so there's no way for those entries to
get in like that.

Are you sure that the "128/25" part isn't contained in the $ORIGIN or the owner
name somehow? If so, then this is just a harmless formatting quirk. Perhaps you
could post an extract of the zonefile for inspection (feel free to anonymize
the RDATA of the PTR record if you wish -- that's not really important to
diagnosing this problem).

> I am not sure who is messing with our host file: dhcp (3.0b2pl16-1 rpm from
> Charles Anderson) or BIND (8.2.3 rpm from RH).  I know these are old
> versions and I am about to move up but I need to be sure this problem can be
> solved.  As I've said, I don't know who's messing the config so I'm
> cross-posting this message to both the bind-users and dhcp-server lists.
> Anyway, whichever it is that's re-writing the host file, how can I solve
> this problem?  Is there a method of specifying what $ORIGIN to put or maybe
> stop it from sticking things in the host file except for the DDNS update
> itself (hostname+domain and IP address)?

I wish you would stop calling it a host file. It's not a host file; it's a zone
file. Moreover, when you enable a zone for Dynamic Update, you give named free
license to format the associated zone file any way it feels like. Is the data
actually *wrong*, or is it just formatted a way that you don't like and/or
didn't expect? I strongly suspect the latter. I've been using Dynamic Update
for *all* of my DNS maintenance for months now (for both the internal DNS and a
separate "hidden master" instance for our external DNS zones), and I've never
had it accept an update for the wrong zone.

Now, I would understand if a DHCP client wasn't RFC 2317 aware and might try to
update the PTR record in the /24 reverse zone instead of following the CNAME.
But that's exactly the *opposite* of what you are claiming here, and in any
case that update should be rejected also because otherwise it would create a
forbidden "CNAME and other data" in the /24 reverse zone.


- Kevin