Univention Bugzilla – Bug 47200
Creating PTR records in forward zones is not possible
Last modified: 2024-01-29 14:22:13 CET
Usually PTR records are required seen in reverse Zones, however some Applications implementing DNS Service Discovery (DNS-SD) as specified in RFC6763 may require PTR records within a DNS forward zone too but also specifies the use of certain SRV and TXT records. Depending on how the application choses to implement DNS-SD it may only rely on PTR records. One known case being PaperCut's Mobility Print Server. Right now neither UDM, nor UMC allow the creating of PTR records in a forward zone. Therefore consider this as feature request that permits said PTR records to be created. I'll be testing a workaround within /etc/bind/named.conf.local for the client. Links: * RFC6763: https://tools.ietf.org/html/rfc6763 * Documentation of PaperCut's Mobility Print DNS Documentation: https://www.papercut.com/products/ng/mobility-print/manual/how-to-setup/step-2-configuration/discover-your-printers-using-dns/ Regards Mathieu Simon, Adfinis SyGroup
Thanks for the input! I guess there may be a few of lines in the code that assume PTR records to only live in reverse zones, we'll have to check.
FYI: If you have Samba/AD installed on a UCS DC server system you may do a workaround to create the record like this: root@master10:~# samba-tool dns add localhost ucs.dom 123 ptr foo.ucs.dom -P root@master10:~# host -t ptr 123.ucs.dom 123.ucs.dom domain name pointer foo.ucs.dom. The S4-Connector will reject to synchronize this change to OpenLDAP, so the record is accessible for the bind9 DNS server but it's not visible in UMC. Just a workaround, but maybe it helps you.
Hi I wanted to let you know how we ended up implementing a workaround for this limitation so others will have to search a bit less, TL;DR: In the end we opted for a BIND response policy. The good: Adding further records of this type is going easy in the future. (edit the zone file) The bad: Needs awareness about if the System is running with or without Samba 4. The ugly: This needs to be done on each resolver. Depending on whether a S4 server is active or not, either the templates for univention-bind-proxy or -samba4 in /etc/univention/templates/files/etc/bind need to have this small section added section "options{ };" --- response-policy { zone "papercut-response-policy"; }; --- Then the zone needs to be defined in as as follows by adding the snippet below in /etc/bind/local.conf.proxy (UCS w/o S4) or in /etc/bind/local.conf.samba4 (UCS with S4) --- zone "papercut-response-policy" { type master; file "/etc/bind/papercut-response-policy"; allow-query { none; }; }; --- The zone file /etc/bind/papercut-response-policy might look like this: --- $TTL 1H @ IN SOA localhost. hostmaster.example.org. ( 1 ; serial 3H ; refresh 1H ; retry 1W ; expiry 1H) ; minimum IN NS localhost. ; define all internal domains to overwrite b._dns-sd._udp.example.org IN PTR pc-printer-discovery.example.org. lb._dns-sd._udp.example.org IN PTR pc-printer-discovery.example.org. Validate the configs * Ohne S4: named-checkconf -jz /etc/bind/named.conf.proxy * Mit S4: named-checkconf -jz /etc/bind/named.conf.samba4 Restart the respective univention-bind-proxy or univention-bind-samba4 daemon and verify the records can be resolved like: host -t PTR b._dns-sd._udp.example.org (<your dns resolver IP>)