Re: Debugging TSIG signed nsupdate problems - Specifically a logging question
In the dnssec.log file I only found references to normal key rotation. Adding the section for update_security and running at trace 99 didn't provide _any_ update_security log output, nor did it provide any extra output to the update log. even when running in single combined log format I couldn't find any messages beyond "REFUSED" It looks like the logging in the update section requires some directive I have been unable to figure out. I did find the issue with the updates, it was a typo in the object that was allowed to be updated. Not the A nor the AAA part, but the named object in the had a typo in the domain portion. my entries in the update-policy section are in the form: grant ... ; No clue why It appeared to be working before. Would be really nice to have some kind of log message, perhaps like "named object not listed in policy for ". -Erik On 5/28/24 12:48 AM, Crist Clark wrote: Have you looked in the "dnssec" logs? That may contain info about TSIG processing. Also, I didn't see the "update-security" category in your shared configuration. Not sure those have what you are looking for. You did look at the descriptions of all of the categories? https://bind9.readthedocs.io/en/stable/reference.html#namedconf-statement-category OpenPGP_signature.asc Description: OpenPGP digital signature -- 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
Re: Debugging TSIG signed nsupdate problems - Specifically a logging question
Please allow me to refocus this thread to the original question. I'm asking about the logging facility with respect to the "update" section of code in ISC's bind9 product. Yes, I understand update-policy choices/errors will generate the REFUSED response. _I'm only asking about the logging function itself._ Should the trace level of 99 generate more information in the logs for the update function than I am observing? -Erik OpenPGP_signature.asc Description: OpenPGP digital signature -- 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
Re: Debugging TSIG signed nsupdate problems
> On 27 May 2024, at 16:06, Erik Edwards via bind-users
> 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 {
Re: Debugging TSIG signed nsupdate problems
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
Re: Debugging TSIG signed nsupdate problems
Start from the beginning. Show the actual configuration (named.conf, K* files, etc.). X out the secret keys. Show the actual commands you are running. Show the actual logs being produced. REFUSED can come from lots of things. Named emits log messages for almost all of them without needing to turn on debugging. Stop making us guess which version you BIND you upgraded from. This bind-users, not Fedora support. F36-F39 is meaningless here. If you are using nsupdate to send the UPDATE request turn on its debugging. At the moment all you have said is that you have a problem but have given NOTHING for people to work with to help you. Mark > On 27 May 2024, at 13:39, Mark Andrews wrote: > > > >> On 25 May 2024, at 03:25, Erik Edwards via bind-users >> wrote: >> >> algorithm hmac-sha256; >> >> named-checkconf -p shows the key with the matching name, algo, and secret. >> >> When I mis-configure, change, or typo the secret it returns "BAD SECRET" >> >> The error I'm seeing is "REFUSED" on a config that worked until the upgrade. >> It worked on F36-F39, upgrades were seamless. >> >> Really wondering how to get debug level logs on this module. >> >> On 5/24/24 11:31 AM, John Thurston wrote: >>> named-conf -px >> >> -- >> 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 > -- 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
Re: Debugging TSIG signed nsupdate problems
algorithm hmac-sha256; named-checkconf -p shows the key with the matching name, algo, and secret. When I mis-configure, change, or typo the secret it returns "BAD SECRET" The error I'm seeing is "REFUSED" on a config that worked until the upgrade. It worked on F36-F39, upgrades were seamless. Really wondering how to get debug level logs on this module. On 5/24/24 11:31 AM, John Thurston wrote: named-conf -px OpenPGP_signature.asc Description: OpenPGP digital signature -- 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
Re: Debugging TSIG signed nsupdate problems
It doesn't answer your original question, but I suggest looking at the 'algorithm' of that key. Might it be a hmac-md5 ? If you 'named-conf -px' does it appear in the list of keys? -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 5/24/2024 8:17 AM, Erik Edwards via bind-users wrote: CAUTION: This email originated from outside the State of Alaska mail system. Do not click links or open attachments unless you recognize the sender and know the content is safe. How can I set debug level log for update events? I've tried "rndc trace 99" which gives *lots* of information expect for UPDATE REFUSED issues even thought the channel is set to dynamic severity. Is there a different way to get named to generate debug level logs for UPDATE events? I'm running BIND 9.18.26 (Extended Support Version) from Fedora 40. The updates and keys had been working correctly until the update to Fedora 40/BIND 9.18.26 The issues I'm experiencing are only applying to a single key & update-policy line, other TSIG's are working correctly. -Erik -- 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
Debugging TSIG signed nsupdate problems
How can I set debug level log for update events? I've tried "rndc trace 99" which gives *lots* of information expect for UPDATE REFUSED issues even thought the channel is set to dynamic severity. Is there a different way to get named to generate debug level logs for UPDATE events? I'm running BIND 9.18.26 (Extended Support Version) from Fedora 40. The updates and keys had been working correctly until the update to Fedora 40/BIND 9.18.26 The issues I'm experiencing are only applying to a single key & update-policy line, other TSIG's are working correctly. -Erik OpenPGP_signature.asc Description: OpenPGP digital signature -- 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
