dhcp registration not using correct dns domain in unbound

Mystique_

pfsense has a default domain defined in general: building.arpa

dhcp with vlans defined; all working fine..

vlan172 has a domain name defined as v172.building.company

vlan50 has a domain name defined as v50.building.company

I checked the unbound 'enabled dhcp registrations' and hosts are being added do dhcpleases_entries.conf

but workstation.building.arpa is what is being saved into unbound

v50.building.company is what shows up as the windows 'connection-specific dns'

local-data: "2UA44615YN.pms.arpa IN A 10.20.62.188"
local-data-ptr: "10.20.62.188 2UA44615YN.pms.arpa"

22.05-RELEASE pfsense plus.. Netgate 6100 (should any of that matter)

unbound 1.15.0

Thank you in advance.

Mystique_

/usr/local/sbin/dhcpleases -l /var/dhcpd/var/db/dhcpd.leases -d pms.arpa -p /var/run/unbound.pid -u /var/unbound/dhcpleases_entries.conf -h /etc/hosts

if this works as it's read..

the -d is the system domain name and not each defined dhcp scope..

grep pms.arpa /conf/config.xml
<domain>pms.arpa</domain>

cmcdonald

@mystique_

I am completely rewriting the dns registration feature. Hopefully will make it in 23.05. We will see.

Notable points:

Uses the per-scope domain name. Will still fallback to using the system domain name if a per-scope domain name is not configured.
Enable/disable DNS registration on a per-scope basis...it will no longer be an all-or-nothing checkbox.
Modify DNS records in the running Unbound process without having to restart unbound. This means no more restarting Unbound over and over, thus causing service outages.

Gertjan

@cmcdonald

Aaaah, some finally takes unbound-control to good usage
I knew you were on it for some time now.
If you're looking for testers, add me to the list.
I can read/write C, PHP, perl and even shell scripts (edit : so pretty good at yelling at code that works well but not yet fully understood by me)

@mystique_ said in dhcp registration not using correct dns domain in unbound:

/usr/local/sbin/dhcpleases -l /var/dhcpd/var/db/dhcpd.leases -d pms.arpa -p /var/run/unbound.pid -u /var/unbound/dhcpleases_entries.conf -h /etc/hosts

Yep, it's that simple.
The dhcpleases stays in memory, it stats the /var/dhcpd/var/db/dhcpd.leases file, maintained by the dhcp server. When it changes = when the DHCP servers updates it, the dhcpleases process parses it, and writes out to /etc/hosts and /var/unbound/dhcpleases_entries.conf.
It uses the /var/run/unbound.pid file to know the pid of unbound, and send it a SIGHUP signal. Unbound will restart upon receiving of that SIGHUP.
And yes : only one domain.

Mystique_

So 24 hours ish later.. I have a working solution..

"Just" setup Bind9 on another machine..

"Just" figure out RFC 2136 DDNS - which only works with ISC-DHCPD and BIND..

"Just" make some proper Bind Zone files..

Some helpful commands:

ddns-confgen -a hmac-sha384
nsupdate -L 4 -k ddns-key.domain

Get all that going correctly.. then add the pieces to pfsense isc-dhcpd..

And when it seemingly works.. it looks like this:

Still working on the allow-update grant portion.. It seems to update A and TXT records.. I would like to understand that portion better and limit it to "you can only update your own, with your name" A and possibly TXT..

But for a proof of concept this gives me something to build on and work with..

I have a little less than 10 dhcp pools per building.. and 10 buildings.. (ospf is your friend..)

I am not sure how greedy I can be w/ ddns-confgen domains but I am hoping not to need one key, zone, and in-addr.arpa per network; per building..

But have a working solution..

http://www.ipamworldwide.com/ipam/update-policy.html

This seems to have a human readable update-policy; but I've not gotten that far..

Wanted to share, in case others were more comfortable with this type of solution.

I would then just tell unbound where to find the authoritative domains at this bind server..

Suggestions or comments welcomed..

Thank you for listening..

Gertjan

@mystique_ said in dhcp registration not using correct dns domain in unbound:

I would like to understand that portion better and limit it to "you can only update your own, with your name" A and possibly TXT..

Bind : allow-update { .... };

Probably not allow-update, but the update-policy as that one can be limted to "A" only, for example.
But, why bother : if DHCPd wants to send some TXT records .... let him be happy.

cmcdonald

@mystique_ Setting up an actual authoritative DNS server is the "right" way of doing this. Unbound is a recursive resolver, not an authoritative server (though it can serve local resource records). Running a local-only internal DNS server is certainly an option and one that I have jotted down in my engineering daybook. The idea here would be that Unbound would remain the "frontend" DNS server and would forward local domain requests to the internal DNS server which would be updated via DDNS from DHCPD. The other issue is that we do plan to move to Kea as soon as possible.

ISC DHCPD also can only update ONE DNS server via DDNS. Any additional updates to other servers would have to be made from the one server that handled the DDNS request from ISC DHCPD. It's feasible sure but more complexity.

The hardest part of moving to Kea is going to be it's database model. It requires a full-blown SQL server for the lease database...yikes. That makes HA with Kea tricky because doing database HA is complicated.

It's a multifaceted issue for sure.

Mystique_

Yesterday was a learning and fighting day..

Suggestion: "click here to generate named ddns config for this subnet"

solution to only allowing A and TXT entries..

update-policy {
    grant "ddns-key.pcsd" wildcard *.pcsd. A TXT DHCID;
};

DHCID is not supported because the ddns-update-style..

/var/dhcpd/etc: grep ddns-update-style dhcpd.conf
                ddns-update-style interim;
                ddns-update-style interim;
                ddns-update-style interim;
                ddns-update-style interim;

So the next problem for which I cannot seem to over come is dhcp reservations.. apparently they do their own thing..

2023-04-20T12:17:10.71658 user.notice: Apr 20 08:17:10 named: 20-Apr-2023 08:17:10.715 client @0x7f1b9f682bf8 10.20.250.18#52499/key ddns-key.pcsd: updating zone 'pcsd/IN': update unsuccessful: rh6002-tech.pcsd: 'name not in use' prerequisite not satisfied (YXDOMAIN)
2023-04-20T12:17:10.71695 user.notice: Apr 20 08:17:10 named: 20-Apr-2023 08:17:10.716 client @0x7f1b9f682bf8 10.20.250.18#52499/key ddns-key.pcsd: updating zone 'pcsd/IN': deleting rrset at 'rh6002-tech.pcsd' TXT
2023-04-20T12:17:10.71697 user.notice: Apr 20 08:17:10 named: 20-Apr-2023 08:17:10.716 client @0x7f1b9f682bf8 10.20.250.18#52499/key ddns-key.pcsd: updating zone 'pcsd/IN': adding an RR at 'rh6002-tech.pcsd' TXT "313202da98edce616f3de3c1db63c48612"
2023-04-20T12:17:10.71697 user.notice: Apr 20 08:17:10 named: 20-Apr-2023 08:17:10.716 client @0x7f1b9f682bf8 10.20.250.18#52499/key ddns-key.pcsd: updating zone 'pcsd/IN': deleting rrset at 'rh6002-tech.pcsd' A
2023-04-20T12:17:10.71698 user.notice: Apr 20 08:17:10 named: 20-Apr-2023 08:17:10.716 client @0x7f1b9f682bf8 10.20.250.18#52499/key ddns-key.pcsd: updating zone 'pcsd/IN': adding an RR at 'rh6002-tech.pcsd' A 10.20.63.209

I have dozens of these:

And none of them follow any of the options now that ddns is enabled..

they are registered with the parent domain and not with the subdomain at the parent domain no matter what I do..

I'm going to say this feels like a bug as nothing I do seems to change anything..

I am looking for these reserved devices to be registered in the same subdomain as they are defined in..

Again, I probably have 100+ of these across the buildings and networks.. will try defining a few of them in named and see what errors are generated..

So the suggestion regarding the 'generate the config'..

pfsense dhcpd config for this scope:

subnet 10.20.48.0 netmask 255.255.240.0 {
        pool {
                ddns-update-style interim;
                range 10.20.60.1 10.20.62.254;
        }

        option routers 10.20.48.1;
        option domain-name "pms.pcsd";
        ddns-domainname "pcsd";
        allow client-updates;
        option domain-name-servers 10.20.48.1;
        default-lease-time 7202;
        max-lease-time 28808;
        ping-check true;
        option ntp-servers 10.20.48.1;

        option custom-opt5-0 01:04:00:00:00:02;
        option custom-opt5-1 "http://option252.pcsd/redacted/redacted.pac";
}

I have other scopes which are simple /24 or well designed /22 (this /20 is inherited.. undesirable but valid..)

I cannot seem to produce a working named config to receive the updates for the PTRs..

this 192.168.48.0/24 seems fine..

2023-04-20T12:01:24.68219 user.notice: Apr 20 08:01:24 named: 20-Apr-2023 08:01:24.680 client @0x7f1b80009178 10.20.250.18#55685/key ddns-key.pms.v42: updating zone '48.168.192.in-addr.arpa/IN': deleting rrset at '162.48.168.192.in-addr.arpa' PTR
2023-04-20T12:01:24.68220 user.notice: Apr 20 08:01:24 named: 20-Apr-2023 08:01:24.680 client @0x7f1b80009178 10.20.250.18#55685/key ddns-key.pms.v42: updating zone '48.168.192.in-addr.arpa/IN': adding an RR at '162.48.168.192.in-addr.arpa' PTR Pixel-6a.pms.v42.
2023-04-20T12:28:38.36077 user.notice: Apr 20 08:28:38 named: 20-Apr-2023 08:28:38.360 client @0x7f1b9f682bf8 10.20.250.18#52499/key ddns-key.pms.v42: updating zone '48.168.192.in-addr.arpa/IN': deleting rrset at '134.48.168.192.in-addr.arpa' PTR
2023-04-20T12:28:38.36078 user.notice: Apr 20 08:28:38 named: 20-Apr-2023 08:28:38.360 client @0x7f1b9f682bf8 10.20.250.18#52499/key ddns-key.pms.v42: updating zone '48.168.192.in-addr.arpa/IN': adding an RR at '134.48.168.192.in-addr.arpa' PTR MP258M08.pms.v42.
2023-04-20T12:30:13.11472 user.notice: Apr 20 08:30:13 named: 20-Apr-2023 08:30:13.113 client @0x7f1b9f682bf8 10.20.250.18#52499/key ddns-key.pms.v42: updating zone '48.168.192.in-addr.arpa/IN': deleting rrset at '103.48.168.192.in-addr.arpa' PTR

and it's config:

zone "48.168.192.in-addr.arpa" IN {
    type master;
    file "/var/named/dynamic/reverse-192.168.48";
update-policy {
            grant "ddns-key.pms.v42" wildcard *.48.168.192.in-addr.arpa. PTR;
    };
};

Tried this - I have a lot going on in the 10.10, 10.20 10.30, etc.. but this didn't work

// zone "10.in-addr.arpa" IN {
//     type master;
//     file "/var/named/dynamic/reverse-10";
// update-policy {
//             grant "ddns-key.pcsd" wildcard *.10.in-addr.arpa. PTR;
//     };
// };

then these..

zone "60.20.10.in-addr.arpa" IN {
    type master;
    file "/var/named/dynamic/reverse-10.20.60";
update-policy {
            grant "ddns-key.pcsd" wildcard *.60.20.10.in-addr.arpa. PTR;
    };
};

zone "61.20.10.in-addr.arpa" IN {
    type master;
    file "/var/named/dynamic/reverse-10.20.61";
update-policy {
            grant "ddns-key.pcsd" wildcard *.61.20.10.in-addr.arpa. PTR;
    };
};

while technically correct it does not get updated.. like the 192.168.48/24 does

And from the much isc mailing list, which no one seems to talk about this ddns anymore.. which I don't know why.. all the working configs that I can find have differently defined dhcp scopes and the greedy 10.in-addr.arpa. (16.172.in-addr.arpa. in other examples..) received requests for updates within that..

so from my isc dhcpd defined network.. can you make a suggestion as to what the zone should look like within named?

on the list of things to try today from last evenings reading..

zone "22/0.60.20.10.in-addr.arpa" IN { ...

I don't feel I'm an rfc2317 case.. as no one delegating this to me..

Again, thank you for listening..

Suggestions welcomed..

Mystique_

https://www.oreilly.com/library/view/dns-and-bind/0596100574/ch04.html

They seem to never give this example..

zone "30.10.in-addr.arpa" IN {
    type master;
    file "/var/named/dynamic/reverse-generate-10";
};

cat reverse-generate-10

$ORIGIN .
$TTL 32 ; 30 seconds

30.10.in-addr.arpa IN SOA       a.ns.pcsd. hostmaster.b.cook. (
                                2023041802 ; serial
                                3600       ; refresh (1 hour)
                                600        ; retry (10 minutes)
                                2600       ; expire (43 minutes 20 seconds)
                                30         ; minimum (30 seconds)
                                )
                        IN  NS  a.ns.pcsd.

$ORIGIN 0.30.10.in-addr.arpa.
$GENERATE 1-254  $.0.30.10.in-addr.arpa. IN PTR $.0-rev.pcsd.

$ORIGIN 1.30.10.in-addr.arpa.
$GENERATE 1-254  $.1.30.10.in-addr.arpa. IN PTR $.1-rev.pcsd.

and finally..

drill -Q -x 10.30.1.1 
1.1-rev.pcsd.

drill -Q -x 10.30.1.23 
23.1-rev.pcsd.

drill -Q -x 10.30.0.47 
47.0-rev.pcsd.

Let me see what I can workout now that this is working..

Mystique_

Still not updating.. but

1 zone "20.10.in-addr.arpa" IN {
2     type master;
3     file "/var/named/dynamic/reverse-10-20";
4 update-policy {
5             grant "ddns-key.pcsd" wildcard *.20.10.in-addr.arpa. PTR;
6     };
7 };

and this:

$ORIGIN 20.10.in-addr.arpa.

@   1D  IN SOA  a.ns.pcsd. hostmaster. (
                                42          ;     2023041802 ; serial
                                1H       ; refresh (1 hour)
                                10M        ; retry (10 minutes)
                                1D       ; expire (43 minutes 20 seconds)
                                30         ; minimum (30 seconds)
                                )
                        NS      a.ns.pcsd.
$TTL 42 ; 30 seconds

;1                       1D IN PTR       localhost.

100.0   IN PTR  a.ns.pcsd.

; for i in (seq 0 160); echo \$GENERATE 1-254 \$.$i IN PTR \$.$i.20.10.rev.pcsd.; end
$GENERATE 1-99 $.0 IN PTR $.0.20.10.rev.pcsd.
$GENERATE 101-254 $.0 IN PTR $.0.20.10.rev.pcsd.
$GENERATE 1-254 $.1 IN PTR $.1.20.10.rev.pcsd.
$GENERATE 1-254 $.2 IN PTR $.2.20.10.rev.pcsd.
$GENERATE 1-254 $.3 IN PTR $.3.20.10.rev.pcsd.

(the for loop is fish shell syntax..)

I had to pull this from the loopback in-addr.arpa to get the syntax right..

not having the origin as the first line was causing other errors as well.. not sure why..

There are hundreds of questions regarding being authoritative for a /21 or /22.. something more than a /24 - no one ever seems to post an answer.

afaict the above is valid and working..

2023-04-21T13:47:38.50210 user.notice: Apr 21 09:47:38 named: 21-Apr-2023 09:47:38.500 /var/named/dynamic/reverse-10-20:10: using RFC1035 TTL semantics

(loopback doesn't say that.. but it's just the 1H, 10M, etc vs time in seconds..)

2023-04-21T13:48:48.22222 user.notice: Apr 21 09:48:48 named: 21-Apr-2023 09:48:48.220 starting BIND 9.16.22 (Extended Support Version) <id:59bfaba>

Still cannot get pfsense to update the PTR.. still not sure how come..

Gertjan

@mystique_

Maybe not what you need right now, but :

I know, this is 'IPv6' so it's 'dhcp6d' doing doing RF2136 thing.
I have "Add reverse dynamic DNS entries. checked.

Btw : My IPv6 /56 comes from my ISP, and there is no way I can have this info pushed so 'everybody' can reverse request my IPv6.
My web/mail/whatever dedicated server uses bind, and also takes care of zone of my pfsense local domain.
So now my server knows how to find diskstation.my-domain.tld by its IPv6, so I can backup my server to NAS behind pfSense.

I don't do "registration of DHCP client names in DNS" for my IPv4, as these are ... IPv4 and all RFC1819.