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

From: Pieter Lexis <[email-masked]>
Date: Wed, 5 Aug 2020 18:05:39 +0200

Hi folks,

Section 2.4.1 says

```
The primary purpose of AliasMode is to allow aliasing at the zone apex,
where CNAME is not allowed. In AliasMode, TargetName MUST be the name of
a domain that has SVCB, AAAA, or A records.
```

and section 4.1 says

```
When replying to a SVCB query, authoritative DNS servers SHOULD return
A, AAAA, and SVCB records in the Additional Section for any in-bailiwick
TargetNames.
```

Does this mean that the processing differs from 'regular' in-zone CNAME
processing? Where I define this processing as "look for the Target name
with the type from the query and use that result's status as query result".

Considering this zone (abbreviated):

```
svcb-alias.example.net SVCB 0 alias-target.example.net
alias-target.example.net A 192.0.2.1
```

What would be the correct response to a svcb-alias.example.net|SVCB query?

```
;; QUESTION SECTION:
;svcb-alias.example.net.		IN	SVBC

;; ANSWER SECTION:
svcb-alias.example.net.	3600	IN	SVBC    3600  0 alias-target.example.net
example.net.	IN	SOA	3600	[....]

;; ADDITIONAL SECTION:
alias-target.example.net. 3600	IN	A	192.0.2.1

```

or

```
;; QUESTION SECTION:
;svcb-alias.example.net.		IN	SVBC

;; ANSWER SECTION:
svcb-alias.example.net.	3600	IN	SVBC    3600  0 alias-target.example.net

;; ADDITIONAL SECTION:
alias-target.example.net. 3600	IN	A	192.0.2.1

```

With the former, implementers would be be able to reuse the existing
aliasing code paths. With the latter, changes will have to be made to
the codepath as the AliasMode is not a 'true' alias as CNAME is.

In the same vein, what happens in a zone like this (with the same
incoming query for svcb-alias.example.net|SVCB):

```
svcb-alias.example.net SVCB 0 alias-target1.example.net
alias-target1.example.net SVCB 0 alias-target2.example.net
alias-target2.example.net SVCB 1 . ipv4hint=192.0.2.1

alias-target2.example.net A 192.0.2.1
```

Do *both* alias-target{1,2}.example.net|SVBC records end up in the
ADDITIONAL section. Or are they (as is the case with an in-zone CNAME)
considered an answer and should they go into the ANSWER section?

I find the alias mode semantics (on the DNS-level) unclear and
under-specified in the draft. I look forward to guidance from the authors.

Best regards,

Pieter

-- 
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 5 Aug 2020 13:07:51 -0400

On Wed, Aug 5, 2020 at 12:06 PM Pieter Lexis <[email-masked]>
wrote:
...

> considered an answer and should they go into the ANSWER section?

I think Section 4.1 is pretty clear that everything goes in the Additional
section.  (But this can be changed!)

> under-specified in the draft. I look forward to guidance from the authors.

And I look forward to guidance from you!  How do you think it should work?
Send text!

Personally, I'd like to know which of these questions actually need to be
resolved in the standard, and which can safely be left to the discretion of
implementors.  Is there a compatibility concern with any of these
questions, or is it only a question of consistency across implementations?

Conceptually, AliasMode is not a CNAME: it only affects SVCB queries (not
other RR types), and can safely be implemented entirely as an RFC 3597
Unknown RR Type.  That suggests that it is at least safe, and perhaps
least-surprising, for the authoritative server to put all responses for
other owner names in the Additional section, as the current text seems to
indicate fairly clearly.

P.S. The text on this point has recently changed:
https://github.com/MikeBishop/dns-alt-svc/pull/199#discussion_r444979971.
One of the questions there is what should happen for
AliasMode->CNAME->ServiceMode->AAAA, all in-bailiwick.  The draft says
"Clients and recursive resolvers MUST follow CNAMEs as normal.", but it no
longer says anything about authoritatives.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 5 Aug 2020 11:03:01 -0700

On Wed, Aug 5, 2020 at 10:08 AM Ben Schwartz <bemasc=
[email-masked]> wrote:

> And I look forward to guidance from you!  How do you think it should
> work?  Send text!
>

Both, actually, since bad coding practices abound. It is not unheard of for
implementers to work off of results they get from other implementations,
and assume that is the only variation they will get.
Consistency across implementations thus ends up being really important for
interoperability.
It's not how it should be, of course.
But, clear and concise RFCs lead to the best possible outcomes.

> other owner names in the Additional section, as the current text seems to

I beg to differ, in that I would view AliasMode as a constrained CNAME.

The Unknown Type logic is why the in-bailiwick stuff is SHOULD rather than
MUST (and that's the right rule to use).

What I would suggest is the following, paraphrased (i.e. please clean it up
before using in the I-D, if you agree it's the right semantics):

   - In-bailiwick CNAME, SVCB, A, and AAAA records SHOULD be added (and for
   CNAME and SVCB, in-bailiwick RDATA for those SHOULD also be iteratively
   processed for inclusion)
   - CNAME and SVCB records MUST be placed in the Answer section (because
   of existing CNAME rules and because of RRTYPE match to the query)
   - A and AAAA records MUST be placed in the Additional section (since
   those would not match the query RRTYPE of SVCB)

(I am not sure of the question/issue of including the SOA, or where that
would go, but I'll defer to anyone who knows or has an opinion. My gut
says, do whatever gets done for CNAME.)

All the in-bailiwick stuff is essentially an optimization. Authority
servers may not implement that, and would still be compliant if they did
not.
Resolvers MUST be prepared to handle the non-inclusion of in-bailiwick
stuff from authority servers, as this would not be an error or violation of
the (eventual) RFC.

>
> P..S. The text on this point has recently changed:
IMHO, I think this is correct, or at least consistent with what I wrote
above. (If there are any inconsistencies, could you highlight what those
would be, please?)

Brian

---

From: Pieter Lexis <[email-masked]>
Date: Wed, 5 Aug 2020 20:51:37 +0200

On 8/5/20 8:03 PM, Brian Dickson wrote:
>
>
> On Wed, Aug 5, 2020 at 10:08 AM Ben Schwartz
> <bemasc=[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Wed, Aug 5, 2020 at 12:06 PM Pieter Lexis
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     ...
>
>     Conceptually, AliasMode is not a CNAME: it only affects SVCB queries
>     (not other RR types), and can safely be implemented entirely as an
>     RFC 3597 Unknown RR Type.  That suggests that it is at least safe,
>     and perhaps least-surprising, for the authoritative server to put
>     all responses for other owner names in the Additional section, as
>     the current text seems to indicate fairly clearly.
>
>

I agree with Brian here. Compliant DNS servers (be it auth or recursor)
 MUST treat an Alias-mode SVCB (or derived) record as a CNAME for the
purposes of processing that SVCB or derived record.

i.e. foo.example.com SVCB 0 srv1.example.net == (logically)
foo.example.com CNAME srv1.example.com when QType = SVCB, but not for
any other QType.

> What I would suggest is the following, paraphrased (i.e. please clean it
> up before using in the I-D, if you agree it's the right semantics):
>
>   * In-bailiwick CNAME, SVCB, A, and AAAA records SHOULD be added (and
>     for CNAME and SVCB, in-bailiwick RDATA for those SHOULD also be
>     iteratively processed for inclusion)
>   * CNAME and SVCB records MUST be placed in the Answer section (because
>   * A and AAAA records MUST be placed in the Additional section (since

+1 to this summary. It reflects how I see the semantics of alias mode as
well.

> says, do whatever gets done for CNAME.)

The SOA MUST go in the packet. As a compliant resolver talking to an
auth that does not implement SVCB will follow the chain and the auth
will respond with NODATA (and thus the SOA).

After reading section 4.2, I also think that a resolver that implements
this MUST include the SOA as well if the final target has no SVCB
record, to indicate that the answer to the actual question
(example.com|SVCB) yielded NODATA after alias chaining. A compliant
client can ignore the fact that the DNS says NODATA and use the A/AAAA
records from the ADDITIONAL section (or send a query for them based on
the final target).

> stuff from authority servers, as this would not be an error or violation
> of the (eventual) RFC.

Yes.

>     AliasMode->CNAME->ServiceMode->AAAA, all in-bailiwick.  The draft
>     says "Clients and recursive resolvers MUST follow CNAMEs as
>     normal.", but it no longer says anything about authoritatives.
>
>

I believe you are correct.

Cheers,

Pieter

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 5 Aug 2020 15:06:06 -0400

Thanks for the review!  I'd appreciate it if other authoritative server
implementors could comment on this proposal.  If they agree then I'm happy
to make this change.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 6 Aug 2020 07:00:28 +1000

> On 6 Aug 2020, at 02:05, Pieter Lexis <[email-masked]> wrote:
> 
> Hi folks,
> 
> Section 2.4.1 says
> 
> ```

The second.

> the codepath as the AliasMode is not a 'true' alias as CNAME is.

It isn’t an ALIAS.  Its a bad description that is the result of HTTP mis-using the CNAME record for the last 20 odd years.  HTTP has always needed a "server for" record like MX or SRV.  We just haven’t been able to get http developers invested in the idea until now.

> considered an answer and should they go into the ANSWER section?

They go in the additional section.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 6 Aug 2020 07:13:48 +1000

> On 6 Aug 2020, at 04:51, Pieter Lexis <[email-masked]> wrote:
> 

-Infinity. Definitely not. 

> will respond with NODATA (and thus the SOA).

You make a SVCB query you will get a CNAME if it exists at the QNAME, SVCB
if it exists at the QNAME or you will get NODATA if neither exists.  If you
find a CNAME you repeat at the target of the CNAME.

If the server is SVCB aware it will then process the SVCB RRset and add those
records to the additional section, if any of those trigger additional section
processing those records too get added to the additional section.  This is
consistent with STD 13 that says words to the effect of “add anything useful” (I’m
not going to look up the exact words).  The additional section rules for SVCB say
to add CNAME, SVCB, A and AAAA to the additional section.

---

From: Pieter Lexis <[email-masked]>
Date: Thu, 6 Aug 2020 12:28:52 +0200

> to add CNAME, SVCB, A and AAAA to the additional section.

The semantic rules for the Alias form lead me to believe that an SVCB at
the targetname *is* an answer to the question (no other SVCB at that
ownername, at the very least no Service mode SVCB at that name).

The end-clients (browsers, other programs actually querying for
SVCB/HTTPS)

Looking at section 5.4.1 ("Ranking Data") of RFC 2181, a non-SVCB
recursor might accept the data in the answer section:

  […]
  + Data from the answer section of a non-authoritative answer, and
    non-authoritative data from the answer section of authoritative
    answers,
  + Additional information from an authoritative answer,
    Data from the authority section of a non-authoritative answer,
    Additional information from non-authoritative answers.

On the other hand, a non-SVCB-aware resolver might even choose to drop
both the data in the ANSWER and ADDITIONAL section that do not match the
original QNAME. Thus only serving its client the SVCB alias record in
the ANSWER section, leading to the end-client re-querying for the
targetname SVCB record.

It would be good to know what most implementations do when they
encounter in-bailiwick data with a different owner name in both the
ANSWER and ADDITIONAL sections. Then the SCVB draft can pick the right
method:

 * Semantically correct (chained SVCB in ANSWER, using 'CNAME chasing')
 * Backwards compatible (All related data in ADDITIONAL)

Best regards,

Pieter

---

From: Mark Andrews <[email-masked]>
Date: Thu, 6 Aug 2020 23:22:09 +1000

> On 6 Aug 2020, at 20:28, Pieter Lexis <[email-masked]> wrote:
> 

SVCB is NOT A CNAME and despite it being called “ALIAS FORM” it does not produce the equivalent of CNAME processing in the ANSWER section.

I really don’t know how this thread got started with clear and unambiguous instructions to add all the records to the additional section.

"Cooperating DNS recursive resolvers will perform subsequent record resolution (for SVCB, A, and AAAA records) and return them in the Additional Section of the response. Clients either use responses included in the additional section returned by the recursive resolver or perform necessary SVCB, A, and AAAA record resolutions. DNS authoritative servers can attach in-bailiwick SVCB, A, AAAA, and CNAME records in the Additional Section to responses for a SVCB query."

Yes this means you need may need to change additional section process to chase other records.  Named was already doing this for one type and with HTTPS and SVCB needing we made the processing general.  Yes, it also means that one has to add CNAMEs to the additional section when processing HTTPS or SVBC.

> * Backwards compatible (All related data in ADDITIONAL)

Named ignores anything it is not expecting.  That said adding DNAME to the answer section caused problems (answers being rejected because a DNAME was present).  Adding unexpected stuff to the ANSWER section is always fought with problems.  If a client falls over because stuff was added to the additional section then the client is broken.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 6 Aug 2020 11:03:08 -0700

On Thu, Aug 6, 2020 at 6:22 AM Mark Andrews <[email-masked]> wrote:

>
>
> I really don’t know how this thread got started with clear and unambiguous
> instructions to add all the records to the additional section.
>

The possibility of changing what is specified in the draft, was what
started this thread.
Your responses all suppose that it is not possible to change what is
specified in the draft.
It would be helpful (IMHO) to the conversation to give consideration to the
contents of the thread, from the perspective that the specs in the draft
are not absolutely set in stone and immutable.

Here's the quote from Ben:

>
> "Cooperating DNS recursive resolvers will perform subsequent record
> resolution (for SVCB, A, and AAAA records) and return them in the
> Additional Section of the response. Clients either use responses included
> in the additional section returned by the recursive resolver or perform
> necessary SVCB, A, and AAAA record resolutions. DNS authoritative servers
> can attach in-bailiwick SVCB, A, AAAA, and CNAME records in the Additional
> Section to responses for a SVCB query."
>
> Yes this means you need may need to change additional section process to
> chase other records.  Named was already doing this for one type and with
> HTTPS and SVCB needing we made the processing general.  Yes, it also means
> that one has to add CNAMEs to the additional section when processing HTTPS
> or SVBC.
>
>
We can all read, and we understand what the current draft says.
That's NOT what is being discussed (how to interpret those words).
What IS being discussed in this thread is whether it may be more sensible
to align the process of handling the "alias" form in a manner more
consistent with how CNAME processing happens.
It is a proposal to change the spec itself, rather than an alternate
interpretation of what the current draft of the spec says.

This is why I suggested that, while it is not CNAME per se, treating it as
"constrained alias applicable only to SVCB queries" isn't a huge leap, and
would simplify the code for handling alias form, on both the server and
client side of a lookup.

If the standard says they belong in the Answer section (as I am
suggesting), I think the expected BIND client-side handling of SVCB records
(alias and non-alias, if in-bailiwick) and CNAME records if they are both
placed in the answer section by the server should be okay, in both
situations: when SVCB is "unknown" (it's a match to QTYPE), or when SVCB
handling logic is added.

Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 7 Aug 2020 09:11:19 +1000

> On 7 Aug 2020, at 04:03, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> The possibility of changing what is specified in the draft, was what started this thread.
> Your responses all suppose that it is not possible to change what is specified in the draft.
> It would be helpful (IMHO) to the conversation to give consideration to the contents of the thread, from the perspective that the specs in the draft are not absolutely set in stone and immutable.
> 
> I think Section 4.1 is pretty clear that everything goes in the Additional section.  (But this can be changed!) 
>  
> 
> What IS being discussed in this thread is whether it may be more sensible to align the process of handling the "alias" form in a manner more consistent with how CNAME processing happens.
> It is a proposal to change the spec itself, rather than an alternate interpretation of what the current draft of the spec says.
> 
> This is why I suggested that, while it is not CNAME per se, treating it as "constrained alias applicable only to SVCB queries" isn't a huge leap, and would simplify the code for handling alias form, on both the server and client side of a lookup.
> 
> If the standard says they belong in the Answer section (as I am suggesting), I think the expected BIND client-side handling of SVCB records (alias and non-alias, if in-bailiwick) and CNAME records if they are both placed in the answer section by the server should be okay, in both situations: when SVCB is "unknown" (it's a match to QTYPE), or when SVCB handling logic is added.
> 
> Brian

What benefit is there in changing this now?  Moving the SVBC chain (graph actually) to the answer section.  I know I can follow a graph much easier in the additional section than I can in the answer section with simple depth limited recursion.  In the answer section I have to initiate multiple parallel recursions to complete the graph hitting different zones. What happens when one of those recursions fail? Do I return a partial answer? Do I SERVFAIL the entire query?  What if one returns NXDOMAN? With everything in the addition section those questions go away.  I return what I have.  I can initiate speculative queries for missing RRsets where I don’t have NODATA/NXDOMAIN cached so when the client comes back I have the response in cache.

The code point has been allocated.  Implementations have been written to the existing spec.  That’s what happens when you ask for a code point. You are saying:
* This is its wire form.
* This is its presentation form. 
* This is what the nameserver does. 
Now we can go play with the rest of the specification and tidy that up with nameservers that know about the code point. Working group chairs are supposed to believe the specification is in this state of readiness before asking for a early code point.

If you want to compare to CNAME and query for CNAME you get back exactly 1 CNAME record even if there is a chain of CNAME records.  The target is not followed.  This is RFC 1034 behaviour.

What I would like is for SVCB alias form to ONLY require looking for SVCB records and SVCB service mode to only require looking up address records.  At the moment there is a scatter gun approach though I may have missed something.  CNAME/DNAME records are found as a side effect of looking for other types.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 6 Aug 2020 18:54:43 -0700

On Thu, Aug 6, 2020 at 4:11 PM Mark Andrews <[email-masked]> wrote:

>
>
> What benefit is there in changing this now?  Moving the SVBC chain (graph
> actually) to the answer section.  I know I can follow a graph much easier
> in the additional section than I can in the answer section with simple
> depth limited recursion.  In the answer section I have to initiate multiple
> parallel recursions to complete the graph hitting different zones. What
> happens when one of those recursions fail? Do I return a partial answer? Do
> I SERVFAIL the entire query?  What if one returns NXDOMAN? With everything
> in the addition section those questions go away.  I return what I have.  I
> can initiate speculative queries for missing RRsets where I don’t have
> NODATA/NXDOMAIN cached so when the client comes back I have the response in
> cache.

I don't think this actually changes the spec, only clarifies it or fixes
errors. It doesn't change wire format or presentation format, nor does
it change the logical resolution tree. It only proposes a change to where
the authoritative server should place RRs when QTYPE is found. It does so
to maintain consistency with the general processing rules from 1034. That
it happens to very closely align with parts of the CNAME rules, is a happy
coincidence.

But, this is the correct time to fix lingering issues that require
clarification or correction. The latest rev, which includes substantial
changes, is only a few weeks old (early June to early August).

Here's a run-down of how I see the more explicit summary of what an
authoritative server should do:

An authority server should (in response to an SVCB query) return, at most

   - a single sequence of zero or more CNAMEs (with a 1:1 linkage from
   RDATA to owner once the chain is normalized), which must be in the Answer
   section
   - followed optionally by an SVCB record set of only AliasForm records,
   - followed optionally by an SVCB record set of only ServiceForm records.

These would all necessarily be in the Answer section, as they all are (a)
in-bailiwick, and (b) match the QTYPE (or are CNAMEs and as per RFC 1034
required to be in the Answer section).
The above statement is ONLY in reference to recursive-to-authority
query/response packets.

Note: section 2.4.1 talks about AliasMode, but does not refer to Answer vs
Additional sections at all. It only specifies the logical relationship
between owner names and TargetNames and SVCB types.
Note: Section 4.1 (Authoritative Servers) is only one paragraph long. IMHO,
this is the part that is way under-specified. It also appears to be
conflating the Additional section placement with what the Client expects.
Clients should not be talking directly to Authoritative servers, so it
might be a legitimate error that needs to be fixed. The overall placement
of what should be an Answer, in the Additional section (i.e. when QTYPE ==
SVCB and RRTYPE returned == SVCB) is at odds with RFC 1034, IMNSHO.

NB: If (and only if) there are in-bailiwick A/AAAA records which are also
resolved from the AliasForm records, those would need to be in the
Additional section; this is not something I dispute in any way.
Also NB: If TargetName names can be CNAME owner names (see below), it's not
entirely clear whether those should go in the Answer section or Additional
section. My initial opinion on this is, it's really Additional section
processing, as there was no rewriting of the QNAME itself involved, so put
it in the Additional section.
Also NB: If an authority server happened to be authoritative for multiple
zones, any SVCB records of either form from the non-in-bailiwick zone(s),
if included at all, ,should be in the Additional section. (The spec doesn't
mention authoritative servers that are authoritative for multiple zones, so
my assumption would be that adding these should be explicitly excluded by
the spec (but is not), or their treatment should be explicitly outlined by
the spec as belonging in the Additional section.)

So, to address your other questions:
How a recursive responds to a client is something else entirely; whether
and where SVCB records get returned might be an implicit signal for
understanding SVCB as something other than "unknown" record types. Putting
everything into the Additional section would be okay, but really only if
the recursive knew the client was an actual end system, and not another
resolver in "forwarder" mode. A more conservative approach would be to put
all the received Answer sections in the Answer section, and all the
Additional sections in the additional section.

I don't think the graph process depends on where the authoritative puts the
answers to a single query... you have to deal with the results either way.
Each of those is going to be an atomic result with a single RCODE.
This actually provides stronger support for AliasMode treatment being the
same as CNAME treatment.
If an authoritative server is adding in-bailiwick data, and gets to a
TargetName which is (a) in-bailiwick, but (b) a non-existent name, this
should get the RCODE=3 treatment (same as if a CNAME canonical name was
in-bailiwick but was a non-existent name).
An authoritative server providing an answer would, by definition, not
SERVFAIL, so the question there is moot.
How you handle references between zones is orthogonal. You have either
walked the graph to a successful answer, or you have not.
If you have, do whatever the rest of the DNS protocol specs say to do. I
think that ends up being: return the appropriate data in the appropriate
section(s) if you get an answer. Otherwise, return the appropriate stuff
(either NOERROR, NODATA, or the last non SERVFAIL answer, or SERVFAIL, I
think.)

>
> The code point has been allocated.  Implementations have been written to
> the existing spec.  That’s what happens when you ask for a code point. You
> are saying:
> * This is its wire form.
> Now we can go play with the rest of the specification and tidy that up
> with nameservers that know about the code point. Working group chairs are
> supposed to believe the specification is in this state of readiness before
> asking for a early code point.
>

The key word there is "supposed to believe". It may not be the case that
all the errors have already been caught.
That's why the WG is supposed to review the draft, and provide feedback,
including on any semantic, structural, logic, or language errors or nits.
This is better categorized as "how the nameserver does what it does"
changes, rather than "what the nameserver does".

>
> If you want to compare to CNAME and query for CNAME you get back exactly 1
> CNAME record even if there is a chain of CNAME records.  The target is not
> followed.  This is RFC 1034 behaviour.
>

I'm not comparing to QTYPE == CNAME. I'm comparing it to QTYPE != CNAME,
with the constraint here that the processing treat AliasForm SVCB
analogously to the AliasForm SVCB actually being a CNAME record. I.e.
acting as an "apex CNAME" which is not something that the DNS RFCs support.
So, this constrained "CNAME-like" behavior is being proposed SPECIFICALLY
because it isn't something that could ever have been done with an actual
CNAME.
The fact that the original DNS RFCs make it impossible, does not rule out
re-using the same semantic rules for this use case. I would argue, the
exact opposite is the case -- the absence of any way of accomplishing this
aliasing at an apex, is EXACTLY why treating SVCB AliasForm at the apex "as
if" it were a CNAME is the correct approach to use.

Clearly, it has no bearing on the behavior of any other QTYPEs.

>
> What I would like is for SVCB alias form to ONLY require looking for SVCB
> records and SVCB service mode to only require looking up address records.
> At the moment there is a scatter gun approach though I may have missed
> something.  CNAME/DNAME records are found as a side effect of looking for
> other types.
>

Then the current draft needs work, because it has inconsistencies (or
errors, depending on how you look at them), that currently differ from what
you like.

So, specifically:
2.4.1, paragraph 2, sentence 2:

> In AliasMode, TargetName MUST be
> the name of a domain that has SVCB, AAAA, or A records

However, same section, a few paragraphs later, we get the following
sentence:

> Note that the SVCB record's owner name MAY be the canonical name of a

CNAME record, and the TargetName MAY be the owner of a CNAME record.

I'm good with either of these, but obviously it has to be one or the other
-- possibly a CNAME, or never a CNAME.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 6 Aug 2020 22:13:09 -0400

Brian,

I think arguing about the strength of the analogies to CNAME (Answer) vs
SRV (Additional) is going to be a slow path to consensus.  Apart from that
analogy, I'm not sure I understand your motivating use case.  Could you
write a small example zone where you think the "chain in Answer" behavior
has a clear advantage over "chain in Additional"?

My main concern with "chain in Answer" is that SVCB-aware recursive
resolvers are required to handle SVCB responses from non-SVCB-aware
Authoritatives, so they can't rely on any followup records being present.
That seems to match well with the semantics of Additional, whose contents
are not reliably present, and less well with the semantics of Answer, whose
contents are normally reliable.

--Ben

On Thu, Aug 6, 2020 at 9:55 PM Brian Dickson <[email-masked]>
wrote:
...

> -- possibly a CNAME, or never a CNAME.

It's definitely "possibly a CNAME", with the second quoted sentence
intended as a clarification of what is meant by "domain that has".  I agree
that this text could be clearer.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 6 Aug 2020 19:49:06 -0700

> has a clear advantage over "chain in Additional"?

Sure. Here are two very similar examples, where the first one I think is
required to put the entire chain in the Answer for ${reasons}. (Take as
ready any underscore prefixing needed to make this make sense...)

whatever.example.com. CNAME example.com.
example.com. SVCB 0 my-common-thing.example.com.
my-common-thing.example.com. CNAME my-canonical-thing.example.com
my-canonical-thing.example.com. SVCB <not=0> <stuff>

whatever.example.com. CNAME example.com.
example.com. SVCB 0 my-canonical-thing.example.com
my-canonical-thing.example.com. SVCB <not=0> <stuff>

The motivation here is that the optimization of adding in-bailiwick records
should, to maximize the benefit to the resolver and to the authority
server, process the second CNAME of the first example.

However, if the placement of the in-bailiwick TargetName's records is in
the Additional section, this is somewhat more complex. Either the CNAME
processing has to happen before the TargetName and CNAME canonical name
records are collectively placed in the Additional section, or the
Additional section must now also process the CNAME. Not doing either of
those would leave a "dangling CNAME" in the Additional section, which would
then necessitate an additional query round-trip from the recursive to
authoritative.

Putting them all in the Answer section, means normal Answer section
handling would basically handle the second CNAME "for free".

This is all opportunistic behavior. It doesn't matter whether the extra
records are added or not, so their absence from either section does not
imply their non-existence, nor does it imply the authoritative server is
aware or unaware of SVCB.

I'm not sure I understand why having them be in the Answer section is any
different from having them be in the Additional section, when it comes to
their handling upon receipt by a recursive resolver.

If the rules were "Put any SVCB records into the Answer section along with
CNAME records found while obtaining them", then the only records that
should be in the Additional section would be A/AAAA records and related
DNSSEC records (and possibly CNAMEs found when obtaining the A/AAAA
records?).
I think this actually simplifies the processing:
The ServiceForm SVCB record(s) might not be present (based on whether the
authoritative is SVCB-aware and whether it is doing the addition of those
records), but IF they are present, they are in the Answer section.
This ALSO means that the only reason for anything being in the Additional
section is if there are A or AAAA records returned, which (hopefully)
implies the presence of a ServiceForm SVCB record.
The only other reason A/AAAA records should be in the Additional section,
is if there is a delegation, in which case there should be stuff in the
Authority section too.

So basically, it becomes:
AliasForm only in Answer -> not in-bailiwick, or not SVCB-aware. Either
way, another query is needed.
AliasForm plus Service Form in Answer -> Check Additional for A/AAAA
records, or query for them if not found
(Both of the above possibly also include CNAMEs in the chain)
CNAME chain only in the Answer -> not in bailiwick, need another query.
No Data in the Answer, Authority has a delegation -> follow the delegation,
possibly use Additional section for glue.

I think this is pretty simple logic, and I don't see the problem... could
you point out the problem if there is one?

Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 7 Aug 2020 14:42:11 +1000

> On 7 Aug 2020, at 11:54, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> I don't think this actually changes the spec, only clarifies it or fixes errors. It doesn't change wire format or presentation format, nor does it change the logical resolution tree. It only proposes a change to where the authoritative server should place RRs when QTYPE is found. It does so to maintain consistency with the general processing rules from 1034. That it happens to very closely align with parts of the CNAME rules, is a happy coincidence.

No, it doesn’t maintain consistency with RFC 1034.

         a. If the whole of QNAME is matched, we have found the
            node.

            If the data at the node is a CNAME, and QTYPE doesn't
            match CNAME, copy the CNAME RR into the answer section
            of the response, change QNAME to the canonical name in
            the CNAME RR, and go back to step 1.

            Otherwise, copy all RRs which match QTYPE into the
            answer section and go to step 6.

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.

If you want to treat SVBC and HTTPS as CNAMES then lets do that.

         a. If the whole of QNAME is matched, we have found the
            node.

            If the data at the node is a SINGLE SVCB in AliasForm,
	    and QTYPE doesn’t match SVBC, copy the SVCB RR into the
	    answer section of the response, change QNAME to the target
	    name in the SVCB RR, and go back to step 1.

	    If the data at the node is SVBC and the 

            Otherwise, copy all RRs which match QTYPE into the
            answer section and go to step 6.

   6. Using local data only, attempt to add other RRs which may be
      useful to the additional section of the query.  Exit.

> But, this is the correct time to fix lingering issues that require clarification or correction. The latest rev, which includes substantial changes, is only a few weeks old (early June to early August).
> 
> Here's a run-down of how I see the more explicit summary of what an authoritative server should do:
> 
> 	• a single sequence of zero or more CNAMEs (with a 1:1 linkage from RDATA to owner once the chain is normalized), which must be in the Answer section
> 	• followed optionally by an SVCB record set of only AliasForm records, 

Sorry you just broke DNSSEC if there are more than one AliasForm records.  More than one is permitted with the same name.

> 	• followed optionally by an SVCB record set of only ServiceForm records.

Well this at the minimum would be a RRset and possibly multiple RRsets.

> These would all necessarily be in the Answer section, as they all are (a) in-bailiwick, and (b) match the QTYPE (or are CNAMEs and as per RFC 1034 required to be in the Answer section). 
> The above statement is ONLY in reference to recursive-to-authority query/response packets.
> 
> Note: section 2.4.1 talks about AliasMode, but does not refer to Answer vs Additional sections at all.

When there was already clear instructions to add records to the Additional section why would it?

> It only specifies the logical relationship between owner names and TargetNames and SVCB types.
> Note: Section 4.1 (Authoritative Servers) is only one paragraph long. IMHO, this is the part that is way under-specified. It also appears to be conflating the Additional section placement with what the Client expects.

The clients will expect what we tell them to expect.

> Clients should not be talking directly to Authoritative servers,

Garbage.

> so it might be a legitimate error that needs to be fixed. The overall placement of what should be an Answer, in the Additional section (i.e. when QTYPE == SVCB and RRTYPE returned == SVCB) is at odds with RFC 1034, IMNSHO.

The DNS says if there are records of the given type at this name return them (this applies to CNAMES as well).
If you happen to encounter a CNAME (and you are not asking for a CNAME) restart the query with the CNAME target.

> NB: If (and only if) there are in-bailiwick A/AAAA records which are also resolved from the AliasForm records, those would need to be in the Additional section; this is not something I dispute in any way.
> Also NB: If TargetName names can be CNAME owner names (see below), it's not entirely clear whether those should go in the Answer section or Additional section. My initial opinion on this is, it's really Additional section processing, as there was no rewriting of the QNAME itself involved, so put it in the Additional section.
> Also NB: If an authority server happened to be authoritative for multiple zones, any SVCB records of either form from the non-in-bailiwick zone(s), if included at all, ,should be in the Additional section. (The spec doesn't mention authoritative servers that are authoritative for multiple zones, so my assumption would be that adding these should be explicitly excluded by the spec (but is not), or their treatment should be explicitly outlined by the spec as belonging in the Additional section.)
> 
> How a recursive responds to a client is something else entirely; whether and where SVCB records get returned might be an implicit signal for understanding SVCB as something other than "unknown" record types. Putting everything into the Additional section would be okay, but really only if the recursive knew the client was an actual end system, and not another resolver in "forwarder" mode. A more conservative approach would be to put all the received Answer sections in the Answer section, and all the Additional sections in the additional section.

Really the question is are you answering authoritatively or recursively.  See RD and RA. That is actually different to are you authoritative for the QNAME or not.

> I don't think the graph process depends on where the authoritative puts the answers to a single query... you have to deal with the results either way.

But if does when the result will be different rcodes.

> Each of those is going to be an atomic result with a single RCODE.

Nope.  Can’t be.

> This actually provides stronger support for AliasMode treatment being the same as CNAME treatment.
> If an authoritative server is adding in-bailiwick data, and gets to a TargetName which is (a) in-bailiwick, but (b) a non-existent name, this should get the RCODE=3 treatment (same as if a CNAME canonical name was in-bailiwick but was a non-existent name).

And how do you do that with a graph?  This is the multiple QNAME problem.

> An authoritative server providing an answer would, by definition, not SERVFAIL, so the question there is moot.
> How you handle references between zones is orthogonal. You have either walked the graph to a successful answer, or you have not.
> If you have, do whatever the rest of the DNS protocol specs say to do. I think that ends up being: return the appropriate data in the appropriate section(s) if you get an answer. Otherwise, return the appropriate stuff (either NOERROR, NODATA, or the last non SERVFAIL answer, or SERVFAIL, I think.)
>  
> 
> The key word there is "supposed to believe". It may not be the case that all the errors have already been caught.
> That's why the WG is supposed to review the draft, and provide feedback, including on any semantic, structural, logic, or language errors or nits.
> This is better categorized as "how the nameserver does what it does" changes, rather than "what the nameserver does”.
>  
> 
> I'm not comparing to QTYPE == CNAME. I'm comparing it to QTYPE != CNAME, with the constraint here that the processing treat AliasForm SVCB analogously to the AliasForm SVCB actually being a CNAME record. I.e. acting as an "apex CNAME" which is not something that the DNS RFCs support. So, this constrained "CNAME-like" behavior is being proposed SPECIFICALLY because it isn't something that could ever have been done with an actual CNAME.
> The fact that the original DNS RFCs make it impossible, does not rule out re-using the same semantic rules for this use case. I would argue, the exact opposite is the case -- the absence of any way of accomplishing this aliasing at an apex, is EXACTLY why treating SVCB AliasForm at the apex "as if" it were a CNAME is the correct approach to use.
> 
> Then the current draft needs work, because it has inconsistencies (or errors, depending on how you look at them), that currently differ from what you like.
> 
> So, specifically:
> However, same section, a few paragraphs later, we get the following sentence:
> I'm good with either of these, but obviously it has to be one or the other -- possibly a CNAME, or never a CNAME.
> 
> Brian

---

From: Brian Dickson <[email-masked]>
Date: Fri, 7 Aug 2020 01:14:06 -0700

On Thu, Aug 6, 2020 at 9:42 PM Mark Andrews <[email-masked]> wrote:

>
> Sorry you just broke DNSSEC if there are more than one AliasForm records.
> More than one is permitted with the same name.
>

Good point.

"More than one is permitted" is the case only because of the current spec.
I don't see any explanation for why this is (or needs to be) the case.
What would be wrong with changing the spec to prohibit more than one
AliasForm record at a given name?

Now, suppose only one AliasForm is permitted (just like CNAME), what
downside would there be?
The handling of multiple AliasForms at a given name should be handled in
the same way that having more than one CNAME is handled.
That seems like it wouldn't be hard.

And as far as I can tell, the ServiceForm is the thing for handling the
multi-CDN, availability, etc. issues. It's the right tool for the multiple
RR situation.

> And how do you do that with a graph?  This is the multiple QNAME problem.

So, other than at the terminus of the ultimate set of ServiceForm SVCBs,
why should this even be a graph, rather than a chain?
Does reducing this to a chain fix the multiple QNAME problem?

The ServiceForm records all clearly need to be processed so that the
correct set of answers is returned to the client. I'm not proposing any
changes to that part of the spec.

Having only a single AliasForm record allowed at any given owner name would
avoid any forking.

Additionally, much of the text and the examples suggests that where
possible zone administrators should use CNAME instead of AliasForm, i.e.
everywhere other than at a zone apex.
That would seem incompatible with the alternative of intentionally allowing
or encouraging multiple AliasForm records (which, unlike ServiceForm
records, do not have a priority field.)

I think it's not much of a stretch to change the SHOULD to a MUST (on only
one AliasForm), and I think that fixes a lot of the remaining issues.

I'm willing to drop the Answer vs Additional section for in-bailiwick
TargetName (plus A/AAAA) placement.
(However, I'm not the only person in the WG other than the authors; others
may have stronger feelings about this, since at least one person concurred
with my original post.)
It's up to the WG on this latter issue (placement), I'm good with whatever
the consensus is.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 7 Aug 2020 10:42:36 -0400

On Fri, Aug 7, 2020 at 4:14 AM Brian Dickson <[email-masked]>
wrote:

>> Sorry you just broke DNSSEC if there are more than one AliasForm
>> records.  More than one is permitted with the same name.
>>
>
> Good point.
>

I'm not sure I understand this problem.  The authoritative server could
deliver the whole SVCB RRSet with its signature, along with the chain from
following (just) one of the AliasMode RRs.  This is the behavior that is
required (in the current draft) of recursive resolvers (and clients).

> AliasForm record at a given name?

The current text says "SVCB RRSets SHOULD only have a single resource
record in AliasMode."  Early drafts say "RRSets MUST only have a single
resource record in this form." (
https://www.ietf.org/archive/id/draft-nygren-httpbis-httpssvc-03.txt).  I
believe this was changed because declaring that RRSets MUST only have one
record, and also declaring what recipients should do if there are more than
one, seemed like a contradiction.  Also, round-robin AliasForm seemed
harmless, and potentially useful for multi-CDN.

> multi-CDN, availability, etc. issues. It's the right tool for the multiple

Correct, ServiceForm is the intended solution for multi-CDN.  Using
round-robin AliasForm for multi-CDN would give less fallback capability to
clients (they could only use one CDN or the other), but would reduce
coupling between the CDN and customer (no need to copy SvcParams into the
customer zones, where they might be hard to update).

...

> It's up to the WG on this latter issue (placement), I'm good with whatever

I wonder if the most popular option would be to allow either behavior, and
instruct recipients to check both sections.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 7 Aug 2020 10:40:48 -0700

On Fri, Aug 7, 2020 at 7:42 AM Ben Schwartz <[email-masked]> wrote:

>
>
> On Fri, Aug 7, 2020 at 4:14 AM Brian Dickson <
> [email-masked]> wrote:
>
>
No, it isn't a contradiction. If it is forbidden, you have to handle
non-compliance. That's just protocol 101.
Also, it may be messy to try to be prescriptive on what to do?
Maybe just provide loose guidance to implementers to the effect of, "You
have to handle this situation for multiple CNAMEs. Using the same logic for
that is the right thing to do." Even if how multiple CNAMEs isn't
necessarily well spelled out in the RFCs, it isn't a problem that I see
causing major problems on various DNS implementations (at least as far as I
know).
The same guidance would be applicable regardless of where in the ecosystem
the issues are handled, from APIs to UIs to auth to recursive to client.
Not sure how anyone feels about that as guidance, but I think it would make
the document pretty easy to understand and minimize any confusion.

> customer zones, where they might be hard to update).
So, it's really only a minor convenience thing, not a blocker per se. I.e.
making multiple AliasForm entries a "MUST NOT", would not prevent someone
from being able to use multiple CDNs, it would just be slightly less
friendly/flexible.
My issue with the round-robin impact is doing so would very likely make
diagnosing or solving problems when multiple CDNs are involved, extremely
difficult and confusing, at the one place where you really don't want
things to be confusing or difficult to diagnose.
It's a non-deterministic behavior in a place without any real way to figure
out what is happening.
One of the main benefits of the parameters in the ServiceForm is that you
can re-prioritize if equal-weight stuff is having problems, and that allows
both diagnosis and fixes to problems that are discovered (lower the weight
of the broken thing.)

I think bringing back the prohibition on multiple AliasForm records at an
owner name is the wisest choice.

Brian

---

From: Tony Finch <[email-masked]>
Date: Mon, 10 Aug 2020 23:17:00 +0100

>    those would not match the query RRTYPE of SVCB)

I've only skimmed this thread, so I might be repeating something that's
already agreed... but I want to emphasize that a new RR type specification
will have impossible interop problems if it tries to put records in the
ANSWER section that aren't expected by existing DNS software.

"Unexpected" means anything that isn't part of a CNAME or DNAME chain on
the way from the original query name to an RRset of the query type.

If a resolver queries for the owner of SVCB record (or a CNAME pointing at
one) then anything related to the RDATA of the SVCB record(s) has to go in
the ADDITIONAL section, or there will be sadness.

It was a very long time before DNAME was usable and even within the last
10 years there was software that would choke on DNAME records in the
ANSWER section that it didn't expect.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon, Rockall: Variable 2 to 4. Moderate, occasionally slight. Drizzle.
Moderate or poor.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 11 Aug 2020 16:14:59 -0400

Thanks for that warning, Tony.  It sounds like we should stick to the
Additional section, and not alter the Answer contents.

I've tried to incorporate the feedback from this discussion into a proposed
change that avoids imposing new requirements, but enables the CNAME chain
optimizations identified by Brian Dickson and specifies SOA behavior as
proposed by Pieter Lexis:
https://github.com/MikeBishop/dns-alt-svc/pull/238/files?short_path=d44bc72#diff-d44bc722e745a4e66186057a4127f461

This change would replace Section 4.1 with the following text:

When replying to a SVCB query, authoritative DNS servers SHOULD return
any useful in-bailiwick records in the Additional section.  Authoritative
servers MAY implement this Additional section processing by applying the
following procedure to each returned SVCB record:

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.

All follow-up queries MUST retain the original query's "DNSSEC OK" setting.

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}}.

On Mon, Aug 10, 2020 at 6:17 PM Tony Finch <[email-masked]> wrote:

> up

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Aug 2020 21:54:12 +0100

Ben Schwartz <[email-masked]> wrote:
>
> 1. If TargetName is not in-bailiwick and is not ".", terminate the procedure.
> 2. If SvcPriority is 0:
> 3. Perform A and AAAA follow-up queries for TargetName (or for the owner name if

I think the actual wording you want here is "in the same zone" not "in
bailiwick". The important thing you don't want is to require an auth
server to go out to the network to query for address records in a
delegated subdomain. The more subtle thing is happens with auth servers
that host zones from many customers: they want to avoid cross-zone
contamination in additional sections because a careless or malicious
customer may have set up a shadow zone for a domains whose NS records
point elsewhere.

The "bailiwick" term should only be used when discussing whether
delegations need glue or not. (See RFC 8499 and DJB's notes on
gluelessness that introduced the term http://cr.yp.to/djbdns/notes.html)

> section to enable negative caching of the follow-up queries, as in

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

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.
(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.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  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.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 11 Aug 2020 17:38:00 -0400

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

> bailiwick".
...

Thanks, I will make that correction.

...

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

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

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

---

From: Brian Dickson <[email-masked]>
Date: Tue, 11 Aug 2020 14:50:50 -0700

> Thanks, I will make that correction.

I think the condition might be, "both in bailiwick and in the same zone"
meaning "in bailiwick and not below a zone cut"?

It may be overly explicit to say "not below a zone cut (delegation point)",
but "in the same zone" can be erroneously interpreted by implementers who
fail to recognize the pitfalls of zone cuts.

I might be overthinking it, though.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 11 Aug 2020 17:53:40 -0400

> meaning "in bailiwick and not below a zone cut"?

It seems to me that returning a (downward) delegation could actually be
useful.  So why not include that?

> It may be overly explicit to say "not below a zone cut (delegation
> point)", but "in the same zone" can be erroneously interpreted by
> implementers who fail to recognize the pitfalls of zone cuts.
>

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Aug 2020 23:18:45 +0100

Ben Schwartz <bemasc=[email-masked]> wrote:
> Additional section.

I thought the target types were just A, AAAA, SVCB, so where does the SOA
come from?

> work, I'd love to know why.

I can't see anything in the current SVCB draft that would change this.
There's simply no way to put a negative answer in an additional section
(without DNSSEC) - RFC 2308 relies on the context of the message header
and query sections and they don't exist for additional records.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
protect and enlarge the conditions of liberty and social justice

---

From: Tony Finch <[email-masked]>
Date: Tue, 11 Aug 2020 23:38:07 +0100

> > meaning "in bailiwick and not below a zone cut"?

I don't think that makes sense - "bailiwick" is about glue. Maybe you
could say "in the same zone (not below a zone cut)" and refer to RFC 1034
section 4.2 for the definition of a zone.

> useful.  So why not include that?

Additional section processing does not normally include referrals. 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. Which is basically what the draft
says now, though it unnecessarily respecifies additional section
processing.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  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.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 11 Aug 2020 20:25:03 -0400

...

> I thought the target types were just A, AAAA, SVCB, so where does the SOA

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).

On Tue, Aug 11, 2020 at 6:38 PM Tony Finch <[email-masked]> wrote:
...

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

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.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 12 Aug 2020 11:15:58 +1000

> On 12 Aug 2020, at 10:25, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 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?  What if one can’t fit some of these RRsets but can fit a SOA?

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?

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

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

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

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 11 Aug 2020 21:31:01 -0400

On Tue, Aug 11, 2020 at 9:16 PM Mark Andrews <[email-masked]> wrote:

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

> > * 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?
> >
> PHONE: +61 2 9871 4742 <+61%202%209871%204742>              INTERNET:
> [email-masked]
>
>

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 17 Aug 2020 10:43:14 -0400

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.