Dear BIND 9 users,
BIND 9 has a lot of configuration options. Some have lost value over
the years, but the policy was to keep the options to not break old
configurations.
However, we also want to clean up the code at some point. Keeping these
options increases the number of corner cases and
,
Matthijs
On 5/20/19 12:34 PM, Matthijs Mekking wrote:
> Dear BIND 9 users,
>
> The BIND 9 development team has been discussing whether we should remove
> the DLV code from the BIND 9 source. Reasons for doing this:
>
> * The zone dlv.isc.org has been decommissioned some time ago
Hi,
On 6/13/19 2:40 PM, G.W. Haywood via bind-users wrote:
> Hi there,
>
> On Thu, 13 Jun 2019, Matthijs Mekking wrote:
>
>> We would like to hear your feedback.
>
> Thank you for the timely heads up.
>
>> | managed-keys | 9.15/9.16 | replaced with d
Dear BIND 9 users,
The BIND 9 development team has been discussing whether we should remove
the DLV code from the BIND 9 source. Reasons for doing this:
* The zone dlv.isc.org has been decommissioned some time ago.
* It will make the code much easier to maintain, which is beneficial for
Hi Grant,
On 5/20/19 11:44 PM, Grant Taylor via bind-users wrote:
On 5/20/19 4:34 AM, Matthijs Mekking wrote:
* It will make the code much easier to maintain, which is beneficial
for users too since that will mean in general less bugs, easier to
find bugs, and easier to extend it with new
Hi Graham,
On 2/29/20 5:27 PM, Graham Clinch wrote:
> How does the new-in-9.16 dnssec-policy interact with views - in
> particular for key generation/rollover?
>
> For example, we have a zone defined in multiple views with different
> contents (and thus not suitable for in-view), being signed by
Hi Tom,
Because you just started signing your zone. The DNSKEY and RRSIG records
are published but have to wait a TTL time to before the DS may be
published, to avoid a situation where a resolver fetches the DS but
still has the corresponding DNSKEY query in the negative cache.
This time is
Hi Matthias,
The answer is almost, as long as the zone has a DNSSEC policy configured:
zone "newdomain.de" {
type master;
file "../master/newdomain.de";
dnssec-policy default;
}
The only thing not yet fully automated is submitting the DS to the
parent. You can do that as soon as named
Hi Philippe,
On 4/7/20 3:46 PM, Philippe Maechler wrote:
> Hello bind users
>
>> The answer is almost, as long as the zone has a DNSSEC policy configured:
>>
>> zone "newdomain.de" {
>> type master;
>> file "../master/newdomain.de";
>> dnssec-policy default;
>> }
>>
>> The only thing not
Mark,
On 4/13/20 8:54 PM, Evan Hunt wrote:
> On Mon, Apr 13, 2020 at 02:22:53PM +0200, Mark Elkins wrote:
>> Question - What are the "TYPE65534" records? What are they saying? I am
>> using "DiG 9.16.1" so surprised it doesn't know.
>
> This is a mechanism named uses to keep track of the status
licy x" with "inline-signing no" does
> not seem to be handled gracefully.
> This makes me suspect that it's not an intended scenario, is that correct?
>
>
> /Håkan
>
> On 2020-03-25 16:57, Håkan Lindqvist via bind-users wrote:
>> On 2020-03-25 14:03, Matth
is not yet suitable for
your use case. We will implement NSEC3 for dnssec-policy in 9.17 and
backport it to 9.16.
Best regards,
Matthijs
On 3/25/20 8:50 PM, Shumon Huque wrote:
> On Wed, Mar 25, 2020 at 9:04 AM Matthijs Mekking <mailto:matth...@isc.org>> wrote:
>
> Hi Håkan,
&
Hi Håkan,
First of all, thanks for trying out the new dnssec-policy feature.
I'll admit there is insufficient documentation and tooling around
migration to dnssec-policy, possibly there is a bug too.
Existing keys do not have a .state file, and so named will try to match
those keys with the
Hi,
If you want to switch to KASP with the a different algorithm, you should
be able to use BIND 9.16.2 and just reconfigure your zone to use
"dnssec-policy". The existing keys will be removed in a timely manner,
while named creates new keys with the new algorithm.
Make sure you will
Hi John,
It all depends on the key material that is used to sign your zone. It
looks like you have to update the DNSKEY RRset, so I assume the vendors
are responsible for signing and each have their own key material.
In order to let the world know you are going to use new keys you will
have to
Hi Christian,
There are no plans for this.
While technically a secondary can have a "dnssec-policy" statement
(acting as a bump-in-the-wire signer), signing a zone is mainly a
primary server responsibility and a policy configuration does not need
to be transferred to its secondaries.
For now I
Hi Gregory,
Thanks for trying out out the new KASP. Let me try to answer your
questions below.
On 5/20/20 2:37 AM, Gregory Shapiro via bind-users wrote:
> After the fantastic ISC DNSSEC webinar series last month, I began
> using KASP for my DNSSEC signed zones. I have noticed an odd
> behavior
: yes - since Wed Dec 23 09:38:24 2020
Next rollover scheduled on Wed Dec 30 07:33:24 2020
- goal: omnipresent
- dnskey: omnipresent
- ds: rumoured
- zone rrsig: rumoured
- key rrsig: omnipresent
Daniel
On 23.12.20 10:33, Matthijs Mekking
Hi Daniel,
With which specific 9.16 version are you testing? The first versions
used an unsafe time based rollover, assuming the DS would be published
withing a certain time. In 9.16.7 a new rndc command "rndc dnssec
-checkds" was introduced to tell BIND 9 that the DS for a given key has
And in 9.16 you can use the following line to sign your zones:
dnssec-policy default;
And you can create your own dnssec-policy if you need a different
signing configuration.
Best regards,
Matthijs
On 11/2/20 7:20 AM, Nyamkhand Buluukhuu wrote:
> Hello,
>
> Yes you can define below
Hi Thomas,
Your policy requests four keys in two algorithms: rsasha1 and
ecdsap256sha256. The keys that are being retired are of algorithm
rsasha256. Because the existing algorithms don't match the policy, they
are being retired.
In other words, it doesn't look like the existing keys were
Hi,
Depends on what your DNSSEC configuration is. Are you using
dnssec-signzone/named? auto-dnssec maintain? inline-signing?
dnssec-policy? dnssec-keymgr?
Yes there are a lot of ways to maintain DNSSEC in BIND. The recommended
way forward is to use dnssec-policy. Migrating to it may still
On 01-02-2021 17:34, @lbutlr wrote:
On 01 Feb 2021, at 07:14, Matthijs Mekking wrote:
Depends on what your DNSSEC configuration is. Are you using
dnssec-signzone/named? auto-dnssec maintain? inline-signing?
dnssec-policy? dnssec-keymgr?
These are all good questions, and when I set this up
On 02-02-2021 14:40, @lbutlr wrote:
On 02 Feb 2021, at 02:23, Matthijs Mekking wrote:
1. Create a dnssec-policy that matches your current keys (so in your case
algorithm 7, also make sure you use the same length).
So I guess something like:
dnssec-policy alg13-ksk-unlimited-zsk-60day
Hi,
On 02-02-2021 18:16, @lbutlr wrote:
On 02 Feb 2021, at 07:36, Matthijs Mekking wrote:
If the PDF is not working for you, perhaps https://bind9.readthedocs.io/ suits
you better?
The PDF works fine, and I can search for "dnssec" and "policy" but it is using
so
Hi -T,
I cannot reproduce this confusing warning message. Please use the
absolute path /var/named/chroot/etc/named.root.key in
https://bugzilla.redhat.com/show_bug.cgi?id=1972022
Best regards,
Matthijs
On 15-06-2021 07:46, ToddAndMargo via bind-users wrote:
On 6/14/21 9:30 PM, Jim
On 15-06-2021 16:32, PGNet Dev wrote:
On 6/10/21 8:38 AM, Tony Finch wrote:
PGNet Dev wrote:
Has anyone here on-list figured out how to hook bind's internal signing
process to *trigger* and external script to exec those API pushes?
I have not, and I also want to be able to do this, and I
On 16-06-2021 17:04, PGNet Dev wrote:
@jpmens was kind enough to share the original basis for the simple perl
He also mentioned
Logging of CDS/CDNSKEY generation for workflow
https://gitlab.isc.org/isc-projects/bind9/-/issues/1748
which requests:
Would it be possible to
Hi,
On 05-02-2021 10:23, @lbutlr wrote:
So, with my test domain that is using dsnssec-policy default dnsviz reports
"DNSKEY: No response was received from the server over UDP"
But:
dig +norec +dnssec +bufsize=512 +ignore dnskey
Shows a DNSKEY record.
It would be useful to also provide the
Hi,
On 08-02-2021 12:20, @lbutlr wrote:
I feel I am getting close. I got the digest generated for hover.com and updated
the DNS on the test zone, but I am getting errors on verify that I don't
understand.
#v+
# dnssec-verify -I text -o example.com /etc/namedb/working/example.com.signed
Most likely you have to delete those files manually.
In 9.16.13, a new "dnssec-policy" option is introduced, "purge-keys". By
default the keys are retained for 90 days after their latest usage. So
in that case keys will be cleaned up automatically.
If you run a lower version, or if you set
On 14-04-2021 22:30, Greg Rivers via bind-users wrote:
On Wednesday, 14 April 2021 15:00:38 CDT Bob Harold wrote:
Does anyone have an automated KSK roll process, that checks for the DS
record at the parent, that they can share?
As far as I can tell, the automated signing in BIND will roll
On 11-04-2021 01:22, @lbutlr wrote:
On 06 Apr 2021, at 01:13, Matthijs Mekking wrote:
In 9.16.13, a new "dnssec-policy" option is introduced, "purge-keys". By
default the keys are retained for 90 days after their latest usage. So in that case keys will be
clea
On 15-04-2021 16:35, Bob Harold wrote:
On Thu, Apr 15, 2021 at 8:50 AM Bob Harold <mailto:rharo...@umich.edu>> wrote:
On Thu, Apr 15, 2021 at 2:57 AM Matthijs Mekking mailto:matth...@isc.org>> wrote:
On 14-04-2021 22:30, Greg Rivers via b
Perhaps inspect the zone file?
Also the CDS/CDNSKEY consistency checks stick out. Perhaps remove them
from the unsigned zone files?
Best regards,
Matthijs
On 12-04-2021 14:52, @lbutlr wrote:
I restored a backup of my named.conf after a little bit of an oops. The file is
the same exact
On 15-04-2021 18:44, Tony Finch wrote:
Matthijs Mekking wrote:
On 15-04-2021 16:35, Bob Harold wrote:
If BIND holds both the child and parent zone, will it add the DS record
at the correct time? Or do I still need to write scripts to update the
DS records in all my sub-zones
Hi,
On 16-08-2021 04:28, raf via bind-users wrote:
On Sun, Aug 15, 2021 at 10:35:27PM +1000, raf wrote:
...
So it's looking good and I'm happy now. But how long
after the zone has been signed can I expect to see
CDS/CDNSKEY RRs appear? Why aren't they created at
the same time as the DNSKEY
On 16-08-2021 11:22, raf via bind-users wrote:
On Mon, Aug 16, 2021 at 10:32:35AM +0200, Matthijs Mekking
wrote:
Hi,
On 16-08-2021 04:28, raf via bind-users wrote:
On Sun, Aug 15, 2021 at 10:35:27PM +1000, raf wrote:
...
So it's looking good and I'm happy now. But how long
after
Reading and parsing EDE is added in June 2020. versions 9.11.20, 9.16.4,
9.17.2.
Setting EDE is not yet supported. There has been done preliminary work
to set a few options at the IETF110 Hackathon, but this work hasn't made
any BIND release yet.
Best regards,
Matthijs
On 07-09-2021
Hi raf,
On 09-08-2021 10:08, raf via bind-users wrote:
Hi,
I've got a bunch of DNSSEC questions.
Any advice would be appreciated.
The context is a little VM with six little zones,
soon to be upgraded to debian-11 and bind-9.16.15.
I haven't signed my zones before but now is the time.
I'm
Hi users,
We are planning to deprecate the options 'auto-dnssec' and
'inline-signing' in BIND 9.18. The reason for this is because
'dnssec-policy' is the preferred way of maintaining your DNSSEC zone.
Deprecating means that you can still use the options in 9.18, but a
warning will be logged
Hi Emannuel,
Thanks for your response.
On 10-08-2021 11:28, FUSTE Emmanuel via bind-users wrote:
Le 10/08/2021 à 10:02, Matthijs Mekking a écrit :
Hi users,
We are planning to deprecate the options 'auto-dnssec' and
'inline-signing' in BIND 9.18. The reason for this is because
'dnssec-policy
Thanks, I got some more suggestions to improve the KB article, I'll
include yours to that list.
On 10-08-2021 15:28, Klaus Darilion wrote:
On 10-08-2021 13:38, Klaus Darilion wrote:
Hi Matthijs!
We would like to encourage you to change your configurations to
'dnssec-policy'. See this KB
Hi Klaus,
On 10-08-2021 13:38, Klaus Darilion wrote:
Hi Matthijs!
We would like to encourage you to change your configurations to
'dnssec-policy'. See this KB article for migration help:
https://kb.isc.org/docs/dnssec-key-and-signing-policy
Some comments to this KB article and
Syntax question:
In https://bind9.readthedocs.io/en/latest/dnssec-guide.html
the double quotes are never used in the zone stanza
where the dnssec-policy is referred to. The double
quotes sometimes (but not always) appear in the
dnssec-policy definition stanza.
Are the double quotes optional in
Hi Tim,
On 11-08-2021 04:19, Tim Daneliuk via bind-users wrote:
On 8/10/21 7:32 PM, raf via bind-users wrote:
To get the DS record information to convey to the
registrar, after starting to use the default policy.
look for the CDS record (the child version of the DS
record) with dig:
dig
Hi raf,
On 06-08-2021 16:29, raf via bind-users wrote:
Hi,
I've just read:
https://bind9.readthedocs.io/en/latest/dnssec-guide.html
(excellent, by the way)
Thanks!
And I've noticed (only!) one typo.
In the "Migrating from NSEC to NSEC3" section, it says:
dnssec-policy
On 10-08-2021 15:51, Tim Daneliuk via bind-users wrote:
On 8/10/21 7:51 AM, Matthijs Mekking wrote:
Hi Klaus,
On 10-08-2021 13:38, Klaus Darilion wrote:
Hi Matthijs!
We would like to encourage you to change your configurations to
'dnssec-policy'. See this KB article for migration help
Hi,
On 12-08-2021 09:02, Josef Vybíhal wrote:
Hi, for a second day, I am scratching my head over (automatic)
publishing CDS/CDNSKEY records. When I read Matthijs Mekkings KB article
at https://kb.isc.org/docs/dnssec-key-and-signing-policy
gards,
Tom
On 21.09.21 09:47, Matthijs Mekking wrote:
Hi Tom,
The max-zone-ttl is there to calculate the right timings for key
rollovers. It won't alter the zone TTL values.
You should set the max-zone-ttl to whatever the highest TTL is in your
zone to make sure key rollovers timings a
Hi Tom,
The max-zone-ttl is there to calculate the right timings for key
rollovers. It won't alter the zone TTL values.
You should set the max-zone-ttl to whatever the highest TTL is in your
zone to make sure key rollovers timings are correct.
This value exists until we have added code to
Hi Tom,
On 29-11-2021 09:36, Tom wrote:
Hi
Using BIND-9.16.22:
After some tests with the new KASP feature, I'm running in a issue,
where BIND isn't signing the zone anymore.
In the old fashion way (auto-dnssec maintain;), I was able - under some
circumstances - to remove the ".signed" and
On 27-10-2021 18:48, Alessandro Vesely wrote:
3. The server produces new .signed and .signed.jnl files every day,
which is inconvenient as the zone files directory is checked by
tripwire. Is that timing determined by the dnskey-ttl? Would it be
okay to set it to one month?
The zone is
Hi Allesandro,
Your policy has three keys:
keys {
ksk key-directory lifetime unlimited algorithm rsasha256 2048;
zsk key-directory lifetime unlimited algorithm rsasha256 2048;
csk key-directory lifetime unlimited algorithm rsasha256 2048;
};
Two of them require DS
on logging, on each run the keymgr will tell
you the reason why it cannot move the DS to the next state. Such logs
happen on DEBUG(1) level.
Best regards,
Matthijs
On 09-02-2022 17:35, Larry Rosenman wrote:
On 02/09/2022 9:52 am, Matthijs Mekking wrote:
Hi Larry,
Without more information
Hi Tom,
The lifetime is applied to new keys, so when the ZSK is rolled the
lifetime of the successor key should be 60 days.
I have considered applying it to existing keys as well (and maybe we
will some day), but there are a bunch of corner cases that make it
non-trivial, especially when
Hi Larry,
Without more information it is hard to tell what is going on.
Can you share your dnssec-policy and the contents of the key state file?
And if you have useful logs (grep for keymgr) that would be handy too to
see what is going on.
If you prefer to share them off list, you can mail
ighonker.lerctr.org named
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: dnssec says
no to KSK lerctr.org/RSASHA256/269 type DS state HIDDEN to state RUMOURED
ler in thebighonker in ~ via ☕ v1.8.0 via v5.32.1 via v2.7.5 as 慄
❯
On 02/10/2022 6:20 am, Matthijs Mekking wrote:
Hi
Rosenman wrote:
On 02/10/2022 10:10 am, Matthijs Mekking wrote:
Hi,
There are several things wrong here. The gist of it is that there is
no valid ZSK and since the zone is not properly signed, BIND does not
want to publish the DS record (even if outside BIND you already
published the DS).
You can
Hi,
On 10-04-2022 19:46, @lbutlr via bind-users wrote:
In the process of setting u a new domain I noticed that some existing domains
are logging and error into /var/log/messages
domain.tld.signed:120: signature has expired
Each domain that is expired shows the same :120
The lines in
Hi,
BIND 9.16 has dnssec-policy that makes algorithm rollover much easier. I
recommend you start using that.
Read more on migrating to dnssec-policy here:
https://kb.isc.org/docs/dnssec-key-and-signing-policy
Best regards,
Matthijs
On 06-04-2022 21:47, Danilo Godec via bind-users
Hi Niall,
On 14-04-2022 13:59, Niall O'Reilly wrote:
Hi.
Clue needed, please.
I’ve managed to migrate a number of zones from cron-driven signing
using homegrown scripts to automatic management by named, while
retaining the respective original KSK for each.
Following migration, ZSK:s have
Thank you for pointing it out.
In the future, you can create a gitlab issue for such things.
For this one I created one already:
https://gitlab.isc.org/isc-projects/bind9/-/issues/4417
Best regards,
Matthijs
On 11/4/23 17:04, Kurt Jaeger wrote:
Hi!
In
When your ZSK is safe to be retired depends on the state of the DS, so
without knowing the state of the KSK it is hard to say whether this
immediate removal of the old ZSK is legit or not.
Best regards,
Matthijs
On 10/20/23 01:46, Eddie Rowe wrote:
Thank you for your kind reply - BIND is
Hi,
Disabling inline-signing is a good workaround. The issue is that BIND
with inline-signing maintains a signed file separately and needs to bump
the SOA SERIAL.
The serial queried is for the DNSSEC signed zone, but the dynamic update
is done against the unsigned version of the zone. Hence
Hi,
To be precise, BIND updates the key files each keymgr run. But If the
keymgr waits for an event (rather than a duration), it will retry every
refresh key interval, which defaults to an hour.
You can check the logs for "next key event" to see when the keymgr is
scheduled next.
But yes,
t propagation delay time
to see the state switch to "omnipresent".
If there are multiple keys eligible you need to specify the key id with
"-key id".
Hope this helps, and if not, please let me know.
Best regards,
Matthijs
On 26-04-2022 10:50, Bjørn Mork wrote:
Matthijs Mekk
On 26-04-2022 14:25, Bjørn Mork wrote:
Matthijs Mekking writes:
What can you do to get it to "omnipresent"? Tell BIND that the DS is
in the parent (only do so if it is true of course). You can run
rndc dnssec -checkds published your.zone
And it should update the keyfile.
Nick,
On 27-05-2022 10:27, Nick Tait via bind-users wrote:
On 26/05/22 20:34, Matthijs Mekking wrote:
What version are you using? We had a bug with dnssec-policy and views
(#2463), but that has been fixed.
Since 9.16.18 you should not be able to set the same key-directory for
the same zone
Hi,
Sorry for not replying earlier (traveling).
Yes, I would recommend key separation (that is use a different
key-directory per view).
I am going to investigate your configuration more next week, to see if
there is a hidden bug.
Best regards,
Matthijs
On 26-05-2022 14:33, Sandro
Sandro,
What version are you using? We had a bug with dnssec-policy and views
(#2463), but that has been fixed.
Since 9.16.18 you should not be able to set the same key-directory for
the same zone in different views.
Matthijs
On 23-05-2022 16:12, Sandro wrote:
On 23-05-2022 15:48, Tony
Hello Mirsad,
You changed to dnssec-policy with different key algorithms than you used
for manual signing:
Jun 1 21:46:06 domac named[46537]: keymgr: retire DNSKEY
alu.hr/RSASHA256/46119 (ZSK)
Jun 1 21:46:06 domac named[46537]: keymgr: retire DNSKEY
alu.hr/RSASHA256/34042 (KSK)
Jun 1
Hi Nik,
On 16-05-2022 07:49, Nick Tait via bind-users wrote:
Hi there.
Ever since I updated my BIND configuration to use the new dnssec-policy
feature (a year or so ago) my KSK/CSK rollovers have been a complete
shambles. My problems stem from the inference (based documentation and
Hi Nick,
Thanks for bringing this to our attention. Yes, this is a copy paste
error. I think it can be removed, although we could change it because
you should make sure the address matches with what the parental agent
expects.
Best regards,
Matthijs
On 01-05-2022 07:18, Nick Tait via
Hi,
On 09-05-2022 10:16, Bjørn Mork wrote:
Michael Richardson via bind-users writes:
4) I don't understand the difference between "auto-dnssec maintain;"
and "dnssec-policy default" (given that I haven't overridden anything).
I believe the only difference is that the latter will track
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
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:
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
On 26-10-2022 20:21, PGNet Dev wrote:
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.
Hi,
On 21-10-2022 23:05, PGNet Dev wrote:
I exec
rndc dnssec -checkds -key 63917 published example.com IN external
with dnssec loglevel -> debug, on exec, in logs
2022-10-21T16:55:22.690603-04:00 ns named[36683]: 21-Oct-2022
16:55:22.689 dnssec: debug 1: keymgr: examine KSK
Hi Josef,
First of all I would like to point out the KB article about to
dnssec-policy, especially the part about migrating.
https://kb.isc.org/docs/dnssec-key-and-signing-policy
Although we try to asses the current signing situation, since there are
no key state files it will be an
Which parental-agent to use is up to you. Something you trust.
You can also configure multiple, if so then all parental agents will
perform the DS check and only if all parental agents agree (have seen
the DS), BIND will set the DS as "seen published in the parent" and the
rollover will
Hi,
This is a log level bug. This log happens when BIND want to check the
parental-agents if the DS has been published. But if you don't have
parental-agents set up, the list of keys to check will be empty. Hence
the "not found" result.
Thanks for reporting, this will be fixed in the next
Hi Magnus,
On 10-08-2022 11:13, Magnus Holmgren wrote:
Hi,
I migrated a couple of zones from BIND 9.16.6 on SuSE to 9.16.27 on Debian and
at the same time switched from auto-dnssec maintain to a dnssec-policy with
RSASHA256 instead of RSASHA1 (actually, I first applied a policy matching the
On 10-08-2022 11:21, Matthijs Mekking wrote:
The last zone, milltime.se, has become stuck. sudo rndc dnssec -status
reports
that the old keys are removed from the zone and the new keys are
omnipresent,
but the log says "zone milltime.se/IN (signed): Key
milltime.se/RSASHA1/22971
mi
Magnus,
On 11-08-2022 11:26, Magnus Holmgren wrote:
onsdag 10 augusti 2022 kl. 11:21:11 CEST skrev Matthijs Mekking:
On 10-08-2022 11:13, Magnus Holmgren wrote:
One question: Is it
necessary to use rndc dnssec -checkds or is that only meant as a backup,
and named is supposed to query
Hi Edwardo,
On 12/22/22 05:01, Edwardo Garcia wrote:
Hi,
I recently upgraded from 9.16 to latest version and changed a zone, ran
verisign test and it said all good, so changed my zones from auto
maintain dnssec to dnssec policy default, what a nightmare, most our
zones vanished few hours
On 12/22/22 16:23, Eric Germann wrote:
On Dec 22, 2022, at 09:32, Matthijs Mekking wrote:
I hope you have read our KB article on dnssec-policy before migrating:
https://kb.isc.org/v1/docs/en/dnssec-key-and-signing-policy
It should list the main pitfalls to save you a lot of hassle
;/ **/ ** / ** .db";
key-directory "/ ** / ** / ** .fr";
auto-dnssec maintain;
inline-signing yes;
};
am i rigth ?
Regards
Adrien
Le ven. 9 déc. 2022 à 09:33, Matthijs Mekking <mailto
'parental-agents' work the same as 'primaries'. It only supports addresses.
Listing them as domain names would technically be possible to implement,
but it requires an authoritative server to act as an resolver. Adding
resolver code to the path of an authoritative server is like crossing
the
Hi Adrien,
You should **not** copy the dnssec-policy configuration to your
secondaries. They transfer in the signed zone from the primary server.
Best regards,
Matthijs
On 12/9/22 09:24, adrien sipasseuth wrote:
Hello,
Lokking for some guidance, sorry if i use the wrong way to contact
v 21, 2022, at 3:29 AM, Matthijs Mekking wrote:
Hi,
It is hard to see what the problem is without any configuration or state
information. Also, log level debug 3 gives you probably more useful logs when
investigating a problem.
Can you share (privately if you wish) the key **state** files, and
Hi Mark,
On 24-11-2022 13:44, Mark Elkins via bind-users wrote:
OK - so I read RFC7344... Automating DNSSEC Delegation Trust Maintenance
There are two interesting paragraphs.
_/5. CDS/CDNSKEY Publication/_/
//
// The Child DNS Operator publishes CDS/CDNSKEY RRset(s). In order to//
//
Hi,
I think this should work with some caveats.
First, If you migrate to dnssec-policy (that is the zone is already
signed), make sure that the key properties match the current DNSKEYs.
Second is about your script:
> If the child looses a CDS record - my external script will remove the
>
Hi,
It is hard to see what the problem is without any configuration or state
information. Also, log level debug 3 gives you probably more useful logs
when investigating a problem.
Can you share (privately if you wish) the key **state** files, and the
output of 'rndc dnssec -status' for the
On 29-11-2022 00:39, vom513 wrote:
On Nov 28, 2022, at 3:12 PM, vom513 wrote:
Thanks for the reply and info…
I would have thought the CDS would be published before the key went
active. I.e. there would be a period of TWO DS’es at the parent
(I’m assuming the parent supports CDS/CDNSKEY
Done, thanks for reading and reporting.
Best regards,
Matthijs
On 17-11-2022 02:43, vom513 wrote:
ISC folks: can someone take a look at:
https://kb.isc.org/docs/dnssec-key-and-signing-policy
Seems one of the examples has a “-when” argument to rndc and the time is “1w”
rndc seems to want
Hi,
On 16-11-2022 18:53, vom513 wrote:
Hello,
I’m wanting to go ahead and look at migrating to dnssec-policy for my
zones. I currently use “auto-dnssec maintain” and “inline-signing
yes”. I also have a “stack” of ZSKs I made that all nicely overlap
with their various date settings. I think
Hi,
On 27-11-2022 23:32, vom513 wrote:
Hello all,
I’m still having a really hard time understanding and getting my
timings right. At least I think I am (from the way I’m reading the
status/logs/state files).
I let my current CSK get completely “omnipresent” for all it’s timers
(I’m not even
Hi Adrien,
Without any logs or key **state** files, I can't really tell what is
going on.
My only gut feeling is that you have never signaled BIND 9 that the DS
has been published. You can run 'rndc dnssec -checkds -key 12345
published example.com' or set up parental-agents to do it for
1 - 100 of 131 matches
Mail list logo
