Testing KASP, CDS, and .ch
jimpop at domainmail.org
Sat Apr 10 11:42:12 UTC 2021
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 <hsalgado at 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
> 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
> 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.
More information about the bind-users