Re: [dnssd] Intended behavior for eliding KEY record in DNS query response? (draft-ietf-dnssd-srp)

[Ted Lemon <[e-mail]>]

I made a small adjustment to the document. I think it was already fairly
clear, but I added: "To avoid DNSSEC validation failures, an SRP registrar
that signs the zone for DNSSEC but refuses to return a KEY record
MUST NOT store the KEY record in the zone itself."

"No data" is a well-understood term in DNS, so I think it's okay to use it
here.

"signs the zone" is referring to DNSSEC. I added "for DNSSEC" above to make
that clear.

Replacing the key contents with a dummy value is probably also a valid
approach, but why specify two different ways to do the same thing? The
dummy key value would have to be included in the DNSSEC signature, so it's
just a more complicated way to solve the same problem.

You are correct about "server" versus "registrar"—thanks for noticing that!

On Thu, Aug 24, 2023 at 4:11 AM Esko Dijk <[e-mail]>
wrote:

> > I've updated the text to say:
>
> >
>
> > To avoid DNSSEC validation failures, an SRP server that refuses to
> return a KEY record MUST NOT store the
> > KEY record in the zone itself. Because the key record isn't in the zone,
> the nonexistance of the KEY record can be
> > validated. If the zone is not signed, the server MAY instead return a
> negative non-error response (either NXDOMAIN or
> > no data).
>
>
>
> Thanks; at first glance this seemed ok for me. However today I have
> trouble understanding the requirement.
>
>
>
>    - Is the “MUST NOT” condition always applicable?  Or only if the SRP
>    Registrar keeps a “zone that is not signed” i.e. conditional.
>       - If the MUST NOT is conditional then maybe the text should be
>       rephrased to make this clear.
>       - I.e. it seems ok to store the KEY record in the zone and delete
>       that KEY record from any query answer, as long as the SRP Registrar doesn’t
>       apply DNSSEC security for its zone.
>    - What is the “SRP server” ? Should this be “SRP Registrar”?
>       - See also other references to “SRP server” in the document.
>    - “no data” is kind of cryptic – should we just say “NOERROR with zero
>    answer records” ?
>    - What does it mean for a “zone to be not signed” ?  (I’m probably
>    missing some DNS background here. In my mind, SRP updates can be signed but
>    not an entire zone.)
>    - A related question that came is why not just replace the KEY record
>    contents by a dummy value (e.g. 0x0) if the purpose is to hide the contents
>    of the KEY record only.
>
>
>
>
>
> Regards
>
> Esko
>
>
>
>
>
> *From:* Ted Lemon <[e-mail]>
> *Sent:* Friday, July 7, 2023 21:15
> *To:* Esko Dijk <[e-mail]>; dnssd <[e-mail]>
> *Subject:* Re: [dnssd] Intended behavior for eliding KEY record in DNS
> query response? (draft-ietf-dnssd-srp)
>
>
>
> I've updated the text to say:
>
>
>
> To avoid DNSSEC validation failures, an SRP server that refuses to return
> a KEY record MUST NOT store the
> KEY record in the zone itself. Because the key record isn't in the zone,
> the nonexistance of the KEY record can be
> validated. If the zone is not signed, the server MAY instead return a
> negative non-error response (either NXDOMAIN or
> no data).
>
>
>
> On Wed, Jul 5, 2023 at 11:03 AM Ted Lemon <[e-mail]> wrote:
>
> Op wo 5 jul 2023 om 03:06 schreef Esko Dijk <[e-mail]>
>
> The “why” is maybe not so relevant – if something is optional in a spec to
> NOT do, implementers will jump on it by NOT doing the thing. They even
> don’t implement RECOMMENDED functions in my experience ;-)
>
> For the testers, it means they have to test for the possible variants and
> need to know what to test against.  Right now as specified there’s 3 cases
> possible: 1) return KEY ; 2) return RCODE=0; 3) return RCODE=5 .
>
>
>
> Okay, that makes sense. This is a pretty late clarification. Chairs, do
> you object to me including this in the forthcoming update?
>
>