[dconn] Re: 6.4. Public Key Publication clarification

[Sami Kerola <[e-mail]>]

On Wed, 11 Mar 2026 at 15:50, Pawel Kowalik
<kowalik=[e-mail]> wrote:
> answers inline after [PK].

Hi Pawel,

Likewise, always inline. Old-fashioned email etiquette is the best.

> On 11.03.26 10:17, Sami Kerola wrote:
> > While working on the DNS provider side of the business I started
> > checking if the synchronous public key flow works correctly here in
> > Cloudflare. Here is link to the section I am talking about.
> >
> > https://www.ietf.org/archive/id/draft-ietf-dconn-domainconnect-01.html#section-6.4
> >
> > Technically a Service Provider could publish:
> >
> > _key.dc.example.com. 300 IN TXT "p=1,a=RS256,d=MIIBI..."
> > _key.dc.example.com. 300 IN TXT "p=2,a=RS256,d=..."
> > _key.dc.example.com. 300 IN TXT "p=1,a=RS512,d=MIIBI..."
> > _key.dc.example.com. 300 IN TXT "p=2,a=RS512,d=..."
> >
> > And that does not violate the current draft. But I doubt DNS Providers
> > commonly expect a single resource containing multiple keys separated
> > by different algorithms. Perhaps the specification should clarify that
> > a single resource MUST NOT mix multiple algorithms.
>
> [PK] The intention was clearly to never publish more than one key on the
> same "key" label.

That is what I assumed, but I did not want to leave this open to interpretation.

> The current text:
> To allow for key rotation or use of multiple keys, the Service Provider
> MAY publish key records at multiple hosts within "syncPubKeyDomain". The
> "key" apply parameter identifies which host to query for each request
> and MUST be included in the signed apply request.
>
> I propose to add:
>
> Service Provider MUST NOT publish more than one key on the same host name.

I favour one hostname, one key.

> > In practise key
> > publishing would then look something like this:
> >
> > _rs256.dc.example.com. 300 IN TXT "p=1,a=RS256,d=MIIBI..."
> > _rs256.dc.example.com. 300 IN TXT "p=2,a=RS256,d=..."
> > _rs512.dc.example.com. 300 IN TXT "p=1,a=RS512,d=MIIBI..."
> > _rs512.dc.example.com. 300 IN TXT "p=2,a=RS512,d=..."
> >
> > When the Service Provider generates a validation hash the algorithm
> > used is known, so it should not be too much to require to the related
> > pubkey resource to the downstream DNS Provider. I think that makes
> > sense, any thoughs?
> >
> [PK]  Yes. This is controlled with "key" parameter and shall be set
> according to the key in use.
>
> There is also an aspect of "a" and "d" parameters for key fragments.
> Theoretically it's not necessary to repeat them for fragment other than
> 1 (p=1), but for now the draft tells that they must be equal for all
> fragments (repeated) for consistency.

Sounds good. I will try to make the debug tool work according to the
text above.

https://pkg.go.dev/github.com/kerolasa/dc-debug-pubkey

And there are a couple of bits I need to flip & fiddle with the Cloudflare
Domain Connect implementation, but that's closed source so I'm not
going to comment further on what's up with it.

Yours, Sami

-- 
Sami Kerola
https://kerolasa.iki.fi/