> On 6 Aug 2020, at 20:28, Pieter Lexis <[email protected]> wrote:
>
> On 8/5/20 11:13 PM, Mark Andrews wrote:
>>> On 6 Aug 2020, at 04:51, Pieter Lexis <[email protected]> wrote:
>>> On 8/5/20 8:03 PM, Brian Dickson wrote:
>>>> (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.)
>>>
>>> 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).
>>
>> 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.
>
> 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).
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.
> 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)
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.
> Best regards,
>
> Pieter
>
> --
> Pieter Lexis
> PowerDNS.COM BV -- https://www.powerdns.com
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
