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

[Ben Schwartz <[e-mail]>]

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