Re: managed-keys-zone: Failed to create fetch for DNSKEY update
On 2022 Apr 12, at 18:25, @lbutlr wrote:
>
> My secondary DNS server (bind916-9-16-27) is reporting:
>
> managed-keys-zone: Failed to create fetch for DNSKEY update
Named.conf relevant settings (I think) are:
recursion yes;
allow-query { any; };
allow-recursion { 127.0.0.1; ; };
listen-on { ; 127.0.0.1; };
forwarders { ; };
forward first;
Dig @localhost returns:
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23697
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
--
If you must choose between two evils, pick the one you've never tried
before.
--
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: How to prevent gratuitous publication of CDS/CDNSKEY records
On 14 Apr 2022, at 13:22, Matthijs Mekking wrote: these records may also stay in the zone. BIND chooses to keep them in the zone Thanks, Matthijs. That fills the gap for me. Niall -- 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
Why did my DNS bill go up?
Greetings, all. I had a surprise on the bill from my secondary DNS provider after I turned on DNSSEC. The number of record queries on my domains increased by a factor of about 5, compared to the number of record queries when I didn't have DNSSEC. Is this normal for DNSSEC? It's been a consistent significantly higher query level since deploying DNSSEC 3 months ago on 2 small domains (total of 120 records across the two domains), and it was 57 new RRSIG, DNSKEY, and NSEC3PARAM records added the domains for the DNSSEC. The average number of attacks per day on my webserver (according to the server logs) does not appear to have increased since the DNSSEC deployment. This is for the ka2ddo.org and ka2ddo.radio domains. So, is DNSSEC really that much more costly in terms of queries? Andrew Pavlin -- 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: How to prevent gratuitous publication of CDS/CDNSKEY records
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 been replaced as might be expected,
since the keys were shorter than is nowadays recommended.
The old ZSK files are still lingering in the key-directory.
Keys will be purged after the 'purge-keys' interval, which by default is
90 days after they have been removed from the zone.
I’m seeing that fresh CDS and CDNSKEY are being generated, and
wonder why, as the CDS RDATA matches the parent CD RDATA. I’ve
deleted these using nsupdate, only to find them re-inserted
some time later.
If you use dnssec-policy, you leave the DNSSEC signing to BIND. It
inserts CDS and CDNSKEY records of the keys that require a DS in the parent.
Note that those records may be removed once the parent has the
corresponding DS published, but these records may also stay in the zone.
BIND chooses to keep them in the zone, so that it is clear which DS is
expected at the parent from the child zone's perspective.
Could it be significant that the parent DS TTL differs from that
of the local CDS?
No.
Best regards,
Matthijs
One of the zones involved is foo.ie.
The server is running BIND 9.16.27-Ubuntu, installed from ppa:isc/bind.
Here below is the relevant dnssec-policy configuration fragment.
|dnssec-policy persistent { // This policy attempts to match or
accommodate what zonefactory did // and gives keys unrestricted lifetime
dnskey-ttl 3600; keys { ksk lifetime unlimited algorithm rsasha256; zsk
lifetime unlimited algorithm rsasha256; }; max-zone-ttl 3600;
parent-ds-ttl 86400; parent-propagation-delay 48h; publish-safety 7d;
retire-safety 7d; signatures-refresh 5d; signatures-validity 30d;
signatures-validity-dnskey 30d; zone-propagation-delay 2h; }; |
Thanks in anticipation.
Niall
--
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
How to prevent gratuitous publication of CDS/CDNSKEY records
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 been replaced as might be expected,
since the keys were shorter than is nowadays recommended.
The old ZSK files are still lingering in the key-directory.
I’m seeing that fresh CDS and CDNSKEY are being generated, and
wonder why, as the CDS RDATA matches the parent CD RDATA. I’ve
deleted these using nsupdate, only to find them re-inserted
some time later.
Could it be significant that the parent DS TTL differs from that
of the local CDS?
One of the zones involved is foo.ie.
The server is running BIND 9.16.27-Ubuntu, installed from ppa:isc/bind.
Here below is the relevant dnssec-policy configuration fragment.
```
dnssec-policy persistent {
// This policy attempts to match or accommodate what zonefactory did
// and gives keys unrestricted lifetime
dnskey-ttl 3600;
keys {
ksk lifetime unlimited algorithm rsasha256;
zsk lifetime unlimited algorithm rsasha256;
};
max-zone-ttl 3600;
parent-ds-ttl 86400;
parent-propagation-delay 48h;
publish-safety 7d;
retire-safety 7d;
signatures-refresh 5d;
signatures-validity 30d;
signatures-validity-dnskey 30d;
zone-propagation-delay 2h;
};
```
Thanks in anticipation.
Niall
--
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
