Re: dnssec-policy - KSK rollover
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
> corresponding DS record from the parent.
This is true for BIND 9, as it will publish the CDS for as long as the
DS should be in the parent. But it doesn't have to be the case. The RFC
(7344) says:
When the Parent DS is in sync with the CDS/CDNSKEY
RRset(s), the Child DNS Operator MAY delete the CDS/CDNSKEY RRset(s);
the Child can determine if this is the case by querying for DS
records in the Parent.
Personally I like to keep the CDS in the child zone, so you can see if
the parent is in sync, that is why I implemented it in BIND 9 to keep
the CDS.
Best regards,
Matthijs
On 23-11-2022 18:24, Mark Elkins via bind-users wrote:
Hi people,
I have read https://kb.isc.org/docs/dnssec-key-and-signing-policy
I have put the following policy in my named.conf file:-
dnssec-policy "ecdsa256-policy" {
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;
dnskey-ttl 3600;
publish-safety 1h;
retire-safety 1h;
purge-keys 10d;
keys {
ksk lifetime 370d algorithm ecdsa256; // < this part in
particular!
zsk lifetime 34d algorithm ecdsa256;
};
zone-propagation-delay 300s;
max-zone-ttl 86400s;
parent-propagation-delay 1h;
parent-ds-ttl 3600;
};
I also have some external code that goes trawling for CDS records and
puts into a parent whatever it finds in the child - that in this case is
signed with the above policy stanza.
If the child creates a new CDS - my external scripts will find it and
pop it into the parent as a DS record.
If the child looses a CDS record - my external script will remove the
corresponding DS record from the parent.
Basically - whatever is in the child as a CDS will be in the parent as a DS.
A null CDS removes all DS records - but that's not my question.
Is there anything else I need to do? Any additional rndc's ??
--
Mark James ELKINS - Posix Systems - (South) Africa
m...@posix.co.za Tel: +27.826010496
--
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
dnssec-policy - KSK rollover
Hi people,
I have read https://kb.isc.org/docs/dnssec-key-and-signing-policy
I have put the following policy in my named.conf file:-
dnssec-policy "ecdsa256-policy" {
signatures-refresh 5d;
signatures-validity 14d;
signatures-validity-dnskey 14d;
dnskey-ttl 3600;
publish-safety 1h;
retire-safety 1h;
purge-keys 10d;
keys {
ksk lifetime 370d algorithm ecdsa256; // < this part in
particular!
zsk lifetime 34d algorithm ecdsa256;
};
zone-propagation-delay 300s;
max-zone-ttl 86400s;
parent-propagation-delay 1h;
parent-ds-ttl 3600;
};
I also have some external code that goes trawling for CDS records and
puts into a parent whatever it finds in the child - that in this case is
signed with the above policy stanza.
If the child creates a new CDS - my external scripts will find it and
pop it into the parent as a DS record.
If the child looses a CDS record - my external script will remove the
corresponding DS record from the parent.
Basically - whatever is in the child as a CDS will be in the parent as a DS.
A null CDS removes all DS records - but that's not my question.
Is there anything else I need to do? Any additional rndc's ??
--
Mark James ELKINS - Posix Systems - (South) Africa
m...@posix.co.za Tel: +27.826010496
--
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
Documentation suggestion for Ubuntu PPA http://ppa.launchpad.net/isc/bind/ubuntu
Hi. With "APT-Sources: http://ppa.launchpad.net/isc/bind/ubuntu focal/main amd64 Packages", the file /usr/share/doc/bind9/README.Debian recommends: Zones subject to automatic updates (such as via DHCP and/or nsupdate) should be stored in /var/lib/bind, and specified with full pathnames. Do I understand correctly that this advice also applies to zones for which a dnssec-policy and inline-signing (rather than update-policy) are specified? If so, it might be well to extend the parenthesis "(such as ...)" to mention this case also. Best regards, Niall O'Reilly -- 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: Dnstap CLIENT_RESPONSE and query time information
> On 23 Nov 2022, at 10:09, Borja Marcos wrote: > > Hi, > > I am working on some DNS monitoring using Dnstap. I have noticed that RR > messages include > *both* the query time and response time but, despite being recommended on the > Protobuf > specification (I know, it’s just a recommendation!) the CR messages do not > include it. > > Is there any particular reason for it? Looking at lib/dnstap.c, there is a > switch clause which > especifically prevents Dnstap message types other than RR and FR from > obtaining > a query time. I made a simple modification to dnstap.c (line 816, so that it allows CR messages to obtain the query timestamp and it works, the query time (qtime) is already passed to dns_dt_send(). I have tried with 9.18.9 for now. Cheers, Borja. -- 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
Dnstap CLIENT_RESPONSE and query time information
Hi, I am working on some DNS monitoring using Dnstap. I have noticed that RR messages include *both* the query time and response time but, despite being recommended on the Protobuf specification (I know, it’s just a recommendation!) the CR messages do not include it. Is there any particular reason for it? Looking at lib/dnstap.c, there is a switch clause which especifically prevents Dnstap message types other than RR and FR from obtaining a query time. It would be really useful to have that information available. But I am not sure whether there is any particular reason not to include it. Maybe avoiding an additional system call? Thanks! Borja. -- 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
