Hi Crist,
Now the resolution from the problematic record started working again
without any change in zones or BIND9 options, also without the server
process restart ... :-/
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
Non-authoritative answer:
195.186.198.193.in-addr.arpa canonical name =
195.192/27.186.198.193.in-addr.arpa.
195.192/27.186.198.193.in-addr.arpa name = test-record.slava.alu.hr.
Authoritative answers can be found from:
192/27.186.198.193.in-addr.arpa nameserver = domac.alu.hr.
domac.alu.hr internet address = 161.53.235.3
root@domac:~#
I guess this was something with timeouts. Suppose this will work
satisfactory on desktops that usually keep the same IP address assigned
by DHCP across the lease renewals, but not for laptops, Android and
iPhone devices that connect and disconnect, and change network ...
Why I want smartphones to have reverse PTRs is to see in logs if
something becomes virus infected or even spambot, and not have to browse
DHCP leases in forensic analysis, which my fellow administrator probably
would not know how to do ...
Kind regards,
Mirsad Todorovac
On 12/12/2021 10:19 AM, Mirsad Goran Todorovac wrote:
Hi Crist,
Thank you for your explanation. It was much appreciated.
However, as I previously asserted, it is impossible to know how the
system will behave without testing it with real life production load
on Monday :-)
On 12/11/2021 11:18 PM, Crist Clark wrote:
Looks like you're trying to use the setup in that serverfault link.
That example only works on an internal network.
I thought the 186.198.193. part was enough to make the zone unique.
But your assertion is correct: I would collide if any other
administrators on other subnets in range 193.198.186.0/24 decide to
make reverse DHCP DDNS update in the future. Thanks for the thought!
The point of the example I gave is that you are going to build your
own reverse zone inside of a zone you control on the Internet. Now
that you've given some examples, I can perhaps make it more obvious
what I'm suggesting. Your DNS zone would look something like,
$ORIGIN 192-27.186.198.193.in-addr.arpa.
@ IN NS domac.alu.hr <http://domac.alu.hr/>.
@ IN NS bjesomar.srce.hr <http://bjesomar.srce.hr/>.
195 IN PTR test-record.dhcp.slava.alu.hr
<http://test-record.slava.alu.hr/>.
$GENERATE 200-222 $ CNAME $.186.198.193.dhcp.slava.alu.hr
<http://186.198.193.dhcp.slava.alu.hr>.
And your DHCP configuration,
ddns-domainname "slava.alu.hr <http://slava.alu.hr/>";
ddns-rev-domainname "dhcp.slaval.alu.hr <http://dhcp.slaval.alu.hr>";
zone slava.alu.hr <http://slava.alu.hr/>. {
primary 127.0.0.1;
key DDNS_UPDATE;
}
NOT TESTED. NO GUARANTEES. NOT SUITABLE FOR ANY GIVEN PURPOSE. YOUR
MILEAGE MAY VARY. PLEASE CONSULT YOUR PERSONAL PHYSICIAN BEFORE
STARTING ISC PRODUCTS.
Noted. :-) I am not afraid of experimenting. But failures of the
experimental setup are perceived as my incompetence, and success taken
for granted the very next day ;-)
One other odd thing, sometimes you refer to a
"192/27.186.198.193.in-addr.arpa" zone and sometimes
"192-27.186.198.193.in-addr.arpa." Those are different names and are
not interchangeable. Both are totally fine for use in DNS, but a lot
of administrators don't like the '/' in zone names since they often
use the zone name in file names. Slashes present a problem in
file names on *nix flavored OSes. I used the dash, '-', version in my
example.
This setup is mandated from the upper level sysadmins and I cannot
control it, I can only beg them to use a hyphen as in RFC 2317 chapter
4 last paragraph, but I cannot guarantee that they will change it. It
is their arbitrary decision. :-/
Frankly, /27 is more readable, but if it creates havoc in Linux
resolver, then what the heck ...
Thank you very much again for your advice. I will post back here on
the results with your recommended zone setup.
Kind regards,
Mirsad Todorovac
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 <http://domac.alu.hr>.
;@ IN NS bjesomar.srce.hr <http://bjesomar.srce.hr>.
195 IN PTR test-record.slava.alu.hr
<http://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 <http://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 <http://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 <http://domac.alu.hr>.
@ IN NS bjesomar.srce.hr <http://bjesomar.srce.hr>.
195 IN PTR test-record.slava.alu.hr
<http://test-record.slava.alu.hr>.
$GENERATE 200-222 $ CNAME $.186.198.193.dhcp.
/etc/dhcp/dhcpd.conf has this:
ddns-domainname "slava.alu.hr <http://slava.alu.hr>";
ddns-rev-domainname "dhcp";
zone slava.alu.hr <http://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 <http://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
_______________________________________________
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
