DHCP Server and PTR creation
-
kiokoman@nanto:/chroot/bind/etc/bind/internal$ cat reverse-192.168.20 $ORIGIN . $TTL 907200 ; 1 week 3 days 12 hours 20.168.192.in-addr.arpa IN SOA ns1.kiokoman.home. kiokoman.kiokoman.home. ( 2018048040 ; serial 28800 ; refresh (8 hours) 604800 ; retry (1 week) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS ns1.kiokoman.home. $ORIGIN 20.168.192.IN-ADDR.ARPA. $TTL 3600 ; 1 hour 20 PTR GearS3-178E.kiokoman.home. 200 PTR Google-Nest-Hub.kiokoman.home. 201 PTR Google-Nest-Mini.kiokoman.home. 202 PTR HUAWEI_P20_lite-a3a96fba8.kiokoman.home. 203 PTR Galaxy-Note8.kiokoman.home. 206 PTR netnas4.kiokoman.home. 210 PTR MediaServer.kiokoman.home. 211 PTR Switch.kiokoman.home. 230 PTR ESP_83719C.kiokoman.home. 231 PTR ESP_C5E604.kiokoman.home. 232 PTR ESP_8372D2.kiokoman.home. 233 PTR ESP_8AF208.kiokoman.home. 234 PTR ESP_837256.kiokoman.home. 235 PTR TIZEN.kiokoman.home. 236 PTR TIZEN.kiokoman.home. 237 PTR ESP_329C34.kiokoman.home. 240 PTR android-e7709cc980a30628.kiokoman.home.kiokoman@nanto:/chroot/bind/etc/bind$ cat named.conf.local ..... zone "20.168.192.IN-ADDR.ARPA" IN { type master; file "/etc/bind/internal/reverse-192.168.20"; allow-transfer {192.168.10.202; 2001:470:26:5dc:ffff:ffff:ffff:fffd;}; allow-update { key rndc-key; }; }; .....kiokoman@nanto:/var/log/named$ cat update.log ...... 21-Oct-2020 20:24:33.768 client @0x7f8ab81a3b50 172.17.0.254#64216/key rndc-key: view trusted: updating zone 'kiokoman.home/IN': adding an RR at 'freepbx.kiokoman.home' A 192.168.50.1 21-Oct-2020 20:24:33.768 client @0x7f8ab81a3b50 172.17.0.254#64216/key rndc-key: view trusted: updating zone '50.168.192.IN-ADDR.ARPA/IN': deleting rrset at '1.50.168.192.in-addr.arpa' PTR 21-Oct-2020 20:24:33.768 client @0x7f8ab81a3b50 172.17.0.254#64216/key rndc-key: view trusted: updating zone '50.168.192.IN-ADDR.ARPA/IN': adding an RR at '1.50.168.192.in-addr.arpa' PTR freepbx.kiokoman.home. ...... 21-Oct-2020 20:57:21.632 client @0x7f8ac017f2f0 172.17.0.254#63020/key rndc-key: view trusted: updating zone 'kiokoman.home/IN': adding an RR at 'ESP_837256.kiokoman.home' TXT "00611a155cbe499a9419ac465de7ac6e8b" 21-Oct-2020 20:57:21.632 client @0x7f8ac017f2f0 172.17.0.254#63020/key rndc-key: view trusted: updating zone 'kiokoman.home/IN': deleting rrset at 'ESP_837256.kiokoman.home' A 21-Oct-2020 20:57:21.632 client @0x7f8ac017f2f0 172.17.0.254#63020/key rndc-key: view trusted: updating zone 'kiokoman.home/IN': adding an RR at 'ESP_837256.kiokoman.home' A 192.168.20.234 ......172.17.0.254 is pfsense
-
Unbound may be able to do views, but the combination of: DDNS updates (not static mappings) from the DHCP server, forwarding certain zones to specific destinations, secondarying some zones, some zones being secondary'd and GSS-TSIG updates - is likely beyond unbound's current capability.
Wasn't until testing that it was realized that the DDNS updates for the PTR records weren't working - at least not when the destination zone is an RFC-2317 style declaration. Was thinking/expecting that the DHCP would simply include the zone declarations for the configured [as master] zones vs. assumptions about the namespace (as its declaring zones based on network size - not what's actually available to it in the DNS).
Your second post came in as I was replying - create an interface using a /25 network, generate a pool for that interface and have the the /24 parent arpa zone defined in [BIND] DNS. Try with a DHCP client (not a static mapping) and see if you have a PTR. Then try disabling the /24 arpa zone and create the RFC-2317 zone [matched to dhcpd.conf definition] - still nets a lack of PTR record for consumers in the /25 network. There's also not a [visible] means to 'force' the zone declaration in dhcpd.conf for the x.x.x.in-addr.arpa zone (or at least override the incorrect RFC-2317 zone declaration).
Food for thought, historically RFC-2317 zones were considered "taboo" when it came to DHCP driven DDNS updates because of the fact that there is "extra data" (not just purely octets of the IP address). In an example where the DHCP server handed out "172.17.0.50" with a zone declaration [dhcpd.conf] of 0-25.0.17.172.in-addr.arpa where the DHCP server is expecting 50.0.17.172.in-addr.arpa not 50.0-25.0.17.172.in-addr.arpa - hence the conundrum as DHCP [historically] only understands 8-bit boundaries. RFC-2317 was intended as "topology description" that would net resolution by relying on CNAMEs (one per IP Address, commonly via $GENERATE statement) in the 8-bit boundary parent in-addr.arpa zone that point to the actual child PTR (in the destination NS's child zone) in order to resolve. Imagine if one had to guess at the boundary [extra] bits in the lookup value to finally get a valid PTR response.... Out of scope for DHCP - even when attempting to point directly at the logical child zone.
Just FYI on the above: apparently the GUI logic for the BIND DNS Server does not allow creation of "CNAME" records in in-addr.arpa zones (only NS/PTR), which would prevent RFC-2317 style child zones from being properly resolved. Yes, one could do "custom" to inject the record(s) but it may not be apparent that CNAMEs are required for RFC-2317 style delegations.
-
ok, it's hard to understand for me because english is not my first language but maybe you are referring to this
https://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update
DHCP does not support updating of arbitrary zones, it takes the ip
address, reverses the octets, and appends the reverse domain name$GENERATE 1-25 $ CNAME $.0.17.172.dhcp.https://www.zytrax.com/books/dns/ch3/
-
Looking into this more, the fact that the zones (as defined in the BIND DNS Server) aren't configured/configurable is problematic. For example, how do you define a zone (as an update target) that is located "off box"? eg: ISC named on another system.
Remember, RFC-2317 only comes into play for DNS resolution. It does NOT come into play for DHCP. DHCP is octet driven. DNS ARPA zones naturally break on the following bit boundaries: 8, 16 and 24. DHCP makes use of this fact and does a simple regex on those bit boundaries to match the "zone" statement to determine where (and how) to update the DNS server. The CNAME (RFC-2317) does not come into play as DHCP does not utilize DNS to determine how/where to update DNS (thus the CNAME is immaterial as it cannot be utilized). Again, DHCP simply reverses the octects, tacks on ".in-addr.arpa", regex matches "zone" and then submits using associated parameters for "zone". Think of the regex match as:
if (UPDATERECORD =~ /ZONEDECLARATION$/) { # if most granular match use ZONEDECLARATION for update }
Then it simply pushes a the DNS update against the configure IP Address (or addresses). eg: machine.example.lan as 10.22.11.57 would match 57.11.22.10.in-addr.arpa against 22.11.10.in-addr.arpa. (it would never "match" against an RFC-2317 zone definition: X-Y.11.22.10.in-addr.arpa.)
Noticed another issue, when reviewing the dhcpd.conf that is generated. Here are two examples from the conf file:
zone example.lan. {
primary 10.11.22.1;
key dns-update-key;
}
zone 22.11.10.in-addr.arpa {
primary 10.11.22.1;
key dns-update-key;
}These should appear as:
zone "example.lan." {
primary 10.11.22.1;
key dns-update-key;
}
zone "22.11.10.in-addr.arpa." {
primary 10.11.22.1;
key dns-update-key;
}Changes:
- quotes are used to ensure clarity of the zone (preventing potential for alternative interpretation)
- The ARPA zone (in the original) lacks a trailing period. This issue is consistent across all ARPA zones.
The above was discovered after taking one site and completely re-configuring it from a /23 to a /21 - so that all networks are a 24-bit mask. After doing so, noticed that ARPA entries still aren't being created - despite movement to 24-bit networks to match non RFC-2317 boundaries.
Given the coupling between DNS and DHCP, it would be more pragmatic to have a checkbox (as example) on each zone that enables (or disables) its use for DHCP. If enabled - include the zone in dhcpd.conf so that the zone can be utilized for updates. This is in contrast to existing behavior that makes assumption based on network, when the assertion should be based on DNS. This inherently addresses the scenario where the ARPA zone (the logical /24) covers the smaller networks defined on interfaces.
-
justme2 said in DHCP Server and PTR creation:
quotes are used to ensure clarity of the zone (preventing potential for alternative interpretation)
see https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcpdconf:
Also note that in the DHCP configuration, zone names are not encapsulated in quotes where there are in the DNS configuration.
The ARPA zone (in the original) lacks a trailing period. This issue is consistent across all ARPA zones.
fixed in https://redmine.pfsense.org/issues/11224
Please check it on the latest 2.5 snapshot,
there are numerous fixes/features -
Excellent!
Does this also address the RFC-2317 generation of reverse zone that prevents PTR generation? eg: under 2.4.5p1 the in-addr.arpa update zone declarations are generated as:
0-23.10.10.in-addr.arpa
When it should be:
0.10.10.in-addr.arpa
1.10.10.in-addr.arpaDNS dictates the namespace for update - not DHCP. This issue occurs anytime the network doesn't fall on an 8/16/24 bit boundary.
While there may not be a "clear cut" solution, would be amicable to have a text blob box (like in various config sections) where if anything is entered - it is utilized verbatim for update zone declarations, instead of the automatically generated ones. The RFC2317 structuring fails due to lack of right-hand side, most granular match. eg: /17.1.10.10.in.addr.arpa$/ would never match against /0-23.10.10.in-addr.arpa$/ for determination of whom and how to issue the DDNS update.
Thanks!
-
@justme2 said in DHCP Server and PTR creation:
Excellent!
Does this also address the RFC-2317 generation of reverse zone that prevents PTR generation? eg: under 2.4.5p1 the in-addr.arpa update zone declarations are generated as:
0-23.10.10.in-addr.arpa
When it should be:
0.10.10.in-addr.arpa
1.10.10.in-addr.arpaDNS dictates the namespace for update - not DHCP. This issue occurs anytime the network doesn't fall on an 8/16/24 bit boundary.
While there may not be a "clear cut" solution, would be amicable to have a text blob box (like in various config sections) where if anything is entered - it is utilized verbatim for update zone declarations, instead of the automatically generated ones. The RFC2317 structuring fails due to lack of right-hand side, most granular match. eg: /17.1.10.10.in.addr.arpa$/ would never match against /0-23.10.10.in-addr.arpa$/ for determination of whom and how to issue the DDNS update.
Thanks!
Please create a bugreport https://docs.netgate.com/pfsense/en/latest/development/bug-reports.html
-
Can we also get the DDNS to use or the option to use the “standard” DHCID records rather than the “interim” TXT records?
The notes for DHCPD say that any new installation should use standard, and the interim was only a transition whilst the RFCs were finalised. I think after 15 years since it was proposed most DNS systems will have moved on to versions that support DHCID records - BIND has supported it for 7 years.
It only requires the DHCP config file to use “ ddns-update-style standard;” instead of interim.
-
@vollans Please create a feature request: https://docs.netgate.com/pfsense/en/latest/development/feature-requests.html
something like a dropdown intermediate/standard menu entry
-
@viktor_g Will do, it would also be useful if in the IPv6 range it allocated domain prefixes for domains that don’t have a name rather than just leaving them blank.
A rule like:
ddns-hostname = pick (option dhcp6.fqdn, option fqdn.hostname, option host-name, binary-to-ascii (16, 8, "-", substring (hardware, 1, 6)), concat("dyn-", binary-to-ascii (16, 16, "-", substring(option dhcp6.ia-na, 16, 16)))); option host-name = config-option server.ddns-hostname;In the Range6 section of services.inc would do the trick.
-
L LaserGuidedCake referenced this topic on
