LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)
-   -   DHCP is mangling my PTR records in DNS (https://www.linuxquestions.org/questions/linux-server-73/dhcp-is-mangling-my-ptr-records-in-dns-4175412344/)

Zwilrich 06-19-2012 05:42 PM
DHCP is mangling my PTR records in DNS
 
DHCP is repeating the first three octets when it adds a PTR record. From my messages log:
Code:
dhcpd: added reverse map from 10.2.168.192.2.168.192.in-addr.arpa to FTIR.Adherent.lab
I'm sure it is something stupid like a missing period, but I haven't been able to figure it out.

This happens on both the 192.168.2.xyz and 192.168.4.xyz networks.

Notice that the FTIR computer is already in the hosts and ptr files but a new entry still gets added. Also, nowhere in my configuration files do I have Adherent with a capital A, but the capitalized version shows up in the mangled file.

My DHCP/BIND server is Ubuntu Linux but all of the network computers are Windows.
Here is my system info:
Code:
$ uname -a
Linux ATI-DHCP.adherent.lan 2.6.32-41-server #90-Ubuntu SMP Tue May 22 12:41:40 UTC 2012 x86_64 GNU/Linux
$ lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 10.04.4 LTS
Release:        10.04
Codename:      lucid
$ named -v
BIND 9.7.0-P1
Here are my various configuration files (I would include then as attachments, but I'm not allowed).

dhcpd.conf:
Code:
ddns-update-style interim;
ddns-updates on;
authoritative;

log-facility local1;

default-lease-time 86400;
max-lease-time 259200;

include "/etc/dhcp3/ddns.key";

# Adherent internal network with internet access
zone adherent.lan. {
        primary 192.168.1.201;
        key ddns;
        }

# Reverse zone for 192.168.1.xyz
zone 1.168.192.in-addr.arpa. {
        primary 192.168.1.201;
        key ddns;
        }

# Adherent insecure network-NO internet access
zone lab.adherent.lan. {
        primary 192.168.2.201;
        key ddns;
        }

# Reverse zone for 192.168.2.xyz
zone 2.168.192.in-addr.arpa. {
        primary 192.168.2.201;
        key ddns;
        }

# Guest-Internet only
zone guest.adherent.lan. {
        primary 192.168.4.201;
        key ddns;
        }

# Reverse zone for 192.168.4.xyz
zone 4.168.192.in-addr.arpa. {
        primary 192.168.4.201;
        key ddns;
        }

# ATI shared network:  Internal (192.168.1.xyz) and visitor (192.168.4.xyz) nets
shared-network ATIshared {

        # ATI internal
        subnet 192.168.1.0 netmask 255.255.255.0 {
                #range 192.168.1.10 192.168.1.19;
                deny unknown-clients;
                ddns-domainname "adherent.lan";
                ddns-rev-domainname "1.168.192.in-addr.arpa";
                option domain-name "adherent.lan";
                option routers 192.168.1.201;
                option domain-name-servers 192.168.1.201;
                }

        # Visitor subnet
        subnet 192.168.4.0 netmask 255.255.255.0 {
                default-lease-time 3600;
                range 192.168.4.40 192.168.4.49;
                allow unknown-clients;
                ddns-domainname "guest.adherent.lan";
                ddns-rev-domainname "4.168.192.in-addr.arpa";
                option domain-name "guest.adherent.lan";
                option routers 192.168.4.201;
                option domain-name-servers 192.168.4.201;
                }
        }

# Adherent insecure network-NO internet access (192.168.2.xyz)
subnet 192.168.2.0 netmask 255.255.255.0 {
        range 192.168.2.240 192.168.2.250;
        ddns-domainname "lab.adherent.lan";
        ddns-rev-domainname "2.168.192.in-addr.arpa";
        option domain-name "lab.adherent.lan";
        option routers 192.168.2.101;
        option domain-name-servers 192.168.2.201;
        }

include "/etc/dhcp3/hosts.dhcp3";
named.conf.local
Code:

include "/etc/bind/zones.rfc1918";

include "/etc/bind/ddns.key";

###########################################################
# Adherent main zone. 
# All addresses are fixed and from 192.168.1.0/24
# If DHCP doesn't have an entry for a computer, it gets put in the guest zone.
#
zone "adherent.lan" {
        type master;
        file "/var/lib/bind/adherent.lan.hosts";
        allow-update { key ddns ;};
};

zone "1.168.192.in-addr.arpa" {
        type master;
        file "/var/lib/bind/192.168.1.rev";
        allow-update { key ddns ;};
};

###########################################################
# Adherent lab zone. 
# All addresses are from 192.168.2.0/24
# Doesn't matter if DHCP has an entry for the computer.

zone "lab.adherent.lan" {
        type master;
        file "/var/lib/bind/adherent-lab.lan.hosts";
        allow-update { key ddns ;};
};

zone "2.168.192.in-addr.arpa" {
        type master;
        file "/var/lib/bind/192.168.2.rev";
        allow-update { key ddns ;};
};

###########################################################
# Adherent guest zone. 
# All addresses are from 192.168.4.0/24
# If DHCP doesn't have an entry for a computer, it gets put in this zone.
#
zone "guest.adherent.lan" {
        type master;
        file "/var/lib/bind/adherent-guest.lan.hosts";
        allow-update { key ddns ;};
};

zone "4.168.192.in-addr.arpa" {
        type master;
        file "/var/lib/bind/192.168.4.rev";
        allow-update { key ddns ;};
};
file /var/lib/bind/adherent-lab.lan.hosts
Code:
$ttl 3h
@      IN      SOA    ATI-DHCP.adherent.lan. bgordon.adherent-tech.com. (
                        2012061801      ; serial
                        3h              ; Refresh
                        1h              ; Retry
                        1w              ; Expire
                        1h              ; Minimum
                        )
@      IN      NS      ATI-DHCP.adherent.lan.

FTIR                IN        A        192.168.2.10
GCMS                IN        A        192.168.2.12
datalogg        IN        A        192.168.2.13
TA                IN        A        192.168.2.14
instron                IN        A        192.168.2.20
instron2        IN        A        192.168.2.21
file /var/lib/bind/192.168.2.rev
Code:
$TTL 3h
@        IN SOA        ATI-DHCP.adherent.lan. bgordon.adherent-tech.com. (
                                2012061801        ; serial
                                3h                ; refresh (3 hours)
                                1h                ; retry (1 hour)
                                1w                ; expire (1 week)
                                1h                ; minimum (1 hour)
                                )
@                        NS        ATI-DHCP.adherent.lan.
10                        PTR        FTIR.lab.adherent.lan.
12                        PTR        GCMS.lab.adherent.lan.
13                        PTR        datalogg.lab.adherent.lan.
14                        PTR        TA.lab.adherent.lan.
20                        PTR        instron.lab.adherent.lan.
21                        PTR        instron2.lab.adherent.lan.
Same file after mangling (all changes made by DHCP/BIND:
Code:
$ORIGIN .
$TTL 10800        ; 3 hours
2.168.192.in-addr.arpa        IN SOA        ATI-DHCP.adherent.lan. bgordon.adherent-tech.com. (
                                2012061802 ; serial
                                10800      ; refresh (3 hours)
                                3600      ; retry (1 hour)
                                604800    ; expire (1 week)
                                3600      ; minimum (1 hour)
                                )
                        NS        ATI-DHCP.adherent.lan.
$ORIGIN 2.168.192.in-addr.arpa.
10                        PTR        FTIR.lab.adherent.lan.
12                        PTR        GCMS.lab.adherent.lan.
13                        PTR        datalogg.lab.adherent.lan.
14                        PTR        TA.lab.adherent.lan.
$TTL 43200        ; 12 hours
10.2.168.192                PTR        FTIR.Adherent.lab.
$TTL 10800        ; 3 hours
20                        PTR        instron.lab.adherent.lan.
21                        PTR        instron2.lab.adherent.lan.

maccas17 06-20-2012 10:06 AM
In your reverse lookup zone you don't have the class field detailed in your resource records, you have:

Code:
10                        PTR        FTIR.lab.adherent.lan
Instead of:

Code:
10        IN        PTR        FTIR.lab.adherent.lan
Not sure if this is irrelevant or if it could be contributing to your record mangling?

Zwilrich 06-20-2012 12:52 PM
Quote:
Originally Posted by maccas17 (Post 4707815)
In your reverse lookup zone you don't have the class field detailed in your resource records, you have:

Code:
10                        PTR        FTIR.lab.adherent.lan
Instead of:

Code:
10        IN        PTR        FTIR.lab.adherent.lan
Not sure if this is irrelevant or if it could be contributing to your record mangling?
It should default to IN class, but I'll change it just in case.

maccas17 06-22-2012 06:44 AM
Just out of interest, did this help matters?

Zwilrich 06-22-2012 10:33 AM
Quote:
Originally Posted by maccas17 (Post 4709231)
Just out of interest, did this help matters?
I haven't had a chance to make the change until now. Once I know something, I'll post it.

Zwilrich 06-26-2012 03:47 PM
Adding the IN class made no difference.

maccas17 06-27-2012 09:50 AM
Have you tried declaring $ORIGIN in your zone files?

file /var/lib/bind/adherent-lab.lan.hosts:

Code:
$TTL 3h
$ORIGIN lab.adherent.lan.
@        IN SOA        ATI-DHCP.adherent.lan. bgordon.adherent-tech.com. (
<snip>
file /var/lib/bind/192.168.2.rev:

Code:
$TTL 3h
$ORIGIN 2.168.192.in-addr.arpa.
@        IN SOA        ATI-DHCP.adherent.lan. bgordon.adherent-tech.com. (
<snip>

Zwilrich 06-28-2012 05:22 PM
Still mangling after adding the $ORIGIN statement.

RobertEachus 07-05-2012 12:13 PM
Solution?
 
Try adding the following to your subnet clauses.

Code:
ddns-rev-domainname "in-addr.arpa.";
Wish I could take credit but I found it here:
http://www.linuxquestions.org/questi...-entry-867266/

I compared this to my DNS/DHCP server and it looks like it should work the way you have it, except I think DHCPD is assuming you have a /8 (192.x.x.x) because you have more than one /24.

As an added thought the "error" is in DHCP, I saw a few references to this behavior when I was looking for a way to fix it, and the common theme is your configuration would work as is if there was only one subset.

Zwilrich 07-05-2012 04:23 PM
Thanks Robert for posting that link; it fixed the problem. I guess I never hit the right combination of search terms to find that posting.

RobertEachus 07-05-2012 04:42 PM
Its ok, I was lucky enough to be a DNS Eng for a large ISP for several years. The combo I used was "dhcp ddns wrong zone" in Google. Some times its all about knowing the right words. I had an unfair advantage searching plus I had a very good idea of where the problem had to be, just glad I could help.


All times are GMT -5. The time now is 04:13 AM.