Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest

Philip Homburg <pch-dnsop-3@u-1.phicoh.com> Tue, 31 July 2018 14:38 UTC

Return-Path: <pch-bCE2691D2@u-1.phicoh.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1A2130F8A for <dnsop@ietfa.amsl.com>; Tue, 31 Jul 2018 07:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 ljFc2P3AZrOl for <dnsop@ietfa.amsl.com>; Tue, 31 Jul 2018 07:38:39 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46C4130F7F for <dnsop@ietf.org>; Tue, 31 Jul 2018 07:38:38 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fkVnH-0000H0C; Tue, 31 Jul 2018 16:38:35 +0200
Message-Id: <m1fkVnH-0000H0C@stereo.hq.phicoh.net>
To: dnsop@ietf.org
Cc: Joe Abley <jabley@hopcount.ca>
From: Philip Homburg <pch-dnsop-3@u-1.phicoh.com>
Sender: pch-bCE2691D2@u-1.phicoh.com
References: <CADyWQ+HizOJsE9EZ=VEvrbnnyPwaG_yBRg7fP5VvUNTdnidXZA@mail.gmail.com> <ybl4lgg6ztm.fsf@w7.hardakers.net> <m1fkRCk-0000GTC@stereo.hq.phicoh.net> <2766BDE0-41C3-4C45-B5E0-445472C56956@hopcount.ca>
In-reply-to: Your message of "Tue, 31 Jul 2018 09:38:11 -0400 ." <2766BDE0-41C3-4C45-B5E0-445472C56956@hopcount.ca>
Date: Tue, 31 Jul 2018 16:38:34 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6vTtKhTORrIZrVttz1vicH8EYdA>
Subject: Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 31 Jul 2018 14:38:44 -0000

> Are you suggesting that web servers can't be massively scaleable
> ?
> I'm not sure I understand your examples.

Yes, you can build massively scaleable web servers, but at what price?

What if some popular IoT device starts to fetch the root zone. And at a
high rate?

> You cite overprovisionoing in the root server system as a reason
> not to try and supplement it, but I think it makes sense to look
> at it the other way round -- if there were ways to distribute th
> e
> root zone reliably and accurately without presenting the attack
> targets that the root server system does, the need for continued
> investment in the infrastructure could be reduced (or the effect
> ive
> benefit to end-users from that investment could be increased).

What if your web servers are not massively overprovisioned? Can we handle
failures there. If you do massively overprovision those web servers, will it
actually be cheaper or better than the current system?

> The bandwidth available at the consumer edge, where a lot of the
> attack sources now live, continues to grow far faster than the
> bandwidth that can be provisioned at the root server edge. The
> observation that "there's enough bandwidth that we're safe" does
> n't
> seem future-proof (it doesn't even seem present-proof, really).

>From a ddos point of view there doesn't seem to be big difference between
how the current DNS root absorbs traffic and what a highly available web
service would have to do.