Re: [Resolverless-dns] Load-balancing concerns

Justin Henck <> Thu, 08 November 2018 08:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E4E1130DD9 for <>; Thu, 8 Nov 2018 00:19:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Status: No, score=-17.501 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, 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 NSijeO93BURn for <>; Thu, 8 Nov 2018 00:19:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 85B1A1294D0 for <>; Thu, 8 Nov 2018 00:19:35 -0800 (PST)
Received: by with SMTP id d8so6893436ual.2 for <>; Thu, 08 Nov 2018 00:19:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=8vG13YZiCyPM7PrDI/XX79C7PYCQswVmEoDvz1gl/HI=; b=Oa8DmPd6DRl89fCN/w1wd8v3kYcG9OUEZ2A638RPr3UsE1lvoPRsqW5vTo4LdWsiOm 72ZNDQSBW7QD0Frq/zVK2CBK85aoN1DtVkqeSswyoSplNX2Zh+Dmp9aKI2C4FzJE1c29 DWwEQQnexsEV9Q0OPj6Z81LH2RhyIRuJcXuHuc97W4yN0U+60ogOgsGgftvSAfwLLVI9 G1ANoC5KlHLyO59ugqg/3MqoK8ACwFiEdtVm9xzb59c3q30+b73LzBh4s8BQHY4rtqdI uitH6tnAAOPbLnB7ZzQO6SVmH5Nocyg550vRZJkIdF0ZPhar91ObA2p+8Doke/7emk2z LjOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8vG13YZiCyPM7PrDI/XX79C7PYCQswVmEoDvz1gl/HI=; b=lv5TfgouBoc/HJk3Bwi2yj9KxdIVUJutrhAA0QUlHaPhNlJIuS0D7j1UQMd5/yJJXf R4qUkv2dm+BaveUTJI3M09JO05i3myU9LOJNHoa+xtMPRz/E/Qf06qkJlUt+dMnRDXJX OMn03x9pGXvHqqrP615aKi+s4llvFf4ospp1HV96Ptna9Qro6L1eplV29PUBhrDV8gpd M6Fnjn24yrBGUAg/sZQdmXD1cwFMtHxNMS+YAyVnQti+2UfM/qBgi5t46HjiQ/AVn2o1 lmeEpATUmDjrNYjbnrsCTMXtdoNOE+SZse5QY6Yjggv396IQuwDFqkUvFVVOkkzlCDH0 a82w==
X-Gm-Message-State: AGRZ1gJKKrKn/TSbyvHGsKvytdH5aG5giCi47igmJ0nndstnDXCyTYru urSyTR5cKWQJpzw1WEoiG1CEP9EH0jdSDxLre7yawB5KGwTl6A==
X-Google-Smtp-Source: AJdET5dSz21BhYW0iTSV4rNOjxJtahj/q0qgpC6urslBNzYfmN8J/49FTEMQAaAgV4/5LlYjZ8YAlSHG/LP/zJnIAN4=
X-Received: by 2002:a9f:2622:: with SMTP id 31mr1663613uag.90.1541665173931; Thu, 08 Nov 2018 00:19:33 -0800 (PST)
MIME-Version: 1.0
From: Justin Henck <>
Date: Thu, 8 Nov 2018 15:19:21 +0700
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000000e6834057a22e544"
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 08:19:38 -0000

> I'm afraid I don't understand the connection you're making.  What does
> the setup, "would have to push an entire RRSET", have to do with the
> rest of "If we combine that..."?  I'm not clear on how DNSSEC makes
> any difference at all in this particular problem.
> My guess is that you are imagining a situation where all possible
> addresses that clients could receive are put into one A or AAAA
> RRset.  This isn't the way most such systems work though.

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
RRSET.  So although there might be multiple such RRSETs you will at least
have (perhaps) more than one IP.

I was imagining a worst-case scenario (heavily simplified):
Primary Server  - In country "A"
Referred Service - Global. Has different sets of servers for different
Many Users - In country "B"

1. Many Users load page from Primary Server in a short time.
2. Primary Server queries for a record for Referred Service.
3. Primary Server caches a single IP in country "A" for Referred Service
4. Many Users hit single IP for Referred Service which experiences Bad

The partial alleviation I was hypothesizing about was:
1. Many Users load page from Primary Server in a short time.
2. Primary Server queries for a complete RRSET for Referred Service
3. Primary Server caches country "A" RRSET for Referred Service
4. Many Users' clients pick different IPs for Referred Service and connect
to them
5. Many Users' clients receive AltSvc records telling them to use an IP in
country "B" for their next connection

Pure point of ignorance: To your point about different clients getting
different IPs - does that extend beyond the resolver+ECS level? E.g. if
10,000 customers using a mobile carrier in a single city hit their ECS-less
resolver for a particular domain, will they get different IPs?

Justin Henck
Product Manager

PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B