Hi Crist,
Thank you for your reply and the information provided.
I have roughly implemented this workaround. I was hoping there was a way
to instruct BIND to masquerade a delegated domain with data from another
(dynamically updated from ISC DHCP) zone.
More accurately, my (from upper level) mandated delegation is the
literal 192/27.186.198.193.in-addr.arpa, using
192-27.186.198.193.in-addr.arpa says "ignoring records outside of the
origin" or something like that.
I have used the following records in the zone:
$ORIGIN 192/27.186.198.193.in-addr.arpa.
@ IN NS domac.alu.hr.
@ IN NS bjesomar.srce.hr.
195 IN PTR test-record.slava.alu.hr.
$GENERATE 200-222 $ CNAME $.186.198.193.dhcp.
/etc/dhcp/dhcpd.conf has this:
ddns-domainname "slava.alu.hr";
ddns-rev-domainname "dhcp";
zone slava.alu.hr. {
primary 127.0.0.1;
key DDNS_UPDATE;
}
zone 186.198.193.dhcp. {
primary 127.0.0.1;
key DDNS_UPDATE;
}
However, don't I have to convince people managing bjesomar.srce.hr to be
a slave server for the "186.198.193.dhcp" zone? Or the dynamically
updated reverse PTR record will have effect only in my local domain
(which I had even before the entire setup), won't it?
Also, I get spurious REFUSED or NXDOMAIN errors, some pass with time, so
there must be some TTL or timeout.
Kind regards,
Mirsad
On 12/11/2021 6:04 AM, Crist Clark wrote:
No idea if this is the best way. It is a way.
Do you control any other zone? Let’s say you own “example.com.” You
can tell ISC DHCP to build the reverse zone at an arbitrary base name
instead of in-addr.arpa.
Configure DHCP to put the reverse records at say, “rev.example.com.”
So you’ll get records at,
193.186.198.193.rev.example.com <http://193.186.198.193.rev.example.com>
194.186.198.193.rev.example.com <http://194.186.198.193.rev.example.com>
…
And in your RFC 2317-style delegation, you then enumerate another
CNAME layer,
$ORIGIN 192-27.186.198.193.in-addr.arpa.
193 IN CNAME 193.186.198.193.rev.example.com
<http://193.186.198.193.rev.example.com>.
194 IN CNAME 194.186.198.193.rev.example.com
<http://194.186.198.193.rev.example.com>.
…
On Fri, Dec 10, 2021 at 2:51 PM Mirsad Goran Todorovac
<mirsad.todoro...@alu.unizg.hr> wrote:
Hello,
I have a problem with DHCP DDNS update to BIND 9 reverse PTR zone
subnet that is owned by several organizations, so I can't get a
direct DHCP DDNS update access with a key or with hostname.
I have been delegated domain name |192-27.186.198.193.in-addr.arpa
from the upper level admins, and that appears to be immutable.|
|However, my subnet is 193.198.186.192/27
<http://193.198.186.192/27>, and DHCP only knows how to perform
DDNS update to 186.198.193.in-addr.arpa. (See here:
https://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update
and here:
https://lists.isc.org/mailman/htdig/dhcp-users/2006-August/001422.html
).
|
|(This setup is because we have DHCP addresses that are not over
NAT, but /24 subnet is shared with other organizations, even under
another Minstry.)|
|I want to have the effect of delegating the same database to
upper level under their zone name, while updating the same
database under my DHCP-understood zone name.|
|I tried this /etc/bind/named.conf.local:|
|zone "192-27.186.198.193.in-addr.arpa" in { type master; file
"/var/cache/bind/192-27.186.198.193.in-addr.arpa.db"; }; zone
"186.198.193.in-addr.arpa" in { type master; file
"/var/cache/bind/192-27.186.198.193.in-addr.arpa.db"; allow-update
{ key DDNS_UPDATE; }; }; |
(Two zones with the same file.)
What I got was:
|root@domac:/etc/bind# named-checkconf
/etc/bind/named.conf.local:49: writeable file
'/var/cache/bind/192-27.186.198.193.in-addr.arpa.db': already in
use: /etc/bind/named.conf.local:44 root@domac:/etc/bind# Can you
please tell me is there a way to achieve the effect of the above
(illegal) setup? I can't change DHCP nor I know an option to tell
it to accept update to |||192-27.186.198.193.in-addr.arpa| (it is a syntax
error). The
DHCP dhcpd.conf subnet configuration is: |||subnet 193.198.186.192 netmask
255.255.255.224 { range
193.198.186.200 193.198.186.222; # MT 20211210 option subnet-mask
255.255.255.224; option domain-name-servers 161.53.235.3,
161.53.2.70; option domain-name "slava.alu.hr
<http://slava.alu.hr>"; ddns-domainname "slava.alu.hr
<http://slava.alu.hr>"; zone slava.alu.hr <http://slava.alu.hr>. {
primary 127.0.0.1; key DDNS_UPDATE; } zone
186.198.193.in-addr.arpa. { primary 127.0.0.1; key DDNS_UPDATE; }
option broadcast-address 193.198.186.223; option routers
193.198.186.193; default-lease-time 43200; max-lease-time 86400; }
| Thank you very much for your time reading this mail and help.
Kind regards, -- Mirsad Goran Todorovac Academy of Fine Arts |
Faculty of Graphic Arts University of Zagreb |
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
ISC funds the development of this software with paid support
subscriptions. Contact us at https://www.isc.org/contact/ for more
information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
