Re: [DNSOP] Anycast and DNS questions

George Michaelson <ggm@algebras.org> Wed, 03 September 2014 23:27 UTC

Return-Path: <ggm@algebras.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E595E1A6FD8 for <dnsop@ietfa.amsl.com>; Wed, 3 Sep 2014 16:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 J3YfDfId7KED for <dnsop@ietfa.amsl.com>; Wed, 3 Sep 2014 16:27:34 -0700 (PDT)
Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374DB1A0ADD for <dnsop@ietf.org>; Wed, 3 Sep 2014 16:27:34 -0700 (PDT)
Received: by mail-pa0-f47.google.com with SMTP id hz1so18470797pad.20 for <dnsop@ietf.org>; Wed, 03 Sep 2014 16:27:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6G8YnSdZQcQaAUtxPcCFeIhVc1itm3Xi8/7nBqTeato=; b=KFQcpfEH+DoeZ88qfjdmG6TsBTGs52rPahhKSNtLuZN/OHgrZJG3qbGza2kJkHyHeT 9j+/H52DFOLSELa7qs/ONLHOYW9D5Xu91z++JkfTMs8DGG7K7fpoa6CKBcQj3YCFnK03 WrwEJH9+7inArSdVm2VlFgL+1J4BC040mnedvvwhWHZ4JZSvCSx3UjcDvgGzURqqRMmo QAJe43S2H91zSHVunqx/u+JYiYEnzzJ4EgujcYQYrSzod3eajrMUBilUTWNfpIQ9Yscw yx9L/w000GRBDpmIXZ+8aqA0P2Ro8TJNcmcNpm5+NImDP7NH4D5kKLAeMynuxU4/roTT zmPg==
X-Gm-Message-State: ALoCoQnc0JgYkOdnLZMb3LpLrZcl6Dkwxym7uBTBdxIx3ZA1Amejm+9hH6fHeOtGe4zppu9EZQgh
MIME-Version: 1.0
X-Received: by 10.70.88.237 with SMTP id bj13mr1120482pdb.57.1409786853723; Wed, 03 Sep 2014 16:27:33 -0700 (PDT)
Received: by 10.70.95.135 with HTTP; Wed, 3 Sep 2014 16:27:33 -0700 (PDT)
X-Originating-IP: [2001:dc0:a000:4:7831:c1ff:fe5c:6600]
In-Reply-To: <1704A9DF-C082-451F-9962-69AC20495313@virtualized.org>
References: <20140806114759.GF5546@cisco.com> <25907D96-0076-417A-8DB9-41A5A178D479@ianai.net> <20140806123205.GG5546@cisco.com> <2014082716115865363718@cnnic.cn> <BAF35D7F-D6BA-45F3-B57E-BAF25F940355@virtualized.org> <5405718F.5010007@sidn.nl> <2014090312002502171843@cnnic.cn> <5406DD50.5040502@necom830.hpcl.titech.ac.jp> <2014090323421459684126@cnnic.cn> <1704A9DF-C082-451F-9962-69AC20495313@virtualized.org>
Date: Thu, 04 Sep 2014 09:27:33 +1000
Message-ID: <CAKr6gn3i1Two0aOYw728i=PmN1Kyb-m7ZdfujThOQist5N=-wg@mail.gmail.com>
From: George Michaelson <ggm@algebras.org>
To: David Conrad <drc@virtualized.org>
Content-Type: multipart/alternative; boundary="001a11c23b52a02536050231940b"
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/HjiVjofEUhtu9vipjmJ5G-7LCI4
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Guangqing Deng <dengguangqing@cnnic.cn>
Subject: Re: [DNSOP] Anycast and DNS questions
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Sep 2014 23:27:39 -0000

DNSSEC signing problems get worse with more NS, if the signatures go bad.
Even with the remediation Mark Andrews put in later bind, there is an
increase in traffic at the authority points and in the system as a whole.

So "more is better" is not necessarily true.

Also, AAAA ns and A NS are morally considered 'different' NS by the system
because they do not present as the 'same' NS to the logic of 'where shall I
ask next' (I don't understand why: the NS label should be the same.
however, we observe that we see NS traffic on the V6 and V4 at the same and
also sequentially. Therefore, I beleive this)

So, having the SAME NS in as both V6 and V4 (is that V10?) does not help
you: it can, in bad DNSSEC, actually hinder you.

Oh, 464XLAT since it has to write non-authoritative changes into AAAA/A
bindings, breaks DNSSEC. so if you are behind 464XLAT, and DNSSEC signed,
more NS is not neccessarily helping you...


On Thu, Sep 4, 2014 at 3:01 AM, David Conrad <drc@virtualized.org> wrote:

> Hi,
>
> On Sep 3, 2014, at 8:42 AM, Guangqing Deng <dengguangqing@cnnic.cn> wrote:
> > From RFC1034 section 4.1, it seems that the way used for improving the
> redundancy and resilience of DNS system is to increase DNS servers. I agree
> that for the performance of the DNS system, the redundancy and resilience
> are the first goal and low latency is the second goal. Usually, the first
> goal mainly depends on the DNS server deployment policy (such as the total
> number and geographical distribution of DNS severs) and the second goal
> relates to not only the DNS server deployment policy but also the method
> used for DNS clients selecting the best DNS server like any cast.
>
> Careful here.
>
> Anycast improves redundancy/resiliency for the system as a whole.  As
> typically deployed, it may not improve redundancy/resiliency for a single
> client.  For example, if a DNS server instance in an anycast cloud is no
> longer responding to DNS queries due to a DoS but the routing announcement
> of that instance is not pulled down, the clients topologically nearest that
> instance will not see improved redundancy/resiliency — they’ll not see any
> responses.
>
> Anycast may or may not improve latency — it depends on the routing system.
> If the “nearest” instance network topologically to a set of clients happens
> to be on the other planet, latency will not be improved for those clients.
>
> Anycast is a very blunt tool. It can help improve redundancy/resiliency
> and latency if properly deployed, constantly monitored, and maintained, but
> it is very important to understand its limitations and implications.
>
> Regards,
> -drc
>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>