Project

General

Profile

Feature #337

Restrict DNS A records to DHCP lease addresses and provide for static entries

Added by rgmhtt about 11 years ago. Updated about 8 years ago.

Status:
New
Priority:
Medium
Assignee:
-
Category:
-
Target version:
-
Start date:
10/14/2009
Due date:
% Done:

0%


Description

The h<n>.home.com entries in DNS should only be for the addresses leased by DHCP. Currently it is for addresses 1-254 even though one of these addresses is the hda server and another is the gateway.

Currently in the /usr/bin/hdactl script the variables dyn_lo and dyn_hi are set twice (and used once!) and control the range for DHCP. They should be set earlier in the script and used also for the forward and reverse zone file construction.

Further, add an include into both zone files that can be customized by skilled users until a database controlled script can support the addition of statically addressed hosts within the domain.

e.g. add the line:

include custom-n2a.conf

in the hda-n2a.conf file and similar in the reverse file. Create these files with just a comment so that they can be added to as appropriate until this can be a database driven feature.

History

#1 Updated by rgmhtt about 11 years ago

While you are at it, just add dym_lo and dym_hi to the settings table where they belong.

#2 Updated by rgmhtt about 11 years ago

OK. Here is some fixes:

INSERT INTO `demo_development`.`settings` (`id`, `name`, `value`, `kind`) VALUES ('45', 'dhcp_dyn_lo', '100', 'network'), ('46', 'dhcp_dyn_hi', '250', 'network');

whatever the right value for id should be...

In /usr/bin/hdactl:

The following appear twice:

my $dyn_lo = $net . "." $settings{'dhcp_dyn_lo'};
my $dyn_hi = $net . "." $settings{'dhcp_dyn_hi'};

The next part is tricky. I don't know if I have it right...

It looks like the first appearance of the above commands was to use them to build the zone files in the first place! But it is in the print_named_conf sub, do they need to be in the fill_hosts_table, print_n2a_info, and print_a2n_info subs? But at least in these subs ...

change:

foreach my $i (1 .. 14) {

to

foreach my $i ($dyn_lo .. $dyn_hi) {

and:

if ($address > 0 && $address < 15) {

to

if ($address >= $dyn_lo && $address <= $dyn_hi) {

I don't know if I got the inequalities right... And this is only in the first sub.

Now in print_aliases sub, there is one line I am not sure of:

if (($ip > 0) && ($ip < 255)) {

Should this be changed to use $dyn_lo and $dym_hi as well?

#3 Updated by rgmhtt about 11 years ago

Some corrections and improvements over the prior recommendation:

First the fill_hosts_table sub. Now that I see what this does (for static IP addresses), it remains untouched, 1 - 254.

For the sub print_n2a_info sub:

add:

my $dyn_lo = $settings{'dhcp_dyn_lo'};
my $dyn_hi = $settings{'dhcp_dyn_hi'};

replace:

foreach my $i (1 .. 254) {
printf $name2addr "%s\t\tA\t%s.%d\n",
$host[$i], $net, $i;
}

With a simple $GENERATE:

printf $name2addr "$GENERATE " $dyn_lo "-" $dyn_hi "\th$\t\tA\t" $net "$";

That SHOULD print:

$GENERATE lo-hi h$ A 192.168.1.$

Where lo is the content of $dyn_lo and hi is $dyn_hi and replace 192.168.1. with whatever is in $net.

Note that early copies of Cricket's BIND book had the $GENERATE wrong. Took me time to figure that out and send him an errata on it. I use this function a lot in my zone files.

For the print_a2n_info sub:

also add:

my $dyn_lo = $settings{'dhcp_dyn_lo'};
my $dyn_hi = $settings{'dhcp_dyn_hi'};

replace:

foreach my $i ($dyn_lo .. $dyn_hi) {
printf $addr2name "%d\tPTR\t%s.%s.\n",
$i, $host[$i], $domain;
}

With:

printf $addr2name "$GENERATE " $dyn_lo "-" $dyn_hi "\t" $net "$\t\tPTR\t" $net "h$";

That SHOULD print:

$GENERATE lo-hi 192.168.1.$ PTR 192.168.1.h$

You can probably clean this up better than me. But I STILL don't feel I have the content of the hosts table being done right. Those A and PTR records should be handled better than it looks like they are. You are not SUPPOSE to have statically assigned addresses within your DHCP address range, but, well you never know what people will do.

Also I am missing printing the PTR for hda and router. Those need to be added directly to the print_a2n_info sub (and not give them h<addr> PTR records as is done now).

Now this could all work fine for the forward zone. But for the reverse zone, some like to have ALL addresses have PTR records so that if someone drops in a static addresses system and does not register it to the hosts file (if this is ONLY for static DHCP leases it IS a concern), then you want a PTR records. Your $host array COULD be used for this as a binary table. Set the table to 1s. Set the entry for hda, router, and lo-hi to 0s. As you print host table entries, set those $host entries to 0. Now loop through the table and make PTR records for these 'missing' addresses; perhaps with a reverse name of $i.client.domain.

Well let me know what you think.

All this would get close to supporting CIDR ranges. You only want to generate A records for addresses you are going to allocate and there are two camps on PTR records.

#4 Updated by ichat almost 11 years ago

A-records yes, but you may want to leeve alone the c-name-records, to be able to support external services like google apps...
also MX records should be protected, as well as defined with ...
it should not be set to ip but hostname only...

aso add the SPF functions to be able to define safty mesures if mail (spam) is installed to the system...

#5 Updated by bigfoot65 about 8 years ago

  • Priority changed from High to Medium

Also available in: Atom