Re: [Resolverless-dns] Load-balancing concerns

Justin Henck <> Thu, 08 November 2018 09:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3736D128BCC for <>; Thu, 8 Nov 2018 01:16:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uw98N_LcnA72 for <>; Thu, 8 Nov 2018 01:16:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C149712870E for <>; Thu, 8 Nov 2018 01:16:18 -0800 (PST)
Received: by with SMTP id u62so4396969vkb.3 for <>; Thu, 08 Nov 2018 01:16:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DRWlrEMuTac7fcxQFwDqRVSxIUpT+HCoSN5NCJsBzYA=; b=YjkqnBaQJS5bxv4SjUx9vAhXyHvGFrx4v/bcaM8nPoDcF9vAZCSsHmHxdS6xWWDCHE GBNsmo0Qu9uD0PlgKeO8wPzvB8Eeh1gkfkFv6w6hzZGLCAUYnuw4JrabeX2wLK2L3r56 jEIF9XhF1BTuXqDy8zBqo08O6B/v6pCvZVp2M66uOT0a1srGanwtx5YwMdfcKPJZYPjb kxv9oFGZWg55ArOZppkrkF8iExvae/2K6o9MVjQLNNfTtCJy3sBJQ8IQHpkgIV1iONQE SA0qKEqrG34D9OcI6SM+bsqCAHI9yuCWpm7vu8opELVszCSI6HheLE5DRathqQZ6veCM Ii1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DRWlrEMuTac7fcxQFwDqRVSxIUpT+HCoSN5NCJsBzYA=; b=MOjX4CsI+tZxXhEy6ty+YjhyeD7KHPZFAzqjReTjXkC9LIU1s3acq9V7SVu4So22Cy vU3HzTQ+tbKljJXf33UJneE0/RP+xfqJWI8XHw6zTT1kouqVYwZt7w6HYqq1s36Y+EuA ztvJAjpRGei5IdztukMbckcZAXp870CckmzQEnzsdLGn1lj9Tw8GemXgLFKL/C7/IXsY f+b+6fGc7acqiSeJBdRejaNoDNJ8GqpGbBf5KCVo2LM2ATF7uT634W9OdYN3J681gQOJ s9ppXh3mfAche+E0Jry5uhEmUj3lDlF4GatI5UwOEEGitS22BvpaUMEbyJGFNMX2b4Ib TKCQ==
X-Gm-Message-State: AGRZ1gJFecyXdzufUF7HrjZyOX+qpgMFAdxYONgXAalaD/vIkH0XgbcR jLprzQkBtoIetKmN2BiQ30UoS/ph1vDwyrepzuKqpw==
X-Google-Smtp-Source: AJdET5dwJvMfRWlgo0M1g2v6+zSroKg3icnYzmmM+LFaY06xAaiiM4wr1GmDjfi+/8TZjIvixhWEZ1C4DJDrOQOwJMY=
X-Received: by 2002:a1f:2145:: with SMTP id h66mr1643756vkh.65.1541668577510; Thu, 08 Nov 2018 01:16:17 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Justin Henck <>
Date: Thu, 8 Nov 2018 16:16:04 +0700
Message-ID: <>
To: Jim Reid <>
Content-Type: multipart/alternative; boundary="000000000000ed04e2057a23afbe"
Archived-At: <>
Subject: Re: [Resolverless-dns] Load-balancing concerns
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: Thu, 08 Nov 2018 09:16:21 -0000

Got it, I made a mistake and inferred behavior from recursives :-/

How is a "resolverless" (unrequested resolution?) solution here any
different from sharing a recursive, if we use ECS or if the primary service
is widely deployed?

E.g. it seems to me that there are three scenarios:
1) really large globally distributed services implementing will act like
geographicaply distributed resolvers, which some of them also are
2) small single-datacenter services won't produce enough traffic to matter
3) large single-datacenter services might cause a problem

Are there other negative scenarios? I suppose 1 but not very well

On Thu, Nov 8, 2018, 3:47 PM Jim Reid < wrote:

> > On 8 Nov 2018, at 08:19, Justin Henck <>
> wrote:
> >
> > You'll have to forgive my ignorance - I definitely don't pretend to be
> an expert in any of these areas.  My understanding (please correct me!) was
> that generally an authoritative will return a single A or AAAA record based
> on a particular query, but with DNSSEC it will return an entire relevant
> Not quite. If an authoritative server is queried for the A or AAAA records
> for some name, it will return all the matching A (or AAAA) records. [Modulo
> truncated responses and TCP retries.] It won't return a single A or AAAA
> record unless of course there's only one of them.
> When DNSSEC is used, authoritative servers return RRsets.* That's because
> the signature covers the RRset and the validator has to have all of the
> original data -- the RRset -- so that it can validate the signed response.
> *That's pretty much the same as the unsigned response with the addition of
> some extra RRtypes for the DNSSEC special sauce.