From nobody Thu Nov 2 07:40:21 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A7313F830 for ; Thu, 2 Nov 2017 07:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 GLqwd6GO9IbD for ; Thu, 2 Nov 2017 07:40:18 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C58113F6BC for ; Thu, 2 Nov 2017 07:40:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3ySSRg6z1rzMnGJ; Thu, 2 Nov 2017 15:40:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Pfw8Z2tFx8x; Thu, 2 Nov 2017 15:40:14 +0100 (CET) X-MtScore: NO score=0 Received: from [161.23.243.157] (unknown [161.23.243.157]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 2 Nov 2017 15:40:13 +0100 (CET) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <2FDB72C6-C818-4740-8C18-8852DA70147A@tik.ee.ethz.ch> Date: Thu, 2 Nov 2017 14:40:12 +0000 Cc: maprg@irtf.org To: Brian Trammell , Roland van Rijswijk - Deij , "Giovane C. M. Moura" , Wes Hardaker , Nieminen Klaus , Dave Plonka X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Maprg] Please send slides for maprg by Nov 10! X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 14:40:20 -0000 Hi maprg speakers, as always we would like to have your slides slightly early to be able to = provide you feedback on the scope needed for maprg. Please send your = slides by Nov 10 for review to Dave and me. Thanks and see you in Singapore! Mirja From nobody Wed Nov 8 05:51:17 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DAF127058 for ; Wed, 8 Nov 2017 05:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 hHRyoMkx7KJH for ; Wed, 8 Nov 2017 05:51:14 -0800 (PST) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A3F126D45 for ; Wed, 8 Nov 2017 05:51:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3yX74H6ZcCzMnLY; Wed, 8 Nov 2017 14:51:11 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD_hjamVGYL5; Wed, 8 Nov 2017 14:51:06 +0100 (CET) X-MtScore: NO score=0 Received: from [172.16.2.110] (unknown [211.237.218.83]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 8 Nov 2017 14:51:03 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <2FDB72C6-C818-4740-8C18-8852DA70147A@tik.ee.ethz.ch> Date: Wed, 8 Nov 2017 22:50:58 +0900 Cc: maprg@irtf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9EE701C0-7323-4F2B-8140-96699DFF21CB@tik.ee.ethz.ch> References: <2FDB72C6-C818-4740-8C18-8852DA70147A@tik.ee.ethz.ch> To: Roland van Rijswijk - Deij , Wes Hardaker , Nieminen Klaus , Dave Plonka X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Maprg] Please send slides for maprg by Nov 10! X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 13:51:16 -0000 Hi speakers! This is a friendly reminder to send your slides as soon as possible, = latest by Friday (2 days)! Please let me know when you plan to have them = ready! Thanks! Mirja > Am 02.11.2017 um 23:40 schrieb Mirja K=C3=BChlewind = : >=20 > Hi maprg speakers, >=20 > as always we would like to have your slides slightly early to be able = to provide you feedback on the scope needed for maprg. Please send your = slides by Nov 10 for review to Dave and me. >=20 > Thanks and see you in Singapore! > Mirja >=20 >=20 > _______________________________________________ > Maprg mailing list > Maprg@irtf.org > https://www.irtf.org/mailman/listinfo/maprg From nobody Mon Nov 13 01:49:57 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D1D129457 for ; Mon, 13 Nov 2017 01:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 KpFdwrqZPBmv for ; Mon, 13 Nov 2017 01:49:53 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A80C12762F for ; Mon, 13 Nov 2017 01:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-mailer:x-ms-exchange-messagesentrepresentingtype:x-ms-exchange-transport-fromentityheader:x-originating-ip:content-type:mime-version; bh=boAkXBBsse2b5JqvHACDOwxpNKH0yBpuiuyODUA+weU=; b=wjeCOgxKcCO1hfYNKGtYYyR9fhePz5K7Ar2d96p+/QjbiiaVHy0kmO9Vhi6BgI+Nrrs1CKuTjMa4vuvvXJjO7DWI/DjCSxlucb7dFFjZlDc1oTfyjkWE1us0/5g7Lfm2MR6H0x8T6eiG0TcOtl81+XK/RX/MWVZKuz+htqFA9reePnIXejROk0lvBbAPApTUdix6hj5T6vujxLoRe+u4oL2RFttBIDbs1oe0cULh2J7xITRssShzuxCUZD9Hp25trUd2tpYbvgpcwzyrKJWcglPnRBlxgRGwY/YyaGNlN4bUOHJU2zX/95oqpYdthFJl/GMXd5mpVQ0T4hrB8W5N1Q== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id vAD9npYj011968-vAD9npYl011968 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Mon, 13 Nov 2017 10:49:51 +0100 Received: from ka-mbx01.SIDN.local (192.168.2.177) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 13 Nov 2017 10:49:50 +0100 Received: from ka-mbx01.SIDN.local ([fe80::e051:e184:7a9f:b09d]) by ka-mbx01.SIDN.local ([fe80::e051:e184:7a9f:b09d%13]) with mapi id 15.00.1130.005; Mon, 13 Nov 2017 10:49:50 +0100 From: Moritz Muller To: "maprg@irtf.org" Thread-Topic: Follow up: The Root Canary: measuring the root KSK rollover and beyond Thread-Index: AQHTXGS/3HYv4pMHq0WYyUzWZ6LFPw== Date: Mon, 13 Nov 2017 09:49:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [94.198.159.156] Content-Type: multipart/signed; boundary="Apple-Mail=_EAA6ECA4-3C22-4069-8187-B3EEAE27688B"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Subject: [Maprg] Follow up: The Root Canary: measuring the root KSK rollover and beyond X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 09:49:55 -0000 --Apple-Mail=_EAA6ECA4-3C22-4069-8187-B3EEAE27688B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii At the meeting today Roland presented the Root Canary project, where we, = among others, measured the impact of the increased DNSKEY RR during the = size at the Root Servers. The question was raised if we also looked at other Root Letters besides = B, but as Roland said, this is future work. However, during the OARC 27 meeting I spoke with folks from ICANN and = they confirmed to me that they saw a similar picture at other root = servers and therefore we can assume that B-root was not an exception. Note that most root server operators have provided an additional DITL = data set for 19. September which is also available to other researchers. Moritz --Apple-Mail=_EAA6ECA4-3C22-4069-8187-B3EEAE27688B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEzP2ZWezgrnEvsIELCviSKxZZtEgFAloJar0ACgkQCviSKxZZ tEi+pwgAvzsbTkJyuTJBCeVcBNfS2sHLX3TGOHoPCFLcId68dHl4oCkBREpc2aqp jBqnKS/IdfphhjrotcPFSuy2QxS5yL39FoLKob8pUJ1CDSIjoumKLETlCq3PTaNn HB3/9We2NtbJA7fHfFM3mxoX+98wi8pjZ/4+H+2qZ6SkBKdhrj/YVCzrp2VqvMz6 QmhP0IDam03NIq0PFPhz+/TUhxw4NKnldm1H4nmNOmNvKk+ii4qdQSHnCxx++BIQ tIeZQkkEEp+RIZR+PeXTTtVEtr/u4DkA8tBQvLp559exmIs7E6L4Eg8DqTQi18To FFxsyYZU+WcF05BwgP+ZlcU+4C7sTg== =zYuB -----END PGP SIGNATURE----- --Apple-Mail=_EAA6ECA4-3C22-4069-8187-B3EEAE27688B-- From nobody Mon Nov 13 18:48:39 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D42127136 for ; Mon, 13 Nov 2017 18:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 O7thdkL1IZRA for ; Mon, 13 Nov 2017 18:48:35 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A30A126CBF for ; Mon, 13 Nov 2017 18:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=from:subject:to:message-id:date:user-agent:mime-version:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=EG8vgQd2DtpXqZXAYEQt4rIZGGalRUQCFsl+nbbqV8Q=; b=C06Q8zf0AynqGA3zgO8JkywafosGGhq4Z/w/BhraHAySUPyJeZrTEhW5qzSljpE9vpliBOFZGhVAx1e5s2h49I0skJjtyTGBzCBRke5k2Cs/sASTCkL/2usMS5hIOGQmmd9kLKQSbeQFyDW4S9SHfZ+ujPFEKFHYDiT1Jm8yYTUtw614He5E3JN39F9VmDAat7p1z+b9Ul9p+pTAc1LGbuH8mWtfYqIBitvWigYXATrNpXv2eQ0QIW5IgQm0Sl9216OjP21w6m5nz5+SXPo35PiRP9Lifw9F3k2E/apMnJvqikqu0naADpScDb0BNBAmoaZvjzR4aqTM7netKrJuVQ== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id vAE2mXuf021401-vAE2mXuh021401 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Tue, 14 Nov 2017 03:48:33 +0100 Received: from [94.198.159.133] (94.198.159.133) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 14 Nov 2017 03:48:32 +0100 From: "Giovane C. M. Moura" To: Message-ID: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> Date: Tue, 14 Nov 2017 10:48:28 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.133] X-ClientProxiedBy: ka-hubcasn01.SIDN.local (192.168.2.171) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.133, helo=, mailFrom=giovane.moura@sidn.nl, headerFrom=giovane.moura@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of giovane.moura@sidn.nl designates 94.198.159.133 as permitted sender) smtp.mailfrom=giovane.moura@sidn.nl Archived-At: Subject: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:48:39 -0000 Hi, So yesterday I presented our "Recursives in the Wild" paper [1,2] at the MAPRG session (IETF100). Our main finding was that, in the wild, recursives resolvers will query all available authoritative servers available for a given DNS zone, even if there's a long delay between the recursive resolver and authoritative. Recursive resolvers distribute their queeries roughly inversely proportional to the RTT between recursives and authoritatives. >From this findings, our main recommendation is to use *anycast* in every single authoritative server to reduce latency. Unicast cannot deliver good latency to all resolvers globally simply because some clients will be geographically too far from a unicast authoritative (implying long delays). After the presentation, there was a question about our recommendation, that anycast for all authoritatives may not be good idea because of ICMP IPv6 fragmentation issues issues [3]. In short: on IPv6 only environments, some resolvers may not be able to receive fragmented packets on IPv6 only environments. This is a problem which is orthogonal to ours. Our goal was to understand how recursives in the wild choose authoritative servers, so we can better engineer them. Our findings hold for both IPv4 and IPv6 stacks: to deliver lower latency, you have to use anycast, in all your authoritatives. In fact, this is already used in many production environments: * 12 of the 13 root server letters[4] * DNS providers (e.g: Amazon Route 53[5], Dyn[6], Netnod[7]), * many ccTLDs (as well as the authoritative name servers (ns5) we run at our .nl ccTLD). So in short: anycast is a robust technology that has been used in production environments for quite some years. And it is the best way to deliver reduced latency. The question of fragmentation of IPv6 only environments is important, and maybe there's an opportunity for an *open datasets* measurement paper in here, so other people can reproduce and analyze the results, and determine if this is a problem in the wild (actually DNS-OARC DITL datasets[8] is a good starting point for anyone wanting to drill down on this -- it has pcap data from the roots servers). Thanks Geoff for bringing this up. However, this does not change any of our findings in the paper. Anycast is the way forward to reduce latency, for both IPv4 and IPv6, and we (.nl) are moving towards that too. /giovane [1] https://datatracker.ietf.org/meeting/100/materials/slides-100-maprg-recursives-in-the-wild-engineering-authoritative-dns-servers-giovane-c-m-moura/ [2] https://conferences.sigcomm.org/imc/2017/papers/imc17-final12.pdf [3] https://pc.nanog.org/static/published/meetings/NANOG71/1465/20171003_Huston_Ipv6_The_Dns_v1.pdf [4] http://root-servers.org/ [5] https://aws.amazon.com/about-aws/whats-new/2016/10/amazon-route-53-now-supports-dns-queries-over-ipv6-networks [6] https://dyn.com/dns/managed-dns/ [7] https://www.netnod.se/dns/netnod-dns-services [8] https://www.dns-oarc.net/oarc/data/ditl From nobody Tue Nov 14 05:26:40 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342AA12420B for ; Tue, 14 Nov 2017 05:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AyvtA5q07nof for ; Tue, 14 Nov 2017 05:26:38 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D61912025C for ; Tue, 14 Nov 2017 05:26:38 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id u3so210336pgn.7 for ; Tue, 14 Nov 2017 05:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SCyIoyZU5HHnGTb8Xhhm4ZJ9kQSOJH+NPoHh+h2j3FQ=; b=iGyKuxGp+Zb+2e4+oMjh4NbOXMwj/LlDEx9t4yWypFo1tfi1Lufj4HFHwQ5MnspYPV EJkY4To9oK29Ul7SMl2zarwcyBjLKkjD+R5IZP7l8ATZIG38hL3EXaWA2Ceklkf5ZjY/ o5dDY4ZKhlCgNci+UFpvKQmbV9EC2Zfiyqtxc/6X+598PiPwjM1zvJY3iAr8kgKpLHvg 8tEnJvzBR/htkYTfczxSHYo38dKbKA9009L9qhBrY7lR6JhGYN5X9CblYLmQwCvsLfIQ DZ+6wiCj+twFYkInJwHmb8aa4DG6+h8pZkBMQEwUwJYYloJEaVsyoyrY2FpBGh07PZp8 d0Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SCyIoyZU5HHnGTb8Xhhm4ZJ9kQSOJH+NPoHh+h2j3FQ=; b=AoBXDErBi5T9e0j11L949j7QJ7Wwz4XT59PF3SBebFf0pAgl3HFBNhJJ4Js1CwSPYw Bfu6x/Axcsu5M6EDuNg1Knzu0kwNECI74ySCZNRu114s8gZqHARkTz2G8fJSPt9H5Avw XENzdmvnbvEi3AFRuanlQf4X5Bf946Pf30V8sgp4Pja9hpRY+oEg1+lL+t+2jbw2PH/9 7mNiKHr7xDB8V8JdiD8n8Fjhk/UBAWEd6MVyKFCRquV7E+oovDVRRHc9q+BnS3TaSfQA 9zWvNmJLhRR21r0+gCcaRbueDWfogA06j/k9vYAf4xT23tIqxc3L55LI/cp+nF/aJjaY 1NiQ== X-Gm-Message-State: AJaThX7HIGZFoVGjPlGY37uq4lDmFu91mx+jl5YhNnskVjC/idRDis+r tYP56lvOs/mQZvA3rx87vgU= X-Google-Smtp-Source: AGs4zMbKCu9nSnSe1dxPi9v8+8XHtjMLcS4RevHwKU8mDX+oSvk0o2PHzVRCIFCN3C15d9MCUxFwZw== X-Received: by 10.98.41.194 with SMTP id p185mr13780083pfp.140.1510665997534; Tue, 14 Nov 2017 05:26:37 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:45a3:6b21:5738:46c6? ([2001:67c:1232:144:45a3:6b21:5738:46c6]) by smtp.gmail.com with ESMTPSA id h3sm25959186pfk.55.2017.11.14.05.26.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 05:26:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Geoff Huston In-Reply-To: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> Date: Wed, 15 Nov 2017 00:26:33 +1100 Cc: maprg@irtf.org Content-Transfer-Encoding: quoted-printable Message-Id: <15FE901F-8DA7-421A-8F19-ABBB9E19D13E@gmail.com> References: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> To: "Giovane C. M. Moura" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 13:26:39 -0000 > On 14 Nov 2017, at 1:48 pm, Giovane C. M. Moura = wrote: >=20 > Hi, >=20 > So yesterday I presented our "Recursives in the Wild" paper [1,2] at = the > MAPRG session (IETF100). Our main finding was that, in the wild, > recursives resolvers will query all available authoritative servers > available for a given DNS zone, even if there's a long delay between = the > recursive resolver and authoritative. Recursive resolvers distribute > their queeries roughly inversely proportional to the RTT between > recursives and authoritatives. >=20 >> =46rom this findings, our main recommendation is to use *anycast* in = every > single authoritative server to reduce latency. Unicast cannot deliver > good latency to all resolvers globally simply because some clients = will > be geographically too far from a unicast authoritative (implying long > delays). >=20 > After the presentation, there was a question about our recommendation, > that anycast for all authoritatives may not be good idea because of = ICMP > IPv6 fragmentation issues issues [3]. In short: on IPv6 only > environments, some resolvers may not be able to receive fragmented > packets on IPv6 only environments. >=20 It appears from this explanation that you may not have understood the = question. The problem here is that the ICMPv6 PTB messages that are sent in = response to a PTB issue on the path are sent may not necessarily arrive at the = anycast instance that sent the original packet - the return path of the response is not = necessarily the same as the forwarding path of the query and the =E2=80=9Cclosest=E2=80=9D = anycast instance of the routers on the return path may be different from the sending = anycast instance. What this means it that anycast should not be used with impunity - you = need to be careful about path MTU considerations as you may not receive the conventional ICMP signalling back to the same anycast instance. Fragmentation in IPv6 is its own special problem, irrespective of = anycast. Geoff From nobody Tue Nov 14 05:27:36 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E0612025C for ; Tue, 14 Nov 2017 05:27:34 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.onmicrosoft.com 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 bwqws9qVaNO4 for ; Tue, 14 Nov 2017 05:27:32 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0082.outbound.protection.outlook.com [104.47.124.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0D41204DA for ; Tue, 14 Nov 2017 05:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SCyIoyZU5HHnGTb8Xhhm4ZJ9kQSOJH+NPoHh+h2j3FQ=; b=JVHV10IUEiVnhGn3KzK1dWdUKAfyQrpY90eA4M/5nh1uqU4M5agLkBpOrc9WxnkHy/hM8D1jw5yoNgammIRqKpqBAU72UHNmRVkT1hitekBrHZ+0wA7ShGLpE+kXU36FeJ/c1pCnzt62HxL5SUtX6se5wEo5Nu/0IzExafeGMcM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from [IPv6:2001:67c:1232:144:45a3:6b21:5738:46c6] (2001:67c:1232:144:45a3:6b21:5738:46c6) by SIXPR04MB0697.apcprd04.prod.outlook.com (2a01:111:e400:51ee::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Tue, 14 Nov 2017 13:27:28 +0000 From: Geoff Huston Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 15 Nov 2017 00:27:20 +1100 References: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> To: maprg@irtf.org In-Reply-To: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> Message-Id: <7D6D7E06-87D0-4A2D-A6E3-AF75521A51C9@apnic.net> X-Mailer: Apple Mail (2.3273) X-Originating-IP: [2001:67c:1232:144:45a3:6b21:5738:46c6] X-ClientProxiedBy: SG2PR0401CA0003.apcprd04.prod.outlook.com (2603:1096:3:1::13) To SIXPR04MB0697.apcprd04.prod.outlook.com (2a01:111:e400:51ee::20) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5113f32b-7d6e-4ec6-64ee-08d52b63739e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:SIXPR04MB0697; X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0697; 3:+0YmJBIkhbLw7oq+mItCZATWh9kfeX97VqH1o4tYUz17ZMUm1Yni/TToj3Y/2K4j9/sOUZheD+IIhrEK3oou+kc4IytUckVks+4qOkX+lzgiiuU6KElsyZLLaJcJ72nbM84sMMHZ5VtdFgQDPpOPr8Vlq9BG9lbd/W/A2CkWOWboOVyAG3PWgk1svnmiA7BP/f+SocOnc13a5OhUf1DRySL65W4psATpj/f+aHc8oQmtbzFhIUXzFaR51YFbLxig; 25:qQbXEWRjSPsqM+/OcW9jfI0nIi2kFDSLNWmMuOP/oBSd5CN5JYNQC5zXYlKJSVkciOPSvZULJqbJO9hnMM4huACuw0Ar6i+LkQFe69px9PAmqTm5Mb4+pbkEqBlPa9vAcW+CcF6dM8JH88XZCPJatIuYbCNeC5fmeb79Sinpu9cYOGR2SZiISZt5gq3RLoqvl1AM6m6MxPH+gpXRAP5uJmSY94WryiqQ8Ng1v+BSN/CUi9aF/sUqKnjoJdh6lbNkgu3JgVKBy4L1KYLJMVR9ygqL3sVQmPi21jx1UAqEMoL0NzlwWSbp35mEcs4UxxUX2Jg1tBdqVJHzBr4OH+ouuA==; 31:O8/N87lvcAJP3qP3lkW/bJad1xudQjoe4KW+6hPLzgUxT+Pdkg4h3d/35dKE7sJzQBv3B2qVZNgKBn06nBayvcgxCbmNoOdQjlgoQDwCe9/rZXUdOgBDoyrRlPhFApW6qDwjjVDH6y3cQSxP+hbYgkCKxxfkpzT6P/+3faZZgyRM+eu4jMFWuT49GN4OHJ5R1ByS7yMuUholDCnn8AZQIRh3hprWgeZgWEPbWkk8aOo= X-MS-TrafficTypeDiagnostic: SIXPR04MB0697: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(3231022)(6041248)(20161123560025)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201703061421075)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SIXPR04MB0697; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SIXPR04MB0697; X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0697; 4:K775Fah2FHjeV3t3uQV8lE6sCSgg/0m9S/zHlGrbJbP5hoB0AZ1DGmHMS10VcG8uoRq4W2fIAE923GSRi0OS31OKn+Dl8i7cKA291i/AIfLvnsr6uJ2+TR7muomV980zTv1jTkD5iMfxw8oNMfe9HZv/3ZVbmkYwECGBQGN4AR+U06cNOUW4wKvAeS9BGTss5NucDSeZkekCOMdCQkxIoXn25MWQGXMMcmAbUPRN0XEvMjtRDOtg7hmVoCh26cGZUB7eQOd3sR6S/DvVDlx8dq8Ifgjdlu4GlJbGCRfbH57/SAFIa6Cc1Lf+ZExWv6P4 X-Forefront-PRVS: 04916EA04C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(189002)(24454002)(86362001)(25786009)(53936002)(81166006)(6246003)(83716003)(5660300001)(6116002)(8936002)(1706002)(50466002)(2950100002)(81156014)(508600001)(6486002)(6916009)(6666003)(8676002)(36756003)(97736004)(8746002)(53546010)(23676003)(50226002)(101416001)(2906002)(189998001)(2351001)(50986999)(76176999)(68736007)(7736002)(105586002)(305945005)(33656002)(2361001)(47776003)(106356001)(82746002)(57306001)(229853002)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:SIXPR04MB0697; H:[IPv6:2001:67c:1232:144:45a3:6b21:5738:46c6]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTSVhQUjA0TUIwNjk3OzIzOnBqNzNXV1VEc2xQREEwd2Y3cUFSRFVmWmlr?= =?utf-8?B?RkRBRHlvM1lmblh3TE9vS3RqNUxzdjZjSTAyZWpXOGZ2YTlxZ2JELzhqdEp0?= =?utf-8?B?dGttTUVEZmV6VzJVNUNPMjBieFkrS1BCSzl4aGNjYzJLeWp0WTcrWG1oRjRh?= =?utf-8?B?SHhrdTVOYVMxMENRb0Y0M0JtKys3S2hZRzBwQ1Q0NVJWekp0NThQN29lUVJs?= =?utf-8?B?eERzUG5jdHR6dHVkVHRPU2xHQTFwRG01bnh6SUV4NW5GMDJHb0JzeWIwMlZv?= =?utf-8?B?cmN3NnJDUWhkSUlOVGM5RkMzSTUxZmJVTU9mU1JSV0tlYjV1OFlsTmZjQncw?= =?utf-8?B?N2FLakxVVjBCcitNRXZvTkJEcjcvU1V5ODllQ0JIRXdIWXk2SG9uMEMySCtv?= =?utf-8?B?bmlNUkVMbkNWdmFMemVDWWRNN2hFVlRuMENXT2FJdzFmSDdtb2cyekhFZVd6?= =?utf-8?B?dTJQajJzMSs1Z0dMNnZBWU16Z3JWWlZ1WEY5U1hxY0tGTTRha1hQa1p1NHd1?= =?utf-8?B?NnRlTlZlSWU4QkVseFVaTVVraEU2ZVhWY2NPWitKMnRDU3JNSndqak55alZX?= =?utf-8?B?cTEvaUk5MTNyMCtxWXR0Sko3ZnFpbXpJRk9WN3FVODlGSW04a3BESC8vN1gr?= =?utf-8?B?SitiSEhGWnVvUWoyMHZRV2hON0JaYkp0bG11T0hVT0FHbzlkaTEyWHVPS3hx?= =?utf-8?B?R3pUZVdFUHpFVlZrNkpodTJDYmVUc3lpTXd4NnZCcTcyUFQwL0VEM0ZSaXkv?= =?utf-8?B?UnZ0QmRDMCsrS1pBaWRjaWc4Q0xQdmtKNERLS3YzSVNwWFd2WFFrTXR5Snlm?= =?utf-8?B?eU81VDFZajB0K1FzQmRaVDQyR25waVhQdUxORHYwMDRDTmlUM1hoMHVNKytw?= =?utf-8?B?SE9QV2w0Ky81VjBrM3MwcXlLYmRrOHdhem9lRlhtaEJkazZlaXVIVWpmSnpL?= =?utf-8?B?L1J3Z0tnMklPbCsvL0h3UG5MdFM0anlyUzlEMzFUVjViQ3NQT0N4Y2tMbmg5?= =?utf-8?B?N0tLWnVGRjNkZ1R4VDIveVVyU3dMa3NQd2hNQWNwZEtrdGZWSlN6K2RnK0hQ?= =?utf-8?B?akZmanowTE5rMmJ2eXlyWWNvYm5FSUhNWnBLcFg4TEhDdFRZVlhXaXZxcW5W?= =?utf-8?B?amtHeFFBYTNpdnJDQXkyc2VQcHIra3gyeCtuVzFuZFRIZ0dudFlFQjJLK0xr?= =?utf-8?B?U0h1U3BFanFLZ1R3UTNVenBWd2l4bXR3Um5pR0FGTHpHYXp5L0hVT0N3b0h3?= =?utf-8?B?cE5aMVJHM2JYbkNpanBIU2dYSWZKOWtpd0Z1NVQ3dGZWTksxQmE4N0lWUEtP?= =?utf-8?B?QndETWFQTG5odUJBMmM3YmlJdmx4MWhkOHhNVlcyTzRJOEsrTlkvSWw0M2FD?= =?utf-8?B?eHJLNU9TdVdOVkpGMGczaURWMTZTL0lLcnBrQk13NDRjb3ZBSENlYU1qV2tE?= =?utf-8?B?eldUb011VCszL3M4ZFJ2TG5DL0hDUXR1T1A2QkwzcVFDTWdLOW53cThhVzhj?= =?utf-8?Q?M3MLGplPWT3GBaAkr5IZ4rrf0=3D?= X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0697; 6:K9PIWp9pNl0ePpFhUqxkV5yIr8bJA1B8obPRC8htE80qgOXaeoSbZijZ0iIDqzycrK9xG/UdjsdfBBKY5OcQ7tQSe2IwCQqd2OdWOpUQWmVRGoocWAp59KGTKReepv00Xa2Cx9DEXWvzpLealnHsT/pkhP3Qv48D8ZqW+uZsH6BzZOMdclPjlsW/+OQDaDU5WvILKeRjksnD7k5sPcximt46h3K8f0soNOfbDVSH/C1bPGtpUr+UmssLKZ4zhkxANEqETSD4LYJQOYfEnDt781OKt7WxihJOj0tdcouJNhhwSA0Rm0wgS6yXOBujyZW8+FZYjZFG+obVJ1yMJN0+2hCC9XCDtwOb1+pOFU82h+w=; 5:YKBA/3F0dkPoqbdVBxLJqqeZvkHpU51u1EZodgBshl41tiSWzhoZbh63xn+2HpkvqIGEkZbSbA1SDGGK0XLEYAoTou82mWUQNmJdG8/CHjRz9hGmII18r4OZEsEmoxthACWY9Y+x8dV/I05flVwLd47uN7hO+J7d5rBkhQ+lUf0=; 24:qnIB3JGAEwaCBapT2+q3ZOcapRN7EhORaH43g/Ws4CXxH9t5Q7z841nkyZArpydTLvXuEmQS38FjDnf/nocuqyowMjYxEXZ5Ry1Q7KXz/WQ=; 7:K7n0EvAhsQnrNmqIeq4Y+BI36fak+FAfmyvDRQTczVKojFDbDLdAGMJMtjdgdcn+L8pM6n9W0EseyG6/HDvT8Bmxc9VFlhbtEkAzKl2SxXy2Epx8rix1J8HlPn3pcYBFnXAzv/ZIaVwQvBo0uu5Ewy4vtbjv3cJWBIv3T4LoWkMoeRSLQ0ilykJOsGM9H2r977RTvNKhXP7+rBKJ5VH/t7fCW33pCiey9Lm8j2z3+FQsw8O70q8fGyjDtxlHf/i5 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2017 13:27:28.3997 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5113f32b-7d6e-4ec6-64ee-08d52b63739e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: SIXPR04MB0697 Archived-At: Subject: Re: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 13:27:35 -0000 > On 14 Nov 2017, at 1:48 pm, Giovane C. M. Moura = wrote: >=20 > Hi, >=20 > So yesterday I presented our "Recursives in the Wild" paper [1,2] at = the > MAPRG session (IETF100). Our main finding was that, in the wild, > recursives resolvers will query all available authoritative servers > available for a given DNS zone, even if there's a long delay between = the > recursive resolver and authoritative. Recursive resolvers distribute > their queeries roughly inversely proportional to the RTT between > recursives and authoritatives. >=20 >> =46rom this findings, our main recommendation is to use *anycast* in = every > single authoritative server to reduce latency. Unicast cannot deliver > good latency to all resolvers globally simply because some clients = will > be geographically too far from a unicast authoritative (implying long > delays). >=20 > After the presentation, there was a question about our recommendation, > that anycast for all authoritatives may not be good idea because of = ICMP > IPv6 fragmentation issues issues [3]. In short: on IPv6 only > environments, some resolvers may not be able to receive fragmented > packets on IPv6 only environments. >=20 It appears from this explanation that you may not have understood the = question. The problem here is that the ICMPv6 PTB messages that are sent in = response to a PTB issue on the path are sent may not necessarily arrive at the = anycast instance that sent the original packet - the return path of the response is not = necessarily the same as the forwarding path of the query and the =E2=80=9Cclosest=E2=80=9D = anycast instance of the routers on the return path may be different from the sending = anycast instance. What this means it that anycast should not be used with impunity - you = need to be careful about path MTU considerations as you may not receive the conventional ICMP signalling back to the same anycast instance. Fragmentation in IPv6 is its own special problem, irrespective of = anycast. Geoff From nobody Tue Nov 14 05:42:14 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B152A12025C for ; Tue, 14 Nov 2017 05:42:12 -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 u6FeA5KLG6SK for ; Tue, 14 Nov 2017 05:42:11 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail2.net.t-labs.tu-berlin.de [IPv6:2001:638:809:ff20:130:149:152:141]) by ietfa.amsl.com (Postfix) with ESMTP id E15531200E5 for ; Tue, 14 Nov 2017 05:42:10 -0800 (PST) Received: from smith.sec.t-labs.tu-berlin.de (5072A964.static.ziggozakelijk.nl [80.114.169.100]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 883B020334; Tue, 14 Nov 2017 14:42:07 +0100 (CET) Message-ID: <1510666927.3986.3.camel@inet.tu-berlin.de> From: Tobias Fiebig To: Geoff Huston , maprg@irtf.org, giovane.moura@sidn.nl Date: Tue, 14 Nov 2017 14:42:07 +0100 In-Reply-To: <7D6D7E06-87D0-4A2D-A6E3-AF75521A51C9@apnic.net> References: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> <7D6D7E06-87D0-4A2D-A6E3-AF75521A51C9@apnic.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 13:42:13 -0000 Heho, > > > From this findings, our main recommendation is to use *anycast* in every > > > > single authoritative server to reduce latency. Unicast cannot deliver > > good latency to all resolvers globally simply because some clients will > > be geographically too far from a unicast authoritative (implying long > > delays). To pic up on this, because i have been wondering about it for some time now: Does that not defeat the purpose of having multiple authoritative servers set for DNS zones? Given that one deploys anycast for all auth. NS, queries from a client, in my understanding, would mostly arrive at the (geographically) same node. Hence an issue at that one node, e.g., a faulty Bind refusing to start or a dDoS to the anycast zone, will make the whole zone unavailable to clients of a specific region, as all IP traffic for any auth NS will be directed to a potentially unresponsive AS, requiring semi- manual failover (retracting the network used for anycast)? This would not be the case when using the DNS "redundancy measure", which, while introducing latency due to (potential timeouts) provides better resilience? With best regards, Tobias --  Tobias Fiebig                      building MAR, 4th floor, room 4.003 Fachgebiet INET - Sekr. MAR 4-4        phone: +49 162 243 205 2 Technische Universität Berlin         gpg-fp: 21A9 91EB 4971 ED48 001E Marchstrasse 23 - 10587 Berlin                FBBC B6AF 3CD8 59A2 795B From nobody Tue Nov 14 11:32:42 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B24128854 for ; Tue, 14 Nov 2017 11:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 64HGa5x9e3Pa for ; Tue, 14 Nov 2017 11:32:38 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30D76124B18 for ; Tue, 14 Nov 2017 11:32:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=from:to:cc:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-mailer:x-ms-exchange-messagesentrepresentingtype:x-ms-exchange-transport-fromentityheader:x-originating-ip:content-type:mime-version; bh=zrcXxSxwcfu3/YZ8bbmLfDRUwUHFergETohysq6nmdI=; b=Wh4H6cEAYW3GtK0YiWG8dhKmKqYeMuSeXD1TSE78DpeKYfcybtVX+YAeOYpkcTUHr1JL8tTNF6aNC+2KkpqzVcH6w4xAJuornARdhr2N4mQIYyv3Yu7FGfYMeimILBmBWXxnfpd0Q2yTeaimD5L1HP9OCcgw8m07xGPvP84lyS4tEYqW4KdqxGmh5mcLC0qrye/TjSQ1f/ks9jOwdUDOt1SxkVH3NX/oIGDTGeQmyhxj/Vfof54ZyxX70NmNlR7jFwcSQSgSPdw9Tgow7qWS1AvNnxUSPuPgDqXFKzl51/nj6HcZuFR1XZRA9MMiI3dNPfMbXpUq+/IE38defIy+Iw== Received: from ka-mbx02.SIDN.local ([192.168.2.178]) by arn2-kamx.sidn.nl with ESMTP id vAEJWNp4025497-vAEJWNp6025497 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Tue, 14 Nov 2017 20:32:23 +0100 Received: from ka-mbx01.SIDN.local (192.168.2.177) by ka-mbx02.SIDN.local (192.168.2.178) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 14 Nov 2017 20:32:22 +0100 Received: from ka-mbx01.SIDN.local ([fe80::e051:e184:7a9f:b09d]) by ka-mbx01.SIDN.local ([fe80::e051:e184:7a9f:b09d%13]) with mapi id 15.00.1130.005; Tue, 14 Nov 2017 20:32:22 +0100 From: Moritz Muller To: Tobias Fiebig CC: Geoff Huston , "maprg@irtf.org" , "Giovane Moura" Thread-Topic: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 Thread-Index: AQHTXPMWx4HZnDVkG02VvIGTb0t/iKMTze4AgAAEIYCAAGHdgA== Date: Tue, 14 Nov 2017 19:32:22 +0000 Message-ID: <4B73E862-8130-485F-9CCA-1B64A4AFF05F@sidn.nl> References: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> <7D6D7E06-87D0-4A2D-A6E3-AF75521A51C9@apnic.net> <1510666927.3986.3.camel@inet.tu-berlin.de> In-Reply-To: <1510666927.3986.3.camel@inet.tu-berlin.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [94.198.159.138] Content-Type: multipart/signed; boundary="Apple-Mail=_FF0BACF8-CC6A-4D82-AC4C-67C154DFF117"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Subject: Re: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 19:32:40 -0000 --Apple-Mail=_FF0BACF8-CC6A-4D82-AC4C-67C154DFF117 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I=E2=80=99m one of the authors of the paper Giovane presented at the = maprg. You=E2=80=99re raising a good point Tobias. I think it does not make sense to have different NSes all sharing the = same sites. We recommend having different anycast services for the NSes, equally = well peered, but not peered equally. In the paper we mention a couple of things you should consider when = deploying anycast on all your NSes but maybe we should have been more = explicit. And overall a DNS operator should always find a balance between = performance and stability. Cheers, Moritz > On 14 Nov 2017, at 14:42, Tobias Fiebig = wrote: >=20 > Heho, >=20 >>>> =46rom this findings, our main recommendation is to use *anycast* = in every >>>=20 >>> single authoritative server to reduce latency. Unicast cannot = deliver >>> good latency to all resolvers globally simply because some clients = will >>> be geographically too far from a unicast authoritative (implying = long >>> delays). >=20 > To pic up on this, because i have been wondering about it for some = time now: Does that not defeat > the purpose of having multiple authoritative servers set for DNS = zones? Given that one deploys > anycast for all auth. NS, queries from a client, in my understanding, = would mostly arrive at the > (geographically) same node. Hence an issue at that one node, e.g., a = faulty Bind refusing to start > or a dDoS to the anycast zone, will make the whole zone unavailable to = clients of a specific region, > as all IP traffic for any auth NS will be directed to a potentially = unresponsive AS, requiring semi- > manual failover (retracting the network used for anycast)? >=20 > This would not be the case when using the DNS "redundancy measure", = which, while introducing latency > due to (potential timeouts) provides better resilience? >=20 > With best regards, > Tobias >=20 > -- > Tobias Fiebig building MAR, 4th floor, room 4.003 > Fachgebiet INET - Sekr. MAR 4-4 phone: +49 162 243 205 2 > Technische Universit=C3=A4t Berlin gpg-fp: 21A9 91EB 4971 ED48 = 001E > Marchstrasse 23 - 10587 Berlin FBBC B6AF 3CD8 59A2 795B >=20 > _______________________________________________ > Maprg mailing list > Maprg@irtf.org > https://www.irtf.org/mailman/listinfo/maprg --Apple-Mail=_FF0BACF8-CC6A-4D82-AC4C-67C154DFF117 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEzP2ZWezgrnEvsIELCviSKxZZtEgFAloLRMcACgkQCviSKxZZ tEhpbwf+N3FbYfnmcF0mdWYH+tarl+dUtyvxEXTY1HKy8Y6wC+v3VNgX+ANyXspA s85aQF8MJbpgtEa8gi/gtIvTjvbx0UJXdPCBR0MbWJDPlhcxD+BiXtX124dk6RaW sOq/QelfRg2cRwInTQYsqXaW0P+q3SFqbh5SCb/HawAMo2DYetoqpvnogWkXG+Fw OJbatXv++XOafeBYtwt9K2xNdp6ZXh6WCVS6dZU4I7AGc3bH+qtALm/FNIZ16g7p yKMGiVY6pC7iuS1sO+q8sraIaesNecc6/jhQgb+AZ4zkUIw8/dytogNsODoUJ4gf go/ZEEJtkggIXNtqN/s5dq3OwcaNyQ== =zIPE -----END PGP SIGNATURE----- --Apple-Mail=_FF0BACF8-CC6A-4D82-AC4C-67C154DFF117-- From nobody Tue Nov 14 13:35:28 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C500E1293FF for ; Tue, 14 Nov 2017 13:35:26 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.onmicrosoft.com 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 R--Gj-IvfCvo for ; Tue, 14 Nov 2017 13:35:23 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0074.outbound.protection.outlook.com [104.47.126.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E80C41293F3 for ; Tue, 14 Nov 2017 13:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1WDB0DgrGzxHyrZ2AfJ+7EoWMrobUCTR7toCQfY3rF4=; b=TbmYBpT18DV7CmkvO28ZkAfClfU84zZTnLeUMFOXjJfyADJM0sgv78lXQR6LaK1nCUdDp7Ns5hVZZtbAtuZu4zJUw80wywBkTg8jzbM4I0jSaVzCbJgbIAdWaXFyCi/OlDoSMJEyoPSAzvlxpSuwodlKDn6reani383Q9DFp0L4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from [IPv6:2001:67c:1232:144:35d6:97f7:f5ec:9d0e] (2001:67c:1232:144:35d6:97f7:f5ec:9d0e) by SIXPR04MB0698.apcprd04.prod.outlook.com (2a01:111:e400:51ee::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Tue, 14 Nov 2017 21:35:19 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Geoff Huston In-Reply-To: <1510666927.3986.3.camel@inet.tu-berlin.de> Date: Wed, 15 Nov 2017 08:35:12 +1100 Cc: maprg@irtf.org, giovane.moura@sidn.nl Content-Transfer-Encoding: quoted-printable Message-Id: <6CD188A9-339D-4E47-B850-A29727CEBCB7@apnic.net> References: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> <7D6D7E06-87D0-4A2D-A6E3-AF75521A51C9@apnic.net> <1510666927.3986.3.camel@inet.tu-berlin.de> To: Tobias Fiebig X-Mailer: Apple Mail (2.3273) X-Originating-IP: [2001:67c:1232:144:35d6:97f7:f5ec:9d0e] X-ClientProxiedBy: SG2PR0401CA0012.apcprd04.prod.outlook.com (2603:1096:3:1::22) To SIXPR04MB0698.apcprd04.prod.outlook.com (2a01:111:e400:51ee::21) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 88283103-993e-4104-8c09-08d52ba79a95 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:SIXPR04MB0698; X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0698; 3:WeO4KcGF9irAe71dkA1C3TLkUf/yWaD9L8e78RtmNYZj4oMjws1wsrJGUHbKeoUlw7/0b49JuCbRcqKgqsKB5sZu38gVy6B/IkhDL6nMvVu6Xw1diQlM5aHP9Y9DeikDcN7F7FpPG2DgUT8NG6HCOzdcSBM2BBpXTFsQpcVIGAmy8AFh2QDANorEiXn4HJtKca6TXKpyy30sAFEOGFZEY1szjxcfqWkwBg+TqhcOVGOGgEfOoGVxRmjGcMpyJjZR; 25:7BqATdPtZV8HEvn74+rj1O0EjW0tMqZirsURIw6E6BsbTwmBmivdUi+fhpA8xmVDVyjvyaBbLXv3gok/lv1+FU5TshVnoxCG0Fs8gC64Wg/fUfazWDaXg4CX5JM5mHcrcLACDHm9kIcLPZDMdK59cgLHqDoUOZgzu0KaUXsOUDWcuMBK5SU/K8OoYdpge+V7uQPELoO1Yw8dQnr2rDrjsy299RgFZXqjtlbk8AH0eXF9wTd0Lp9jll4BBvQrsm2lUPeT8YwIFXSuaIcClQzb/GIZhGET7XMpTx2vNluFqzOT5YfzLapsNbDQabwDEzQUAr534Gbs6xf8adZZ4mCjVg==; 31:7RNV2ttuDzO4AHBB3gujdowPgI1RWtdaJH0yszcePByYRUECYkrdLqLAPwa7ZbdMMAA/xjGI+lUMfx5IE+z78XUM+Ao0G4lV0XcXPD/mBmA/pnlivB21jzUvD+7NuC/r0BrilgKt5UOZ5K6mX+yeDC1fJd+2sRISUQE5M0zdZ+OoILAHNRppArzLc6Q1aMQ0rqkk3dQi1jzUWUNwe27rwjtdCnI+VMSEPbYDuzXRdpg= X-MS-TrafficTypeDiagnostic: SIXPR04MB0698: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(190756311086443)(158342451672863)(33945880838080); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(3231022)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123558100)(20161123555025)(201703131423075)(201703061421075)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SIXPR04MB0698; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SIXPR04MB0698; X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0698; 4:2v5W6DH4ktYxhYD0uA8Rk3kJU5ZyJGhn8ntSLn2BZGKbZk8qvx7X/t8SMOWtrKqtzBnU5fwuHH7aVbNXPsZiPDww8Fed7mQVH1/j4PAtD+WFqRzu47z379JS9NIVXkspyM0DitXU7sFWyfsD0kXXGUWPs1BYBh7depMpD26SIzyI2VOk3KBU9pYl21Crkl/DjfX5n1IsG0HCCZu6yLaNMin+dt4e1BY+I91aekoc1frvmBSNV5n4nWP7bzbcatgWwSsXT9CBlvakJc7F3j0LyW9l7H3TJAY+IRptfBJnGav2Yfsoh3rOrRuHkDbV9jVZ/AKLIrVFrlShRm6BI9GXxeH11I5q2Z1iTC8GJNcr+awnJMELZfmYtvYeWzVD3qCX X-Forefront-PRVS: 04916EA04C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(24454002)(199003)(189002)(6116002)(101416001)(5660300001)(53936002)(508600001)(50986999)(76176999)(2906002)(53546010)(50226002)(8936002)(68736007)(81156014)(8746002)(81166006)(33656002)(1706002)(8676002)(4326008)(36756003)(6246003)(6486002)(25786009)(229853002)(82746002)(7736002)(6666003)(6916009)(189998001)(57306001)(2950100002)(105586002)(83716003)(106356001)(47776003)(305945005)(50466002)(86362001)(23676003)(97736004)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:SIXPR04MB0698; H:[IPv6:2001:67c:1232:144:35d6:97f7:f5ec:9d0e]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTSVhQUjA0TUIwNjk4OzIzOnpod3NLUldieFdUcTNRZ1VHbUVHa3RNSVhJ?= =?utf-8?B?V050VWcwMkVPWGFBR0ZwTTRuTjl3TisvNEFZdHRVTXIrRjNnWEdtVXowOTFk?= =?utf-8?B?TmVBRFBlYjhWNUFNci9GU0N5SlVZalNHUWl3K0FQTU1QQVJzV0pPVUJ2Ym5L?= =?utf-8?B?Vjk2YlpHa2FYNkFCd1JuQk9OQm9QbG96czVOQ01KT0twQjY0SFRTWThFeUs4?= =?utf-8?B?SFJVWWdBTjFZSGpkaHpKQW4zNUNteFRtelIzVG5EWUdxYlNyWXFGQVhtRm1P?= =?utf-8?B?NlRtN2p3bGpRc1gyRit3VXNTSjZ2Z3c3ZHZ6SzdLdm1yRXVFZzNKOHFBdXYw?= =?utf-8?B?QUdoeGs3KzkwcmorUmtNOWcreXMxY0x0UmljWXhmem1QVFN3ZG4wUDhOWm5U?= =?utf-8?B?L2p1Kzh0K3hZaXNNUm8ySUttYW9DL2dUaUNYZ2FqUGFlbDNTcXFjYmZQL0hm?= =?utf-8?B?eDNkM1JTUGw0UUwyWERGaXplT2FocmhOQjFuYkVrVENvRlUxMHRtc1ZDWk8v?= =?utf-8?B?bGE3a0RlWUF1S3JTWmhnOUQyMHFCR2xnZkhEaDk5TFFaWWR1SmJJQlBpSlBX?= =?utf-8?B?Z0w3TFhnQXBoUkI3M3VlNkxDT0ZFQXJJWnlKTFl1WnNLRkdGbTBKeTZQa0FV?= =?utf-8?B?MkMwWUNselVCWkFxd1VQMG1Ibk82ZlFrNEFKY1ZRR3JsWTV5VzRrekNuSkdI?= =?utf-8?B?S1Yvb2xZOFQ0dkRZMXR3WDFJTVhCbUdWVWxRUGNIQXpRaE42aStoOVRRTWxX?= =?utf-8?B?enJNcjdGcDV4ajU0WWtyak5Yb2lYRmtqZ2J4aEhLZXIrT3RsK2tyQWZlNDla?= =?utf-8?B?Ly9EVFBrbEZ4QnM2YmlEbWwzdTBuaGhjTTZwRVdieFVKSmxFQmNSekxPZE5I?= =?utf-8?B?NGhqa01sWGpMZ2d4cTJFN0lyYW82TVd2dXoxWDNmZ3h6cU5jWm1tWnJZaGlS?= =?utf-8?B?RXlxQXZuNjFDWXdZTzd4czRUU3hOdkYyTktMOStFYU5nTlVCN2tkNjROeXZN?= =?utf-8?B?cEZuaU55YXRxQlpDNnREZW8yd0pXNnNPYzh2b3JpN2xwRVBWRVZBRm40Q041?= =?utf-8?B?ZHl0QldSMExmSmhVNTdoTW44YitNL0drUmQ4SDRQV2FObDlJZkltQWJZZEdN?= =?utf-8?B?OGtFem5QUWhTcHVnMzRWK3BJZjhkaFozY1BhU01SMGZMdXBnRmJ2K1pJdHp1?= =?utf-8?B?c0ZyRExObEtZSDFYNVU2TFFtekNtYy9lR25yYXF1b0tyQjVJcFkvK05sKzAw?= =?utf-8?B?MEtlbERWZ3djZnd1dzRpdDZsd01sVTh0TWZ6TlVJS1c1QitMb1hyZEtweE1F?= =?utf-8?B?QTM0c3VWc05mMTlKU2c4c2prUXBqRGZUOHRvVWRSbUNva0NoVExuMVF3RjZB?= =?utf-8?B?QlFvM2JtTHdyMndMREttZVBvd1VoMTVHSk8yK3l6cWx0UDZTMVJwSzYxY3dv?= =?utf-8?B?LzhIcU9xZFRMK3lYVFc5bGlVck1KVTBWV0pRN2xsWVR1OWt4Q2V4U2w3MjZF?= =?utf-8?B?SE05dz09?= X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0698; 6:ZGOkCEsOkwfy4X27nNFgqDWrp9e7KsfRSjHWucCEe75uuuXrsHI9bEFWn8vqtEJPoVN2bVvRZrwhFseW5jl4y93GOKm4pe4outCYuU6nU4TGSsin/DRigkecos8qIG7M2iJ8DSnTCkGWdK7WFGRP2LKeR1sv3D5eo4Z43xOlxQvys7hflebHNsiuqQ4aFO2YsfqKaP7FxImRHye+QFnSl1jCNCMS3yncXfyRh/tqlNUMSuyG9oVeogkJexODt/+lLaOGlxcACooVPNIyncSGIMO+8LtrU5oZdHwqBXwDHuoTrMQeOjQ3IBY/2tA7lh2Q5RTzJzAOWXSHUDKXb6s9OL/i8lqj4XIurEG+17V8hFI=; 5:ny465ZUAC7a8R63M0wjGERXlDqwxu02NS94fUY0J/+iJbAAShUNIMx3NvQiEU5xiNsnG2VRLbHFwcqfAUyCZX8l0u2VGeha5RtfWdkkc7wzWXIE6rukf4T3A2E1tk+bY1MY2Gt1CnFxBlw043D3hcfDuLmGDrdXx3/FPcqmsk4w=; 24:2FXKhG8dQ7chf7353EQ6uPEgymJAcKzHAJkcs3bpXEWXBBjsBqzcSG605laC1WJsTEZ3P9IGewVsyRyR1/Oyp8N+8LtRGWQ/6D358Adesvk=; 7:4nZphZbqJ5LetiW7j1E33FZ8joL6xOd2lX2cZn5P/Wbf4uBpiKKuOqBNjEK3Gv/8dzjrUjygIVNtqNDkYZlsjDvKQd+QoFOrDELUI44d9my2vNqY9jBoMEgZVZPPvUcTnvLOvqAZ7D64cqrTrGVZM7r9fJoKCVARdK6kZEdP+dlKCrInOlgRcXX3L8QKki5jWYNDwm4F8DmoXcnCrOstK937v2T8zULy0ytE9RPVrkGqI8gS8v0ClRvhjpCVU41+ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2017 21:35:19.5349 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 88283103-993e-4104-8c09-08d52ba79a95 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: SIXPR04MB0698 Archived-At: Subject: Re: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 21:35:27 -0000 > On 15 Nov 2017, at 12:42 am, Tobias Fiebig = wrote: >=20 > Heho, >=20 >>>> =46rom this findings, our main recommendation is to use *anycast* = in every >>>=20 >>> single authoritative server to reduce latency. Unicast cannot = deliver >>> good latency to all resolvers globally simply because some clients = will >>> be geographically too far from a unicast authoritative (implying = long >>> delays). >=20 > To pic up on this, because i have been wondering about it for some = time now: Does that not defeat > the purpose of having multiple authoritative servers set for DNS = zones? Given that one deploys > anycast for all auth. NS, queries from a client, in my understanding, = would mostly arrive at the > (geographically) same node. Hence an issue at that one node, e.g., a = faulty Bind refusing to start > or a dDoS to the anycast zone, will make the whole zone unavailable to = clients of a specific region, > as all IP traffic for any auth NS will be directed to a potentially = unresponsive AS, requiring semi- > manual failover (retracting the network used for anycast)? >=20 > This would not be the case when using the DNS "redundancy measure", = which, while introducing latency > due to (potential timeouts) provides better resilience? >=20 It would be cynical to observe that current fashion is to address an = issue at every level of the protocol stack - simultaneously. So while there is an application level = response in the DNS, obviously the IP folk felt left out, hence anycast. After all too much = is always better, right? :-) As I recall, when anycast was first considered, much of the motivation = was to partition DOS attacks, so that an attack might take out one or two instances of the = authoritative servers but it would be harder to take out all of them. We seem to have changed the motivational = story behind anycast from damage limitation to some mythical concept of improved performance. = I don=E2=80=99t quite understand=20 the performance argument, given that caching is meant to be the major = performance lever in name resolution, and in the wonderful world of caching the only queries = (other than cache=20 miss/refresh) that head directly to the authoritative servers are for = non-existent names. So is the more precise statement of the performance story one of =E2=80=9Csaying= no faster=E2=80=9D? If thats the case, then whether you measure the speed of =E2=80=9Cno=E2=80=9D or not, it = seems to be rather a fanciful performance objective! Geoff From nobody Tue Nov 14 14:27:36 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BBA1289C3 for ; Tue, 14 Nov 2017 14:27:35 -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 XS3e_VhyqVLn for ; Tue, 14 Nov 2017 14:27:33 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:638:809:ff11:130:149:220:242]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEA5124319 for ; Tue, 14 Nov 2017 14:27:33 -0800 (PST) Received: from smith.sec.t-labs.tu-berlin.de (5072A964.static.ziggozakelijk.nl [80.114.169.100]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 158B124E; Tue, 14 Nov 2017 23:27:32 +0100 (CET) Message-ID: <1510698451.3986.5.camel@inet.tu-berlin.de> From: Tobias Fiebig To: Geoff Huston Cc: maprg@irtf.org, giovane.moura@sidn.nl Date: Tue, 14 Nov 2017 23:27:31 +0100 In-Reply-To: <6CD188A9-339D-4E47-B850-A29727CEBCB7@apnic.net> References: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> <7D6D7E06-87D0-4A2D-A6E3-AF75521A51C9@apnic.net> <1510666927.3986.3.camel@inet.tu-berlin.de> <6CD188A9-339D-4E47-B850-A29727CEBCB7@apnic.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 22:27:35 -0000 Heho, > It would be cynical to observe that current fashion is to address an issue at every level of the > protocol stack - simultaneously. So while there is an application level response in the DNS, > obviously the IP folk felt left out, hence anycast. After all too much is always better, right? :- > ) Well... i think i may have to plead guilty here... i will try to limit myself on that front... > I don’t quite understand the performance argument, given that caching is meant to be the major > performance lever in name resolution, and in the wonderful world of caching the only queries > (other than cache miss/refresh) that head directly to the authoritative servers are for non- > existent names. So is the more precise statement of the performance story one of “saying no > faster”? If thats the case, then whether you measure the speed of “no” or not, it seems to be > rather a fanciful performance objective! The underlying problem is, in my understanding, that the modern(tm) web evolved to a rather request- heavy and latency driven place. This increases the importance of DNS in the overall latency of a websession. When thinking about a small, standard site, we commonly have some (or all) of the following resources involved: - The frontend.example.org host, mostly pushing a small php application written a decade ago which has grown to a javascript delivery platform - api(v1|v2).example.org to feed the frontend with data via some json-rest-stateless-plain-http-api - (eu|na|sa|af|ap)-example-org.somecdn.org for the static content larger than 4kb - around 50 different hosts supplying various forms of ads, tracking, and, ad-tracking in minified- javascript spaghetti code Sadly, in many websites, these also build iteratively upon each other, so you are not resolving 50 names at once, but more-or-less in sequence. The problem here now is, assuming made up numbers for illustrative purposes, that if all authoritative servers for a zone are (potentially) the first to be contacted, or, during a subsequent request for a name the one to be contacted, this my introduce a cascading latency spike. For example, if you run the authoritative servers for .org, and the site in question has a lot of different slds under .org, and your six authoritatives are evenly spread around the globe, the recursor on a customers CPE will only query a geographically close server in 1/6th of the cases--- given that the CPE does simple round-robbin---which may lead to a significantly higher site load time than it _would have to be_ if all those queries would go to a geographically close server. After all, 50*70ms is quiet some time, if you could have had 50*15ms. So, to reach this optimal 50*15ms loadtime, the authors now propose (and demonstrate that it reduces load-time) to have, instead of six authoritative servers spread around the globe, six anycast zones, all with members spread around the globe. That way, every user will always have six authoritative servers in her own region, and always enjoy a 15ms latency to the next authoritative server. So, in my opinion this proposal aims at solving the same problems that brought us syn-with-data: Cascading latencies in the overly fragmented web eccosystem that created use-cases that were not anticipated during the initial design of the protocols running the Internet. With best regards, Tobias --  Tobias Fiebig                      building MAR, 4th floor, room 4.003 Fachgebiet INET - Sekr. MAR 4-4        phone: +49 162 243 205 2 Technische Universität Berlin         gpg-fp: 21A9 91EB 4971 ED48 001E Marchstrasse 23 - 10587 Berlin                FBBC B6AF 3CD8 59A2 795B From nobody Tue Nov 14 15:02:00 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4A8127B31 for ; Tue, 14 Nov 2017 15:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.onmicrosoft.com 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 O3s8a_or6Wds for ; Tue, 14 Nov 2017 15:01:56 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0048.outbound.protection.outlook.com [104.47.124.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6241270AB for ; Tue, 14 Nov 2017 15:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.onmicrosoft.com; s=selector1-apnic-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SxhITnitfdkywvwCBHIOo9nHhIxtgxfZVd+AOShAJUA=; b=OXNMywxDc27lf75IKbRKLEM9NAnSydwCW6muw6bdnEb5XpHyIp2nHmyiFtSaaibnyxC/fvFt9ZvqdviLdKxK4MuL1QzCtIHgijeHuDeY9kteQVd6GxJSMEfd5JXplz0nfIkKwJrN+NXAPO0ZUs9vzOUU3vV1j390x1bjLFgBFB8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from [IPv6:2001:67c:1232:144:35d6:97f7:f5ec:9d0e] (2001:67c:1232:144:35d6:97f7:f5ec:9d0e) by SG2PR04MB0695.apcprd04.prod.outlook.com (2a01:111:e400:520a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 14 Nov 2017 23:01:52 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Geoff Huston In-Reply-To: <1510698451.3986.5.camel@inet.tu-berlin.de> Date: Wed, 15 Nov 2017 10:01:43 +1100 Cc: maprg@irtf.org, giovane.moura@sidn.nl Content-Transfer-Encoding: quoted-printable Message-Id: References: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> <7D6D7E06-87D0-4A2D-A6E3-AF75521A51C9@apnic.net> <1510666927.3986.3.camel@inet.tu-berlin.de> <6CD188A9-339D-4E47-B850-A29727CEBCB7@apnic.net> <1510698451.3986.5.camel@inet.tu-berlin.de> To: Tobias Fiebig X-Mailer: Apple Mail (2.3273) X-Originating-IP: [2001:67c:1232:144:35d6:97f7:f5ec:9d0e] X-ClientProxiedBy: SG2PR06CA0107.apcprd06.prod.outlook.com (2603:1096:3:14::33) To SG2PR04MB0695.apcprd04.prod.outlook.com (2a01:111:e400:520a::21) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9e3b52a3-13c8-4929-2c68-08d52bb3b1c9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:SG2PR04MB0695; X-Microsoft-Exchange-Diagnostics: 1; SG2PR04MB0695; 3:E6rmVIS2EYAe3Ss/nAqwwJKEsoVBJUiqBTk7E+oL9THVyO60XZho2q+l3zyPmZN/zt7CK3nBggfsWHcZCFF865ANnC8DDEx5JW42PE5rT8kyQPoKMYHlY0ukmdQulJjziP0R3YdiRcuoC+qMv/l5Qen8LjhmKLHL7wwDrYlA8pvKmqpRynYbMeANLh+jLfPeY5fzipkhLoeHHG+KKe9xGQAFk4G+6NpNgKSupG3Bn+1VUZ5cq+emmDFUQyQcNDIK; 25:wDjXjpj+fP7Fg/N0v8OwbpIMmrZmkfNwR4Sslm32ivUQGI+PQ9y14T34NT4Lc2QzyKkjHGLSq4uVJOaAkItlkuY71RzbBepvUEz3QmWsME5eldq3JVOaq1Pn8WBaSrJsAO664GHOvD4DaGvFSNA+Dv48yaWbSrlMt1kZ6xA16fkJVMhT8861IpyoY3ZNpsP6K7Q96WWVOwG3bhD6yD+3Ka2b9kYJpxYxzW5EBWBJw2LuW+5oYcym0Y2i10V1qGB9FP+xU9ygqCSWa1YBqOlXskrx6p9lKnD+mfEuALlm8vqJNJbo815cAyY/TJnlnk8bt4KhdXbzgmgB+3W6qXTdgUTzmlaDvqqBO0Y5YvqIhCc=; 31:SKQ7Uae/ujXgY+NBPTy6RAZ9vNRRe+bGmkTaX4+ZujuAqe/uzbuP1xjMrpj6yh65qdVINah+fgsb0hDnkxZhMoQblTFkSl4PkVb3Oux46ZQjBz+TIcq5z32VpREa5bx/52k4klOoIlHLmD0jZctBu58WK7TiyxQuqndnle7GT1tFxP2PUQ0te8B77LC9gnIy/CDpwUgMODwsH5u3QvHAMltuPaTH9JV5BDzHn58h2wE= X-MS-TrafficTypeDiagnostic: SG2PR04MB0695: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(190756311086443)(33945880838080); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3231022)(3002001)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SG2PR04MB0695; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SG2PR04MB0695; X-Microsoft-Exchange-Diagnostics: 1; SG2PR04MB0695; 4:cV3YlFXRG7Y5VPZ4six4ZynN/NwPS78GfxTmyHDh1/cpicnlpCgJN7RLFX5zCnsNMEZ4IopCNOCpdw8tld5mJgj9HCR/Bs99uooRfhXoF6kNKCVdp31Glz9CzA3ptOS9Kv9SeQwgSgiFdnlA91eP4ejvirYl/cHFiHHbAwiXiqDcGzo2/7xk8uG8ni/mFqkeH2ulmW7P1GTuiTYsbjk5FJR+khb4udQHINAomPQHLb+Yw7/4dvvtWDr5CT2FGcOcSv+H8XEJKqTBjZjbrn3swaqAs+KAZoPrgLxxrQZqfhzwvoLh4+qqhEY6ref51IfIPJPW+8xIBfh48JCy8kl947W3z1en8TkBttYiY+1siiU= X-Forefront-PRVS: 04916EA04C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(39830400002)(376002)(24454002)(189002)(199003)(50986999)(105586002)(4326008)(68736007)(76176999)(53936002)(8936002)(23676003)(36756003)(229853002)(5660300001)(189998001)(6116002)(83716003)(1706002)(93886005)(82746002)(86362001)(97736004)(33656002)(57306001)(2906002)(47776003)(6486002)(8746002)(8676002)(6246003)(316002)(478600001)(106356001)(25786009)(53546010)(50226002)(7736002)(101416001)(81166006)(81156014)(6916009)(2950100002)(305945005)(50466002)(6666003)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:SG2PR04MB0695; H:[IPv6:2001:67c:1232:144:35d6:97f7:f5ec:9d0e]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: apnic.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTRzJQUjA0TUIwNjk1OzIzOkJxRFc2azV4TXNmb3pnOCtFZ3U5Y0lUS0pR?= =?utf-8?B?SDFjTU5sYlVFdy93UW52bFdTcS9IbE96R1JtQ2Z5YkRSa2JFWDlneHVrUTF4?= =?utf-8?B?V3F0SnN5bTRvR3NXSFlCVTNkMUV1Umd2MVVGTHZRaGdnbGVWK2pUVnNyY0Y0?= =?utf-8?B?elhjbE85UmdqVmxtbU5jdGJpanFxQUVlVjdWUEwzcDg5T2pCaHJVcGxsOE45?= =?utf-8?B?bUdmZ0RyaFBjMGVXVjMrUm9keEZEUjY2ZWpxUkkxRUVldWlXNVdxV1dTRUR5?= =?utf-8?B?a0p4WGFBYWw3dmZwOU1YN1BWZ0Q5VTV2WUZHbzFRNEpFWHppSTlMWUVaK3ZK?= =?utf-8?B?aDYzWGY1QVZEbVRyNk5XZGpGSFhDT1dndXhaVUZQT1hNNk02Q1QyY3VxeGpV?= =?utf-8?B?N0djR21YS2Rua0lEYlFRelJkbENCU3l1TmgxSGozakpXNXh5V25ZR0JvNExC?= =?utf-8?B?VkE4d25NZE1FeGp5ZXV5eDZYUDRwS1ZBbEJQekoxS3RpWHFkTHBtcGJRTW4v?= =?utf-8?B?Y2R1KzdidU9JY1ZwUFhUTDI3YVNkQlIwSXIzcXFsM0NkaFAwdW9rWS9UWmV5?= =?utf-8?B?R3J6K1ZyL3M0RWl1TFdRNE5rRVQ1RUtwN2E3NUFSUXdIejBrcGtvSlVYcHhS?= =?utf-8?B?Vi9CbUlBSUVwV2hBZi9pNVV6SDdMMG1sWUZiNzV1c2NJQTl6OGJIZVpJUDZh?= =?utf-8?B?Z05iaEhLS25DUlZ2c0YwaTBXVkcrS2M3RzJPYUpraVBMYk1pMzRET0hiTEdT?= =?utf-8?B?cWIxWlRDSGtmb3EveE1mV2MvWFZMVkgwZjlxTUlEVHZacGEzNDgrSVZGOENF?= =?utf-8?B?V2tyeDN6TmEyWmhxMFJhR1BRUFZhVS9hUUY1RmZQVWppZFU0N1Q4bkkrVFVV?= =?utf-8?B?U3RWVWQ2ajIrV05wSmJWbTduVEhidkl0QlJNRncrcWJLbHBYR1h2MXJRZXJE?= =?utf-8?B?VEQ3VDIrVDdRb3NTa3hPcUN0ZGVJL3dBOENjZmhFRHNFV0hkQ2g1R0NFY21q?= =?utf-8?B?ZzJmLzFraXIxczdMM1VaUFdHMVQ2ZXdqTExMU0U5SnlMSS9yeFJuM1ArSTJs?= =?utf-8?B?YjllYVVRZGFKOWNmTWVJMlpiM2M2NDB3b2crcjQrZ0dZZFRyQmc3VVVReG9x?= =?utf-8?B?OXEvWDkza3ljcTBpQWZvUmtKcFplUCtuMkU2UWlQMUdzOVkwVGZIZ0UvUVZ0?= =?utf-8?B?NTh5aGIyNDNEYUJKWkxmZEgrTjk3TG9VeG9Ca2FpZDFzR3h3anl2UHVUdTVU?= =?utf-8?B?aGdCYXNqUkhQL1BXaGFzWjlUejY4RzQxbmJMQVJzWFo2blVXM0F3Z3NvaWJI?= =?utf-8?B?d1Z6aGZ1S0ZvTTYwVEpoRnp6SGhnMmhQVU1xajQ0T0lVbE83NmphLzVQaU01?= =?utf-8?B?ZndoUmgrQVhuUXU0aEVnUm5LbEZ2aXdBL3NXcWtKZGthQk42M1IyV1BWc0hU?= =?utf-8?B?dElqbUphTFVVWUNVQW9STThjcVpVM1h0OWx5V2oxQVRHQjYxdVJMWDlYR2tI?= =?utf-8?B?SkVxOHRjbkV5Rm8vZmU4WkxnR25XbUtFVk1UdHNHU0p4aDNmV0tBNHNoNFV5?= =?utf-8?B?dCtDNW5ZdXpsaStlQmcxTHB0MXZleXc9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; SG2PR04MB0695; 6:yoj8BWxJp/kk66f67ubq68EbQAqyCknxcvYM5uUjSSYw1lgkW7q+xar05P4Aeji95HetHSRkU9TYXCWldk+mMf0G3LWD+qSSXDpxbmHamzeFLh/eqkyBABH7A0dVNWjoQs65xW15gOBqZhiIT49K/ButaSuWANvL2wtK8nU7bzlsOe1RtNJHEPXCJhijhAB5ISyy+sNyc4lS/nui0ucjeZNKPyGjvzTAn7+tvtTWJfJQFBt7U4eU77j7PK12Y7GXNcLbsuvmwfYb4DbZpEX+FFtjGXug7oo3MqcCSUlEMbnZs1+R6hNbCkv1DFwgpaT/NdFpFE9ZxXC3rFMxYjqaU5gyW4aBONob+V5G6KsTBno=; 5:Y1WBmWkBmPA9rBJ5cnjPAZ9dMSSE7qahqsKrOWoApYxQQxkLw+UjtiacAlqU+7O00/TIpRCXLtaCFTxXWf1Fs5nBm/DvWhzvl5GPjvkX+Th5wdlRdxDKWOWrx5zSg0OLmiF4EvbjIykkSxgGd4WfPwhyLtrgKTAokxUouDLWEt4=; 24:2CtscVXIKthibUa2OZCVghU9aXMH/I8hUkZYJ9c1qBi/s6dEv7I/TzZj4glekPdEWoCNi0W3zjcA++CsNeJCx0dt28zVcNe7/37R64mqsxc=; 7:625862k/Q89nWLOTtMNzG4ELLcBDhiO/pKT8mkc+rOwaAGRd3tbE5VLy/1hUV6+eMWc++KjL+Kp+h1UUUhlhpDLLiEeXoViYQ4VnMytNk/btVElQrDKhEsQw4LXrsQ3Pk0y3681n7NatbaHDHceZCcxMtq0k+0qMZhLmWFP76hAVScMerkFtPRZpp0vmHK/TkgiKfIR+Kz4VqeXeoLhfP/J9aMaqEId7mpY64cmkjd1iFr0xC+ErayPRbMWZM30n SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Nov 2017 23:01:52.4059 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9e3b52a3-13c8-4929-2c68-08d52bb3b1c9 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR04MB0695 Archived-At: Subject: Re: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 23:01:59 -0000 > On 15 Nov 2017, at 9:27 am, Tobias Fiebig = wrote: >=20 > Heho, >> It would be cynical to observe that current fashion is to address an = issue at every level of the >> protocol stack - simultaneously. So while there is an application = level response in the DNS, >> obviously the IP folk felt left out, hence anycast. After all too = much is always better, right? :- >> ) > Well... i think i may have to plead guilty here... i will try to limit = myself on that front...=20 >=20 >> I don=E2=80=99t quite understand the performance argument, given that = caching is meant to be the major >> performance lever in name resolution, and in the wonderful world of = caching the only queries >> (other than cache miss/refresh) that head directly to the = authoritative servers are for non- >> existent names. So is the more precise statement of the performance = story one of =E2=80=9Csaying no >> faster=E2=80=9D? If thats the case, then whether you measure the = speed of =E2=80=9Cno=E2=80=9D or not, it seems to be >> rather a fanciful performance objective! > The underlying problem is, in my understanding, that the modern(tm) = web evolved to a rather request- > heavy and latency driven place. This increases the importance of DNS = in the overall latency of a > websession. >=20 So your response is that you are engineering for the cache miss. Seems a = bit silly when you could be engineering to figure out how to optimise the cache. If the app is so = concerned about this then why not=20 perform the DNS queries well before the point when you need to actually = get the named object? i.e. if the app is having a hard time why are you making this a problem = that the DNS authoritative servers feel that have to solve when the app itself could solve it alone? >> It would be cynical to observe that current fashion is to address an = issue at every level of the >> protocol stack - simultaneously. qed=20 :-) Geoff From nobody Tue Nov 14 15:28:16 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAA0126CB6 for ; Tue, 14 Nov 2017 15:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 2W-9F7L24MZr for ; Tue, 14 Nov 2017 15:28:12 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 0FFD3120721 for ; Tue, 14 Nov 2017 15:28:11 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1BB79AF; Wed, 15 Nov 2017 00:28:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1510702089; bh=wrp6PTcPlmg3d4+GGz3q6L/QMaXuK0bw/Rrum7+D1Sg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oW9jXK1qWiO5T8eWruZvM2+auTEcYIhERE5q40djjYSVS9BNAv0+QgPXCE3cde8F2 RPQXv7QfnJLA+DKSPcwiLt4nts3sVOwoJGLbFVTCTshxjraf67dGPf4LM72zrTobWd yJq6vZkX2cdh3ebeB8+mwabWyXT12JrxPb2uGGv4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 171B09F; Wed, 15 Nov 2017 00:28:09 +0100 (CET) Date: Wed, 15 Nov 2017 00:28:09 +0100 (CET) From: Mikael Abrahamsson To: Geoff Huston cc: maprg@irtf.org In-Reply-To: <6CD188A9-339D-4E47-B850-A29727CEBCB7@apnic.net> Message-ID: References: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> <7D6D7E06-87D0-4A2D-A6E3-AF75521A51C9@apnic.net> <1510666927.3986.3.camel@inet.tu-berlin.de> <6CD188A9-339D-4E47-B850-A29727CEBCB7@apnic.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 23:28:14 -0000 On Wed, 15 Nov 2017, Geoff Huston wrote: > It would be cynical to observe that current fashion is to address an > issue at every level of the protocol stack - simultaneously. So while > there is an application level response in the DNS, obviously the IP folk > felt left out, hence anycast. After all too much is always better, > right? :-) To make something work best, yes, you need redundancy on all levels. Often this redundancy solves different problems, and to solve the most problems that are solvable, you need multiple redundancy methods. Anycast mitigates the DDoS problem, having multiple anycast cluster operators mitigates some of the logical/configuration errors that might occur within one entity, and having non-anycasted servers mitigates the shared resources problem (you being taken down by someone DDoS:ing someone else that might sit on the same anycast clusters). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Nov 14 15:38:30 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015C1127B31 for ; Tue, 14 Nov 2017 15:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.28 X-Spam-Level: X-Spam-Status: No, score=-3.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 c7gSOoP4HPrH for ; Tue, 14 Nov 2017 15:38:27 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1083124239 for ; Tue, 14 Nov 2017 15:38:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:cc:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=bgwqBOcqLSAUZv5P+ULFplQpluDvFqKR2QV6nOFDWsg=; b=3ZmP1/tZgi08uTNAvjgP/a+6S1JTCeEy9b7prUXArKJBUC/wRy8lXz5M7D8ZJLG+mEgBO6N3tlOU259cYyKseFOli1fNA0GRY+VfWAVFSxYoUnkd18yhqJq7SP1tv/Xl+iSQ1rZxHH2EK8Ikj19rKjxGsvnN8M4TqDvY+npMzPBi06BPevHcpeODsVHzrHYBhABcmW/p9sFJyw0lYi3S5JCPWYNEcCVo3f6Xzy9UgyhmmIIdqPpII0QhB56onhHFD5GZ2zsLthFT6db51st2tdC6K+K1wMuDZbXqrlukLc3Rgw/K8DQSR0Sz/511hW8x6i4YJSU6yeAG0igVWK7ARQ== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id vAENcPbC032011-vAENcPbE032011 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Wed, 15 Nov 2017 00:38:25 +0100 Received: from [94.198.159.133] (94.198.159.133) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 15 Nov 2017 00:38:23 +0100 CC: References: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> <15FE901F-8DA7-421A-8F19-ABBB9E19D13E@gmail.com> From: "Giovane C. M. Moura" Message-ID: <125ed2e6-324b-02bb-58cc-f0d85a16e03d@sidn.nl> Date: Wed, 15 Nov 2017 07:38:15 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <15FE901F-8DA7-421A-8F19-ABBB9E19D13E@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [94.198.159.133] X-ClientProxiedBy: ka-hubcasn01.SIDN.local (192.168.2.171) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.133, helo=, mailFrom=giovane.moura@sidn.nl, headerFrom=giovane.moura@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of giovane.moura@sidn.nl designates 94.198.159.133 as permitted sender) smtp.mailfrom=giovane.moura@sidn.nl Archived-At: Subject: Re: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 23:38:29 -0000 > The problem here is that the ICMPv6 PTB messages that are sent in response > to a PTB issue on the path are sent may not necessarily arrive at the anycast instance > that sent the original packet - the return path of the response is not necessarily the same > as the forwarding path of the query and the “closest” anycast instance > of the routers on the return path may be different from the sending anycast > instance. An interesting hypothesis. Thanks for pointing it. However, how frequently does this happen? Maybe something worth measuring in another open datasets measurement paper. Even if it does, we recommend using dual-stack anycast multiple authoritative name servers. If one router in the path cannot forward a packet too big, too bad, the resolver with either move to the next authoritative or use IPv4, ultimately delivering the answer requested. > What this means it that anycast should not be used with impunity - you need to > be careful about path MTU considerations as you may not receive the > conventional ICMP signalling back to the same anycast instance. As any technology, anycast requires good engineering and planning, and testing. And measuring it. But it is robust and already widely deployed. Corner cases should be covered by dual-stack multi NS deployments. /giovane From nobody Tue Nov 14 15:55:29 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2AF126C3D for ; Tue, 14 Nov 2017 15:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 uLdAm49xsh2k for ; Tue, 14 Nov 2017 15:55:25 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CE9126BFD for ; Tue, 14 Nov 2017 15:55:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=mpgTbYCcJlGQYXSC1JvygED+lE4bScFJRqExDp6jYH8=; b=OdKsCPWmG7sHaKwLoY/rrNAbT0PNs7KPRJ9hepQXx4o1a8w8iEd0xjtNfIzNhduBegG/zpbD2YwICMVenyY4hP80cTosa8j7fi403g1cQ3QZHc4Po4jZAt2ccu+3+bchse36Yf4azHt714s4uR9MA3UoErPDL/QZXUHl+J0HnqFzX2YljJou5Xm+ASbUjnumVLgGBmRZZkb2bDol+WbLPuapvCRZRS2KzFZwVZBD1948GRqGYLibss9422RIDrkfav880SXoob06p6Uo9dRDMx3mb145K+ie6snlwm/sVJtNJXmPayUqYZY5Cpg0uBbvv3/SQuBZbMEnMhTW3ItrXQ== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id vAENtNXj032507-vAENtNXl032507 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Wed, 15 Nov 2017 00:55:23 +0100 Received: from [94.198.159.133] (94.198.159.133) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 15 Nov 2017 00:55:21 +0100 To: References: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> <7D6D7E06-87D0-4A2D-A6E3-AF75521A51C9@apnic.net> <1510666927.3986.3.camel@inet.tu-berlin.de> From: "Giovane C. M. Moura" Message-ID: <554ecdb1-c5fb-8d47-d10e-c9d098a5aeb8@sidn.nl> Date: Wed, 15 Nov 2017 07:55:15 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1510666927.3986.3.camel@inet.tu-berlin.de> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.133] X-ClientProxiedBy: ka-hubcasn01.SIDN.local (192.168.2.171) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.133, helo=, mailFrom=giovane.moura@sidn.nl, headerFrom=giovane.moura@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of giovane.moura@sidn.nl designates 94.198.159.133 as permitted sender) smtp.mailfrom=giovane.moura@sidn.nl Archived-At: Subject: Re: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 23:55:27 -0000 > To pic up on this, because i have been wondering about it for some time now: Does that not defeat > the purpose of having multiple authoritative servers set for DNS zones? Given that one deploys > anycast for all auth. NS, queries from a client, in my understanding, would mostly arrive at the > (geographically) same node. Hence an issue at that one node, e.g., a faulty Bind refusing to start > or a dDoS to the anycast zone, will make the whole zone unavailable to clients of a specific region, > as all IP traffic for any auth NS will be directed to a potentially unresponsive AS, requiring semi- > manual failover (retracting the network used for anycast)? > > This would not be the case when using the DNS "redundancy measure", which, while introducing latency > due to (potential timeouts) provides better resilience? This is not what we recommend. We recommend using anycast on every NS, not using the same infrastructure for every NS. The scenario your describe is, in practice a single NS scenario! See our IEPG presentation on that[1]. Let's say you run a large website with four NSes. You don't want to have all your NS on the same infrastructure -- the scenario you described. In the case of a DDoS that is bigger than what your infra can handle, all of your NS will go down. That happened before, leaving many clients unreachable[2]. The key here is *diversity*. You don't want to run your four NS on the same infra[1], in fact, you should diversify. If you run a large website, maybe you could run 4 NSes: 2 on two different anycast networks you maintain (to avoid collateral damage -- see about it on [3]) and the two others on two different DNS providers. In this way, you have a good mix, which it makes it more difficult to bring your NSes down. /giovane [1] http://iepg.org/2017-11-12-ietf100/02-moura-iepg-ietf100-overlap.pdf [2] https://www.nytimes.com/2016/10/22/business/internet-problems-attack.html [3] https://www.isi.edu/~johnh/PAPERS/Moura16b.html From nobody Tue Nov 14 16:21:43 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CDE127369 for ; Tue, 14 Nov 2017 16:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.28 X-Spam-Level: X-Spam-Status: No, score=-3.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 Uc9PibvOZzNB for ; Tue, 14 Nov 2017 16:21:40 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467EA1270AC for ; Tue, 14 Nov 2017 16:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:cc:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=0B2wk7t4CjMky2i2c1tMysKTEDmU6oyDMOBp3CMKvXg=; b=jvwugWfmfuig/ycAkyOvk4R1bI5O6/RR68BQILkwJJP5x7jM0MVYCSxFIfPfSwUedBKPfvbdF9k0EZYUsHvOK8m0q1Ki5xJQ495B+BnQBj8v2pM1s+e5AsimCuG19EMiK2rf05jneV1GF27Py031lE2OgtBpIaCXOMZsZjnLiXIatYX+E2K/wh9WHFDfYYHQdxWtVV8cEk/5KViyXzOEbycWgKyxQzkbKEB0OGlb33FRx1ZUn96d09TWhXF/tl1+KAMBq1QD5EXQ/YiVEJpEOcUz05j7ZT4slozJpIEmqlaV9owWPB9fLd8scHqp6XJKzXsv7UJq+pCpamuemAODpw== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id vAF0Lc8F000710-vAF0Lc8H000710 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Wed, 15 Nov 2017 01:21:38 +0100 Received: from [94.198.159.133] (94.198.159.133) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 15 Nov 2017 01:21:36 +0100 CC: References: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> <7D6D7E06-87D0-4A2D-A6E3-AF75521A51C9@apnic.net> <1510666927.3986.3.camel@inet.tu-berlin.de> <6CD188A9-339D-4E47-B850-A29727CEBCB7@apnic.net> From: "Giovane C. M. Moura" Message-ID: <6a902600-0bef-e6a8-4fcf-46d9ada0b600@sidn.nl> Date: Wed, 15 Nov 2017 08:21:31 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6CD188A9-339D-4E47-B850-A29727CEBCB7@apnic.net> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [94.198.159.133] X-ClientProxiedBy: ka-hubcasn01.SIDN.local (192.168.2.171) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.133, helo=, mailFrom=giovane.moura@sidn.nl, headerFrom=giovane.moura@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of giovane.moura@sidn.nl designates 94.198.159.133 as permitted sender) smtp.mailfrom=giovane.moura@sidn.nl Archived-At: Subject: Re: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 00:21:42 -0000 > As I recall, when anycast was first considered, much of the motivation was to partition DOS attacks, > so that an attack might take out one or two instances of the authoritative servers but it would be > harder to take out all of them. We have already taken a look on the behavior of anycast and DDoS attacks, and indeed it fulfills its goal [1]. > We seem to have changed the motivational story behind anycast > from damage limitation to some mythical concept of improved performance. I don’t quite understand > the performance argument, given that caching is meant to be the major performance lever in > name resolution, and in the wonderful world of caching the only queries (other than cache > miss/refresh) that head directly to the authoritative servers are for non-existent names. Actually there's a different reasoning. At .nl, we noticed that 23% of our traffic to 4 NSes geo-located in the Netherlands was coming from the US, experiencing RTT > 100ms. We are talking hundreds of millions of daily valid queries. On the other hand, the same NSes were delivering RTTs < 10ms to nl-based resolvers. Given we have a globally diverse query distribution, how can we deliver to all our global clients short response times? First, we needed to understand how resolvers choose authoritatives, and that is what we did with our IMC2017 paper. We learned that recursives will use all available NSes. Therefore, to improve the performance of resovlers such as the US-based ones we see, the only way to do it efficiently is to use anycast, and place sites nearby your biggest clients. And as bonus for using anycast, you are likely to have better DDoS resilience. /giovane From nobody Wed Nov 15 00:46:10 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48E81279EB for ; Wed, 15 Nov 2017 00:46: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 WSNdYb-o0GKL for ; Wed, 15 Nov 2017 00:46:08 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.152.141]) by ietfa.amsl.com (Postfix) with ESMTP id DBC2D1200C1 for ; Wed, 15 Nov 2017 00:46:07 -0800 (PST) Received: from smith.sec.t-labs.tu-berlin.de (5072A964.static.ziggozakelijk.nl [80.114.169.100]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 7C57F2024C; Wed, 15 Nov 2017 09:46:06 +0100 (CET) Message-ID: <1510735566.3986.8.camel@inet.tu-berlin.de> From: Tobias Fiebig To: Geoff Huston Cc: maprg@irtf.org, giovane.moura@sidn.nl Date: Wed, 15 Nov 2017 09:46:06 +0100 In-Reply-To: References: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> <7D6D7E06-87D0-4A2D-A6E3-AF75521A51C9@apnic.net> <1510666927.3986.3.camel@inet.tu-berlin.de> <6CD188A9-339D-4E47-B850-A29727CEBCB7@apnic.net> <1510698451.3986.5.camel@inet.tu-berlin.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 08:46:09 -0000 Heho, > So your response is that you are engineering for the cache miss. Just... for the record... I am not an author of the paper we are discussing, and I am honestly not convinced that the proposed solution solves the root issues in how the web evolved. Instead, it tries to adjust existing practices without changing protocols to fix a design issue somewhere else: On the web-application's part. I agree with the authors, that the problem they are trying to solve is real, and that their solution solves/reduces it. I simply do not think that the solution is the right way to solve things in the context of DNS. > Seems a bit silly when you could be engineering to figure out how to optimise the cache. If the > app is so concerned about this then why not perform the DNS queries well before the point when you > need to actually get the named object? Because, due to the (bad) design of many webapps, this is not possible. You first have to have the client request all the JS you crammed into a site, so the client can then process the JS, only then can it determine the names needed in that JS and so forth. Sadly, you can not pre-determine the DNS names as well, as some are dynamically generated by the client, based on, e.g., local properties, and because several pieces of JS are included from remote places you do not even have control over as a site operators. So, for example a blob with all names sent with the root page, while it would reduce the problem (100ms would not be an issue for UX anymore, as it would only be 100ms once, in parallel, best-case), is not a feasible solution. > i.e. if the app is having a hard time why are you making this a problem that the DNS authoritative > servers feel that have to solve when the app itself could solve it alone? Probably because the app developers do not necessarily care, while the DNS operators want to improve UX for all clients, and hence used a lever they do actually have control about. With best regards, Tobias --  Tobias Fiebig                      building MAR, 4th floor, room 4.003 Fachgebiet INET - Sekr. MAR 4-4        phone: +49 162 243 205 2 Technische Universität Berlin         gpg-fp: 21A9 91EB 4971 ED48 001E Marchstrasse 23 - 10587 Berlin                FBBC B6AF 3CD8 59A2 795B From nobody Wed Nov 15 00:51:58 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB751294A4 for ; Wed, 15 Nov 2017 00:51:50 -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 C0e6igzvo_om for ; Wed, 15 Nov 2017 00:51:48 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail1.net.t-labs.tu-berlin.de [IPv6:2001:638:809:ff11:130:149:220:242]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE4212947E for ; Wed, 15 Nov 2017 00:51:48 -0800 (PST) Received: from smith.sec.t-labs.tu-berlin.de (5072A964.static.ziggozakelijk.nl [80.114.169.100]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 6EEEE590; Wed, 15 Nov 2017 09:51:46 +0100 (CET) Message-ID: <1510735906.3986.10.camel@inet.tu-berlin.de> From: Tobias Fiebig To: "Giovane C. M. Moura" , maprg@irtf.org Date: Wed, 15 Nov 2017 09:51:46 +0100 In-Reply-To: <554ecdb1-c5fb-8d47-d10e-c9d098a5aeb8@sidn.nl> References: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> <7D6D7E06-87D0-4A2D-A6E3-AF75521A51C9@apnic.net> <1510666927.3986.3.camel@inet.tu-berlin.de> <554ecdb1-c5fb-8d47-d10e-c9d098a5aeb8@sidn.nl> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 08:51:50 -0000 Heho, > In this way, you have a good mix, which it makes it more difficult to > bring your NSes down. I did not suggest using the same anycast infrastructure. Only that it will probably lead to six nodes from six anycast pools sitting in one geographic location. At the moment, my anecdotal perception is "all .nl auth servers are directly behind amsix." I think that this should actually be a matter for further work: Traceroute the auth-NS from all atlas nodes, check how often the paths converge, and how many SPOFs there could be (large IX directly in front of all nodes, one big DC operator in a (small) region hosting all nodes etc.) I know that ideally this should not be the case. But well... things tend to go wrong. With best regards, Tobias --  Tobias Fiebig                      building MAR, 4th floor, room 4.003 Fachgebiet INET - Sekr. MAR 4-4        phone: +49 162 243 205 2 Technische Universität Berlin         gpg-fp: 21A9 91EB 4971 ED48 001E Marchstrasse 23 - 10587 Berlin                FBBC B6AF 3CD8 59A2 795B From nobody Wed Nov 15 19:08:02 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793E7126CC4 for ; Wed, 15 Nov 2017 19:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 10KcAVPULnqM for ; Wed, 15 Nov 2017 19:07:58 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BBD124BE8 for ; Wed, 15 Nov 2017 19:07:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=CeEBgL5JDC56rqisGXpzqR2CNMukRKQI85UnjEZQiRk=; b=cDZKDIzpD+bY14/BeYtJY/30Bds6075SN9T3Rd7Ug5qPZKkHTUHkVQSvWTUho9T1vTgcmKtJv6Ofk0mzGHX648fb2Rk2MN25UBbQ+0JjkyyehpI1BivX2JjTQksPqd93y2atX9Id0EUXREWdl/1EFzIV735Xr9ZRdgMc5G/o9mU9HFNiNN5xkeDuMriVN9mWJmHQs2oNxvQKDaOCcKxnj9IVLPoV5QjYkAg1xcd1ckA00+nfk7eUuc+siyn3kJpQPxwxNdDQ9IVrcuDWMh/tqoI+/8+JmqJdiTiLy6SX431cseKDniKGfK/MD1JaPAbQ1MZuzD5Q/+ZeZoGlCIF0JQ== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id vAG37t6O008042-vAG37t6Q008042 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Thu, 16 Nov 2017 04:07:55 +0100 Received: from [94.198.159.133] (94.198.159.133) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 16 Nov 2017 04:07:53 +0100 To: References: <5ee819e8-9dfd-3303-8a14-8bda2180370e@sidn.nl> <7D6D7E06-87D0-4A2D-A6E3-AF75521A51C9@apnic.net> <1510666927.3986.3.camel@inet.tu-berlin.de> <554ecdb1-c5fb-8d47-d10e-c9d098a5aeb8@sidn.nl> <1510735906.3986.10.camel@inet.tu-berlin.de> From: "Giovane C. M. Moura" Message-ID: <7aaf0706-1870-405a-6e65-4e38534cfb71@sidn.nl> Date: Thu, 16 Nov 2017 11:07:47 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <1510735906.3986.10.camel@inet.tu-berlin.de> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.133] X-ClientProxiedBy: ka-hubcasn01.SIDN.local (192.168.2.171) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.133, helo=, mailFrom=giovane.moura@sidn.nl, headerFrom=giovane.moura@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of giovane.moura@sidn.nl designates 94.198.159.133 as permitted sender) smtp.mailfrom=giovane.moura@sidn.nl Archived-At: Subject: Re: [Maprg] follow-up "Recursives in the Wild" presentation @ietf100 X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 03:08:00 -0000 > I did not suggest using the same anycast infrastructure. Only that it will probably lead to six > nodes from six anycast pools sitting in one geographic location. Not a problem per se; the roots have 13 letters, but some letters have sites in the same city. See[1,2]. It all depends on how you design your anycast network. you can have 100s of sites if you want, on very diff locations. And on the internet, what matters is your peering, not the geo location. You can have 6 sites in AMS, on 6 diff datacenters/ASes, totally isolated from each other. >At the moment, my anecdotal > perception is "all .nl auth servers are directly behind amsix." Not true. We have 8 NSes, some anycast with more than 50 sites, some third parties, some global dns providers... And I dunno any DNS provider that would config such a dangerous SPOF setup. If you have evidence of any, let us know. > I think that this should actually be a matter for further work: thats the conclusion on [3] > Traceroute the auth-NS from all atlas nodes, check how often the paths converge, and how many SPOFs > there could be (large IX directly in front of all nodes, one big DC operator in a (small) region > hosting all nodes etc.) That's a new neat trick that does something similar that was presented at IMC2017 [4] :) /giovane [1] http://root-servers.org/ [2] https://www.isi.edu/~johnh/PAPERS/Moura16b.html [3] http://iepg.org/2017-11-12-ietf100/02-moura-iepg-ietf100-overlap.pdf [4] https://conferences.sigcomm.org/imc/2017/papers/imc17-final106.pdf From nobody Fri Nov 17 04:38:02 2017 Return-Path: X-Original-To: maprg@ietfa.amsl.com Delivered-To: maprg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23662126CB6 for ; Fri, 17 Nov 2017 04:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 QXGm_Hx2xMtV for ; Fri, 17 Nov 2017 04:37:57 -0800 (PST) Received: from maximilian.ifi.uzh.ch (maximilian.ifi.uzh.ch [130.60.155.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B037127337 for ; Fri, 17 Nov 2017 04:37:56 -0800 (PST) Received: from authenticated sender schmitt by maximilian.ifi.uzh.ch (Postfix) with ESMTPSA id SA for <8665E80B13F>; maprg@irtf.org To: maprg@irtf.org From: Corinna Schmitt Message-ID: <4193123f-f6d6-8a32-c6be-df68c3c4d6c3@ifi.uzh.ch> Date: Fri, 17 Nov 2017 13:37:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: de-DE X-Virus-Scanned: clamav-milter 0.99.2 at maximilian X-Virus-Status: Clean Archived-At: X-Topics: CfP Subject: [Maprg] CfP - IFIP Networking 2018 - approaching deadline for submission X-BeenThere: maprg@irtf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Measurement and Analysis for Protocols \(MAP\) \(Proposed\) RG mailing list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 12:38:00 -0000 [Apologies for cross and multiple postings] ------------------------------------------------------------------ Call for Papers - IFIP Networking 2018 http://networking.ifip.org/2018 The IFIP Networking 2018 Conference (NETWORKING 2018), to be held in Zurich, Switzerland, is the 17th event of the series, sponsored by the IFIP Technical Committee on Communication Systems (TC6). Accepted papers will be published in the IFIP Digital Library and submitted to the IEEE Xplore Digital Library. The main objective of Networking 2018 is to bring together members of the networking community, from both academia and industry, to discuss recent advances in the broad and quickly-evolving fields of computer and communication networks, to highlight key issues, identify trends, and develop a vision for future Internet technology, operation, and use. The technical sessions will be structured around, but are not limited to, the following areas: Network Architectures, Applications and Services ************************************************ Software-defined networking, network (functions) virtualization, data center networking, cloud/fog computing, information-centric networking, content distribution, tactile internet, cyber-physical systems, Internet-of-Things, optical networks, web architectures and protocols, overlay and P2P networks, evolution of IP network architectures and protocols, green networking, resilient networks, network management, traffic engineering, Quality-of-Service, emerging value-added services and applications. Network Modeling and Analysis ***************************** Topology characterization, performance measurements, traffic monitoring and analysis, use behavior modeling, Quality-of- Experience, data-driven design, user profiling and tracking, complex and dynamic networks, analysis of participatory networks, social networks, socio-economic aspects of networks, pricing and billing. Network Security and Privacy **************************** Network security protocols, trust and privacy, anomaly and malware detection, denial-of-service detection and mitigation, network forensics, authentication, applications of privacy-preserving computation in networks, anonymization, dependability, situational awareness, threat intelligence, blockchains and their applications. Wireless Networking ******************* 5G access networks, long-range communication, ad-hoc and mesh networks, mobile networks, self-organizing networks, wireless sensor networks, visible light communication, localization, delay/disruption tolerant networks, opportunistic networks, wireless power transfer networks, device-to-device communication, vehicular networks. Submission Guidelines ********************* Only full papers (not under submission elsewhere) are considered, with a total length of not exceeding 9 pages (IEEE two-column format, 10 pt). Papers must be submitted electronically via EDAS. Important Dates *************** Abstract registration:   December 1, 2017 (anywhere on earth) Full paper submission:   December 8, 2017 Acceptance notification: February 28, 2018 Camera-ready paper:      March 23, 2018 Conference:              May 14-16, 2018 Organizing Committee ******************** General Chair Burkhard Stiller, University of Zurich, Switzerland Technical Program Committee Chairs Claudio Casetti, Politecnico di Torino, Italy Fernando Kuipers, Delft University of Technology, The Netherlands James Sterbenz, The University of Kansas, U.S.A. Steering Committee Jordi Domingo-Pascual, UPC (Chair), Spain Andrea Passarella, IIT-CNR, Italy Aiko Pras, University of Twente, The Netherlands Henning Schulzrinne, Columbia University, U.S.A. Jozef Wozniak, Gdansk University of Technology, Poland Publications Chair Christian Doeer, TU Delft, The Netherlands Local Arrangements Chair Barbara Jost, University of Zurich, Switzerland Web Chair Corinna Schmitt, University of Zurich, Switzerland For further information please refer to: http://networking.ifip.org/2018 -- ****************************************************** Dr. Corinna Schmitt Head of Mobile and Trusted Communications University of Zurich Department of Informatics (IFI) Communication Systems Group (CSG) Binzmühlestrasse 14 8050 Zürich, Switzerland Phone: +41 (0)44 6357585 Fax: +41 (0)44 635 6809 schmitt@ifi.uzh.ch http://www.csg.uzh.ch/staff/schmitt