Hi again,
I had some luck in making this setup work. So far, so good ... However,
there's no telling how the DHCP DDNS will function with the new
186.198.193.dhcp. zone before Monday morning when the subsidiary
computers power up.
However, I have an odd behavior which I cannot explain: without any
change to zone a reverse resolution stopped working. The setup just
doesn't seem stable enough to work with DHCP-updated dynamic DNS in our
organization, with a lot of smartphones and wireless devices frequently
signing on and off.
The zone is:
$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.
200 IN CNAME 200.186.198.193.dhcp.
201 IN CNAME 201.186.198.193.dhcp.
; MT 20211211:
; Here's the magic:
$GENERATE 202-222 $ CNAME $.186.198.193.dhcp.
The command output shows that resolution succeeds, but nslookup can't
finish it for some unknown spurious reason.
root@domac:~# nslookup -query=any 195.192/27.186.198.193.in-addr.arpa.
Server: 161.53.235.3
Address: 161.53.235.3#53
195.192/27.186.198.193.in-addr.arpa name = test-record.slava.alu.hr.
root@domac:~# nslookup -query=ptr 193.198.186.195
Server: 161.53.235.3
Address: 161.53.235.3#53
** server can't find 195.186.198.193.in-addr.arpa: NXDOMAIN
root@domac:~#
This kind of setup that sometimes works and sometimes doesn't will make
me look incompetent.
I know that BIND 9 is great open source server with lots of bells and
whistles. But right now I can't study all those and I just want to
survive, providing a solution fast enough for our uplevel sysadmins.
The /etc/bind/named.conf.local part looks like:
zone "192/27.186.198.193.in-addr.arpa" in {
type master;
file "/etc/bind/zones/192-27.186.198.193.in-addr.arpa.db";
};
zone "186.198.193.dhcp" in {
type master;
file "/var/cache/bind/186.198.193.dhcp.db";
allow-update { key DDNS_UPDATE; };
};
What possibly could be killing the name resolution between resolving
195.192/27.186.198.193.in-addr.arpa to test-record.slava.alu.hr. and
resolving 193.198.186.195 that apparently fails?
Is there a way to see more interim debugging output?
Thank you very much.
Kind regards,
Mirsad Todorovac
On 12/11/2021 10:25 AM, Mirsad Goran Todorovac wrote:
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 visithttps://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 athttps://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
