Hi!!
Don't really know if it could help, but I generate the ZSK keys this way
:
/usr/local/sbin/dnssec-keygen -3 -a 8 -b 1024 -P now -A now -I +45d -D
+47d _
Cheers!!
El 2022-01-25 02:48, Mark Andrews escribió:
> On 25 Jan 2022, at 11:55, ego...@ramattack.net wrote:
>
> Hi
Hi Mark!!!
Thanks again!!!. Very very thankful really. Please allow me to answer
you something more as we found a guru here :) :)
But then Mark, what does a key deletion time of a key mean?. I
understood that when the deletion time was overtaken in a ZSK, the key
dissapeared from the DNSKEY
> On 25 Jan 2022, at 11:55, ego...@ramattack.net wrote:
>
> Hi Mark!!
>
>
>
> Thank you so much for your answer!! and your time!!.
>
>
>
> I have a couple of questions. I ask them between your lines and in blue for
> instance... for emphasizing and being easier to see what I'm referring
Hi Mark!!
Thank you so much for your answer!! and your time!!.
I have a couple of questions. I ask them between your lines and in blue
for instance... for emphasizing and being easier to see what I'm
referring to. I'm talking about ZSK keys in the questions I am asking in
blue.
El 2022-01-25
How ‘named’ manages DNSSEC is very different to how 'dnssec-signzone' manages
DNSSEC. When you tell named to
inactivate a DNSKEY it stops re-signing the zone with it and it stops signing
new records added to the zone
with it. It DOES NOT immediately replace all RRSIGs generated using that
> On 25 Jan 2022, at 07:35, Mark Elkins wrote:
>
> I've just noticed that in the last few days that "BIND 9.16.22 (Extended
> Support Version) " appears to be generating CDS records for both
> KSK ***and ZSK*** records!
>
> Nothing on my side has been changed although I do run automated
I've just noticed that in the last few days that "BIND 9.16.22 (Extended
Support Version) " appears to be generating CDS records for
both KSK ***and ZSK*** records!
Nothing on my side has been changed although I do run automated updates.
I'm on a Linux machine running Gentoo.
$ dig DNSKEY
Hi!!
Thanks a lot for your answer!!
I tried before the fact of renaming back and rndc sign... but does not
work just has removed the error from the log
I have changed my key managing code, for not renaming to "-OLD" the ZSK
(.key and .private) until have passed at least 2 days from
egoitz--- via bind-users wrote:
>
> These are the contents of a cat of the private file I have renamed to
> samename.private-OLD :
>
> Created: 20211031230338
> Publish: 2020220241
> Activate: 2020220341
> Inactive: 20211215230338
> Delete: 20211217230338
Yes, it can be confusing when
Hi!
In the "Bump in wire" dns machine, have finally ended up by fixing the
errors. For that purpose I have done a :
In the directory of the zone file :
- rename the own zonefile to zonefile-NO
- rename the zonefile.jbk to zonefile.jbk-NO
- rename the zonefile.jnl to zonefile.jnl-NO
-
If you return the -OLD files to it's before name (without -OLD) and you
make changes to the zone or perform rndc loadkeys of the zone, error
dissapear but still the DNSKEY become outdated
Any ideas mates?
El 2022-01-24 16:12, ego...@ramattack.net escribió:
> I think the problem is that if
I think the problem is that if you do a :
dig +multi @dnssecserver thedomain.thetld dnskey +dnssec | grep 44526
You then see still that key id exists in DNSKEY records (and an RRSIG of
that ZSK, the 44526, but outdated).
But I don't really understand why because you see the delete date
Thanks Havard.
Appreciate the candor. This was my understanding given the articles and
documentation that I reviewed.
Dan
-Original Message-
From: Havard Eidnes
Sent: Monday, January 24, 2022 10:13 AM
To: LeBlanc, Daniel James
Cc: bind-users@lists.isc.org
Subject: [EXT]Re: Response
> I am trying to create an NXDOMAIN response-policy for the
> following example domain:
>
> x.yy.*.*.dns.*
>
> I have reviewed RFC1034 & RFC4592 and many online articles and
> blog postings, but thus far have not found anything suggesting
> that this type of match is possible. Am I expecting too
In fact... in a domain for whom I have seen these errors, it's arguing
about key id 44526 (it's private file) saying "File not found". But if I
perform an axfr request of the signed zone with pipe grep the key id, no
matches appear... so should not exist rrsigs for that key
These are the
Hi Klaus,
Thank you so much for your answer but when Bind deletes a key from a
zone, if I remember correctly, there should not be any rrsig still
active, signed previously by the deleted key. Isn't it?. So I assume in
that case, I should be doing it properly but still see these messages.
Am I
IIRC, Bind needs the key as long as there are signatures in the zone generated
by this key. After key deactivation I waited the RRSIG lifetime before deleting
them.
regards
Klaus
Von: bind-users Im Auftrag von egoitz--- via
bind-users
Gesendet: Montag, 24. Jänner 2022 13:00
An:
Good morning,
I have a DNSSEC "bump in wire" server, which uses "inline-signing yes;"
and "auto-dnssec maintain;" for that reason.
I do the task of ensuring always are valid keys in the zone with an
script that generates them whenever is needed. All fine until here and
all working.
I have
(Also sending to bind-users as bind-workers is scheduled to be shutdown.)
>>> If I start named, then (without changing named.conf) do "rndc reconfig"
>>> and then send named a DoT query (dig +tls or kdig +tls) named dies with
>>>
>>> Jan 11 13:45:53 dns named[78236]: netmgr/tlsdns.c:1517: fatal
19 matches
Mail list logo
