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

Brian Dickson <> Wed, 05 August 2020 18:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 809283A0E71 for <>; Wed, 5 Aug 2020 11:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8-ix91l_NXbS for <>; Wed, 5 Aug 2020 11:03:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9DD073A0DBE for <>; Wed, 5 Aug 2020 11:03:13 -0700 (PDT)
Received: by with SMTP id p8so15529871vsm.12 for <>; Wed, 05 Aug 2020 11:03:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UqQzfrY9w5tuH28YTS4jaSoyP20OakIiUrhSpb3rKkQ=; b=TMpxzIM+GQwRMDDWefWcR2svmXHdCCWvPBCkQphg7olKHqfl1GDAzuRhXvgNjSpRaD MaEDzsVCIDkju0JBDkSSpq2LBNQIhfv4lxJhjlk3JlpYKCYnflRFpXy3vwphXOY3n50J JHlgWIQEbxgIJrmkDy+E5P3Jfd9/zJErpCoo2JN9hL+G70KJ7QC7EYx8Xt1sGTTrdRgW zdtthHoc22bPUr+QNl8CNfq2pNKn4xZYlNFa1K246Q6Fu4WoqsZsEc+FPGd40H212l29 rTqqNeO70fJ2PrbWFYWVgTGjCNTM36knW8QET7mSyZdsGcut0T2s8RnPYoTanMJp4IPt W6Og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UqQzfrY9w5tuH28YTS4jaSoyP20OakIiUrhSpb3rKkQ=; b=euvHo86Q7EJW4nhGmrmsjNlUnyO1IDyxof2mi4Oi2jh6QeM3Lx3jIx54CqvWOlGeuk 93iHXZD1bCGIKHzzkGtyG+65DawWMP+CTaCs8pW6Df0Iwd0Y9aVDuwNXYKUWVrMzKAqW d98j4x5ZzxtJcgsAtRJYQJNoMBgk05pmTK8AuPx0/zTA9Z0bB0rIezmb0Lba/RZJLGR8 PofaOQtdqMAjabtALDDV8u8jRucfw8Zg/PMt2I8dOBc3JfasyaDZ9XCom09D2xaFYj1/ WeZHmJGSfatcS4m7sEQOMGs8GnxwfauflM7aI/GmReqeS094SVEO/8G3Bh7e2IRIkFxn IVoA==
X-Gm-Message-State: AOAM5315T4J9seerF5zKFRFHZoVxM3e6oGI00WOGUDMHDzmuWkB632Ir YNORjitjNWF7iBIfV8k4VxBC13EwNbiTtFcPP88=
X-Google-Smtp-Source: ABdhPJxeMZqCIGMVqgNzXdgvTOuWI0TuaCCH/BZlz1zrqnewyMg8vMwSBd2Ej/5x9P1pkUGXkD8wUJr12SCso2bjCKQ=
X-Received: by 2002:a67:e81:: with SMTP id 123mr3104828vso.75.1596650592584; Wed, 05 Aug 2020 11:03:12 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Wed, 5 Aug 2020 11:03:01 -0700
Message-ID: <>
To: Ben Schwartz <>
Cc: Pieter Lexis <>, dnsop <>
Content-Type: multipart/alternative; boundary="00000000000066c7f605ac252f8a"
Archived-At: <>
Subject: Re: [DNSOP] Alias mode processing in auths for draft-ietf-dnsop-svcb-https-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Aug 2020 18:03:15 -0000

On Wed, Aug 5, 2020 at 10:08 AM Ben Schwartz <bemasc=> wrote:

> On Wed, Aug 5, 2020 at 12:06 PM Pieter Lexis <>
> wrote:
> ...
>> Do *both* alias-target{1,2}|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 think Section 4.1 is pretty clear that everything goes in the Additional
> section.  (But this can be changed!)
> 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.
> 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?

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
It's not how it should be, of course.
But, clear and concise RFCs lead to the best possible outcomes.

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

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