Re: [DNSOP] ANAME loop detection

Jan Včelák <jv@fcelda.cz> Mon, 08 July 2019 09:32 UTC

Return-Path: <jv@fcelda.cz>
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 2BC7B1200FB for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2019 02:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.703
X-Spam-Level:
X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fcelda.cz
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 gO_Iv130iJsj for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2019 02:32:33 -0700 (PDT)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 EA1011200E7 for <dnsop@ietf.org>; Mon, 8 Jul 2019 02:32:32 -0700 (PDT)
Received: by mail-vs1-xe34.google.com with SMTP id u3so7745215vsh.6 for <dnsop@ietf.org>; Mon, 08 Jul 2019 02:32:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y94Dm28qMEmYkmQsFcn9vdiFDTveqIb+HT8M9JZJatQ=; b=WRbmn5LoP+go0RlPUFddVIvsxeoo3IGS51KQslsInxjRPgrpiX2TuUqnYG/V+FZxXg Ndl1vI+m4bxYnHufOnxtT1jGAjagxInyOEqEhJ0MeUECptxK4FC/6BebX/SuM6c3ixb0 2NlwPqhz0zwGMTC/+oPt5KT62lXVT7E7S5mN8=
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=Y94Dm28qMEmYkmQsFcn9vdiFDTveqIb+HT8M9JZJatQ=; b=syoUa4VSE7cwHSPnupef7htzUHXp+8k6uypBlW0ICpxDCcgWwBVY2AX4SEyAdCFmWV gu6tHcINRPxz31qPsH9Ow71eaqe8sO0RM83HqMQeMc4YiwXsAmY6h5OzSHrhni97LZK8 8iCyMDIx5R//iWi1LiDZwE0TImvu5Xe2jugLvvVkX/OchUZbc2cRfwA96YOqBtg3rI0y dTp829seBvYYE2cuk7VOIQ/QmlTKtxikSX+kbRMrnQWalW9o37kbsmI8T33RkO0ajZAq fAkeIPSOpnv9VBJjmVrrHiUc7K/PMF45y1PSjRv/QdOzV3WPfcpOJ1GT7cewxIXT+Adl 4GMA==
X-Gm-Message-State: APjAAAVtQZYCXJxO7Oyuj0n+PnmufOas9w2ekCG94PdqZDodJkAGcDtJ fLTp5hNPXujDztzp0CVv+ffWgNdMS9BV362EhJ2pKDSjC1Xzxw==
X-Google-Smtp-Source: APXvYqzxP+EhCY9iJM7Vo2mZW1rylVx9WPeG6WBryTzpQrOBgDYAM6I1azvlLrWIsw3nAbiFwSrLaOcMyqwG3NY2nWE=
X-Received: by 2002:a67:cd1a:: with SMTP id u26mr9189552vsl.155.1562578351521; Mon, 08 Jul 2019 02:32:31 -0700 (PDT)
MIME-Version: 1.0
References: <CAM1xaJ9txy98s5Y+Sq5T5N1KaD-LvtrDTut=mUomjHFwTvWnDg@mail.gmail.com> <a4137531-7641-34f2-6443-1cd904b485e3@pletterpet.nl> <CAAiTEH8v4MqpOvvKzLCeY=3NL8UrY5=LehxXy_JVtAt48muMrw@mail.gmail.com> <38b61acb-d223-2d4e-bfd4-02cee87341a5@pletterpet.nl>
In-Reply-To: <38b61acb-d223-2d4e-bfd4-02cee87341a5@pletterpet.nl>
From: Jan Včelák <jv@fcelda.cz>
Date: Mon, 08 Jul 2019 11:32:20 +0200
Message-ID: <CAM1xaJ8Apv6PyyQ=Mv_G8NQPVyxG3Ni_WKeBBmEveX+SHZna=A@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Cc: Matthijs Mekking <matthijs@pletterpet.nl>, Matthew Pounsett <matt@conundrum.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IfU-F8lsyi17J3btwKqNKQLBPQ0>
Subject: Re: [DNSOP] ANAME loop detection
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: Mon, 08 Jul 2019 09:32:35 -0000

On Thu, Jul 4, 2019 at 4:55 PM Matthijs Mekking wrote:
> On 7/4/19 2:32 PM, Matthew Pounsett wrote:
> > I would say they should rely on that.  Why shouldn't they?  Isn't our
> > goal to get downstream servers to adopt the extension and do their own
> > lookup?  The server-side lookups and sibling records are bolt-ons to
> > handle the adoption period.  Remember, this record is geared toward
> > customers of CDNs being able to do get similar behaviour to:
> > www.example.com <http://www.example.com>. IN CNAME webfarm.cdn.net
> > <http://webfarm.cdn.net>.
> > at the apex of example.com <http://example.com>.  That was the original
> > problem we're trying to solve.  I read your statement above about "the
> > service they provide their customers" being about the CDN resolving
> > webfarm.cdn.net <http://webfarm.cdn.net>, which most CDNs can already do
> > within their own infrastructure.
>
> I am talking about DNS providers that perform CNAME at the Apex like
> features: a customer goes to them and opts in to this feature. Such a
> provider wants to make sure that it is providing the behavior the
> customer expects and thus wants to make sure it hands out appropriate
> addresses.
>
> Also what is wrong with an authoritative server already giving out more
> optimal answers than just the ANAME and sibling address records?

I also understand the sibling address records only as a mean to gap
the adoption period. It should not be a feature.

If the DNS provider (i.e. authoritative server) wanted to perform some
magic to provide more optimal answer than the resolver could get by
resolving the ANAME then there is no point of involving ANAME. You can
perform the magic with A/AAAA already.

> > Sending out the sibling records in the presence of this EDNS option
> > might make sense as a backup, since that is low effort on the part of
> > the authoritative, but a declaration by the querying server that it
> > understands ANAME and is prepared to do its own lookups should be
> > trusted by the authoritative server, and it should not to recursive
> > lookups.  To take that further, why would the authoritative server
> > believe that the results of any lookups it does would not be thrown away?
> >
> > This EDNS option should also be useful to recursive servers that
> > understand ANAME, and are planning to do their own ANAME resolution.
> > They can get their answer from the authoritative server much faster this
> > way.
>
> I am not sure if that is true. Perhaps if you do ANAME target lookup on
> the fly yes, but I think most implementations will have a side process
> that does the target lookup and the query resolution can get the target
> addresses just from cache.

This is speculative. The conditions may be very different in each setup.

> > This is also a way to measure adoption.  As the ratio of "EDNS do not
> > follow ANAME" queries to total ANAME queries approaches 1.0, we know
> > that adoption has been successful.  Maybe we could even begin to
> > deprecate authoritative resolution (of ANAMEs) at that point, and begin
> > to get back to something that looks more like plain CNAME.

This probably makes me like the option #1 the most.

Jan