Re: Still seeing some ALG-7 DNSSE
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 cleaned up automatically.
Excellent. Does that go in the zone record with default, or does it replace
default> I don't see the syntax in the release notes.
Or do I add a
dnssec-policy "default" {
purge-keys 30; // (or is that field seconds?)
}
Or will that mess up the predefined for default?
--
'There has to be enough light,' he panted, 'to see the darkness.'
___
Please 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: Testing KASP, CDS, and .ch
On Sat, 2021-04-10 at 13:18 +0200, Oli Schacher wrote: > Hi Jim > let me give you a bit more info > > > On April 9, 2021 8:23:48 PM UTC, Hugo Salgado wrote: > > > Switch has a website to test the CDS processing for .ch: > > > https://www.nic.ch/security/cds/ > > > > > > for domainmail.ch it says "The CDS configuration of the domain name > > > domainmail.ch will not be processed. > > > [ ... ] > > > The DNS query returned: "Server failed to complete the DNS request". > > > " > > It looks like until last night (when the last check ran), the domain was > BOGUS ( https://dnsviz.net/d/domainmail.ch/YHDacA/dnssec/ ) - so we > couldn't even fetch the CDS RRSET. RFC 8078 / 7344 can not be used to > fix a bogus domain, this needs to be fixed by updating the DS through > the registrar (which it seems you have done by now) To be clear, although this is the first time I've reached out to this list, I have had the DNSSEC correct on and off since it was registered on 2021-Jan-04. > The error message on our website in this case is indeed not very clear. > Eventually I hope to improve this once our resolvers support RFC8914 > extended dns errors which we could pass on to the frontend. +1 Thanks!! > On 4/9/21 9:11 PM, Jim Popovitch via bind-users wrote: > > > > What I can't figure out is how/when does .ch query the CDS/CDNSKEY data. > > > > > This process happens in two stages, once every 24 hours. > > In stage 1 (during the night), we scan all .CH and .LI domains for their > CDS RRSETS. > Domains which already have DS in parent are scanned through a validating > resolver. This is where domainmail.ch failed up until last night. > Domains which are currently insecure (=no DS in parent) are scanned over > TCP from multiple locations on every IP address of all nameservers > registered at the registry. > > In stage 2 (during the day) we process the domains with CDS records > found in stage1 and perform additional checks. If all checks pass, we > apply the requested change, i.e. the DS RRSET is changed to match the > published CDS RRSET. > Some restrictions are different if the domain already has a valid DS in > parent. For example, INSECURE domains need to provide a consistent CDS > RRSET on all their nameserver IPs for at least three consecutive days > before the DS RRSET is activated. Key Rollovers or going unsigned > happens immediately if the current CDS RRSET validates ok. The 3 day > delay initially also applied to Rollovers and Deletes, but we have > meanwhile lifted this restriction as it did not provide a security > benefit and caused operational issues(for example, changing Nameserver > operators) > Some other restrictions however apply in all cases, for example, the CDS > RRSET will not be processed if the resulting DS RRSET would break the > chain of trust. Thank you for that info. Something that most certainly contributed to my problems is that when I did my first rounds of testing, months ago, I had a dnssec-policy of 24 hours. At that time I didn't know about the 3-day rule, so I have definitely learned something, Thank you. -Jim P. ___ Please 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: Testing KASP, CDS, and .ch
Hi Jim let me give you a bit more info On April 9, 2021 8:23:48 PM UTC, Hugo Salgado wrote: Switch has a website to test the CDS processing for .ch: https://www.nic.ch/security/cds/ for domainmail.ch it says "The CDS configuration of the domain name domainmail.ch will not be processed. [ ... ] The DNS query returned: "Server failed to complete the DNS request". " It looks like until last night (when the last check ran), the domain was BOGUS ( https://dnsviz.net/d/domainmail.ch/YHDacA/dnssec/ ) - so we couldn't even fetch the CDS RRSET. RFC 8078 / 7344 can not be used to fix a bogus domain, this needs to be fixed by updating the DS through the registrar (which it seems you have done by now) The error message on our website in this case is indeed not very clear. Eventually I hope to improve this once our resolvers support RFC8914 extended dns errors which we could pass on to the frontend. On 4/9/21 9:11 PM, Jim Popovitch via bind-users wrote: What I can't figure out is how/when does .ch query the CDS/CDNSKEY data. This process happens in two stages, once every 24 hours. In stage 1 (during the night), we scan all .CH and .LI domains for their CDS RRSETS. Domains which already have DS in parent are scanned through a validating resolver. This is where domainmail.ch failed up until last night. Domains which are currently insecure (=no DS in parent) are scanned over TCP from multiple locations on every IP address of all nameservers registered at the registry. In stage 2 (during the day) we process the domains with CDS records found in stage1 and perform additional checks. If all checks pass, we apply the requested change, i.e. the DS RRSET is changed to match the published CDS RRSET. Some restrictions are different if the domain already has a valid DS in parent. For example, INSECURE domains need to provide a consistent CDS RRSET on all their nameserver IPs for at least three consecutive days before the DS RRSET is activated. Key Rollovers or going unsigned happens immediately if the current CDS RRSET validates ok. The 3 day delay initially also applied to Rollovers and Deletes, but we have meanwhile lifted this restriction as it did not provide a security benefit and caused operational issues(for example, changing Nameserver operators) Some other restrictions however apply in all cases, for example, the CDS RRSET will not be processed if the resulting DS RRSET would break the chain of trust. Best regards Oli ___ Please 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
