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

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 07 August 2020 01:54 UTC

Return-Path: <brian.peter.dickson@gmail.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 1F6733A0CC8 for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 18:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 vbi5Q6tAysH2 for <dnsop@ietfa.amsl.com>; Thu, 6 Aug 2020 18:54:55 -0700 (PDT)
Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (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 ACF853A0CCA for <dnsop@ietf.org>; Thu, 6 Aug 2020 18:54:55 -0700 (PDT)
Received: by mail-ua1-x931.google.com with SMTP id x19so74082uap.11 for <dnsop@ietf.org>; Thu, 06 Aug 2020 18:54:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7Rx219v3SEIG/QdJ2tIv+CsVtFX8ifvo9riAHRy+I2w=; b=AVA1/hDGkxoWZ3IM+YkW/Eyx9I99jNxbLoKnKqRfIMXUepzax6tgRG7Z+WJkxhPtHU tf/g3+2eN6ZQYOq6oVjgpqvgjElB2OlCUbV+ZZQ5QDnfrRJji+VrHRylXWe1C8g5chw9 8bZZQu/maV0XLOdILoJqLpc93+f44JRqkO1QZgtaHEPUaEfXHQ8HJ3FgI1ax4reLx2co 7jDaCNn8y+sEHhaN4cbiWx2uESmK/sI6F9/SJ4sLxOdwhdhNoehDkqqDbLqEYHaxggEg PxA0yy7UJTpzGa489bJtNzEgmSTbz4KL5yzO+13kY6To2FIwvcGkmLkS7NSO4LXtNhsA BctA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Rx219v3SEIG/QdJ2tIv+CsVtFX8ifvo9riAHRy+I2w=; b=d+Hu4i+LhjIA9NaS6XexODLwV/BUzOB/QrLRyfcgJequvRFHWn8QHsJp3EvJ9JyK+l 9JL83OZVM1Nl/XRgUqsiK4d+bEJbSSIKA81QRtXBRcuh8fb6hEZPfDYTQcR/nyHODBr+ RWyLRe5j6meKBuphqJGBAm2XUzj/QDmi3caOU8Rj0urdzS02BHHucR2Oc/RAW1lifrqJ CuFZcH6w2BTHjtBn86laCB/5X+qXREeTHO5/3Q4/y5UQLPLwG/dflzd38vELrq/4NIVA JwdHJbA8c9qLY4dDQAE8+R3pT4j0jpcxadglqlviFmI/phYTWNtHp/Z8f4hIe4vrnuiG 0XxA==
X-Gm-Message-State: AOAM5333bfutQz7bJYNAJ68R/ORYTqPQhZFLV5ye8M8lh0Qa2nEVROt4 urecwRXCaaosQV4yxwx2fEM4eaKmV8tsk4DFFxc=
X-Google-Smtp-Source: ABdhPJxXl2tc3gMQNqA0GKto1cJ09kRwvW3mcAzb09sjBArNDUZAw2EmAET1YH0QHmHB0aPqmXiauTSNbVj9X1zPJtA=
X-Received: by 2002:ab0:564:: with SMTP id 91mr8416217uax.114.1596765294533; Thu, 06 Aug 2020 18:54:54 -0700 (PDT)
MIME-Version: 1.0
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> <9390cb8a-677f-7309-b466-c45643827b22@powerdns.com> <DCAF1704-B545-4AB8-8133-85E7280ADCD6@isc.org> <CAH1iCioaitgh1JYNLcqawkg06WLG8FqmmDV0LkOrAaqUuNBNcQ@mail.gmail.com> <9F828CCE-81C5-4354-874B-93D7CFC3E730@isc.org>
In-Reply-To: <9F828CCE-81C5-4354-874B-93D7CFC3E730@isc.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 6 Aug 2020 18:54:43 -0700
Message-ID: <CAH1iCipP7p8UayYAgzWSO3CTYZryJX_NVqPJka4je982wjsrKQ@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: Pieter Lexis <pieter.lexis@powerdns.com>, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002ba23d05ac3fe4a9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_Qb7Hsn1NjTJx2UTkdS-KeYIpF0>
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: Fri, 07 Aug 2020 01:54:59 -0000

On Thu, Aug 6, 2020 at 4:11 PM Mark Andrews <marka@isc.org> 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.
> * 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.
>

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