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 <hsalg...@nic.cl> 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