Hello Crist,
This problem you have spotted in your troubleshooting was fixed by the
uplevel sysadmins.
Now I have added bjesomar.srce.hr as the secondary (I don't like the
expressions "master" and "slave") NS for 193.198.186.192/27.
It appears to work. There seem to be more DHCP problems th
Hello Crist,
P.S.
Thank you again for your time and effort. Your expertise is very much
appreciated. The thingy appears to work snappy đ!
It is true that domac.alu.hr recognizes only itself as the authoritative
NS for 193.198.186.192/27 zone.
I had to comment out the bjesomar.srce.hr delegat
Hello Crist,
The good news is that it seems that the dynamic DDNS update from DHCP
works!
See here a snap from /var/log/syslog:
Dec 13 07:36:20 domac dhcpd[26031]: DHCPDISCOVER from 1c:66:6d:90:0b:f7
(ALU-ZAG-14) via 193.198.186.193
Dec 13 07:36:20 domac dhcpd[26031]: DHCPOFFER on 193.198.18
First, for troubleshooting, do not use nslookup(1). If you have BIND,
use dig(1) and host(1).
Since these names are out there on the Internet, we can troubleshoot
too!
I'm noticing a problem with the delegation for the
192/27.186.198.193.in-addr.arpa zone. The servers for
186.198.193.in-add
Hello Crist,
I have implemented the recommended changes. It works forward and reverse
for the test record, from out domain or others, or for almost all of the
test records.
There are still some spurious failures, such as this one:
200 INÂ CNAMEÂ Â 200.186.198.193.dhcp.slava.alu.hr.
20
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.
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
Looks like you're trying to use the setup in that serverfault link. That
example only works on an internal network.
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
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: witho
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)
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 recor
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,
12 matches
Mail list logo
