Testing KASP, CDS, and .ch
oli.schacher at switch.ch
Sat Apr 10 11:18:41 UTC 2021
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:
>> 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
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.
More information about the bind-users