ISC-DHCP and BIND 9 DNS: DDNS update fails for /27 subnet P.S.
Mirsad Goran Todorovac
mirsad.todorovac at alu.unizg.hr
Mon Dec 13 08:27:33 UTC 2021
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 delegation as NS because it
caused spurious failures in reverse resolution.
Now you have made clear why. The error was made upstream, out of my
possibility to fix.
I have discretely requested that the zone is enabled on
bjesomar.srce.hr, but I can't do anything else.
RFC 2317 chapter 5.1 says the name resolution is more stable with the
secondary (slave) servers for the zone.
Kind regards,
Mirsad Todorovac
On 13.12.2021. 9:25, Mirsad Goran Todorovac wrote:
> 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.186.219 to
> 1c:66:6d:90:0b:f7 (ALU-ZAG-14) via 193.198.186.193
> Dec 13 07:36:20 domac dhcpd[26031]: DHCPREQUEST for 193.198.186.219
> (161.53.235.3) from 1c:66:6d:90:0b:f7 (ALU-ZAG-14) via 193.198.186.193
> Dec 13 07:36:20 domac dhcpd[26031]: DHCPACK on 193.198.186.219 to
> 1c:66:6d:90:0b:f7 (ALU-ZAG-14) via 193.198.186.193
> Dec 13 07:36:20 domac dhcpd[26031]: Added new forward map from
> ALU-ZAG-14.slava.alu.hr to 193.198.186.219
> Dec 13 07:36:20 domac dhcpd[26031]: Added reverse map from
> 219.186.198.193.dhcp.slava.alu.hr to ALU-ZAG-14.slava.alu.hr
>
> The test shows this:
>
> root at domac:~# dig ALU-ZAG-14.slava.alu.hr
>
> ; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> ALU-ZAG-14.slava.alu.hr
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17082
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 0e131d851cc6d9b1c609407461b6ee098db47da23e5ea971 (good)
> ;; QUESTION SECTION:
> ;ALU-ZAG-14.slava.alu.hr. IN A
>
> ;; ANSWER SECTION:
> ALU-ZAG-14.slava.alu.hr. 3600 IN A 193.198.186.219
>
> ;; AUTHORITY SECTION:
> slava.alu.hr. 600 IN NS domac.alu.hr.
>
> ;; ADDITIONAL SECTION:
> domac.alu.hr. 86400 IN A 161.53.235.3
>
> ;; Query time: 0 msec
> ;; SERVER: 161.53.235.3#53(161.53.235.3)
> ;; WHEN: Mon Dec 13 07:54:01 CET 2021
> ;; MSG SIZE rcvd: 132
>
> root at domac:~# dig -x 193.198.186.219
>
> ; <<>> DiG 9.11.5-P4-5.1+deb10u6-Debian <<>> -x 193.198.186.219
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59076
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 2
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: c733edf748fdf3e2b91eb45761b6ee172d4cf73a7033ec4e (good)
> ;; QUESTION SECTION:
> ;219.186.198.193.in-addr.arpa. IN PTR
>
> ;; ANSWER SECTION:
> 219.186.198.193.in-addr.arpa. 13398 IN CNAME
> 219.192/27.186.198.193.in-addr.arpa.
> 219.192/27.186.198.193.in-addr.arpa. 900 IN CNAME
> 219.186.198.193.dhcp.slava.alu.hr.
> 219.186.198.193.dhcp.slava.alu.hr. 3600 IN PTR ALU-ZAG-14.slava.alu.hr.
>
> ;; AUTHORITY SECTION:
> 186.198.193.dhcp.slava.alu.hr. 600 IN NS domac.alu.hr.
>
> ;; ADDITIONAL SECTION:
> domac.alu.hr. 86400 IN A 161.53.235.3
>
> ;; Query time: 0 msec
> ;; SERVER: 161.53.235.3#53(161.53.235.3)
> ;; WHEN: Mon Dec 13 07:54:15 CET 2021
> ;; MSG SIZE rcvd: 218
>
> root at domac:~#
>
> Thank you for all the help. I didn't really see it coming that our
> reverse network will become globally visible immediately when I put it
> under slava.alu.hr!
> (I planned to request adding by the upstream administrators.)
>
> Thank you again for all the help. As for the problem you mentioned,
> can I forward this email to our CARNet sysadmins?
> I have requested that they add bjesomar.srce.hr as the secondary
> server for the 193.198.186.192/27 reverse zone.
> I suppose that could resolve the problem as well.
>
> So far they said they would do it, but with nslookup -query=any
> 192/27.186.198.193.in-addr.arpa I see only domac.alu.hr as NS for the
> zone.
>
> I hope that will go away with this change.
> I was surprised how nslookup can connect 193.198.186.201 to
> 201.192/27.186.198.193.in-addr.arpa to
> 201.186.198.193.dhcp.slava.alu.hr, and
> 201.186.198.193.dhcp.slava.alu.hr to test-record2.slava.alu.hr, but
> not 193.198.186.201 to test-record2.slava.alu.hr.
> It was unable to sum up the things together?
>
> Thanks again, I will happy that the reverse /27 subnet DDNS DHCP setup
> works.
>
> Kind regards,
> Mirsad Todorovac
>
> On 13.12.2021. 7:10, Crist Clark wrote:
>> 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-addr.arpa,
>>
>> dns1.CARNet.hr
>> dns2.CARNet.hr
>>
>> Return these two DNS servers,
>>
>> $ dig -x 193.198.186.192/27 ns @dns1.carnet.hr
>>
>> ; <<>> DiG 9.16.22 <<>> -x 193.198.186.192/27 ns @dns1.carnet.hr
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8342
>> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
>> ;; WARNING: recursion requested but not available
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;192/27.186.198.193.in-addr.arpa. IN NS
>>
>> ;; AUTHORITY SECTION:
>> 192/27.186.198.193.in-addr.arpa. 14400 IN NS bjesomar.srce.hr.
>> 192/27.186.198.193.in-addr.arpa. 14400 IN NS domac.alu.hr.
>>
>> ;; Query time: 182 msec
>> ;; SERVER: 2001:b68:ff:2::2#53(2001:b68:ff:2::2)
>> ;; WHEN: Sun Dec 12 22:03:39 PST 2021
>> ;; MSG SIZE rcvd: 114
>>
>> However, if I check that against those servers, domac.alu.hr works
>> (although it only returns itself as authoritative for the domain),
>> and bjsomar.srce.hr sends a REFUSED response,
>>
>> dig -x 193.198.186.192/27 ns @bjesomar.srce.hr
>>
>> ; <<>> DiG 9.16.22 <<>> -x 193.198.186.192/27 ns @bjesomar.srce.hr
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 43941
>> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>> ;; WARNING: recursion requested but not available
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ; COOKIE: 341626673209a23b4777d39761b6e2f9656e01a40d454dcd (good)
>> ;; QUESTION SECTION:
>> ;192/27.186.198.193.in-addr.arpa. IN NS
>>
>> ;; Query time: 181 msec
>> ;; SERVER: 2001:b68:c:2::70:0#53(2001:b68:c:2::70:0)
>> ;; WHEN: Sun Dec 12 22:06:50 PST 2021
>> ;; MSG SIZE rcvd: 88
>>
>>
>>
>> On 2021-12-12 06:45, Mirsad Goran Todorovac wrote:
>>> 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.
>>> 201 IN CNAME 201.186.198.193.dhcp.slava.alu.hr.
>>>
>>> nslookup 193.198.186.200 works and .201 doesn't, despite the symmetric
>>> definition:
>>>
>>> root at domac:/etc/bind/zones# nslookup 193.198.186.200
>>> 200.186.198.193.in-addr.arpa canonical name =
>>> 200.192/27.186.198.193.in-addr.arpa.
>>> 200.192/27.186.198.193.in-addr.arpa canonical name =
>>> 200.186.198.193.dhcp.slava.alu.hr.
>>> 200.186.198.193.dhcp.slava.alu.hr name =
>>> test-record1.slava.alu.hr.
>>>
>>> Authoritative answers can be found from:
>>> 186.198.193.dhcp.slava.alu.hr nameserver = domac.alu.hr.
>>> domac.alu.hr internet address = 161.53.235.3
>>>
>>> root at domac:/etc/bind/zones# nslookup 193.198.186.201
>>> ** server can't find 201.186.198.193.in-addr.arpa: NXDOMAIN
>>>
>>> root at domac:/etc/bind/zones#
>>>
>>> I can't get to the bottom of this, I don't know enough BIND9
>>> internals.
>>>
>>> It will take real-life production load tomorrow to see how this will
>>> behave with DHCP DDNS updates. :-)
>>>
>>> You said ABSOLUTELY NO WARRANTY but I am an open source fan and I can
>>> live with that ;-)
>>>
>>> Until tomorrow, then ...
>>>
>>> Kind regards,
>>> Mirsad Todorovac
>>> On 12/12/2021 10:33 AM, Mirsad Goran Todorovac wrote:
>>>
>>>> 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 at 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 at 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 at 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 [1].
>>>> @ IN NS bjesomar.srce.hr [2].
>>>>
>>>> 195 IN PTR test-record.dhcp.slava.alu.hr [3].
>>>>
>>>> $GENERATE 200-222 $ CNAME $.186.198.193.dhcp.slava.alu.hr [4].
>>>>
>>>> And your DHCP configuration,
>>>>
>>>> ddns-domainname "slava.alu.hr [5]";
>>>> ddns-rev-domainname "dhcp.slaval.alu.hr [6]";
>>>> zone slava.alu.hr [5]. {
>>>> 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 [8].
>>>> ;@ IN NS bjesomar.srce.hr [9].
>>>>
>>>> 195 IN PTR test-record.slava.alu.hr [10].
>>>>
>>>> 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 at 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 [10].
>>>>
>>>> root at 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 at 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
>>>> [10]. 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 [8].
>>>> @ IN NS bjesomar.srce.hr [9].
>>>>
>>>> 195 IN PTR test-record.slava.alu.hr [10].
>>>>
>>>> $GENERATE 200-222 $ CNAME $.186.198.193.dhcp.
>>>>
>>>> /etc/dhcp/dhcpd.conf has this:
>>>>
>>>> ddns-domainname "slava.alu.hr [7]";
>>>> ddns-rev-domainname "dhcp";
>>>> zone slava.alu.hr [7]. {
>>>> 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
>>>> [9] 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 [11]
>>>> 194.186.198.193.rev.example.com [12]
>>>> …
>>>>
>>>> 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 [11].
>>>> 194 IN CNAME 194.186.198.193.rev.example.com [12].
>>>> …
>>>>
>>>> On Fri, Dec 10, 2021 at 2:51 PM Mirsad Goran Todorovac
>>>> <mirsad.todorovac at 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 [13], 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 at 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 at 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 [7]";
>>>> ddns-domainname "slava.alu.hr [7]";
>>>> zone slava.alu.hr [7]. {
>>>> 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 at 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 at 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 at 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 at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1] http://domac.alu.hr/
>>> [2] http://bjesomar.srce.hr/
>>> [3] http://test-record.slava.alu.hr/
>>> [4] http://186.198.193.dhcp.slava.alu.hr
>>> [5] http://slava.alu.hr/
>>> [6] http://dhcp.slaval.alu.hr
>>> [7] http://slava.alu.hr
>>> [8] http://domac.alu.hr
>>> [9] http://bjesomar.srce.hr
>>> [10] http://test-record.slava.alu.hr
>>> [11] http://193.186.198.193.rev.example.com
>>> [12] http://194.186.198.193.rev.example.com
>>> [13] http://193.198.186.192/27
--
Mirsad Todorovac
CARNet sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
More information about the bind-users
mailing list