Testing KASP, CDS, and .ch

Oli Schacher oli.schacher at switch.ch
Sat Apr 10 11:18:41 UTC 2021


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)

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


More information about the bind-users mailing list