Testing KASP, CDS, and .ch

[Jim Popovitch]

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
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.