You need to replace the rule type with something more appropriate for the type
of update being preformed. For the updates made by the DHCP server I would use
“zonesub”. “name” is fine for LetsEncrypt.
update-policy {grant update-key zonesub A ;};
update-policy {grant update
> On 3 Feb 2023, at 21:47, Darren Ankney wrote:
>
> You would probably need to attach your entire named.conf file (with
> sensitive bits (keys and the like) redacted and perhaps subnets
> obscured to examples such as 192.0.2.0/24, for example) before anyone
> would be able to help you.
>
> Tha
You would probably need to attach your entire named.conf file (with
sensitive bits (keys and the like) redacted
named-checkconf -px
is your friend: prints out the named.conf and included files in canonical form
if no errors were detected and obscures shared secrets by replacing them with
str
You would probably need to attach your entire named.conf file (with
sensitive bits (keys and the like) redacted and perhaps subnets
obscured to examples such as 192.0.2.0/24, for example) before anyone
would be able to help you.
That being said, your update policy statements don't look correct to
Since the dig output shows "SERVFAIL" it could also be this bug:
* When an outgoing request timed out, named would retry up to three
times with the same server instead of trying the next available name
server. This has been fixed. [GL #3637]
that was fixed in 9.18.11
(https://bind9.readthedocs.io
Hi Sandeep.
>From a quick look in Wireshark at what my own server (9.18.8) is doing,
this looks like Akamai not responding correctly to a BIND QNAME
minimisation query. Here's one response, from 95.101.36.192 for example, of
many similar ones showing an issue. The response code shouldn't be REFUSED
6 matches
Mail list logo
