They are debugging messages. Stop running in debug mode.
ns_client_log(client, NS_LOGCATEGORY_CLIENT,
NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(1),
"already have ede, ignoring %u %s", code,
text ==
there are separate cases to consider.
the docs
https://bind9.readthedocs.io/en/latest/reference.html#dnssec-policy-block-definition-and-usage
state
The dnssec-policy statement requires dynamic DNS to be set up, or
inline-signing to be enabled.
If inline-signing is enabled,
Retried my named.conf with BIND 9.19.7-dev (Development Release)
which reports:
26-Oct-2022 21:31:42.021 /private/tmp/b/named.conf:11: 'inline-signing
yes;' must also be configured explicitly for zones using dnssec-policy without
a configured 'allow-update' or 'update-policy'. See
ht
Or cache snooping behaves differently between two (or multiple) queries.
That’s why questions like this should not imply where the problem is but rather
describe what can be seen (possibly also on the wire).
Ondrej
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be dif
The change is that with 9.16, if the requested name is a CNAME, only the
CNAME value is returned by dig, while with 9.11 dig would return both the CNAME
value and the IP of the CNAME.
as others have said, this needs more details, but I wonder whether you might
now be querying a server which has
Hi!
We do have somewhat extensive logging on our auth DNS servers,
and currently, we see a load of messages like those:
client @0x80357ad60 #5701 (#65358: set ede: info-code 18 extra-text (null)
What do those messages report and how can I silence those messages ?
--
p...@opsec.eu+4
Hi Veronique.
As other people have said, more details please.
To have a complete picture of what is going on, not only would we need to
know what your dig tests look like, but also where dig is sending its
queries and how that DNS server is configured.
You can tell dig to send queries anywhere, u
For both versions of bind, please submit the actual dig command and the
complete results received. That will make diagnosing this issue MUCH easier.
Regards,
Bob
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software
hi,
If there are currently no keys that we have to check the DS for, then you may
still see this log line.
all my zones have now toggled rumoured -> omnipresent. i took no explicit
manual action other than letting an arbitrarily long-ish time pass.
it just happened ... eventually.
re: your
I am unable to reproduce this. Please share some examples like this:
dig +norecurse @216.239.34.110 www.lathama.org
```
; <<>> DiG 9.11.5-P4-5.1+deb10u8-Debian <<>> +norecurse @216.239.34.110
www.lathama.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY,
the 'inline-signing yes;' is needed IN ADDITION to 'dnssec-policy' in order to
_not_ overwrite original zone files/data on signing.
I cannot confirm that (9.17.22):
sry, fat thumbed copying my reply into email :-/
should have been wrapped in niceties, including "hmm, I can here with 9.18.8
.
ls -1 keys/dnssec/example.com/
(empty)
ls -1 namedb/primary/example.com*
namedb/primary/example.com.zone<== ORIGINAL, unsigned zone file
cat etc/named.conf
...
zone "example.com" IN {
type master; file "namedb/primary/example.com.zone";
the 'inline-signing yes;' is needed IN ADDITION to 'dnssec-policy' in order to
_not_ overwrite original zone files/data on signing.
I cannot confirm that (9.17.22):
% ls -1
example.aa
named.conf
% cat named.conf
options {
directory ".";
listen-on port 5301 { 127.0.0.2; };
The inline-signing feature will not go away.
Thanks, Matthijs, I stand corrected. I believe I had seen that in ISC
documentation and/or issues, but I will now stop saying that. :)
-JP
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds t
You need to be more specific with real examples.
Ondrej
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 26. 10. 2022, at 17:41, Veronique Lefebure
> wrote:
>
>
> Hi,
>
>
Hi,
dig answer is different between BIND 9.11 and BIND 9.16(.33) when +norecurse
option is used.
Is this documented somewhere ?
Is there an option that needs to be set so that the behaviour of 9.16 is the
same as the one in 9.11.
The change is that with 9.16, if the requested name
There are two ways of DNSSEC maintenance in BIND. One is the inline-signing
approach, that preserves the original zone file. The other is to apply the
changes directly to the zone (and zone file) and requires the zone to allow
dynamic updates.
Since the latest release dnssec-policy requires eit
Yes - I think "automated" in-line signing would be useful in
"dnssec-policy" run zones.
We didn't need this some versions of BIND ago ( I had to add it recently
on a zone that I've been testing with - untouched from a year or so ago)
We don't generally edit the signed zone - just the unsigned
On 10/26/22 10:19, Matthijs Mekking wrote:
Thanks for this. It probably should be removed from the docs at this point.
When introducing dnssec-policy, my goal was to reduce the dozens of
DNSSEC related configuration options that are scattered throughout
named.conf and contain them in one sta
On 24-10-2022 20:43, Richard T.A. Neal wrote:
Jan-Piet Mens wrote:
A Beginner's Guide to DNSSEC with BIND 9.
Well done! A few comments, if I may:
{snip}
Thanks JP, I really appreciate the feedback. I'll take all of that onboard,
change my zones and guide from master/slave to primary/s
Thanks for this. It probably should be removed from the docs at this point.
When introducing dnssec-policy, my goal was to reduce the dozens of
DNSSEC related configuration options that are scattered throughout
named.conf and contain them in one stanza. But some options are more
difficult to b
On 24-10-2022 15:14, PGNet Dev wrote:
The good news it is not stuck.
What indicator flags that it IS 'stuck'? Is it explicitly logged?
Because the keymgr logs says it is just waiting time?
2022-10-21T16:55:22.690622-04:00 ns named[36683]: 21-Oct-2022
16:55:22.689 dnssec: debug 1: keymgr:
22 matches
Mail list logo
