dhcpd.conf ddns config question

[Simon Hobson]

Alex Sharaz wrote:

>I've just started looking at configuring ddns here and while I've got
>things working o.k. for a Class C address space , I'm having a wee
>problem when it comes to networks with netmasks <24 bits.
>
>1). This works just fine where I'm specifying a /24 net. The
>corresponding named.conf entries are shown below
>
>--dhcpd.conf
<snip>
>ddns-rev-domainname "in-addr.arpa.";

This is the default value, so the statement is redundant. In 
practice, it's rare that you need to specify it at all.


>We are about to roll out a wireless network which will use 8 class C
>nets in a contiguous block
>
>The host address range is 150.237.216.1 - 150.237.223.254
>Broadcast address is 150.237.223.255
>Name.conf has
>
>zone "wireless.hull.ac.uk" {
>         type master;
>         file "zone.wireless";
>         allow-update {
>         ourhome;
>         };
>};
>
>And
>zone "0/21.216.237.150.IN-ADDR.ARPA" {
>         type master;
>         file "zone.216";
>         allow-update {
>         ourhome;
>         };
>};
>
>For the reverse zone. Running named-checkconf doesn't flag any errors at
>this point.
>
>The prog I've written that generates our dhcpd.conf file therefore
>generates the following dhcpd.conf snippet for this subnet
>
>subnet 150.237.216.0 netmask 255.255.248.0 {
>option broadcast-address 150.237.223.255;
>option routers 150.237.216.1;
>option domain-name-servers  150.237.47.200,150.237.128.27;
>default-lease-time 604800;
>max-lease-time 2592000;
>ignore client-updates;
>ddns-updates on;
>ddns-domainname "wireless.hull.ac.uk.";
>ddns-rev-domainname "in-addr.arpa.";
>option domain-name "wireless.hull.ac.uk.";
>ddns-hostname = concat ("dhcp-", binary-to-ascii (10, 8, "-",
>leased-address));
>option host-name = config-option server.ddns-hostname;
>zone wireless.hull.ac.uk. { primary 127.0.0.1; key "isc-dhcp-omapi"; }
>zone 0/21.216.237.150.in-addr.arpa. { primary 127.0.0.1; key
>"isc-dhcp-omapi"; }
>allow unknown-clients;
>range dynamic-bootp 150.237.216.2 150.237.223.100;
>}
>
>.... which causes the dhcpd to fail because of the zone 0/21.... entry
>
>
>Commenting out the offending line causes our wireless users (me) to get
>a forwardly (?)  generated dns entry
>
>Suppose the question is how do I "escape" the "/" character in the 
>zone statement to get dhcpd to treat 0/21.216.237.150.in-addr.arpa 
>as a valid Zone name

The short answer to that is "you don't".

The longer answer is that you have the wrong question !

Firstly, do you have the 8 blocks of in-addr.arpa delegated properly 
to you, or do you have some scheme where you run a non-standard 
domain and someone 'delegates' to you by putting loads of 
"z.y.x.w.in-addr.arpa CNAME z.y.0/21.216.237.150.in-addr.arpa" style 
records ?

This is VERY important because the two methods require VERY different 
techniques to deal with.


Taking these in reverse order, you really do NOT want to be managing 
the reverse ptr records by some non standard 'delegation' scheme. It 
is absolutely NOT neccessary as you have a superset of /24 subnets 
and therefore can do it by the normal method. The normal reason for 
doing it is because you only have a subset of a /24 subnet and 
therefore it is impossible to delegate stuff directly to you.

How you would do this would be :

Set the root of your reverse lookup domains, eg :

ddns-rev-domainname "reverse.mydomain.com.";

create entries of the form "z.y.x.w.in-addr.arpa CNAME 
z.y.x.w.reverse.mydomain.com" for ALL possible addresses - so that's 
2048 dns entries or 8 $GENERATE directives.

Host reverse.mydomain.com with whatever zone file structure suits you.

dhcpd will update your non-standard domain, anything doing queries 
will follow the CNAME records and find the PTR records in your 
non-standard domain.


All this is a pain in the posterior to manage and serves no useful 
purpose - it would be less effort to simply delegate the 8 domains.



What you actually want to do is VERY simple - you just DON'T do 
anything special and it will 'just work'.

You will need to host the reverse lookups for 
216.237.150.in-addr.arpa through to 223.237.150.in-addr.arpa. You 
have a choice, though it depends on how your systems as Hull are 
managed.

If you are able to allow updates to the whole of the 
237.150.in-addr.arpa zone from this server then you simply do nothing 
apart from enabling updates. You might have to define the 
237.150.in-addr.arpa zone in dhcpd.conf - see below*.


Assuming that you won't be able to do this, what you should do is 
delegate the 8 /24 domains and allow updates to those. Ie you would 
have zones of :

216.237.150.in-addr.arpa
217.237.150.in-addr.arpa
...
223.237.150.in-addr.arpa

You do not have to define these in dhcpd.conf unless one (or both) of 
these cases apply :

1) The SOA records for the zones do not correctly identity the master 
server - which is an error anyway so it should be fixed.

2) You are using signed updates, in which case you need to define the 
zones simply to associate a key with them.


In the parent zone (ie 237.150.in-addr.arpa on 
warpserver.ucc.hull.ac.uk), you would just have 8 records (16 if you 
have a backup dns server) :
216   ns   <yourdnsserver>
217   ns   <yourdnsserver>
...
223   ns   <yourdnsserver>

And in yourdnsserver you would have :

zone "216.237.150.IN-ADDR.ARPA" {
         type master;
         file "zone.216";
         allow-update { ourhome; };
};
zone "217.237.150.IN-ADDR.ARPA" {
         type master;
         file "zone.217";
         allow-update { ourhome; };
};
...
zone "223.237.150.IN-ADDR.ARPA" {
         type master;
         file "zone.223";
         allow-update { ourhome; };
};




* I'm not sure exactly what the server does, I know it uses the SOA 
records, so I would expect it to follow the chain down :

root servers --> ns records for 150.in-addr.arpa
              --> ns records for 237.150.in-addr.arpa

no ns records for 216.237.150.in-addr.arpa --> get the SOA record for 
237.150.in-addr.arpa which tells it to send updates for 
z.216.237.150.in-addr.arpa to warpserver.ucc.hull.ac.uk.



Hope this explains things !

Simon