Re: [Resolverless-dns] Paper on Resolver-less DNS

Joe Abley <jabley@hopcount.ca> Thu, 29 August 2019 22:15 UTC

Return-Path: <jabley@hopcount.ca>
X-Original-To: resolverless-dns@ietfa.amsl.com
Delivered-To: resolverless-dns@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AAD120C1B for <resolverless-dns@ietfa.amsl.com>; Thu, 29 Aug 2019 15:15:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 TxNxkBttozsV for <resolverless-dns@ietfa.amsl.com>; Thu, 29 Aug 2019 15:15:54 -0700 (PDT)
Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 A49E51200A3 for <resolverless-dns@ietf.org>; Thu, 29 Aug 2019 15:15:54 -0700 (PDT)
Received: by mail-pf1-x443.google.com with SMTP id g2so3075607pfq.0 for <resolverless-dns@ietf.org>; Thu, 29 Aug 2019 15:15:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SNc8L3HvN3sstWqtBdiBWwkhvBUNf3WmSEgu1vVbOJU=; b=T+PzbYPX7H0kFnxxyES1Y7zw6eoqw32FDox+/peaS9aHQTstrU0bdz9vLMzsnsAD4h I4DAfjYy2ud60DRKgTl0O1LskVWUxzoVupx9WR3I6nO6hBYAqoQBzvofmzT1KkvfVAQ7 Z795ct2LofhthRtT/1wcWf/KeCImZ/ZIWH2P4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SNc8L3HvN3sstWqtBdiBWwkhvBUNf3WmSEgu1vVbOJU=; b=D4tzvi/PahVdbIEAT7hzB2yvAiETcIAEF1z11HyQYdH7T2hYaRcVIQTrHB0e7AVPDM 0Wrd/KjtjQ58cpew1u3x0PoHhqrHhcgF1A4d3nspnrpHuFiGyMfiTJ7o3ZndYsZ9I70g n5bVmm/WxZSE3QdFMW+kjcuoDggw9x6vvCx7iw4IHKJgbxUQZI89ThNZzNxL7zL/wiKh mv1EhQUxlr+xl/FewxxmJuXySkhH3GPujU65FE0X0fMle9Y+OSkEX2PWt5z6VF1fo0oK 8ULfCf3JdkwjueRDb4ivVwaL/wzYbEoU25HMHl5CNl1axOT6fs8+Qm8idtAk3o4s6Lji HEzw==
X-Gm-Message-State: APjAAAUGY18oSfrTPXXfW+e3c7bUxI9LrKvyimozI3gXXLv7UWrk//F4 /sx9YDCU/1sdhiOFG/gFj9fwcPzlnHgeVw==
X-Google-Smtp-Source: APXvYqy2RIWzgyBHWzWj+tJsVkLkIbRSeOd1BuMWDNeXlExTpP7CJXrXPO/joRzYBEdsEeoQRmZz5g==
X-Received: by 2002:a63:1507:: with SMTP id v7mr94100pgl.397.1567116953415; Thu, 29 Aug 2019 15:15:53 -0700 (PDT)
Received: from [25.171.177.25] ([172.58.27.9]) by smtp.gmail.com with ESMTPSA id j1sm3877797pfh.174.2019.08.29.15.15.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 15:15:52 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Joe Abley <jabley@hopcount.ca>
X-Mailer: iPad Mail (16G102)
In-Reply-To: <64650d58-924f-c0f3-d181-614d59527477@informatik.uni-hamburg.de>
Date: Thu, 29 Aug 2019 18:15:49 -0400
Cc: resolverless-dns@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F173B85-D52F-46F8-90A3-24F7FF59E234@hopcount.ca>
References: <CAHbrMsBhR1yaLxQk7wZk54Jdf5nvkS03KC3UTae0Famu2+SV8g@mail.gmail.com> <4568720.uvMTqBdgP4@linux-9daj> <fb12f102-714d-95cc-c6cc-0871a2df9f50@informatik.uni-hamburg.de> <34813218.VKkrhzyXsx@linux-9daj> <ae355776-a1bb-cf23-f380-133439661d1f@informatik.uni-hamburg.de> <1171283855.590.1566558699991@appsuite-gw1.open-xchange.com> <a8d9398b-4fea-0a1e-3fa7-5954d001f9ea@informatik.uni-hamburg.de> <1405682425.665.1566561941610@appsuite-gw1.open-xchange.com> <220061a8-608c-0a87-4656-213c87979284@informatik.uni-hamburg.de> <849BE7D4-A07E-496B-B413-E1C979390DA8@osterweil.net> <b2b3e56a-c577-f08a-627a-f54e2e6fadb6@informatik.uni-hamburg.de> <f093a605-6e7d-0237-df5c-441d6789c66f@erik-sy.de> <54892F22-27E4-4444-9CC8-2D9E84A9668F@dukhovni.org> <4ec7dd1d-e914-0adb-4240-296f2f762b5f@informatik.uni-hamburg.de> <ADC6E119-0EED-4990-A975-F594C9282872@dukhovni.org> <64650d58-924f-c0f3-d181-614d59527477@informatik.uni-hamburg.de>
To: sy@informatik.uni-hamburg.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/eeopltqk3zQaX1NpWJ_EgDf544M>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-BeenThere: resolverless-dns@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <resolverless-dns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/resolverless-dns/>
List-Post: <mailto:resolverless-dns@ietf.org>
List-Help: <mailto:resolverless-dns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/resolverless-dns>, <mailto:resolverless-dns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Aug 2019 22:15:57 -0000

Hi Erik,

On Aug 29, 2019, at 17:28, Erik Sy <sy@informatik.uni-hamburg.de> wrote:

> On 8/29/19 17:34, Viktor Dukhovni wrote:
>> breaks geo load-balancing,
> No, there are no new issues with geo load-balancing compared to using a
> public DNS resolver.

I am usually pretty wary of absolute statements, especially those that declare the absence of something. I haven't seen a comparative security assessment of both (and it surely depends on precisely what model of resolverless DNS you mean), though, so I will not take a side in the entertaining debate that seems likely to result from that.

However, I do think it's also worth pointing out that geo load-balancing using the DNS today is already a terrible mess and it will be a joyous day when it can be replaced by something less bad.

(soapbox noises)

The general process by which a DNS server responds to a query for a (name, class, type) tuple that is configured with geo-specific answers is to process a set of rules at query time, consulting general-purpose databases maintained at the DNS edge that map an address to something like a (provider, city) pair, and then doing additional database lookups to determine the response that should be sent to the client for the particular service whose name (one of whose names) the client is looking up.

The complexity of the code at the DNS edge is significant, and significant failures have been observed. In an enterprise DNS provider, the code that does this stuff is often not available for public review, since it constitutes secret sauce that tastes of competitive advantage. This stuff is really hard to do without failure and introducing customer-enraging latency; it's not unreasonable that people try to protect their investment.

Centralised resolvers need to make use of the EDNS0 client-subnet option in order to allow the user's real location to be exposed to the server that is geo-answering. The EDNS0 client-subnet option has unintended consequences (see David Dagon's recent descriptions).

The database that maps addresses to (provider, city) pairs is either frequently inaccurate (watch *NOG lists for pleas for help from operators whose customers are being served from nodes far away) or is accurate because it is maintained by mining other data sources. If you have a really broad anycast network you might be able to imagine doing this based on routing and answering node location; for everybody else those data sources are real user monitoring scripts running in browsers on not-obviously-related web sites, all performing performance measurements and centralising the results without the users of those stooge web sites necessarily being aware, or at least being given the option to opt-in.

Complicated web services, perhaps especially those with complex UX, use all of these techniques together with a litany of short-lived, non-repeated DNS names intended to customise and optimise the performance for the end-user. The end result in some networks has been the observation that these short-lived names consitute such a high proportion of cached data (e.g. in campus resolvers) that "we don't have the RAM to handle another Facebook".

Some big access providers configure resolvers with hundreds of exit addresses so that they will source queries for particular names towards enterprise DNS servers from dedicated sources, as a workaround for when the geo-ip on the server is known to fail. This might seem like a ridiculous optimisation until you appreciate that your entire network's capacity planning might depend on decisions being made by CDNs and enterprise DNS providers, and anything you can do to avoid mistakes in those third-party systems is another week you get to keep your customers.

In short, the status quo is extremely slippery, architecturally messy, frequently non-deterministic and high-overhead, one that has been observed to put the burden of performance measurement and reporting on unrelated third-party Internet users, chasing an end-result that is often still not doing a very good job.

As far as DNS geo-mapping for the purposes of content steering today is concerned, the only way is up.

Rearchitecting the whole enterprise DNS and CDN industries is a task on a scale larger than moving from IPv4 to IPv6. However, what we *can* do is take specific components of the problem space and find more-elegant solutions. It seems to me that resolverless DNS has the potential to be one of those. The status quo here is almost not worth defending; some kind of change is needed.


Joe