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

Joe Abley <> Sun, 01 September 2019 23:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DE791200C5 for <>; Sun, 1 Sep 2019 16:28:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zILb5VXl6FxG for <>; Sun, 1 Sep 2019 16:28:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 14742120074 for <>; Sun, 1 Sep 2019 16:28:47 -0700 (PDT)
Received: by with SMTP id f12so8201388iog.12 for <>; Sun, 01 Sep 2019 16:28:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with ESMTPSA id n1sm4530157iob.7.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Sep 2019 16:28:44 -0700 (PDT)
From: Joe Abley <>
Message-Id: <>
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: <>
References: <> <4568720.uvMTqBdgP4@linux-9daj> <> <34813218.VKkrhzyXsx@linux-9daj> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [Resolverless-dns] Paper on Resolver-less DNS
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Resolverless DNS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Sep 2019 23:28:48 -0000

Hi Erik,

On 1 Sep 2019, at 16:40, Erik Sy <> 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.