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

Joe Abley <jabley@hopcount.ca> Sun, 01 September 2019 23:28 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 4DE791200C5 for <resolverless-dns@ietfa.amsl.com>; Sun, 1 Sep 2019 16:28:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 zILb5VXl6FxG for <resolverless-dns@ietfa.amsl.com>; Sun, 1 Sep 2019 16:28:47 -0700 (PDT)
Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 14742120074 for <resolverless-dns@ietf.org>; Sun, 1 Sep 2019 16:28:47 -0700 (PDT)
Received: by mail-io1-xd36.google.com with SMTP id f12so8201388iog.12 for <resolverless-dns@ietf.org>; Sun, 01 Sep 2019 16:28:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=J1P6bdlkSZdVKYVlqXPlmjfzWu6HIgSLCWru+kDF00g=; b=EvsnUDDX8lTFNZZYTjN5V7g6u5ffpO6UOsYa/RF5AHWOAotEabiBYnod7atoO0Yd1y wnwyUKZItLPvkOahX+M4rDqaSsI/KP7T9jpP/U8DZDLJG9XrrcU195Sj7KdkIkKEMbHX NwMSbO/2O1SpnEKeAUDXeifwGYkzMXw31FiO8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=J1P6bdlkSZdVKYVlqXPlmjfzWu6HIgSLCWru+kDF00g=; b=FLC3mBLHg0ioDi539YfentKhQ0M8rQkl5HG9SYt7z2hhfnfcOjPdiS4MapAmmTAC0U /k9QzA1eFhz/No8gNvquAVrfafdKIVJP4s0UN2OanBego+q9wZvB5TytEur/l9vdoQNA ltfPwebbbWFyORRH4iuUK2ugaqBq21Gxj7L43QSoSWQnHyTL9s944vk6PLu9KAxRl9Gp ztKIdCk0GuLX7ZNOgah2gaTqxbPDKJKW11hGfNVL6+Mk/px1oz1LiMBjXHWj1RWdeZ3J hJVk5cSC8haMPIk/4qIEW+67J3uwdh+LN7FVSE1O/GUY979VYukNeN3+7OMssM5HOmMF DEoQ==
X-Gm-Message-State: APjAAAVttYGC1JndXNLrUze8qJYXwrjovWLYZ+nJaR/uUZbJIflhaxM6 2KWIo6/thKb3mx5R5Pc35YFh/01LZkGx02fn
X-Google-Smtp-Source: APXvYqwVKTurWAL+NxrjJWNNxcGczXOhDZwJ+YzITQhYJdN61BLsxvYqSANrlnXEkj/YeTKpWswFsA==
X-Received: by 2002:a6b:730f:: with SMTP id e15mr31251929ioh.74.1567380526259; Sun, 01 Sep 2019 16:28:46 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:e786:128f:fd7c:7ea2:2bb8:4e0d? ([2607:f2c0:e786:128f:fd7c:7ea2:2bb8:4e0d]) by smtp.gmail.com with ESMTPSA id n1sm4530157iob.7.2019.09.01.16.28.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Sep 2019 16:28:44 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <D884C00B-CE41-4675-AE59-EA346859EAE7@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_6000CB71-F335-4B8E-BD88-77872246F293"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Sun, 01 Sep 2019 19:28:42 -0400
In-Reply-To: <2f2377f4-2c7d-566e-2168-3ad77811de66@informatik.uni-hamburg.de>
Cc: resolverless-dns@ietf.org
To: sy@informatik.uni-hamburg.de
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> <4F173B85-D52F-46F8-90A3-24F7FF59E234@hopcount.ca> <2f2377f4-2c7d-566e-2168-3ad77811de66@informatik.uni-hamburg.de>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/mocd3h7qIt-HHaQP_c2qapQEemI>
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: Sun, 01 Sep 2019 23:28:48 -0000

Hi Erik,

On 1 Sep 2019, at 16:40, Erik Sy <sy@informatik.uni-hamburg.de> wrote:

> Thank you for this detailed explanation!
> 
> I assume that web server supporting resolver-less DNS provide only DNS
> records for a small number of domain names. [...]
> 
> Are you aware of more aspects of how resolver-less DNS can contribute to
> a better geo load-balancing?

It's difficult to answer that question in any meaningful way, in a world as we are where resolverless DNS is neither clearly specified nor implemented.

I do think that improving traffic engineering opportunities for CDNs and their end-users and taking some of the heavy lifting involved in that out of the DNS would be a worthwhile goal and perhaps even a reason to work on it, though.

Clearly there are a lot of corner cases here that affect operations, security, performance, the whole supporting cast for user experience really, so I don't expect this to be easy. Finding a way to constrain the parts of the namespace that are in play within the TLS bundle to avoid cross-site threats does seem like part of the problem space though, to me.


Joe