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

Pieter Lexis <pieter.lexis@powerdns.com> Thu, 06 August 2020 10:28 UTC

Return-Path: <pieter.lexis@powerdns.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E10F3A10D4 for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 03:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.846
X-Spam-Level:
X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VXBiDtJFaEc for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 03:28:57 -0700 (PDT)
Received: from mango.plexis.eu (mango.plexis.eu [IPv6:2a01:7c8:aaae:3e2::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59C0D3A10D0 for <dnsop@ietf.org>; Thu, 6 Aug 2020 03:28:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mango.plexis.eu (Postfix) with ESMTP id 4700511C8; Thu, 6 Aug 2020 12:28:54 +0200 (CEST)
Received: from mango.plexis.eu ([127.0.0.1]) by localhost (mango.plexis.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XKYFEtgrpr4; Thu, 6 Aug 2020 12:28:53 +0200 (CEST)
Received: from perzik.mobile.plexis.eu (unknown [IPv6:2001:980:5650:0:51ec:6b7d:cfa6:e1c6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mango.plexis.eu (Postfix) with ESMTPSA id 41FC26A4; Thu, 6 Aug 2020 12:28:53 +0200 (CEST)
To: Mark Andrews <marka@isc.org>
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
References: <00cfd965-bf69-d1cb-2df3-1a9bb110d7e0@powerdns.com> <CAHbrMsAJ-cbcW3v4T34f8-gzgzgHSkoBO545_Y3N8D6rof7Nmw@mail.gmail.com> <CAH1iCipZ25XaES0C4MFt3+aOm=d1U5LKigJe5AwKUWG-+yETFw@mail.gmail.com> <cd6021e7-4aad-c2fc-e9ef-948fbeab0809@powerdns.com> <8BC20DED-784F-4004-9E56-8BB2F6356FA7@isc.org>
From: Pieter Lexis <pieter.lexis@powerdns.com>
Autocrypt: addr=pieter.lexis@powerdns.com; prefer-encrypt=mutual; keydata= mQINBFT0b7IBEADHlzJvds1NqKEDhOAG0IWGN4J/jBvO5dPPFqwDJaU32x+4wTw0OOxCcgFY dzWPl17nFwjC8yeXvbACCZNz62Kg5o1lWA6Mdx8eazCiGOuTdUbndZDBlrIEAs1OUZmqxTSy dDnaRNCtLTE2o0t4MaidczjinUn2RkvrtvlCsi1HpQdO5mUTr/bmp7v4mvCP5vERuY2+qVc1 KbqFltCeV0KAOpr1kRGyQ4D9LFloFkr7ftF0ba3B0fbInu2uMp46MC+jPok5uEoT66l+U7sZ sCUkHH02Y6s/uXJ6ack84/phtv4xwRERlpC97Md+7N7qIYVrdhGVbsiHFEDIoBrLAqfdteiv oocguLRI/EUn26J9+bezhmCZUUu1f62iJuBnWCwjpELNMlCIpWugHAucaUZx1xyF71DR65NZ wMs+TxBEf+gYlvrzDm6J8fhkfKFH6PtrjIOC0mCsfqOY4FgRYknTZd4ECufkbMKXRX88qvYG X+Fr1TgnQR9GChEPIiWF9e3a5J+DljBu7tEJ0LOhnWU3ApUCTE1lQSGgrUTDQsbil+lyPVjo MI+rxzP4o3roDyzrFEr/rlnCv3x+0kqprSXTJqcDShVJq+GU2lmeUCy7+pF2yKCqhChcF5CQ D4Jt+plRBPq7stxaDZdLpvUtFvLRl4LO6TJjNAGf5x2+kfvupQARAQABtChQaWV0ZXIgTGV4 aXMgPHBpZXRlci5sZXhpc0Bwb3dlcmRucy5jb20+iQJVBBMBCAA/AhsDBgsJCAcDAgYVCAIJ CgsEFgIDAQIeAQIXgBYhBLds1GccCWi6qH3mHF5QcVvy/+GnBQJeM+LTBQkO4w2hAAoJEF5Q cVvy/+GnRrkP/13Fx1zKeaHWelhroHGfV212Ag7sxt8xvj0bEIYp/vU2yC+GQEzLSYdRycPY 2rKqVuC+CZYTlxRmGwWxJLy1z20rtQypPzfKZkYTvpDuf+jDky22Uc8DNX17A+3amBwlip6w 9BvNXOf1E9vDVsQhxGfbmMGEAQXycdOXkKQ8YwoqweL4N8OkIVh7ZLqib9mBMDmZu/pSXo6L csH44DQ19GSx8iUO3TxLDnQVUqDCH+PTdaXW7wdr1DteeDA4yZHJKaUsfvvWPwbyYxxXy0s6 Y+Jh3T+FgH5Zqdt11+BOIy4ejTe3AH5btepT+Oj5fNp/LZcc+hFytxiMZUTdWcgcHCRvyY5v j6/ceKBThpKA3Y7K/bH8lf1i+Cx7yRrFblkqj2KKlcWk6/FK3k3ExFFoBevCUOqs3JNQl/ZT cL0lW+tQ6AwwzZvowq6SwVD2rCEmw+dJkRF12+TlMH9DX0TI1TbsVuboXr/A6VeTXU/k1EK/ EUZvgm58+s+0fCtETTvmOurt7jtOsa8bRpM4hqihBjIKuSlISuL7bWfApgj0Ar6sWQFzbBV/ xkhK20LBTr2fJAS2HJl9w81lW8vBn+HKOTkJQdJ6HlDYbnnk5KloxC5FeiXoZole84J9w7Mu KYbYO2F2o/Da6A6KUzXOTbNl+E5Mh4t7SqQ1K5gnI2/l613duQINBFT0b7IBEACjecdg3e1I F3zBMadFbFah7ZSPFK4Y8Q+OMbeiu0TzXP65rRXDQi595jdIcQY6/7gB1IguqC0HWUo/Ns7G FnNnWbrAaoVWpLjHXgMJ9hqdyIEgluoJECH53d0Y73oi+PBoYUU5z2tHi7AiiJc9qMG4m9q2 P7xUrnqCqmGO4pU9nFJTFUAodf/ioNk9EdmciLmFUm7XkHNtUcKVQGWER7videdWLW1fhHAz hI1hYkN85ZfIULfrVNZBn1U/L4nry7P7HO0IQxoK7POs6apxU4JyATEyvsnjYU+UOCDPXRIK HAZ4joEnFhyHPyURgdMLxQb0s1hnbTEC+szvqb9kC0rCan1GRb6/VeW9eRi1CoBpHtQEwY6k +YgWpvcfR0w9+6BH5aqypGWnNDCWcOTINUrouALb68oxgnEAowhWIa0ujUYy+PMYF0AFArjL Vxu1IBKaMD/Wsk0ws389xAnbVW81bhHN2Ye2NznDe3YfK5FkUyWXO6GA1tFQw+joxt6+TPcT xRJLS/MG/gXcluQE3Kv+jteqi/dbt5A+potX6qGN+F1GJwD/mQKyULklzlcZCIYZN9OnKVbS xfn2xQ89bjvkNvRjuO33x0IozIr/R/uz4T0H9Ve4UoNj2vT4pH/Ba/ergQSfrrAJMDyIB+SR IgY7LCQFB3rOIvg/HiqAY3VL1wARAQABiQI8BBgBCAAmAhsMFiEEt2zUZxwJaLqofeYcXlBx W/L/4acFAl45dJIFCQ7on2AACgkQXlBxW/L/4afaAw/+PNcqR02gMEf5Iw7Pf/kWwG56KadS s1KQ1J0bZNtmN/0kwfTdqofMwX4aKQ88/SK16cIXvDLsVktUBL2d4TOHGnckfUvlRYAMmGdu mzI5pbdmZFiJY+PfcHd706KeFwRT4XdrrI0+/nDuZwGhXjpVYGDA2vSdMymv37QQqDnoB3hG W3biRj1tVlCbkRDKDuZWV3pr2/OfHAlk3650EL3OMwfmctC9TOldtwgsukKp/L4nt+QVWvyP Vs0Bv3EBJyv4A29l9TOnwy4XNscxyyzAh892RZRrPHlKtJVSyM07mHavhJHduNH2A7NNnhHc JH/X7w0Yscnyt9V5bFoEUxJ0h4QCOSa9ZcflZqK11jvZyXJNjtGtofRMfb6C8cSzK0gMqbFn KYoWiCfg5Ba2VQmydF6fcQgR/dj9VgS5nL8kOmBGeCNXbQLvtRNaH9pFPWrTLgdtR/wco5zO e0/i1302HW7IFoTsmz3yiRApb0DeyaJgn5+7w61F5JH+I/na50emwvWfZy/CPXCiqvk5gS9G aws3+ngeRelSpPm3ftVlTuxGmNkYq5B/FO5qzlb/xssH66aUk7Uzk1DcJgMDY8OKTVMF+5xY 4uNdyeH86ls3Qv7EVshOcojXoL5UsmMpOlE/cgkdcjYEjrNelJbgiGQtDB10FK0/cmOETmni BIiXrrE=
Organization: PowerDNS
Message-ID: <9390cb8a-677f-7309-b466-c45643827b22@powerdns.com>
Date: Thu, 6 Aug 2020 12:28:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <8BC20DED-784F-4004-9E56-8BB2F6356FA7@isc.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2LPs5kB5V_AnWPpv5Fh7YDQmB84>
Subject: Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2020 10:29:00 -0000

On 8/5/20 11:13 PM, Mark Andrews wrote:
>> On 6 Aug 2020, at 04:51, Pieter Lexis <pieter.lexis@powerdns.com> 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).

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

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