> On 27 May 2024, at 16:06, Erik Edwards via bind-users
> <bind-users@lists.isc.org> wrote:
>
> Hello Mark & List,
>
> Thank you for responding, I'm running bind-9.18.26-1.fc40.x86_64 and using
> nsupdate 9.16.27-Debian to send the updates, using rndc Version: 9.18.26.
>
> I'm issuing commands through rndc to set the trace level to 99 -> "rndc trace
> 99". rndc seems to work correctly in all other commands I've employed.
>
> My question is limited to the proper method for turning on the debugging logs
> for the "update" section of the code.
>
> My specific question is: Will or should this turn on more verbose logs for
> the update section of the code.
>
> I'm quite willing to find my own errors in the configuration. Getting the
> verbose logs to provide more than just "REFUSED" would be most helpful and
> save a gdb session.
>
> I'm not a paying customer and not expecting detailed help from ISC, only
> wondering if the "rndc trace 99" should have activated the more verbose logs.
>
> Please pardon the reference to Fedora.
>
> My configuration files have significant private, related, information beyond
> the keys, and I would rather not post them here. I'm willing to send them
> directly if you would prefer.
>
> Here is the logging excerpt from the configuration:
>
> logging {
> channel default_file {
> file "/var/log/named/single.log" versions 3 size 5m;
> severity dynamic;
> print-time local;
> print-severity yes;
> };
>
> category default { default_file; };
> };
>
> With this single file logging configuration, all the other sections of code
> produce what I expect to see from rndc trace 99.
>
> When I use separate logs via:
>
> logging {
> channel default_file {
> file "/var/log/named/default.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel general_file {
> file "/var/log/named/general.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel database_file {
> file "/var/log/named/database.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel security_file {
> file "/var/log/named/security.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel config_file {
> file "/var/log/named/config.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel resolver_file {
> file "/var/log/named/resolver.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel xfer-in_file {
> file "/var/log/named/xfer-in.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel xfer-out_file {
> file "/var/log/named/xfer-out.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel notify_file {
> file "/var/log/named/notify.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel client_file {
> file "/var/log/named/client.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel unmatched_file {
> file "/var/log/named/unmatched.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel queries_file {
> file "/var/log/named/queries.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel network_file {
> file "/var/log/named/network.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel update_file {
> file "/var/log/named/update.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel dispatch_file {
> file "/var/log/named/dispatch.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel dnssec_file {
> file "/var/log/named/dnssec.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
> channel lame-servers_file {
> file "/var/log/named/lame-servers.log" versions 3 size 5m;
> severity dynamic;
> print-time yes;
> };
>
> category default { default_file; };
> category general { general_file; };
> category database { database_file; };
> category security { security_file; };
> category config { config_file; };
> category resolver { resolver_file; };
> category xfer-in { xfer-in_file; };
> category xfer-out { xfer-out_file; };
> category notify { notify_file; };
> category client { client_file; };
> category unmatched { unmatched_file; };
> category queries { queries_file; };
> category network { network_file; };
> category update { update_file; };
> category dispatch { dispatch_file; };
> category dnssec { dnssec_file; };
> category lame-servers { lame-servers_file; };
> };
>
> with 'rndc trace 99', all files except /var/log/named/update.log receive
> copious amounts of information. The update log receives only the REFUSED line
> like 'rndc trace 1' below.
>
> With rndc trace 1 and single file logging I get:
> 26-May-2024 23:23:59.522 info: client @0x7fb4df8ad968 <redacted> <redacted>:
> updating zone '<redacted>/IN': update failed: rejected by secure update
> (REFUSED)
>
> at rndc trace 7:
> 26-May-2024 23:26:21.611 debug 3: client @0x7fb4e4739568 <redacted>#42321:
> UDP request
> 26-May-2024 23:26:21.612 debug 5: client @0x7fb4e4739568 <redacted>#42321:
> using view '_default'
> 26-May-2024 23:26:21.612 debug 3: client @0x7fb4e4739568 <redacted>#42321:
> request has valid signature: <redacted>
> 26-May-2024 23:26:21.612 debug 3: client @0x7fb4e4739568 <redacted>#42321/key
> <redacted>: recursion available
> 26-May-2024 23:26:21.612 info: client @0x7fb4e4739568 <redacted>#42321/key
> <redacted>: updating zone '<redacted>/IN': update failed: rejected by secure
> update (REFUSED)
Post your update-policy and the complete UPDATE message. The update is being
rejected by the policy. Unless you have a grant for every change in the UPDATE
section the result will be REFUSED. My hunch is that you allow A updates but
disallow AAAA updates and with the OS upgrade AAAA records are now being
updated.
You wanted to have your UPDATE messages succeed yet you continued to focus on
logging rather than supplying the UPDATE related configuration after being
requested to go back to the beginning. There really isn’t a security issue
with posting names and address. There is a myth that doing so will make you
insecure. It is just that a myth. Not posting them just makes it harder for
other people to help you.
Mark
> From nsupdate:
>
> nsupdate -L99 -dD -k TrueNAS.key nsupdate-cmds-py.txt
>
> show_message()
> Outgoing update query:
> ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 13334
> ;; flags:; ZONE: 1, PREREQ: 1, UPDATE: 9, ADDITIONAL: 1
> ;; ZONE SECTION:
> ;<redacted>. IN SOA
>
> ;; PREREQUISITE SECTION:
> <redacted>. 0 ANY ANY
>
> ;; UPDATE SECTION:
> <redacted>. 0 ANY A
> <redacted>. 0 ANY AAAA
> <redacted>. 300 IN A <redacted>
> <redacted>. 300 IN AAAA <redacted>
> <redacted>. 300 IN A <redacted>
> <redacted>. 300 IN AAAA <redacted>
> <redacted>. 300 IN A <redacted>
> <redacted>. 300 IN A <redacted>
> <redacted>. 300 IN AAAA <redacted>
>
> ;; TSIG PSEUDOSECTION:
> <redacted>. 0 ANY TSIG <redacted>. 1716789240 300 32
> <redacted> <redacted> NOERROR 0
> --
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--
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
