Re: [Resolverless-dns] Load-balancing concerns
Dave Lawrence <tale@dd.org> Thu, 08 November 2018 09:27 UTC
Return-Path: <tale@dd.org>
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 66D4E130E83 for <resolverless-dns@ietfa.amsl.com>; Thu, 8 Nov 2018 01:27:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 UkBbLpQobPlG for <resolverless-dns@ietfa.amsl.com>; Thu, 8 Nov 2018 01:27:07 -0800 (PST)
Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89F7130E7A for <resolverless-dns@ietf.org>; Thu, 8 Nov 2018 01:27:05 -0800 (PST)
Received: by gro.dd.org (Postfix, from userid 102) id D699832AB0; Thu, 8 Nov 2018 04:27:04 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23524.360.861432.338830@gro.dd.org>
Date: Thu, 08 Nov 2018 04:27:04 -0500
From: Dave Lawrence <tale@dd.org>
To: resolverless-dns@ietf.org
In-Reply-To: <CAN-AkJtKbgy0RNf6c5TZd3j5SsjaYe4CwtkaQzYA=FhrrAvJAA@mail.gmail.com>
References: <CAN-AkJtKbgy0RNf6c5TZd3j5SsjaYe4CwtkaQzYA=FhrrAvJAA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/resolverless-dns/Z-weScHPkQxMvjBdC7HLKYlVKic>
Subject: Re: [Resolverless-dns] Load-balancing concerns
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, 08 Nov 2018 09:27:09 -0000
Justin Henck writes: > 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. It depends. Non-mapping authorities, the pre-CDN norm and still very common, will return every record matching the qname/qclass/qtype tuple. That's the RRSet. Most names (hand-wavingly most--I confess no data) only had one address for A or AAAA though so your sense that they would generally return a single record is probably apt. The presence or absence of DNSSEC doesn't really change any of the preceding. Then CDNs with their mapping authorities came along and muddied things a bit. Akamai would, for example, generally provide two IP addresses in an answers to any given query, but from a much larger pool. Because the number of permutations was large that also meant CDNs were late to the party on DNSSEC implementation, and didn't offer it at all for a very long time so asking for it wouldn't have changed their behaviour. Now those that offer DNSSEC tend to do so with some form of online signing -- it's way too much to sign all the permutations individually and or to hand out all thousands of addresses in one RRset, so they sign just the one their answering with when they need to, and still only hand out a couple (or few) at a time. So the presence or absence of DNSSEC here also ultimately doesn't make a difference as far as how many addresses a client is seeing in a response. > 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? It depends again, but mostly they get the same IPs because caching. It depends a little on what time scale you're looking and other things happening at the time. CDNs can keep mappings pretty stable for long periods of time, so all those clients would tend to get the same addresses over multiple TTL cycles. If a flash mob comes along they might quickly remap the load so that successive refreshes of the cache end up with different addresses.
- [Resolverless-dns] Load-balancing concerns Justin Henck
- Re: [Resolverless-dns] Load-balancing concerns Dave Lawrence
- Re: [Resolverless-dns] Load-balancing concerns manu tman
- Re: [Resolverless-dns] Load-balancing concerns Dave Lawrence
- Re: [Resolverless-dns] Load-balancing concerns manu tman
- Re: [Resolverless-dns] Load-balancing concerns Justin Henck
- Re: [Resolverless-dns] Load-balancing concerns Jim Reid
- Re: [Resolverless-dns] Load-balancing concerns Justin Henck
- Re: [Resolverless-dns] Load-balancing concerns Dave Lawrence
- Re: [Resolverless-dns] Load-balancing concerns Dave Lawrence
- Re: [Resolverless-dns] Load-balancing concerns Justin Henck