Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01

[Ben Schwartz <[e-mail]>]

On Tue, Aug 11, 2020 at 4:54 PM Tony Finch <[e-mail]> wrote:

> Ben Schwartz <[e-mail]> wrote:
> >
> > 1. If TargetName is not in-bailiwick and is not ".", terminate the
> procedure.
> > 2. If SvcPriority is 0:
> >     * If TargetName is ".", terminate the procedure.
> >     * Otherwise, perform a SVCB "follow-up" query for TargetName and add
> all
> >       returned records, including any records added by this procedure.
> >       If any SVCB records were added, terminate.
> > 3. Perform A and AAAA follow-up queries for TargetName (or for the owner
> name if
> >    TargetName is "."), and add all returned records.
>
> I think the actual wording you want here is "in the same zone" not "in
> bailiwick".
>
...

Thanks, I will make that correction.

...

> > If the server does not complete this procedure (e.g. due to response size
> > limits), it MUST remove any SOA records from the Additional section.
> > Recursive resolvers MAY use the presence of an SOA record in the
> Additional
> > section to enable negative caching of the follow-up queries, as in
> > {{?RFC2308}}.
>
> I'm not sure I understand this paragraph. Truncation is normally from the
> end of the additional section backwards, so it is really weird to drop
> records from the authority section first. SOA (start of authority) records
> go in the authority section not the additional section


In this procedure, "all returned records" for follow-up queries are added
to the Additional section.  Therefore, there could be SOA records in the
Additional section.  (However, I _don't_ think there could be SOA records
in both the Additional and the Authority sections at the same time.)

We could remove this requirement when TC=1.

- the authority
> section is all about gossiping zone cuts (i.e. SOA records) and nameserver
> records. I don't understand how negative cacheing is relevant to a
> positive response for a SVCB query.
>

Resolvers are recommended to perform several followup queries when
resolving SVCB records (Section 4.2).  If those records don't exist, it
would be nice to be able to inform the resolver of this so it can skip
them, as Pieter highlighted earlier in the thread.

The DNS doesn't allow a client to know that additional data doesn't exist
> when it is omitted from a response. It sucks, but that's the way it is.
>

Yes; this proposal would change that in this case.  If you think it won't
work, I'd love to know why.

(This is why most SMTP software doesn't actually use the additional
> section in MX responses.) You could in theory put a DNSSEC proof of
> nonexistence in the additional section, but I don't know of any software
> that will make intelligent use of it.
>

Similarly, this proposal would indeed put the proof of nonexistence there.
(The -01 draft already contains this instruction.)

Tony.
> --
> f.anthony.n.finch  <[e-mail]>  http://dotat.at/
> Southeast Iceland: Southeasterly veering southwesterly 3 to 5. Slight or
> moderate. Fog patches, rain at times. Moderate or good, occasionally very
> poor.
>