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

Pieter Lexis <pieter.lexis@powerdns.com> Wed, 05 August 2020 18:51 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 0AAD63A0E67 for <dnsop@ietfa.amsl.com>; Wed, 5 Aug 2020 11:51:43 -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=ham 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 Zpd6wA0ARfJ2 for <dnsop@ietfa.amsl.com>; Wed, 5 Aug 2020 11:51:41 -0700 (PDT)
Received: from mango.plexis.eu (mango.plexis.eu [77.72.150.82]) (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 275D73A0E57 for <dnsop@ietf.org>; Wed, 5 Aug 2020 11:51:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mango.plexis.eu (Postfix) with ESMTP id E7292C9B; Wed, 5 Aug 2020 20:51:38 +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 r3wGumpjsQta; Wed, 5 Aug 2020 20:51:38 +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 117097AA; Wed, 5 Aug 2020 20:51:38 +0200 (CEST)
To: Brian Dickson <brian.peter.dickson@gmail.com>, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: 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>
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: <cd6021e7-4aad-c2fc-e9ef-948fbeab0809@powerdns.com>
Date: Wed, 5 Aug 2020 20:51:37 +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: <CAH1iCipZ25XaES0C4MFt3+aOm=d1U5LKigJe5AwKUWG-+yETFw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IPlktTtuikZK-CksyovRjAgdSyQ>
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: Wed, 05 Aug 2020 18:51:43 -0000

On 8/5/20 8:03 PM, Brian Dickson wrote:
>
>
> On Wed, Aug 5, 2020 at 10:08 AM Ben Schwartz
> <bemasc=40google.com@dmarc.ietf.org
> <mailto:40google.com@dmarc.ietf.org>> wrote:
>
>     On Wed, Aug 5, 2020 at 12:06 PM Pieter Lexis
>     <pieter.lexis@powerdns.com <mailto:pieter.lexis@powerdns.com>> 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 beg to differ, in that I would view AliasMode as a constrained CNAME.

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

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

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

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

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

Yes.

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

I believe you are correct.


Cheers,

Pieter

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