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

[Ben Schwartz <[e-mail]>]

If anyone still wants changes to the -01 draft's text on Additional
section processing by the Authoritative server (
https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-01#section-4.1),
please reply.  Otherwise, I'll assume that Mark and Tony's logic has been
convincing, and we'll leave this as-is.

Personally, I think that text, which encourages Additional section
processing and provides a hint about what's worth including, is sufficient,
and we should be able to define improved answering strategies in a future
draft if necessary.

On Tue, Aug 11, 2020 at 9:31 PM Ben Schwartz <[e-mail]> wrote:

>
>
> On Tue, Aug 11, 2020 at 9:16 PM Mark Andrews <[e-mail]> wrote:
>
>>
>>
>> > On 12 Aug 2020, at 10:25, Ben Schwartz <bemasc=
>> [e-mail]> wrote:
>> >
>> > On Tue, Aug 11, 2020 at 6:18 PM Tony Finch <[e-mail]> wrote:
>> > Ben Schwartz <bemasc=[e-mail]> wrote:
>> > ...
>> > > 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.
>> >
>> > I thought the target types were just A, AAAA, SVCB, so where does the
>> SOA
>> > come from?
>> >
>> > If one of the follow-up queries for those types returns NODATA, there
>> could be an SOA in the Authority section.  "all returned records" includes
>> all sections, so it would be copied into the Additional section (in this
>> procedure).
>>
>> The negative caching of NODATA/NXDOMAIN indication is tied directly the
>> QNAME, QTYPE and rcode.  In the Additional section there is such linkage.
>> See RFC 2308.
>>
>> If I have "example.net SVBC 0 www.example.net” and “example.net SOA …”
>> what exactly does the SOA record mean?
>> There is no records at www.example.net?  There is no SVBC record at
>> www.example.net?  There is no A or AAAA record at www.example.net? There
>> is no CNAME at www.example.net?
>
>
> It means "I completed this defined procedure so anything that's missing
> doesn't exist".  The recipient doesn't even need to look at the SOA RDATA;
> it's just acting as a flag.  The recipient _does_ need to know about the
> procedure, but it's essentially the same as the recursive resolver followup
> procedure in the next section.
>
>
>>   What if one can’t fit some of these RRsets but can fit a SOA?
>>
>
> The proposal text says "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."
>
>
>> What happens when you know there isn’t a SVBC, have a A RRset and know
>> nothing about AAAA?  Do you add the SOA or leave it out?  If you add it
>> then what does it imply?
>>
>
> I think support for AAAA is probably a prerequisite for implementing this
> (optional) procedure.
>
>
>> If one wants to have negative answers, included in the additional section
>> then I would suggest defining a EDNS option the returns <SOA Record sans
>> class and rdlen><target name><rcode><typelist-if-nodata> for unsigned zones
>
>
> That seems like a fine solution to me, though it certainly would need a
> separate draft.
>
>
>> and NSEC/NSEC3 negative data proofs for signed zones and require clients
>> to be DNSSEC aware.  RFC 2308, while it doesn’t state it, only adds SOA
>> records so non-DNSSEC clients/non-DNSSEC zones will get a cacheable
>> response.  There is enough information in the NSEC/NSEC3 proofs to maintain
>> a negative cache entries if all clients where DNSSEC aware.
>>
>
> FWIW, draft-ietf-svcb-https-01 already recommends this.
>
>
>> > On Tue, Aug 11, 2020 at 6:38 PM Tony Finch <[e-mail]> wrote:
>> > ....
>> >
>> > > It seems to me that returning a (downward) delegation could actually
>> be
>> > > useful.  So why not include that?
>> >
>> > Additional section processing does not normally include referrals.
>> >
>> > Do you know why not?  It seems like a logical thing to include, if you
>> predict that the resolver will be making a followup query for which you
>> have a delegation.
>>
>>
>> > That
>> > would be weird and new. I thought the point of the SVCB record was to
>> > appear to existing auth and recursive DNS servers as much as possible
>> like
>> > a bog standard RR type, i.e. just wire and presentation format and a bit
>> > of normal additional section processing.
>> >
>> > Is there a standard for "normal additional section processing"?  My
>> impression is that it is RR-type-dependent, so defining what should go
>> there is in the purview of this draft.
>> >
>> > Which is basically what the draft
>> > says now, though it unnecessarily respecifies additional section
>> > processing.
>> >
>> > Yes, the intent is to work well with "normal additional section
>> processing", but Pieter and Brian requested some behaviors or
>> clarifications in this thread, related to CNAME and SOA records, that are
>> either unclear or not supported with "normal additional section
>> processing".  Hence this proposal, which would leave us in the following
>> position:
>> > * Auths are not required to do any additional section processing
>> > * Auths SHOULD do some kind of additional section processing, details
>> unspecified
>> > * Auths MAY do this specific form of additional section processing,
>> which follows CNAME chains, enables negative caching, and (maybe) even
>> provides referrals when appropriate.
>> >
>> > Do you think this proposal would not actually work?  Or do you think
>> that it is simply too inconvenient to implement?
>> >
>> > I would also like to hear Pieter's perspective, since the proposal is
>> based on his request in this thread.
>> >
>> >
>> > Tony.
>> > --
>> > f.anthony.n.finch  <[e-mail]>  http://dotat.at/
>> > Mull of Kintyre to Ardnamurchan Point: Variable, mainly north or
>> northwest, 2
>> > to 4, occasionally 5 near the Mull of Kintyre and Tiree. Slight,
>> occasionally
>> > smooth in shelter, becoming slight or moderate later. Fog patches
>> developing.
>> > Moderate or good, occasionally very poor.
>> > _______________________________________________
>> > DNSOP mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/dnsop
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: [phone] <+61%202%209871%204742>              INTERNET:
>> [e-mail]
>>
>>