From nobody Fri Dec 1 07:48:29 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F6D1293FD for ; Fri, 1 Dec 2017 07:48:28 -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 vukm4QT95GEu for ; Fri, 1 Dec 2017 07:48:26 -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 B9EBD124B09 for ; Fri, 1 Dec 2017 07:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=to:from:subject:message-id:date:user-agent:mime-version:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=iqizIKypJ76LY28wNSHDsxGmVppMfGQMenbCaXrQ/yY=; b=dRZzevRY7jvS0K7XkYc0dBYBS/KFh1qXatboNImLAb25Zptc426iv5UB8jEm/bM5ANQRIeaAl872bZqh+r9YamgSA7W0gYcd067By5lOilyZm0XCnJ4SRAzHSpDsbf5vKD0ixTatWuEtaPmRSncwh6zp2YthRjjuqF1BRQ+8Sehf7J2sxPyVTsxexphHY8cuILBuccwEJTavTfs1BvlsxRpEYsvZ+Xq4t/LpTy1RtrRl5q+kRyRzKDmabVd0ZtbqHlxGNxyE/8ReRSfWRE868EA+ktVTMjYzhvc/sv6oYg/OuZOZr8r/y54hl/2u0ZIv2BGl7+hw4+8wjgBpnrZjCw== Received: from ka-mbx02.SIDN.local ([192.168.2.178]) by arn2-kamx.sidn.nl with ESMTP id vB1FmNcm017317-vB1FmNco017317 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Fri, 1 Dec 2017 16:48:23 +0100 Received: from [94.198.159.133] (94.198.159.133) by ka-mbx02.SIDN.local (192.168.2.178) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 1 Dec 2017 16:48:23 +0100 To: From: "Giovane C. M. Moura" Message-ID: Date: Fri, 1 Dec 2017 16:48:21 +0100 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-hubcasn02.SIDN.local (192.168.2.172) To ka-mbx02.SIDN.local (192.168.2.178) 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: [DNSOP] Measuring DNS TTL Violations in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 15:48:28 -0000 Hi, In the light of the recent discussions on TTL violations and server stale here on the list, I decided to take a look on how often resolvers perform TTL violations in the wild. To do that, I used almost 10K Ripe Atlas probes. You can find a report and datasets at: https://labs.ripe.net/Members/giovane_moura/dns-ttl-violations-in-the-wild-with-ripe-atlas-2 Now, what was more scary were the violations that *increased* the TTL of of RR some more than 10x. That may put users at risk of service domains that may have been already taken down. /giovane ps: related thread on oarc list at : https://lists.dns-oarc.net/pipermail/dns-operations/2017-November/017039.html From nobody Fri Dec 1 08:38:14 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0FA127286 for ; Fri, 1 Dec 2017 08:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=cloudflare.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 ZmgZvZMI15h1 for ; Fri, 1 Dec 2017 08:38:09 -0800 (PST) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 86389126DCA for ; Fri, 1 Dec 2017 08:38:09 -0800 (PST) Received: by mail-wr0-x22e.google.com with SMTP id y21so10707080wrc.1 for ; Fri, 01 Dec 2017 08:38:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iiIlr+dPzcxNkYLYqDU4QFTIIEH4fvns74PI6KopilM=; b=KKZts07GeL7cNbmz2wKEL8t+NIt0Y+HHiczAPwRHoZcNGnkK/xAPX04GxJgLCnOzM4 rWpP+mSVFp02tYbecYBNEP44K9zlcoLmGpraZXj7hbNYDs/LubaV0qndHUmqUhorkf2N 14zHJ/X2gCtf8ADFPHHWG3xHnrjpNaJo7QNaA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iiIlr+dPzcxNkYLYqDU4QFTIIEH4fvns74PI6KopilM=; b=lhrkfAKplE7ic9VTmfuQb+AG15HglGRXxZiZvEW9c5ducNIZEkZGbgIA8NR7npGgkI Bq94IN+d/vAHZIB5RFAzbQvr8JtD0r/MluJZfHTKrLUroq7GDwld82SXcg0bkj6QEV3+ OUuNHErFMHwbxsTSXlj7orzDEmY+Dijgs8LAZye9PkGNUw/gYPl1WXBdFI2hP4fdf/tl epngbk9GQcjGN7gWzZrm0zvxV/GwS9XaXAeJLz6WwO5OHaBoFfphwqHBZcyhYylJvpTy cOI2gTWtmE0577/dUy/eAOv2PkkwX7mX5qxBgsO4ize4V8MUP9iEp1BrmHvft4xOr4fT fqNw== X-Gm-Message-State: AJaThX5xh2zBDcoZ531BCNA5i3Zd7bkHQIWUg8hOXqnEgX/WkPjQ5D/z /Uv19k7l5OGU6CAY9Rzi1BuDWSMqpK9RqEuD7BQzb8M7 X-Google-Smtp-Source: AGs4zMaaDfkSzNAGiDC23mObcfYm1QleiCoXOOhwAeAS7lfqTbK0ykNxGd+Ylm5nJoKAyFzathwoHO3AwTqDvzyeojo= X-Received: by 10.223.132.101 with SMTP id 92mr6143541wrf.85.1512146287793; Fri, 01 Dec 2017 08:38:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.166.136 with HTTP; Fri, 1 Dec 2017 08:38:07 -0800 (PST) In-Reply-To: References: From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Fri, 1 Dec 2017 16:38:07 +0000 Message-ID: To: "Giovane C. M. Moura" Cc: dnsop Content-Type: multipart/alternative; boundary="94eb2c0d21085533f0055f49fee2" Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL Violations in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 16:38:12 -0000 --94eb2c0d21085533f0055f49fee2 Content-Type: text/plain; charset="UTF-8" I strongly disagree with your "terminology", TTL is a hint about maximum caching period, not a demand or a contract. A resolver can at any time for any reason discard cached entries. Many Authoritative operators have "unreasonable" TTL's like less than 10 seconds or multiple days and I see no reason why resolvers do not apply minimal and/or max caching rules that are reasonable. Olafur On Fri, Dec 1, 2017 at 3:48 PM, Giovane C. M. Moura wrote: > Hi, > > In the light of the recent discussions on TTL violations and server > stale here on the list, I decided to take a look on how often resolvers > perform TTL violations in the wild. > > To do that, I used almost 10K Ripe Atlas probes. You can find a report > and datasets at: > > https://labs.ripe.net/Members/giovane_moura/dns-ttl- > violations-in-the-wild-with-ripe-atlas-2 > > Now, what was more scary were the violations that *increased* the TTL of > of RR some more than 10x. That may put users at risk of service domains > that may have been already taken down. > > /giovane > > ps: related thread on oarc list at : > https://lists.dns-oarc.net/pipermail/dns-operations/2017- > November/017039.html > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --94eb2c0d21085533f0055f49fee2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I strongly disagree with your "te= rminology", TTL is a hint about maximum caching period, not a demand o= r a contract.=C2=A0
A resolver can at any time for any reason dis= card cached entries.=C2=A0
Many Authoritative operators have &quo= t;unreasonable" TTL's like less than 10 seconds or multiple days a= nd I see no reason why resolvers do not=C2=A0
apply minimal and/o= r max caching rules that are reasonable.=C2=A0

Olafur

=C2=A0 =C2=A0 =C2=A0

<= /div>

On Fri, Dec = 1, 2017 at 3:48 PM, Giovane C. M. Moura <giovane.moura@sidn.nl>= wrote:
Hi,

In the light of the recent discussions on TTL violations and server
stale here on the list, I decided to take a look on how often resolvers
perform TTL violations in the wild.

To do that, I used almost 10K Ripe Atlas probes. You can find a report
and datasets at:

https://= labs.ripe.net/Members/giovane_moura/dns-ttl-violations-in-the-wil= d-with-ripe-atlas-2

Now, what was more scary were the violations that *increased* the TTL of =C2=A0of RR some more than 10x. That may put users at risk of service domai= ns
that may have been already taken down.

/giovane

ps: related thread on oarc list at :
https://lists.dns-oarc.= net/pipermail/dns-operations/2017-November/017039.html

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--94eb2c0d21085533f0055f49fee2-- From nobody Fri Dec 1 08:44:04 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D211D127286 for ; Fri, 1 Dec 2017 08:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 yQ5mVIUuVfa0 for ; Fri, 1 Dec 2017 08:44:00 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 84BB7126E7A for ; Fri, 1 Dec 2017 08:44:00 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 1F3F55407E8; Fri, 1 Dec 2017 11:43:57 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Jared Mauch In-Reply-To: Date: Fri, 1 Dec 2017 11:43:50 -0500 Cc: "Giovane C. M. Moura" , dnsop Content-Transfer-Encoding: quoted-printable Message-Id: <0D230F29-6F59-4953-BA98-7DB83880F0EF@puck.nether.net> References: To: =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL clamping in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 16:44:02 -0000 > On Dec 1, 2017, at 11:38 AM, =C3=93lafur Gu=C3=B0mundsson = wrote: >=20 >=20 > I strongly disagree with your "terminology", TTL is a hint about = maximum caching period, not a demand or a contract.=20 > A resolver can at any time for any reason discard cached entries.=20 Agreed. > Many Authoritative operators have "unreasonable" TTL's like less than = 10 seconds or multiple days and I see no reason why resolvers do not=20 > apply minimal and/or max caching rules that are reasonable.=20 Yes, I remember a load balancer from the last century that had serious = issues with DNS requests with low TTLs. We ended up replacing it. TTL is certainly a MAX, but no reason you can=E2=80=99t return a shorter = value. My stub resolver may see a lower number if an item is about to = be evicted from cache, should we not see that? Clamping the max seems = helpful and causes the least enduser harm, so is quite wise. =20 The same would be true hitting a large anycast dns server like = 75.75.75.75 or 8.8.8.8, 4.2.2.1, you may hit a different backend for = whatever reason so see varying TTLs for the same query within a 10 = second interval based on that. That=E2=80=99s not bad, it=E2=80=99s = working as designed. I think measurements are interesting though, so identifying TTL clamping = in the wild would be an interesting study. - jared= From nobody Fri Dec 1 09:02:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB60E127775 for ; Fri, 1 Dec 2017 09:02:04 -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=verisign.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 SpWRawW3kJaT for ; Fri, 1 Dec 2017 09:02:03 -0800 (PST) Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34CDA1274D2 for ; Fri, 1 Dec 2017 09:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=638; q=dns/txt; s=VRSN; t=1512147723; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=8VZHaE0JlZNYIte/ueLd1sB4r6STfddm/sTgYRuohd4=; b=Iicv36W5OXK5IRZc+Kpcn0KOJ93+0/75XQRuNj15DW06/gZcwzAYbSHq 0qOMDyZDFq3OKRnTQ45XbNdRRZmH4E+mJ5AoFvCWEDzWiAifcvCQot4Lw Sf6wyb+6w1RpxL6yePCM98gAxjP3idpljV8ds+eYmKj8G6U2FqEfo6H10 zkg4QjFB7kHIXwU2lfD6rJNcCENivRCOq8vvuPA3U8X+qj8GMn425qYe4 OcbV5zMUZPmVN+6AKhW3SyxnCrSYNNBzo3xLgSCazRZTiL+eveH0N9uZW a5KZvZYY0Cpo6tBZhkXd0c4KYVMhX0cKMA2ReYa/k8NgnDIPkPOZHh/q4 w==; X-IronPort-AV: E=Sophos;i="5.45,346,1508803200"; d="scan'208";a="5324720" IronPort-PHdr: =?us-ascii?q?9a23=3A8uVYVRfcq9p2V/1dqUU4DyZ8lGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxcW+Yh7h7PlgxGXEQZ/co6odzbGH4+a4ASQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7?= =?us-ascii?q?Ovr6GpLIj8Swyuu+54Dfbx9GiTe5Yr5+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYe?= =?us-ascii?q?RWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZ?= =?us-ascii?q?TAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v9LlgRgP2hy?= =?us-ascii?q?gbNj456GDXhdJ2jKJHuxKquhhzz5fJbI2JKPZye6XQds4YS2VcRMZcTyxPDJ2h?= =?us-ascii?q?YYsTAeQPPuhYoIv8p1QSohWxChKhBP/0xT9NmnP6wbE23uYnHArb3AIgBdUOsH?= =?us-ascii?q?HModn7NKgdT/u1zLLWwjXHdPNawSr25obVch87p/GDQ7x8etfWxEYyGQLKkE6Q?= =?us-ascii?q?qZf7MDORzeQAqHab4PR6VeKukG4nqg5xoj61ysgwjYnJg5sYx1bZ/it62IY4Pc?= =?us-ascii?q?C0RFJhbdK5EpZduTuWO5Z2T84sWW1kpik3x70etZKmYCQG0okryhzRZvCdboSF?= =?us-ascii?q?4gzvWPyeLDp+mXlrYqiwhwyo/kil0uD8U86030tUoSddidnMs2wN1wTU6siaVv?= =?us-ascii?q?tx5keh1iiL1wDU8uxLOlo0lazGJ54lzb8wk4AcsUXHHi/xhUX2kLOaels+9ui2?= =?us-ascii?q?9evneLTmpoSdN497jAHyKLghmsu6AeggMwgOWXaU+fik2bH+4UH1WqhGg/84n6?= =?us-ascii?q?XDrZzXJcoWqrSnDwJa0osv8xO/AC2n0NQck3kHNlVFeBefgof0NVDBPuv4Deyh?= =?us-ascii?q?jFSoizdm3O7GMaP7ApXMNXjDkbjhfbBn50FAzwozyMhT54hIBbEZPPLzRkjxuc?= =?us-ascii?q?TWABEhLgK62vzpBc581owARWKPDLWVMKTIsV+H/ugvOfWDZJcJuDbhLPgo//Hu?= =?us-ascii?q?jX4+mV8DZ6ap24UYZGq9HvRhPkWZe2Djj8waEWcLowU+SvbmiFuGUTRLfXa9Q7?= =?us-ascii?q?o85i0nCIKhFYrDQYStj6aP3CemBJ1bfXxJClSLEXf1aoqEVfMMZziIIsB/iDAL?= =?us-ascii?q?Sb+hS4pynS2p4bT+wrR6NKL757UdqJTvz8Ny4aWHkhU7+yFuJ8+Z1HyBQWV9hG?= =?us-ascii?q?5OTDgzivNRu0t4nx283LNjjvhDUZR/+vpPX01yYZLDwvdhBtTpchzMZNaSSVmg?= =?us-ascii?q?BN6hBGdiHZoK39YSbhMlSJ2ZhRfZ0n/vWudNmg=3D=3D?= X-IPAS-Result: =?us-ascii?q?A2GGAgDEiiFa//WZrQpcGgEBAQEBAgEBAQEIAQEBAYU3B4N?= =?us-ascii?q?4mmsmg0GVUQqFOwIahVQUAQEBAQEBAQEBAQKBEII4JAGCRgEBAQECASMRRQULA?= =?us-ascii?q?gEIDQsCAiYCAgIwFRACBA4FihqnCoInimQBAQEBAQEBAwEBAQEBAQEBAQEBHYE?= =?us-ascii?q?PgjKDYYIRC4J3gzKBWRaDFTGCMgWSA5BZBgKXDJFYlhwCBAsCGQGBOjaBcG8VZ?= =?us-ascii?q?AGBfoRVeIhvgRQBAQE?= Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id vB1H21LS011583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Dec 2017 12:02:01 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Fri, 1 Dec 2017 12:02:10 -0500 From: "Wessels, Duane" To: =?utf-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= CC: "Giovane C. M. Moura" , dnsop Thread-Topic: [EXTERNAL] Re: [DNSOP] Measuring DNS TTL Violations in the wild Thread-Index: AQHTasLTxY4qIBaVj0GJ+W3UahxQzqMvCooA Date: Fri, 1 Dec 2017 17:02:09 +0000 Message-ID: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: <41F60C050BC7F14D9DCA5A7B8EF7C49B@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL Violations in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 17:02:05 -0000 DQo+IE9uIERlYyAxLCAyMDE3LCBhdCA4OjM4IEFNLCDDk2xhZnVyIEd1w7BtdW5kc3NvbiA8b2xh ZnVyQGNsb3VkZmxhcmUuY29tPiB3cm90ZToNCj4gDQo+IEkgc3Ryb25nbHkgZGlzYWdyZWUgd2l0 aCB5b3VyICJ0ZXJtaW5vbG9neSIsIFRUTCBpcyBhIGhpbnQgYWJvdXQgbWF4aW11bSBjYWNoaW5n IHBlcmlvZCwgbm90IGEgZGVtYW5kIG9yIGEgY29udHJhY3QuIA0KDQpZb3Ugc2F5IGl0cyBqdXN0 IGEgaGludC4gIElmIHlvdSBwdXQgYSBUVEwgb2YgMSBob3VyIG9uIHlvdXIgZGF0YSwgYW5kIEkg aGF2ZSBhIHJlY3Vyc2l2ZSBuYW1lIHNlcnZlciB0aGF0IHJldXNlcyBpdCBmb3IgMiBob3Vycywg MTIgaG91cnMsIDUgZGF5cy4uLiB0aGF0cyBva2F5Pw0KDQpJZiBpdHMganVzdCBhIGhpbnQgdGhl biB3ZSBhcmUgd2Ugc3BlbmRpbmcgYWxsIHRoaXMgZWZmb3J0IG9uICJzZXJ2ZSBzdGFsZSI/DQoN CkRXDQoNCg== From nobody Fri Dec 1 09:16:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CF5127ABE for ; Fri, 1 Dec 2017 09:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=cloudflare.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 bFvG3tx6lyWN for ; Fri, 1 Dec 2017 09:16:50 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 C825E1274D2 for ; Fri, 1 Dec 2017 09:16:49 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id v105so10831016wrc.3 for ; Fri, 01 Dec 2017 09:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=55XPGtSyHFKTDzurqAXHS5O6QWQKlBnOdxJG6GOzARw=; b=UV5eAqh+PV098VCQCdYkL546WFLkjA35oUy3yzDirWhgJK6CSheFzdrPzRogFO74cW dXbi8/AgF9bvaLt1Mpc56FUfH+mx4fQARxD9vGz075LwFKf+5Ouou5rWBKTSF1miM5Ag lzu180ZAzqHvw8/10unUxVQnpwzrQQD0s3zqI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=55XPGtSyHFKTDzurqAXHS5O6QWQKlBnOdxJG6GOzARw=; b=J8cXsOGtzGfMiUESDZE5JkhdegCQnjrFSlrh7GWzFSrUh7bQaZJ3k5lwqEEbENFNI9 iGh7xEIq4CUMgae+/I5stgpM9bPGUfjZZ/cjdk2aJ7Z/eV+ze00jqBxWdHbUEXvtaS74 jMdsURaoNpKs1NaSJJZYLYTWbrNPfQCieUCCptvVoo2g1OIYh3q4LmEfu65MFhi/tYAS JGgWR5LI0mrIo/JD0dMl02bsNGvf0bco52zUeB794S7WdO4Z5wP6oTZyn23cEEL+lZTD MitX8KPgcwWBBN4wiEKV7bLVVPMe1IqGR9JupnI5tgVyfEDt6JiJGjKJOTzDxwdNAbwZ 676g== X-Gm-Message-State: AJaThX6fx6a1um3MXC4z4/5D8Itw1mgmzfNJOEDnh0Sph/TK6zrTYL4S LDThjLTlVihzzZWrc4v7SEaX6RY/taUc5cOpI4cbWA== X-Google-Smtp-Source: AGs4zMbUGZfQr5JmKER5mwrFEXYFg4KoUq9pmm/3oT4RH5t1Y5k85CatNoljKFSh2izOUFACg51xOed4oO/deBvueBM= X-Received: by 10.223.195.103 with SMTP id e36mr6039810wrg.10.1512148608162; Fri, 01 Dec 2017 09:16:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.166.136 with HTTP; Fri, 1 Dec 2017 09:16:47 -0800 (PST) In-Reply-To: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> References: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Fri, 1 Dec 2017 17:16:47 +0000 Message-ID: To: "Wessels, Duane" Cc: "Giovane C. M. Moura" , dnsop Content-Type: multipart/alternative; boundary="f403045c11c0a332fd055f4a88d8" Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL Violations in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 17:16:52 -0000 --f403045c11c0a332fd055f4a88d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 1, 2017 at 5:02 PM, Wessels, Duane wrote: > > > On Dec 1, 2017, at 8:38 AM, =C3=93lafur Gu=C3=B0mundsson > wrote: > > > > I strongly disagree with your "terminology", TTL is a hint about maximu= m > caching period, not a demand or a contract. > > You say its just a hint. If you put a TTL of 1 hour on your data, and I > have a recursive name server that reuses it for 2 hours, 12 hours, 5 > days... thats okay? > > If its just a hint then we are we spending all this effort on "serve > stale"? > > DW > > Strictly speaking yes, it is the same as when a Secondary does not update the zone for a long time. DNS is not a strict coherency protocol, thus playing loose with the time things are with in reason is ok. Stretching TTL from 1 Hour to 1 day is IMHO BAD, doing it for 10% or 10 minutes is fine. We are getting into religion here, the original poster called people that cap TTL's Heretics, I disagree with that labeling of myself and others that are applying sane caps. Olafur --f403045c11c0a332fd055f4a88d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On Fri, Dec 1, 2017 at 5:02 PM, Wessels, Duane <dwe= ssels@verisign.com> wrote:
=
> On Dec 1, 2017, at 8:38 AM, =C3=93lafur Gu=C3=B0mundsson <olafur@cloudflare.com> wrote:
>
> I strongly disagree with your "terminology", TTL is a hint a= bout maximum caching period, not a demand or a contract.

You say its just a hint.=C2=A0 If you put a TTL of 1 hour on your da= ta, and I have a recursive name server that reuses it for 2 hours, 12 hours= , 5 days... thats okay?

If its just a hint then we are we spending all this effort on "serve s= tale"?

DW


Strictly speaking yes, it is the same = as when a Secondary does not update the zone for a long time.=C2=A0
DNS is not a strict coherency protocol, thus playing=C2=A0 loose with th= e time things are with in reason is ok.
Stretching TTL from 1 Hou= r to 1 day is IMHO BAD, doing it for 10% or 10 minutes is fine.=C2=A0
=
We are getting into religion here, the original poster called people t= hat cap TTL's Heretics,=C2=A0
I disagree with that labeling o= f myself and others that are applying sane caps.=C2=A0

=
Olafur

--f403045c11c0a332fd055f4a88d8-- From nobody Fri Dec 1 09:23:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A91129418 for ; Fri, 1 Dec 2017 09:23:43 -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] 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 Y_Y6mmWvZ9v2 for ; Fri, 1 Dec 2017 09:23:42 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 0F137129413 for ; Fri, 1 Dec 2017 09:23:42 -0800 (PST) Received: from [10.32.60.129] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vB1HM5PF042932 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Dec 2017 10:22:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.129] From: "Paul Hoffman" To: "=?utf-8?b?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?=" Cc: dnsop Date: Fri, 01 Dec 2017 09:23:38 -0800 Message-ID: <953C8354-3F9D-46A4-82AB-7ED3A9E17387@vpnc.org> In-Reply-To: References: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL Violations in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 17:23:44 -0000 On 1 Dec 2017, at 9:16, Ólafur Guðmundsson wrote: > We are getting into religion here, the original poster called people that > cap TTL's Heretics, Looking through the mail archives, no one other than you is using that term. --Paul Hoffman From nobody Fri Dec 1 09:53:10 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C111275C5 for ; Fri, 1 Dec 2017 09:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 DcMRE3mIAxom for ; Fri, 1 Dec 2017 09:53:06 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB39126D74 for ; Fri, 1 Dec 2017 09:53:06 -0800 (PST) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id D3DF9540B9A; Fri, 1 Dec 2017 12:53:03 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Jared Mauch In-Reply-To: <953C8354-3F9D-46A4-82AB-7ED3A9E17387@vpnc.org> Date: Fri, 1 Dec 2017 12:52:57 -0500 Cc: =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , dnsop Content-Transfer-Encoding: quoted-printable Message-Id: References: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> <953C8354-3F9D-46A4-82AB-7ED3A9E17387@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL clamping in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 17:53:07 -0000 > On Dec 1, 2017, at 12:23 PM, Paul Hoffman = wrote: >=20 > On 1 Dec 2017, at 9:16, =C3=93lafur Gu=C3=B0mundsson wrote: >=20 >> We are getting into religion here, the original poster called people = that >> cap TTL's Heretics, >=20 > Looking through the mail archives, no one other than you is using that = term. I think this is subject to interpretation, some people view the done = differently. The subject line felt hostile.. 2nd attempt to adjust subject-line to = make it less hostile. - jared From nobody Fri Dec 1 10:12:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FE412762F for ; Fri, 1 Dec 2017 10:12:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=shinkuro-com.20150623.gappssmtp.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 7TWNg0od4mcD for ; Fri, 1 Dec 2017 10:12:39 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 652F81275C5 for ; Fri, 1 Dec 2017 10:12:39 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id e2so14107687qti.0 for ; Fri, 01 Dec 2017 10:12:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shinkuro-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2zXFaAvmipfhqeEVcv8w3b/Vcd2Yecm/yk2CXVXyuUs=; b=KBIxKv+jns48A7kWql2TMbeo5gyaCnDt1ZHaQFGu+rGnwVOQ2uDnnDZpV+g9evtVdq hOhDwQJFq1V2qOz8Rx/agY0iRwnNcxYrlCX19QFhCJwiNhoSsIs3QIe1hSmXznY8Gmlc Lh+y0tD7QO0Qc90gLfr1RZstQalvhC3k6OYnrvhu4B+kwlSJQhnAU18XFhL8UxrNZKwq 5V7ApZsAYbsHfsbQ5sIxYHnbrQrLoUt9xMmgbjIIbLkR3/YoRa2HnThr0P5uWNEeL5+o WXnwTinGkjY4Fkmvx5WnlyBhbZVgOMxHWZR64jtAw9117sR+nKOAxmBRZGUUWQhKJxIu cPsg== 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=2zXFaAvmipfhqeEVcv8w3b/Vcd2Yecm/yk2CXVXyuUs=; b=XcSCipl8iydiGRl7To8NhRiwphyUp0CNFKlG3/jrFj/6P9nCEc+7HRKcoildS6CgEc 7JOEgdVTQzvpOMT6eHYtsThED0dBtqbh30QeFNBty7Gw2QAA8mJs0haCAZbxf9sdcrCI k8tmUmMzlgd+S8i1aONbOFqqBE/I3vMccMgcJNsg574FOsyfVfjxWvhycTTkxNNSr54x bC8Gv5GpWSSXvl3i4a+mJSbb4ZyiRdeQBHAvTyWD1iuExyOdvIZORiyTpGezedO8f004 dAQ09fZtFVihTIh+q6GmdFa4RImWQ0zTFyo9XJXQhWsvyuJ5mFXMNMWaNoQSTg2TI1Au z+BQ== X-Gm-Message-State: AKGB3mIQOoV+6n8qSEJYZQsz2SFIL1WHoVwEdPhQbjQj3zUuZFBJ/rKh i9MV1kh6QclB8eQjQVjTLu8QJQ== X-Google-Smtp-Source: AGs4zMbDfk+pId/DObNnisNFEoV/Nm9ZIBeVJuW8OxCDwJUSnQVd1nJPFUXzd4DCxRNoZz21EMdQ4g== X-Received: by 10.200.48.144 with SMTP id v16mr10142196qta.244.1512151958508; Fri, 01 Dec 2017 10:12:38 -0800 (PST) Received: from [192.168.168.139] (70-88-139-89-adhvan-corporation-va.hfc.comcastbusiness.net. [70.88.139.89]) by smtp.gmail.com with ESMTPSA id i190sm4924568qkd.5.2017.12.01.10.12.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 10:12:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Steve Crocker In-Reply-To: Date: Fri, 1 Dec 2017 13:12:34 -0500 Cc: "Stephen D. Crocker" Content-Transfer-Encoding: quoted-printable Message-Id: <61DF0A99-0B74-40AB-815F-3DF78755EBE5@shinkuro.com> References: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> <953C8354-3F9D-46A4-82AB-7ED3A9E17387@vpnc.org> To: Jared Mauch , Paul Hoffman , =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , dnsop X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL clamping in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2017 18:12:50 -0000 I would be very interested in a bit more precision here. Is there a way = to say what is permissible vs impermissible re TTLs, and is there a way = to say what is desirable vs undesirable re TTLs? We all understand that = longer TTLs reduce the frequency of refresh at the expense of slower = response whenever the authoritative information changes. However, some = fraction of the recursive resolvers impose minimum and/or maximum limits = on the TTLs they receive from the authoritative servers. Shortening TTLs increases the amount of traffic between the recursive = resolvers and authoritative resolvers and lengthens the response time = for some queries. However, I don=E2=80=99t think there is any service = guarantee with respect to an individual query that is violated by = shortening the TTL. Lengthening a TTL, on the other hand, does change one of the service = guarantees. When there is a change in the entry in the authoritative = server, what is the maximum time until that change is guaranteed to be = propagated throughout the net? This depends primarily on the TTL. = However, when the TTL is lengthened by the recursive resolvers, the = upper bound for propagation of a change is similarly increased. Is there any common understanding of how much lengthening is permitted? = Is commonplace? Let me make a guess that the only lengthening that takes place in = practice is a floor of ten seconds. Comments? Thanks, Steve > On Dec 1, 2017, at 12:52 PM, Jared Mauch = wrote: >=20 >=20 >=20 >> On Dec 1, 2017, at 12:23 PM, Paul Hoffman = wrote: >>=20 >> On 1 Dec 2017, at 9:16, =C3=93lafur Gu=C3=B0mundsson wrote: >>=20 >>> We are getting into religion here, the original poster called people = that >>> cap TTL's Heretics, >>=20 >> Looking through the mail archives, no one other than you is using = that term. >=20 > I think this is subject to interpretation, some people view the done = differently. > The subject line felt hostile.. 2nd attempt to adjust subject-line to = make it less hostile. >=20 > - jared >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Sat Dec 2 02:29:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64310124234 for ; Sat, 2 Dec 2017 02:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, URIBL_BLOCKED=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 k5j1xiwKekbr for ; Sat, 2 Dec 2017 02:29:39 -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 4A8CC1201FA for ; Sat, 2 Dec 2017 02:29:38 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4F92FB5; Sat, 2 Dec 2017 11:29:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1512210575; bh=P7BnYJdF4WxRTCFq9OROpErpz4LLgEazRI7jD3cPOBc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ctSDTYJdhmDdcXctx1MHQRID76in3rcdy0CAK/xSoFv8VPBVr8QZeDSFCi9qLhJvH H3iZ0vmR2peOnznNYWSDP1WKvneKxYyLJ1lX24Q7Z8cXusc0wgMfOwRPW3j1DUU9b7 lB30Pbes0m0Rj3GNHcc5wt61TyKXW7R3iH34++Es= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3688EB4; Sat, 2 Dec 2017 11:29:35 +0100 (CET) Date: Sat, 2 Dec 2017 11:29:35 +0100 (CET) From: Mikael Abrahamsson To: Steve Crocker cc: dnsop In-Reply-To: <61DF0A99-0B74-40AB-815F-3DF78755EBE5@shinkuro.com> Message-ID: References: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> <953C8354-3F9D-46A4-82AB-7ED3A9E17387@vpnc.org> <61DF0A99-0B74-40AB-815F-3DF78755EBE5@shinkuro.com> 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: [DNSOP] Measuring DNS TTL clamping in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2017 10:29:41 -0000 On Fri, 1 Dec 2017, Steve Crocker wrote: > Let me make a guess that the only lengthening that takes place in > practice is a floor of ten seconds. > > Comments? I might be misinterpreting, but from the data presented in the graph in section 3.2 it looks like some will increase TTL to 7200 seconds at the highest. There seems to be large bumps at the 600, 1200 and 1800 second "minimum TTL" capping (if I guess correctly from looking at that graph). It would be interesting to hear what problems these operators are trying to solve by implementing these minimums. 7200 seconds does seem like a pretty high value to lower bound TTLs at. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sat Dec 2 04:19:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71852126B6E for ; Sat, 2 Dec 2017 04:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netiadata.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 qdYL5Jh4jArH for ; Sat, 2 Dec 2017 04:19:35 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0071.outbound.protection.outlook.com [104.47.0.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891571205F1 for ; Sat, 2 Dec 2017 04:19:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netiadata.onmicrosoft.com; s=selector1-netia-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OtzldOsSApSaJ6RpiR4qyj3TAzigaGARe0AYRewXWe0=; b=PLeW2T1WKFrrd0ShHXGJ7kiIKbwVpL/L+ypTe2Z/ga3Sv4/tKKujmbxuOdKQmYnKCFmJrSkiyhLiHMH521kU2/+mW10XFygna59D/qewwe3fEu7eho8ytGZG+wsNEwTMowNE1EMgYr1649rD8ISnGcXHIeXdEWEyQMNl1CZeUlY= Received: from DB5PR09MB0567.eurprd09.prod.outlook.com (10.161.200.27) by DB5PR09MB0565.eurprd09.prod.outlook.com (10.161.199.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.5; Sat, 2 Dec 2017 12:19:30 +0000 Received: from DB5PR09MB0567.eurprd09.prod.outlook.com ([fe80::f141:69a:aab9:ed6b]) by DB5PR09MB0567.eurprd09.prod.outlook.com ([fe80::f141:69a:aab9:ed6b%14]) with mapi id 15.20.0282.007; Sat, 2 Dec 2017 12:19:30 +0000 From: =?iso-8859-1?Q?=C5ke_Nordin?= To: Mikael Abrahamsson , dnsop Thread-Topic: [DNSOP] Measuring DNS TTL clamping in the wild Thread-Index: AQHTas1JOevpUaKupk+LCeZDRBqcb6MuylEAgAEQ+YCAAByWUA== Date: Sat, 2 Dec 2017 12:19:29 +0000 Message-ID: References: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> <953C8354-3F9D-46A4-82AB-7ED3A9E17387@vpnc.org> <61DF0A99-0B74-40AB-815F-3DF78755EBE5@shinkuro.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ake.nordin@netia.se; x-originating-ip: [2001:470:28:7e7:941:396e:504a:233f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR09MB0565; 6:ff2m5gRHUVo6BZ3+mcDkrPKUc88y5cJxrML2xgJq3Z4ukY7w8gSUaKQW+WmuK2o2Fj02eUJWU0XqeCzmnlbjA8R7AxKvJFEtG2Drf7LJb85A4PvyJ65otbxh0k4P7Hdmyt25snjo+IDVM/8QwBmIMxFMqOy8isr9lPz9oJxrac2YioS67XaB8IGWzvhRg51r/5FYdH5XvNtlBuCzitfmY4xgrAUwZDwlMJmiLXhnB5tELEPxtt4xBgzDmmzapaAxJ396MAmZppF0wmeqvIIlx4AGmen3qZg16HAmcU0jHk4HQrnNmBzHdYMbiALwL2Q20OsQW1GBhSS5hvJAl7iOmmzklMhgbZeFzwyFtqkgiQc=; 5:L7s7I/WejFAaC3KYnlZilnhmhacyziUjy10Zxj7qr2URamtj09cbQAs/J+5Cp7FHjo3+jbNQNHTn9DXsdSD5sbdgciqKbOVRj/jkVLXRZKymEKOIqKcmDOByriTFyaWfBLQd5g45QBFGqYHUAiPdGJUeKQ9wK+nLwY11/mV6RgA=; 24:5P2jRdMy+WsS5vkdFZMHvQbWIHKDa/taXO9oqVidJy7FuobLhtgd74NL+Ei4s877Fv/psV4omUx1k7nrzFN2xFfI3nDdv5hzhjTOawuLbU4=; 7:qzpWfoOvoxBj86PK2Bq46ev/gIl3GyNTvuDMwm97qi6Z2l+SxTlzWqOUQbR+7YTBwyu46J98GOmc2Sx4UD6oYiCPevosOymZQfbpp9kYWFpMcyLQTo+ucNxT9idARpv6p1+YCqfsLB4RK0cZ5SjWMq5wS8DDsUW4hydj0acDPkV0OT369KicmblzqUOzD+o/KL3KUFSRaMoNfscxYrdj0LC4NLLIY09LB0cf4CxWIyNkrtjULD+9bYwzAWm3XtF3 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9dc83695-75f8-4ad7-cd23-08d5397ef033 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603286); SRVR:DB5PR09MB0565; x-ms-traffictypediagnostic: DB5PR09MB0565: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231022)(6041248)(2016111802025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(6072148)(6043046)(201708071742011); SRVR:DB5PR09MB0565; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB5PR09MB0565; x-forefront-prvs: 0509245D29 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(366004)(39830400002)(199003)(24454002)(189002)(6436002)(99286004)(19627405001)(5250100002)(7696005)(97736004)(14454004)(54896002)(53936002)(9686003)(6506006)(25786009)(68736007)(106356001)(54356011)(33656002)(5660300001)(229853002)(6246003)(6606003)(55016002)(2950100002)(76176011)(105586002)(6116002)(86362001)(2900100001)(8676002)(81156014)(81166006)(7736002)(189998001)(74316002)(110136005)(3280700002)(8936002)(93886005)(316002)(478600001)(101416001)(3660700001)(74482002)(2906002)(102836003)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR09MB0565; H:DB5PR09MB0567.eurprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netia.se does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR09MB0567E6A4C423C33F6E8611D5E43E0DB5PR09MB0567eurp_" MIME-Version: 1.0 X-OriginatorOrg: netia.se X-MS-Exchange-CrossTenant-Network-Message-Id: 9dc83695-75f8-4ad7-cd23-08d5397ef033 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2017 12:19:29.9351 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8340c518-70dd-4f37-8ede-b82b05e8cdf6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR09MB0565 Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL clamping in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2017 12:19:37 -0000 --_000_DB5PR09MB0567E6A4C423C33F6E8611D5E43E0DB5PR09MB0567eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Sat, 2 dec 2017, Mikael Abrahamsson wrote: > On Fri, 1 Dec 2017, Steve Crocker wrote: > > > Let me make a guess that the only lengthening that takes place in > > practice is a floor of ten seconds. > > > > Comments? > > I might be misinterpreting, but from the data presented in the graph in > section 3.2 it looks like some will increase TTL to 7200 seconds at the > highest. There seems to be large bumps at the 600, 1200 and 1800 second > "minimum TTL" capping (if I guess correctly from looking at that graph). > > It would be interesting to hear what problems these operators are trying > to solve by implementing these minimums. 7200 seconds does seem like a > pretty high value to lower bound TTLs at. Whoah, extending TTL to 2h becomes pretty bad when the name was nefarious and taken down within, say, 15 minutes. That renders a lot of good people's work less useful. BR, -- =C5ke Nordin , resident Net/Lunix/telecom geek. --_000_DB5PR09MB0567E6A4C423C33F6E8611D5E43E0DB5PR09MB0567eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On Sat, 2 dec 2017, Mikael Abrahamsson wrote:
> On Fri, 1 Dec 2017, Steve Crocker wrote:
>
> > Let me make a guess that the only lengthening that takes place in=
> > practice is a floor of ten seconds.
> >
> > Comments?
>
> I might be misinterpreting, but from the data presented in the graph i= n
> section 3.2 it looks like some will increase TTL to 7200 seconds at th= e
> highest. There seems to be large bumps at the 600, 1200 and 1800 secon= d
> "minimum TTL" capping (if I guess correctly from looking at = that graph).
>
> It would be interesting to hear what problems these operators are tryi= ng
> to solve by implementing these minimums. 7200 seconds does seem like a=
> pretty high value to lower bound TTLs at.

Whoah, extending TTL to 2h becomes pretty bad when the name was nefarious and taken down within, say, 15 minutes. That renders a lot of good people's=
work less useful.

BR,

--
=C5ke Nordin <ake.nordin@netia.se>, resident Net/Lunix/telecom geek.<= /div>
--_000_DB5PR09MB0567E6A4C423C33F6E8611D5E43E0DB5PR09MB0567eurp_-- From nobody Sat Dec 2 06:39:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F051286B1 for ; Sat, 2 Dec 2017 06:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 JiRLCZ4kkyAG for ; Sat, 2 Dec 2017 06:39:33 -0800 (PST) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 09757128656 for ; Sat, 2 Dec 2017 06:39:32 -0800 (PST) Received: from jurassic.lan.banu.com (unknown [115.118.156.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 47C1956A0806; Sat, 2 Dec 2017 14:39:28 +0000 (GMT) Date: Sat, 2 Dec 2017 20:09:25 +0530 From: Mukund Sivaraman To: =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= Cc: "Wessels, Duane" , dnsop , "Giovane C. M. Moura" Message-ID: <20171202143925.GA20446@jurassic.lan.banu.com> References: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL Violations in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2017 14:39:34 -0000 On Fri, Dec 01, 2017 at 05:16:47PM +0000, Ólafur Guðmundsson wrote: > On Fri, Dec 1, 2017 at 5:02 PM, Wessels, Duane > wrote: > > > > > > On Dec 1, 2017, at 8:38 AM, Ólafur Guðmundsson > > wrote: > > > > > > I strongly disagree with your "terminology", TTL is a hint about maximum > > caching period, not a demand or a contract. > > > > You say its just a hint. If you put a TTL of 1 hour on your data, and I > > have a recursive name server that reuses it for 2 hours, 12 hours, 5 > > days... thats okay? > > > > If its just a hint then we are we spending all this effort on "serve > > stale"? > > > > DW > > > > > Strictly speaking yes, it is the same as when a Secondary does not update > the zone for a long time. An authoritiative server operator knows what the consequence of setting SOA RDATA fields is. It isn't the same as a cache extending TTL as it sees fit, in spite of the loose coherency among primary and secondaries. I don't agree a downstream cache has authoritiative say about extending TTLs (except exceptional circumstances where the authority is unreachable ~serve-stale). Mukund From nobody Sun Dec 3 15:18:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8107E1250B8 for ; Sun, 3 Dec 2017 15:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 vDNbPAO3wVh7 for ; Sun, 3 Dec 2017 15:18:22 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 954761200F1 for ; Sun, 3 Dec 2017 15:18:22 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id b123so19378442qkg.7 for ; Sun, 03 Dec 2017 15:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=YzyqWDy8yzlcC4Vy5H74ZGDTBcGBosy+LJns2vS3a1s=; b=XlMOo9yJjtoi3QSZO5CECtvAqcmyjxmDRClIp/4LzAgpd0AJpziPx/lOWxYNzz0SN5 1vPRZ7jh7blVdfFeBOEL3o7/DIGuWiLQoVf4JE0c2CaK4CRua3Y1Hb1EOSm6TNy3fJ/X +G67pLu1BvsYOhJis2BRIHHVAsytJ1ic/GSpLGX+hGhGezqEePCO5uJG11D357GexXAV 1tKgVkSl4aWogqjOfYcyGdPV8wQMyHhs56BgFyBq7YKMqeY0HdQN8s9NbhWt9YGTUKgM HIdTvN8Qa7Hq2ss2hCHZ88Yl+/gcLy7B8B/P0FW2aIylzuNNDCtLVriCHnsJjqq5Mb/W 7FNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=YzyqWDy8yzlcC4Vy5H74ZGDTBcGBosy+LJns2vS3a1s=; b=lwQ/Ia4yv0/t/nNBEVaPuvr1hsfBRk04aCSltLSMb/1hUk8O2A6PgdNQdT30Gn05SB AmvypccFtCjRM5KeczdqIoRqkLLQBkO23eYkRU4u8GJ/ENA7veAOtDQSbYSEdMJEM12u 8yhNWnzp+hV7Oss6yjqTuALf58sxyCfN6D23JNNUXxO0UH0khFiv9RpyEMNQsIiyacKT yZ6HgizmwjYVOZz7izuxCTR2vbmypSydC3SV/kCcP5Tl5xOEv4fC467+1iMk3lpkpoCQ N9anu9HntV7KsWZPcS5mNWdOtvb4Hgxxp94/HZQxUFBFajG78raIWIh3hHo92T4Bvkfw GCoQ== X-Gm-Message-State: AKGB3mI/mwz96e3Y+3V+91IlMSES8USLlv6mM95p6h0AHGLliW80rKcG CH7AmO3RyGjycv9Gd3gXoUaiDYLq X-Google-Smtp-Source: AGs4zMb4zmvV1dvah3dmKMGIR/RF5maX5zh6moHXi0FwYr2WAnkWmBhdrRFANeGLz10N2UOBmXanbg== X-Received: by 10.55.162.130 with SMTP id l124mr1965786qke.168.1512343101165; Sun, 03 Dec 2017 15:18:21 -0800 (PST) Received: from ?IPv6:2601:152:4400:720f::1014? ([2601:152:4400:720f::1014]) by smtp.gmail.com with ESMTPSA id k34sm8503619qtk.5.2017.12.03.15.18.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Dec 2017 15:18:19 -0800 (PST) To: dnsop@ietf.org References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> From: Michael StJohns Message-ID: <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> Date: Sun, 3 Dec 2017 18:18:18 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Dec 2017 23:18:24 -0000 On 11/29/2017 5:29 PM, Wes Hardaker wrote: > internet-drafts@ietf.org writes: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Domain Name System >> Operations WG of the IETF. > FYI, this contains the restructuring talked about during IETF100/dnsop > as well the new safetyMargin concepts proposed by MSJ. I haven't done a > complete double check on all my restructuring yet, so for the chairs > especially: there will likely be a -09 very soon ready for second WGLC, > but not this one. Hi - Much improved - but still some disconnects (all review is de novo): In Abstract - insert "by the publisher" after "must be followed" - this is clear later, but should be clear in the abstract. in Section 2 - first para - "from the DNSKEY publication and revocation's point of view" is unusual phrasing.  I'm not sure how a publication or revocation has a point of view.  I think you meant from the trust anchor publisher or SEP DNSKEY publisher's point of view? in 3 - lastSigExpirationTime - replace the first sentence  with "The latest value (i.e. the future most date and time) of any RRSig Signature Expiration field  covering any DNSKEY RRSet containing only the old trust anchor(s) that are being superseded." - This may still need wordsmithing or expansion. in 3 - sigExpirationTimeRemaining - two items: "latestSigExpirationTime" -> lastSigExpirationTime.  and measured from when?   I think its "when the addWaitTime calculation is run" or "lastSigExpirationTime - now" in 5.1.1 T+10 - replace "they have now expired" with "the signatures have now expired" -  clarify context. Delete 6.1.4 - activeRefreshOffset -  its a nonsensical value that is only valid from the resolver's point of view.   For a given publisher/authoritative server - there will be as many activeRefreshOffsets as there are resolvers so the publisher must assume the worst case of activeRefresh. In 6.2.1 - replace activeRefreshOffset with activeRefresh - worst case value. fix 6.2.1.1 delete the term for addHoldDownTime % activeRefresh - the "2 * activeRefresh" in the previous term covers both the activeRefresh interval at the beginning of the acceptance period and the activeRefresh interval at the end. In 6.2.2 - same changes as for 6.2.1 and 6.2.1.1 (e.g. get rid of activeRefreshOffset throughout).                         v          activeRefresh v     addHoldDownTime                 v    activeRefresh v  safetyMargin  v |-----------------------|-------------------------------------|-------------------------------------|--------------------------|----------------|  lastSigExpirationTime^^^                 acceptanceStarts ^^^       acceptance begins to complete^^            earliestSafe^^^ After the second activeRefresh interval all of the well behaved and well connected resolvers should have the new trust anchor. The safetyMargin adds some space for poorly behaving or intermittently connected resolvers or those with some drops in queries. Section 6.3 has one too many activeRefresh terms in both formulas - here are the corrected ones: remWaitTime = sigExpirationTimeRemaining + activeRefresh + safetyFactor remWallClockTime = lastSigExpirationTime + activeRefresh + safetyFactor Basically, assuming no attacker, and no drops, all well-behaved resolvers will see the revocation after one activeRefresh interval from the time of publication.  Add the safety factor to take care of the slackers.  This is a fine value for normal revocations where you're pretty sure that the key hasn't been compromised. There is no hold-time timer for revocation - they take effect immediately upon receipt and validation. In the case of a key compromise, I would suggest that the revoked key be published for the same interval as you would use for adding a new trust anchor.  (But of course, this won't actually matter all that much if you only have a single trust anchor....) Appendix A - fix the calculations to match up with the section 6 formulas. Later, Mike From nobody Sun Dec 3 17:49:44 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF58120227 for ; Sun, 3 Dec 2017 17:49:42 -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] 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 M4PgUe8JZNN5 for ; Sun, 3 Dec 2017 17:49:41 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 0249D1201F8 for ; Sun, 3 Dec 2017 17:49:40 -0800 (PST) Received: from [169.254.119.93] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vB41m3B3071123 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 3 Dec 2017 18:48:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.119.93] From: "Paul Hoffman" To: "dnsop@ietf.org" Date: Sun, 03 Dec 2017 17:49:37 -0800 Message-ID: In-Reply-To: References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> <5562271920774233970@unknownmsgid> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 01:49:42 -0000 On 27 Nov 2017, at 5:22, Tony Finch wrote: > Joe Abley wrote: >> On Nov 23, 2017, at 12:44, Tony Finch wrote: >> >>> It's quite difficult to have multiple masters and DNSSEC and >>> coherent >>> copies of the zone from all masters - i.e. more effort than just >>> spinning >>> up parallel instances of BIND or Knot in automatic signing mode. >> >> Note that I wasn't talking about multiple signers; I was talking >> about >> (from the perspective of one particular slave) having multiple >> masters >> available to serve precisely the same zone. > > A primary master is wrt a zone not a server - a zone's primary master > is > a server that's authoritative for a zone and which does not get the > zone > contents via axfr/ixfr, but instead from a master file and/or UPDATE > (or > a non-standard mechanism such as directly from a database). That sounds correct. It also sounds quite different than what is defined in RFC 1996 and RFC 2136. How is this for new wording? The idea of a primary master is only used in and , and is considered archaic in other parts of the DNS. A modern interpretation of the term "primary master" is a server that is both authoritative for a zone and that gets its updates to the zone from configuration (such as a master file) or from UPDATE transactions. --Paul Hoffman From nobody Mon Dec 4 00:53:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260331201FA for ; Mon, 4 Dec 2017 00:53:52 -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 i_Ml6hiiCeeT for ; Mon, 4 Dec 2017 00:53:49 -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 19E9D120046 for ; Mon, 4 Dec 2017 00:53:48 -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=TeVeMhdJDq5J0OVczFCWXtIR0YMsZRQLCgCBOBCP17g=; b=tF/n1UOslzj7xsJ11zIBO/Sczvp56aI7iPZ0zGfjLTTFlZrrBpH5r5nf1AkrL+0qoFECRByPqiHUvU24i7aJ7Ubc6Zn9vxJJYvDvGPOLNiDQ/avfFpVDrbv/wCuM5D5ZMCSBQlt0ENbWq09PmQwgwBrRxO2bqxdmoghvygnrP8j/uQlK8BNiV94M56c0nd8agGkpvasHBUPolAzfLAzeIe18JCTJs6jqyZNzqtD1z1t5OylWb8XCUohyc2WHktHBw2OGClpqYr/p2WMi75Ybgz+WlBexKmi4Y3xRdPRlnfoYrElQ1NNfFr89CVF+l6ggrOOSjqyc0J8WoUkeLx2NtQ== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id vB48rkSB018354-vB48rkSD018354 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Mon, 4 Dec 2017 09:53:46 +0100 Received: from [94.198.159.169] (94.198.159.169) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 4 Dec 2017 09:53:46 +0100 To: References: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> <953C8354-3F9D-46A4-82AB-7ED3A9E17387@vpnc.org> From: "Giovane C. M. Moura" Message-ID: <94e0ff5e-7641-fd81-449c-8fe6130fcb22@sidn.nl> Date: Mon, 4 Dec 2017 09:53:46 +0100 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: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.169] 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.169, 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.169 as permitted sender) smtp.mailfrom=giovane.moura@sidn.nl Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL clamping in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 08:53:52 -0000 Hi, >>> We are getting into religion here, the original poster called people that >>> cap TTL's Heretics, >> >> Looking through the mail archives, no one other than you is using that term. > > I think this is subject to interpretation, some people view the done differently. > The subject line felt hostile.. 2nd attempt to adjust subject-line to make it less hostile. Oh I apologize for the terminology issue. I actually borrowed the term from two previous academic papers: [1] and [2]. [1] http://www.cs.wm.edu/~haos/papers/sigcomm-ccr-dns.pdf [2] https://dl.acm.org/citation.cfm?doid=3143361.3143375 /giovane From nobody Mon Dec 4 04:08:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B4B1273B1 for ; Mon, 4 Dec 2017 04:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 ggrG_mUMWL5W for ; Mon, 4 Dec 2017 04:08:03 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 CB142126FDC for ; Mon, 4 Dec 2017 04:08:03 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:47885) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eLpXV-000Oxp-0c (Exim 4.89) (return-path ); Mon, 04 Dec 2017 12:08:01 +0000 Date: Mon, 4 Dec 2017 12:08:01 +0000 From: Tony Finch To: Paul Hoffman cc: "dnsop@ietf.org" In-Reply-To: Message-ID: References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> <5562271920774233970@unknownmsgid> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 12:08:07 -0000 Paul Hoffman wrote: > On 27 Nov 2017, at 5:22, Tony Finch wrote: > > > > A primary master is wrt a zone not a server - a zone's primary master is > > a server that's authoritative for a zone and which does not get the zone > > contents via axfr/ixfr, but instead from a master file and/or UPDATE (or > > a non-standard mechanism such as directly from a database). > > That sounds correct. It also sounds quite different than what is defined > in RFC 1996 and RFC 2136. How is this for new wording? Primary Master master server at the root of the zone transfer dependency graph. That's exactly the same meaning as what I wrote above. > The idea of a primary master is only used in and > , and is considered archaic in other > parts of the DNS. Can you please provide citations to show that it's considered archaic? > A modern interpretation of the term "primary master" is a server that is > both authoritative for a zone and that gets its updates to the zone from > configuration (such as a master file) or from UPDATE transactions. How is that different to what I wrote? Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Shannon: South 3 or 4, increasing 5 or 6. Moderate or rough. Drizzle. Moderate or poor. From nobody Mon Dec 4 07:07:54 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E632124F57 for ; Mon, 4 Dec 2017 07:07:52 -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] 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 N9IwB2LKlSqn for ; Mon, 4 Dec 2017 07:07:51 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 12E03127698 for ; Mon, 4 Dec 2017 07:07:51 -0800 (PST) Received: from [10.32.60.151] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vB4F6BWX017388 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Dec 2017 08:06:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.151] From: "Paul Hoffman" To: "Tony Finch" Cc: "dnsop@ietf.org" Date: Mon, 04 Dec 2017 07:07:44 -0800 Message-ID: In-Reply-To: References: <20171123.121943.1115399549648860645.he@uninett.no> <34F896BC-B044-4E46-AC60-8562A8BE782F@hopcount.ca> <5562271920774233970@unknownmsgid> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [DNSOP] Terminology: "primary master" X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 15:07:52 -0000 On 4 Dec 2017, at 4:08, Tony Finch wrote: > Paul Hoffman wrote: >> On 27 Nov 2017, at 5:22, Tony Finch wrote: >>> >>> A primary master is wrt a zone not a server - a zone's primary >>> master is >>> a server that's authoritative for a zone and which does not get the >>> zone >>> contents via axfr/ixfr, but instead from a master file and/or UPDATE >>> (or >>> a non-standard mechanism such as directly from a database). >> >> That sounds correct. It also sounds quite different than what is >> defined >> in RFC 1996 and RFC 2136. How is this for new wording? > > Primary Master master server at the root of the zone transfer > dependency graph. > > That's exactly the same meaning as what I wrote above. That one bit is, yes. However the rest of the quote from 2136 differs. >> The idea of a primary master is only used in >> and >> , and is considered archaic in other >> parts of the DNS. > > Can you please provide citations to show that it's considered archaic? Sure: earlier messages in this thread. Some people said that primary master does not need to be given in the SOA MNAME field. Some people said that there could be multiple primary masters. >> A modern interpretation of the term "primary master" is a server that >> is >> both authoritative for a zone and that gets its updates to the zone >> from >> configuration (such as a master file) or from UPDATE transactions. > > How is that different to what I wrote? Just editorial changes. --Paul Hoffman From nobody Mon Dec 4 10:27:38 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9761286B1 for ; Mon, 4 Dec 2017 10:27:36 -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] 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 w6Lielxn59jW for ; Mon, 4 Dec 2017 10:27:34 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 BA5EB127B60 for ; Mon, 4 Dec 2017 10:27:34 -0800 (PST) Received: from [169.254.211.6] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vB4IPwP1042671 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 4 Dec 2017 11:26:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.211.6] From: "Paul Hoffman" To: "dnsop WG" Date: Mon, 04 Dec 2017 10:27:32 -0800 Message-ID: <707A270D-94DA-4651-84DC-409FAA6793F7@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2017 18:27:37 -0000 Greetings again. Some of the new terms added to the terminology-bis draft (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since RFC 7719 can be a bit tricky. This week, we hope you will look at the definitions in the draft for: - In-bailiwick - Out-of-bailiwick - In-domain - Sibling domain Please review these terms and comment on the list if you think the definitions should change. --Paul Hoffman [[ As a reminder, we asked the following last week, but got no reply: For the past many versions of the terminology-bis draft (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/), Section 2 has definitions of "Global DNS" and "Private DNS", based on the facets listed in "Naming system". This was discussed heavily on the list earlier, but it is also a pretty big change, so we want to be sure that it is what the WG wants. Please review these terms and comment on the list if you think the definitions should change. ]] From nobody Tue Dec 5 08:46:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC2A127867 for ; Tue, 5 Dec 2017 08:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 WJ9i13aELD8w for ; Tue, 5 Dec 2017 08:46:51 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 AF00312704B for ; Tue, 5 Dec 2017 08:46:51 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C4801281076; Tue, 5 Dec 2017 17:46:49 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id BD60028107F; Tue, 5 Dec 2017 17:46:49 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id B64A4281076; Tue, 5 Dec 2017 17:46:49 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id B2A3367F2EC0; Tue, 5 Dec 2017 17:46:49 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id AA3E4401C9; Tue, 5 Dec 2017 17:46:49 +0100 (CET) Date: Tue, 5 Dec 2017 17:46:49 +0100 From: Stephane Bortzmeyer To: Steve Crocker Cc: Jared Mauch , Paul Hoffman , =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , dnsop Message-ID: <20171205164649.2bl3rgagzt6iun2m@nic.fr> References: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> <953C8354-3F9D-46A4-82AB-7ED3A9E17387@vpnc.org> <61DF0A99-0B74-40AB-815F-3DF78755EBE5@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <61DF0A99-0B74-40AB-815F-3DF78755EBE5@shinkuro.com> X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000001, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.5.163916 Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL clamping in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 16:46:54 -0000 On Fri, Dec 01, 2017 at 01:12:34PM -0500, Steve Crocker wrote a message of 41 lines which said: > Shortening TTLs increases the amount of traffic between the recursive resolvers and authoritative resolvers and lengthens the response time for some queries. However, I don’t think there is any service guarantee with respect to an individual query that is violated by shortening the TTL. > > Lengthening a TTL, on the other hand, does change one of the service guarantees. When there is a change in the entry in the authoritative server, what is the maximum time until that change is guaranteed to be propagated throughout the net? This depends primarily on the TTL. However, when the TTL is lengthened by the recursive resolvers, the upper bound for propagation of a change is similarly increased. I fully agree about this very important difference (which is completely missing in the RIPE Labs article). Lengthening the TTL is a protocol violation (otherwise, we wouldn't discuss about draft-ietf-dnsop-serve-stale). Shortening it systematically is bad manners, and is selfish but is not a protocol violation. We should not discuss the two in the same thread: they are very different practices. From nobody Tue Dec 5 13:07:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7101286CA for ; Tue, 5 Dec 2017 13:07:51 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=JR4SeU0m; dkim=pass (1024-bit key) header.d=yitter.info header.b=TbNoMouQ 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 V6yssB3uv0vk for ; Tue, 5 Dec 2017 13:07:49 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCAF012711A for ; Tue, 5 Dec 2017 13:07:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 346A0BD33A for ; Tue, 5 Dec 2017 21:07:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1512508039; bh=hjb8FVlEujnUuGDsVwAjeSWqH3yaEb4dOR+Ldzh9gYI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=JR4SeU0mlnr/yHOluzl6+WIZlpVMslwV6pvRc+yt0JirdyQpOd1fc4lon/QBcOGU5 FtzSxF+v31mLDohDs+QG3WbpWOuzlSEwrO+hlpDEukheTuXJwYBrN+blNeuUa3c/e0 dYUk1D0zQ4G3TPWCCzIcOxpSMq5EoEI5dJQ5SRHQ= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFh8OS69pYKx for ; Tue, 5 Dec 2017 21:07:17 +0000 (UTC) Date: Tue, 5 Dec 2017 16:07:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1512508037; bh=hjb8FVlEujnUuGDsVwAjeSWqH3yaEb4dOR+Ldzh9gYI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=TbNoMouQz+UFNI36Q12nbK5EhTc3mjN+u+XUI//sfdtGO68IrEatFZ6drXPLBxGdB I+Ymy0upOBuwtIHEA+dV2Nq92UJ2B2EjzfvVQ6Kx/U/msNHxJ3eLt9RoNp5huI1bRU DraaYXW6G/jRTIsw5h/8BacoY7K6W7CzYK7O+Mj0= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20171205210716.d6dfvwlwdo44uslp@mx4.yitter.info> References: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> <20171202143925.GA20446@jurassic.lan.banu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171202143925.GA20446@jurassic.lan.banu.com> Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL Violations in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 21:07:52 -0000 On Sat, Dec 02, 2017 at 08:09:25PM +0530, Mukund Sivaraman wrote: > I don't agree a downstream cache has authoritiative say about extending > TTLs (except exceptional circumstances where the authority is > unreachable ~serve-stale). I will note that this WG spent a fair amount of effort on RFC 7583. That text is actually bad advice if you are supposed to expect resolvers to extend the TTL on RRsets, because the Ready state depends on caches expiring. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Dec 5 13:10:01 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F76E12711A for ; Tue, 5 Dec 2017 13:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 23-y6n_1D3cD for ; Tue, 5 Dec 2017 13:09:57 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 24E751270AE for ; Tue, 5 Dec 2017 13:09:57 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id i11so3683743wmf.4 for ; Tue, 05 Dec 2017 13:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+cuYQtaacRU/sxX2KSI28OKhRsVndiTLJ9brx0JZHK8=; b=hOguj8GAZw+jifbrZimh76o+zfvhy2Ok6c2Lf8O30FP0D8BbxrYMJOtw+B6HeVEjlN XPWusUKoVez1//Iza9I3Yj6ZNhdA/Veq0tv4351Cb+UQ3XFq9RdWNtA8YpcTViZBhLya JGybxxrlDv3vRZ+vGEGFieX0yWMtq6Akl669Iq3Pe2RgOO7tZFa2aPniPCPNPTfLoArj t6KfaDC2RDwPe42oeBdv+gf853wwcAqVyqb+LIsX9KJyPZ3SU5qXlfBzmjRffBlZCrul Ts5WN/DKF+G6XlaeJu1ew05gmKdybLhCRTe4sbjSpZDJGAxSdK/n5ZL4sVpm9R7qwMGP vVuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+cuYQtaacRU/sxX2KSI28OKhRsVndiTLJ9brx0JZHK8=; b=c2ktwEhXgJIUQuHCM0JriuGcdshYCsMwplZs+FMwDertYglt0X6RjbDJ3G5NRpcMfX WHaS5c0MMcZR3f/FEgd3fWPe2dhP5Z2DNPGNXOD2JQswNhDmvkL673C+Pm1vh3nLbneH dEgp/A2LTv/ueqrh266SkO9UxoGrg9qieQ8CgUSkQQfP1+9WDvwUBEjgU623ercMvbvB Yh6KoWNiLDw4jYpRwwUubdSADspbcW+VKTjDvKYJHrnul//epEOOxkUe2UvBN/OOLKol Y7INBSA0SGrXNOYn6sBA147c5jY21DaRZjdY6Ze7LyAIp2nNKi3ScxWaZAxgcb0R0Ai6 zkGg== X-Gm-Message-State: AKGB3mI0BGukc/ns4IjOTKJfNTNF7+dPJoQUflNbE7sEWVG5G3UEmgsW Z2wlidYdoLXE/U/b5LUwfO/ndB47bjPZDNcPZoUQd/Bi X-Google-Smtp-Source: AGs4zMaQOTDW9hFzH3TJVjGpTtwTqYdA3jP6USG8q2b5Qb8gwNE6g3TUOkq1fNmXW7YyMKVNQ0TsvWTI/4VC1/Sip68= X-Received: by 10.28.221.138 with SMTP id u132mr6686330wmg.113.1512508195470; Tue, 05 Dec 2017 13:09:55 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.223.185.107 with HTTP; Tue, 5 Dec 2017 13:09:54 -0800 (PST) In-Reply-To: <20171202143925.GA20446@jurassic.lan.banu.com> References: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> <20171202143925.GA20446@jurassic.lan.banu.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 5 Dec 2017 13:09:54 -0800 X-Google-Sender-Auth: 3vCJdqSmE7JAXqSTYJHKrWmONCE Message-ID: To: Mukund Sivaraman Cc: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , dnsop , "Wessels, Duane" , "Giovane C. M. Moura" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL Violations in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2017 21:09:59 -0000 At Sat, 2 Dec 2017 20:09:25 +0530, Mukund Sivaraman wrote: > > Strictly speaking yes, it is the same as when a Secondary does not update > > the zone for a long time. > > An authoritiative server operator knows what the consequence of setting > SOA RDATA fields is. It isn't the same as a cache extending TTL as it > sees fit, in spite of the loose coherency among primary and secondaries. > > I don't agree a downstream cache has authoritiative say about extending > TTLs (except exceptional circumstances where the authority is > unreachable ~serve-stale). +1. I'd accept some level of liberty that an implementation can take, such as ISC BIND 9 extending a 0-TTL of glue to 1 second: /* * Glue with 0 TTL causes problems. We force the TTL to * 1 second to prevent this. */ if (rdataset->ttl == 0) rdataset->ttl = 1; but it should be limited to a quite small range. How much is acceptable may be debatable, but I wouldn't consider "Stretching TTL from 1 Hour [...] for 10% or 10 minutes" to be acceptable at the discretion of an implementation. -- JINMEI, Tatuya From nobody Tue Dec 5 16:06:09 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE21128B4E for ; Tue, 5 Dec 2017 16:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 VDlSfRqbbfBv for ; Tue, 5 Dec 2017 16:06:07 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 215B91273E2 for ; Tue, 5 Dec 2017 16:06:07 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 454C23B75CB; Wed, 6 Dec 2017 00:06:04 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 2DCD6160045; Wed, 6 Dec 2017 00:06:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 14D6A160089; Wed, 6 Dec 2017 00:06:04 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id H3ngPO98-CDR; Wed, 6 Dec 2017 00:06:03 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 6B398160045; Wed, 6 Dec 2017 00:06:03 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <707A270D-94DA-4651-84DC-409FAA6793F7@vpnc.org> Date: Wed, 6 Dec 2017 11:06:00 +1100 Cc: dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: <56BEBCFA-D6BA-4BD1-8B95-190375A57C06@isc.org> References: <707A270D-94DA-4651-84DC-409FAA6793F7@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 00:06:09 -0000 The text for "in-bailwick" is too restrictive, it doesn=E2=80=99t just = cover NS records or glue records. In-bailwick refers to records that in the normal course of DNS = resolution would have been requested of by the server the current response is from. e.g. if you are querying a .com server then all records in the response = that end with .com are in-bailwick. Mark > On 5 Dec 2017, at 5:27 am, Paul Hoffman wrote: >=20 > Greetings again. >=20 > Some of the new terms added to the terminology-bis draft = (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since = RFC 7719 can be a bit tricky. This week, we hope you will look at the = definitions in the draft for: > - In-bailiwick > - Out-of-bailiwick > - In-domain > - Sibling domain > Please review these terms and comment on the list if you think the = definitions should change. >=20 > --Paul Hoffman >=20 > [[ As a reminder, we asked the following last week, but got no reply: = For the past many versions of the terminology-bis draft = (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/), = Section 2 has definitions of "Global DNS" and "Private DNS", based on = the facets listed in "Naming system". This was discussed heavily on the = list earlier, but it is also a pretty big change, so we want to be sure = that it is what the WG wants. Please review these terms and comment on = the list if you think the definitions should change. ]] >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Dec 5 20:04:58 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EBE128799 for ; Tue, 5 Dec 2017 20:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 ycaYnLV9xBgX for ; Tue, 5 Dec 2017 20:04:54 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 BC4531201F2 for ; Tue, 5 Dec 2017 20:04:53 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id n138so4891884wmg.2 for ; Tue, 05 Dec 2017 20:04:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=otL6f18O8PtuQ+4a/m9enwumUmgH9zBRcSxUkB/jDDs=; b=lLrvih0LOEupbDJ95/pw7SHPJCaLHj720uqN3VX4RTPjK3efN8X5T1cSA0DUpLMIb8 Y/zhv9ohhDvZi+vjtV2D44khWX9BxtFYTZYCMaGL9V19VhYCr2X28Bq/Pwpgu6JZZNd0 jAb1OG2PzB9Y3T1fsSBUAM+J4kWHWmoLsVchBslindL662WzLA9yRX1lOgniVIhJemLe xpngd2eUHPwQbrsiaocPvc3iFYG0kLQWhsYa2d+jHTmv37WHGDrtKj/zUnLxBxfeJqPk 9LkBOLVSmYYLFU98PUdwyzWtDQSpU2DBWEr3oqt40Kr438TPad8x/kROWQYIFUmBhHMz bE6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=otL6f18O8PtuQ+4a/m9enwumUmgH9zBRcSxUkB/jDDs=; b=QVUE3FJ4DHv+Vl38RA+BOy6A9vYqJiYyG5gWL+NV0Xlm9MCVjyu89LfAddgwVypk8F hj5bjGN2M1jgcEYv/ex9uKrSLZ9VSlJQfPMJQTCfCY/YlueSB4WZiQnu6619IeBJUgl7 +q+LlvLMnA+LoKp4cOwMKeSkNbE7f/P638IaBkDWS0o+mR9kuGYtRIhV15XLCK78onvc QnxpSE2GAjLYPz1fRbpOu7NLVyIKabHvORBZvUU5esHxeE57FgmsNzSS69RLurdlCcdZ 0lHSO9H44N5rekvswSmIj8cQTIPFxPf+0qBoE2vTeJwRRtCZsYE8cqEvYuqfAxKCtkQS SJLA== X-Gm-Message-State: AJaThX4ml5JZsQ1eed6su74twpB6qtYn53zz3kfnXnTH9JtQfxaMd/XC GdEnanlXKMSJ5P3o2ETGh01RLb5/ZHbduSQ9bC4= X-Google-Smtp-Source: AGs4zMagDpBT/CnetBow8vSBBaZQML3NJgt0sGKD1xRE93NU6jdm5HT7VA5/0g9T/95SHIns81Ryv6Kqp8GsPTrt4Iw= X-Received: by 10.80.177.250 with SMTP id n55mr39838971edd.30.1512533092314; Tue, 05 Dec 2017 20:04:52 -0800 (PST) MIME-Version: 1.0 References: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> <20171202143925.GA20446@jurassic.lan.banu.com> In-Reply-To: <20171202143925.GA20446@jurassic.lan.banu.com> From: Lanlan Pan Date: Wed, 06 Dec 2017 04:04:41 +0000 Message-ID: To: Mukund Sivaraman Cc: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , dnsop , "Wessels, Duane" , "Giovane C. M. Moura" Content-Type: multipart/alternative; boundary="f403045c4308adb381055fa40d7e" Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL Violations in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 04:04:56 -0000 --f403045c4308adb381055fa40d7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mukund Sivaraman =E4=BA=8E2017=E5=B9=B412=E6=9C=882=E6=97=A5= =E5=91=A8=E5=85=AD =E4=B8=8B=E5=8D=8810:39=E5=86=99=E9=81=93=EF=BC=9A > On Fri, Dec 01, 2017 at 05:16:47PM +0000, =C3=93lafur Gu=C3=B0mundsson wr= ote: > > On Fri, Dec 1, 2017 at 5:02 PM, Wessels, Duane > > wrote: > > > > > > > > > On Dec 1, 2017, at 8:38 AM, =C3=93lafur Gu=C3=B0mundsson < > olafur@cloudflare.com> > > > wrote: > > > > > > > > I strongly disagree with your "terminology", TTL is a hint about > maximum > > > caching period, not a demand or a contract. > > > > > > You say its just a hint. If you put a TTL of 1 hour on your data, an= d > I > > > have a recursive name server that reuses it for 2 hours, 12 hours, 5 > > > days... thats okay? > > > > > > If its just a hint then we are we spending all this effort on "serve > > > stale"? > > > > > > DW > > > > > > > > Strictly speaking yes, it is the same as when a Secondary does not upda= te > > the zone for a long time. > > An authoritiative server operator knows what the consequence of setting > SOA RDATA fields is. It isn't the same as a cache extending TTL as it > sees fit, in spite of the loose coherency among primary and secondaries. > > I don't agree a downstream cache has authoritiative say about extending > TTLs (except exceptional circumstances where the authority is > unreachable ~serve-stale). > Some authorititatives set the NS RR TTL<60s, they don't follow the best practice guide. Authoritatives think they "do the right thing" to spread latest NS RR. Needless to say A RR. Some resolvers extend all RR's TTL<60s to 3600s=EF=BC=8Cjust to reduce th= e queries, when the authority is reachable. Resolvers think they "do the right thing", too. > Mukund > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045c4308adb381055fa40d7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Mukund= Sivaraman <muks@isc.org>=E4=BA= =8E2017=E5=B9=B412=E6=9C=882=E6=97=A5=E5=91=A8=E5=85=AD =E4=B8=8B=E5=8D=881= 0:39=E5=86=99=E9=81=93=EF=BC=9A
On = Fri, Dec 01, 2017 at 05:16:47PM +0000, =C3=93lafur Gu=C3=B0mundsson wrote:<= br> > On Fri, Dec 1, 2017 at 5:02 PM, Wessels, Duane <dwessels@verisign.com>
> wrote:
>
> >
> > > On Dec 1, 2017, at 8:38 AM, =C3=93lafur Gu=C3=B0mundsson <= ;olafur@cloudfla= re.com>
> > wrote:
> > >
> > > I strongly disagree with your "terminology", TTL i= s a hint about maximum
> > caching period, not a demand or a contract.
> >
> > You say its just a hint.=C2=A0 If you put a TTL of 1 hour on your= data, and I
> > have a recursive name server that reuses it for 2 hours, 12 hours= , 5
> > days... thats okay?
> >
> > If its just a hint then we are we spending all this effort on &qu= ot;serve
> > stale"?
> >
> > DW
> >
> >
> Strictly speaking yes, it is the same as when a Secondary does not upd= ate
> the zone for a long time.

An authoritiative server operator knows what the consequence of setting
SOA RDATA fields is. It isn't the same as a cache extending TTL as it sees fit, in spite of the loose coherency among primary and secondaries.
I don't agree a downstream cache has authoritiative say about extending=
TTLs (except exceptional circumstances where the authority is
unreachable ~serve-stale).

Some authori= titatives set the NS RR TTL<60s, they don't follow the best practice= guide.
Authoritatives think they "do the right thing" = to spread latest NS RR.
Needless to say A RR.

<= /div>
Some resolvers=C2=A0 extend all RR's TTL<60s=C2=A0 to 3600= s=EF=BC=8Cjust to reduce the queries, when the authority is reachable.
Resolvers think they "do the right thing", too.<= /div>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mukund

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
=E8=87=B4=E7= =A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanl= an
--f403045c4308adb381055fa40d7e-- From nobody Wed Dec 6 03:17:43 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069C61286B1 for ; Wed, 6 Dec 2017 03:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 2g3YN70KYsLZ for ; Wed, 6 Dec 2017 03:17:39 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 A1D20124205 for ; Wed, 6 Dec 2017 03:17:39 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id d137so6669009itc.2 for ; Wed, 06 Dec 2017 03:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Lvyj7PLqaTF5rVu0YphxBxHgf54wqPDWYuilfkX+/L0=; b=FeRjktH53rBoT4Gh9XqMCaj6WiurJQXneT5NPsIlp1+DQCBJRyBcgAb7gN70LF2F0S 7k6kDU+5iV5JDlwfYAb1cEen5WMPAMMrkMsnJr4Vn5E85fLwDU0Uq5yaVIUTvMS0xdqP +3NlnvNM1pEufax3sWhh4RcqNytmYXn8X1i8s= 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=Lvyj7PLqaTF5rVu0YphxBxHgf54wqPDWYuilfkX+/L0=; b=EohNoJUeUHozf3uhvq92nkvIwRNCh1fL/DN3QhwHzEF8gOs9RYF2ryWdYbG5FmUcI9 4Va0G4dmkANusV3gYlnHcWjqzPjJw/vtj/RSOdTU9MNuuWcTF520e+XhBWTox9YKjzfd tTZJoM6Z2w/KDetIJTNnHp5C0hHAextUb1layPZRg+IznvQGlylZ0lPKDpL7JDCGW/Zp xhk8lSbxlUyxV3iNvMcw6bKVIX8Cq7amw3uK+PrWUvFN+M8eF25AiU3MlnqTWn47gi4E 19MVy4GiXiG0irJH3Kx9qUn8ek/DLK4VYsyKRVKy2sUHaOT4MBVqC0qcQWmzOgAtwKTJ kRTw== X-Gm-Message-State: AKGB3mIRr7WWdXPBJHZaHiZ5FOVMX0qYlgkBmgT6r+OaP7zOrca34krC H6vx6qeM9i8JQOnW3COaYNINlzefdVw= X-Google-Smtp-Source: AGs4zMbwXhpCI+UyvosJf0qWvxROurjHojoM1VG0XFfobO30IMv9MKxxcruz66rr0T5Usl7dlUUBRg== X-Received: by 10.36.22.147 with SMTP id a141mr22085618ita.30.1512559058537; Wed, 06 Dec 2017 03:17:38 -0800 (PST) Received: from ?IPv6:2607:f2c0:101:3:644f:842a:4298:8bca? ([2607:f2c0:101:3:644f:842a:4298:8bca]) by smtp.gmail.com with ESMTPSA id r190sm1259644iod.7.2017.12.06.03.17.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Dec 2017 03:17:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (15C114) In-Reply-To: Date: Wed, 6 Dec 2017 06:17:36 -0500 Cc: Mukund Sivaraman , =?utf-8?Q?=C3=93lafur_Gu=C3=B0mundsson?= , "Wessels, Duane" , "Giovane C. M. Moura" , dnsop Content-Transfer-Encoding: quoted-printable Message-Id: References: <9E8E7EAA-7D37-4841-9144-F49C216ABD7B@verisign.com> <20171202143925.GA20446@jurassic.lan.banu.com> To: Lanlan Pan Archived-At: Subject: Re: [DNSOP] Measuring DNS TTL Violations in the wild X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 11:17:41 -0000 On Dec 5, 2017, at 23:04, Lanlan Pan wrote: > Some authorititatives set the NS RR TTL<60s, they don't follow the best pr= actice guide. The trouble here is understanding the motivations of any particular paramete= r, and doing so at scale. You could assume as a resolver operator that a zone manager (note, not an au= thoritative server operator) has made a mistake when you get a response with= a low TTL, or you could take the position that it's not your business to ma= ke such inferences. Local policy to meet your own objectives in the operation of your resolver i= s different from seeking to correct decisions made by zone managers. Assumin= g errors (hence "correction") is a slippery slope to having no single source= of truth. There are protocol design decisions relating to TTLs that relate to metadata= that a resolver operator *can't* reasonably adust, like signature validity p= eriods. More philosophically, the loose-coherency and data persistence associated wi= th caching works because its boundaries are understood. The ability to use t= he system as a whole relies upon an explicit contract between zone manager a= nd resolver operator, and if that contract fractures, applications and user-= experience will follow. Any changes to the contract (and I'm not suggesting t= here can't be changes) need to be conservative, well documented and carefull= y implemented. Playing fast and loose with the interpretation of TTLs on eve= ry other resolver doesn't sound like any of those things. Joe= From nobody Thu Dec 7 16:53:29 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E880B1286CA for ; Thu, 7 Dec 2017 16:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 eKXxvmIDvsQJ for ; Thu, 7 Dec 2017 16:53:26 -0800 (PST) Received: from mail.hardakers.net (unknown [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1EA127698 for ; Thu, 7 Dec 2017 16:53:26 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 50969209C1; Thu, 7 Dec 2017 16:53:25 -0800 (PST) From: Wes Hardaker To: Michael StJohns Cc: dnsop@ietf.org References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> Date: Thu, 07 Dec 2017 16:53:25 -0800 In-Reply-To: <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> (Michael StJohns's message of "Sun, 3 Dec 2017 18:18:18 -0500") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 00:53:28 -0000 Michael StJohns writes: > Much improved - but still some disconnects (all review is de novo): That's Mike. All good comments. I've attached responses and actions (or inactions) below and will push a new version shortly as well. Wes Hardaker Table of Contents _________________ 1 DONE In Abstract - insert "by the publisher" after "must be followed" - 2 DONE Section 2 - first para - "from the DNSKEY publication and 3 DONE in 3 - lastSigExpirationTime - replace the first sentence=C2=A0 with= "The 4 TODO in 3 - sigExpirationTimeRemaining - two items: 5 DONE in 5.1.1 T+10 - replace "they have now expired" with "the signatures 6 WONTDO Delete 6.1.4 - activeRefreshOffset -=C2=A0 its a nonsensical value= that is 7 WONTDO 6.2.1 - replace activeRefreshOffset with activeRefresh - worst case 8 WONTDO fix 6.2.1.1 delete the term for addHoldDownTime % activeRefresh - = the 9 WONTDO In 6.2.2 - same changes as for 6.2.1 and 6.2.1.1 (e.g. get rid of 10 DONE Section 6.3 has one too many activeRefresh terms in both formulas - 11 WONTDO Guidance about key compromise 12 DONE Appendix A - fix the calculations to match up with the section 6 fo= rmulas. 1 DONE In Abstract - insert "by the publisher" after "must be followed" - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D this is clear later, but should be clear in the abstract. 2 DONE Section 2 - first para - "from the DNSKEY publication and =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D revocation's point of view" is unusual phrasing.=C2=A0 I'm not sure how a publication or revocation has a point of view.=C2=A0 I think you meant fr= om the trust anchor publisher or SEP DNSKEY publisher's point of view? + Response: I did indeed mean SEP publisher; fixed 3 DONE in 3 - lastSigExpirationTime - replace the first sentence=C2=A0 with= "The =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D latest value (i.e. the future most date and time) of any RRSig Signature Expiration field=C2=A0 covering any DNSKEY RRSet containing only the old trust anchor(s) that are being superseded." - This may still need wordsmithing or expansion. 4 TODO in 3 - sigExpirationTimeRemaining - two items: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D "latestSigExpirationTime" -> lastSigExpirationTime.=C2=A0 and measured fr= om when?=C2=A0=C2=A0 I think its "when the addWaitTime calculation is run" or "lastSigExpirationTime - now" + Response: I think it's fairly self evident from the text that it's "when used", which is indeed at least during addWaitTime calculation. But it's more conceptual and 'the amount of time remaining' I think is pretty clear to mean "from now". I thought about adding something like "from now" into the sentence, but that didn't seem better to me and added unneeded or complexity to the sentence. Suggestions? 5 DONE in 5.1.1 T+10 - replace "they have now expired" with "the signatures =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D have now expired" -=C2=A0 clarify context. 6 WONTDO Delete 6.1.4 - activeRefreshOffset -=C2=A0 its a nonsensical value= that is =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D only valid from the resolver's point of view.=C2=A0=C2=A0 For a given publisher/authoritative server - there will be as many activeRefreshOffsets as there are resolvers so the publisher must assume the worst case of activeRefresh. + Response: I disagree here. This was put in after a discussion with Matthijs Mekking to specifically address the case where the polling period may not end up right in time-step with the addHoldDownTime. The end result is that when a RFC5011 resolver is polling at a different frequency based on the activeRefresh time. We are defining a minimum mathematically defined safety value and this value is calculatable, so it should remain. There is a hint of guidance text that says you can set it to activeRefresh for simplicity if you want. But the math-line is before a full second activeRefresh. But the value itself needs to be included to account for the odd frequency slippage. TL;DR: this isn't a guidance document, it's a mathematical line document 7 WONTDO 6.2.1 - replace activeRefreshOffset with activeRefresh - worst case =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D value. (Wait Timer Based Calculation) 8 WONTDO fix 6.2.1.1 delete the term for addHoldDownTime % activeRefresh - = the =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D "2 * activeRefresh" in the previous term covers both the activeRefresh interval at the beginning of the acceptance period and the activeRefresh interval at the end. 9 WONTDO In 6.2.2 - same changes as for 6.2.1 and 6.2.1.1 (e.g. get rid of =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D activeRefreshOffset throughout). ,---- | =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 v =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 activeRefresh v=C2=A0=C2=A0= =C2=A0=C2=A0 | addHoldDownTime=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 v=C2=A0=C2=A0=C2=A0 activeRefres= h v=C2=A0 safetyMargin=C2=A0 v |=20 | |-----------------------|-------------------------------------|--------= -----------------------------|--------------------------|----------------| |=20 | =C2=A0lastSigExpirationTime^^^=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 acceptanceStarts ^^^ =C2=A0 =C2=A0 =C2=A0 | acceptance begins to complete^^=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 earliestSafe^^^ `---- After the second activeRefresh interval all of the well behaved and well connected resolvers should have the new trust anchor. The safetyMargin adds some space for poorly behaving or intermittently connected resolvers or those with some drops in queries. 10 DONE Section 6.3 has one too many activeRefresh terms in both formulas - =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D here are the corrected ones: remWaitTime =3D sigExpirationTimeRemaining + activeRefresh + safetyFactor remWallClockTime =3D lastSigExpirationTime + activeRefresh + safetyFactor Basically, assuming no attacker, and no drops, all well-behaved resolvers will see the revocation after one activeRefresh interval from the time of publication.=C2=A0 Add the safety factor to take care of the slackers.=C2=A0 This is a fine value for normal revocations where you're pretty sure that the key hasn't been compromised. There is no hold-time timer for revocation - they take effect immediately upon receipt and validation. 11 WONTDO Guidance about key compromise =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In the case of a key compromise, I would suggest that the revoked key be published for the same interval as you would use for adding a new trust anchor.=C2=A0 (But of course, this won't actually matter all that much if you only have a single trust anchor....) + Good advice to put in an general advice document in the future 12 DONE Appendix A - fix the calculations to match up with the section 6 fo= rmulas. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D --=20 Wes Hardaker USC/ISI From nobody Thu Dec 7 17:06:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4C8129465 for ; Thu, 7 Dec 2017 17:06:18 -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 oLI9SBJbvQ-l for ; Thu, 7 Dec 2017 17:06:17 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A251128B38 for ; Thu, 7 Dec 2017 17:06:17 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id DA5C8209C1; Thu, 7 Dec 2017 17:06:16 -0800 (PST) From: Wes Hardaker To: Edward Lewis Cc: "dnsop\@ietf.org" References: <121B74B2-A670-48E2-B4DF-09E02F376012@icann.org> Date: Thu, 07 Dec 2017 17:06:16 -0800 In-Reply-To: <121B74B2-A670-48E2-B4DF-09E02F376012@icann.org> (Edward Lewis's message of "Wed, 15 Nov 2017 14:34:11 +0000") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] Comments on mic comments, 5011 update's authorship X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 01:06:19 -0000 Edward Lewis writes: Ed, Sorry for the delay in a response. Too many recent deadlines and vacations... > It seems that there is an impression that I feel the authors of the > 5011-update draft are wrong choice to be documenting this. This is > not meant to be a personal attack on the authors but a blanket comment > on seeing operator-focused documents being produced without operator > involvement. (Apologies if it is thought to be an ad hominum > "attack".) I do understand that it wasn't anything personal. > It isn't that Wes and Warren aren't qualified to write the document. > I'm commenting on the legacy of documents written by protocol > designers that are passed off as operations guidance. I think this is where the biggest misconception may lie about the purpose of our document. The document is structured as a mathematically defined security line that you MUST NOT cross, not as operational guidance. We even state so multiple times in the document and I do hope that a future document (authored by someone else) comes out as a BCP or informational document that truly does give good advice, from a publishers point of view, about the best way to use RFC5011 and suggested timing mechanisms for key-rolling things like the root and other domains. This document is a security analysis result, however, and it may be that you might think this was actually the wrong group to submit it through? [good story about operators not reading RFCs...] > Since then I wondered what could be done to improve the usefulness of > RFCs to operators and why I have begun to think of "return on > investment" of documents. I sure wish we had a better answer to this problem, as it's been plaguing the O&M section of the IETF for decades (forever?). Unfortunately, I suspect that there isn't nearly enough "real operator content" here (IETF) to attract the attention of operators. It still looks and feels and smells like a protocol engineer camp, and if you're an operator and have the choice of spending time and a travel budget toward an IETF or toward a *OG/RIPE, it's much more likely you'll head toward the dedicated operational camps. I'm not sure that means we shouldn't produce work out of the O&M area though, as we have a lot of people from operator companies that are here as proxies at least. -- Wes Hardaker USC/ISI From nobody Thu Dec 7 17:10:57 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1559A120726; Thu, 7 Dec 2017 17:10:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151269545604.5910.4395741014662511280@ietfa.amsl.com> Date: Thu, 07 Dec 2017 17:10:56 -0800 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-09.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 01:10:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Security Considerations for RFC5011 Publishers Authors : Wes Hardaker Warren Kumari Filename : draft-ietf-dnsop-rfc5011-security-considerations-09.txt Pages : 19 Date : 2017-12-07 Abstract: This document extends the RFC5011 rollover strategy with timing advice that must be followed by the publisher in order to maintain security. Specifically, this document describes the math behind the minimum time-length that a DNS zone publisher must wait before signing exclusively with recently added DNSKEYs. This document also describes the minimum time-length that a DNS zone publisher must wait after publishing a revoked DNSKEY before assuming that all active RFC5011 resolvers should have seen the revocation-marked key and removed it from their list of trust anchors. This document contains much math and complicated equations, but the summary is that the key rollover / revocation time is much longer than intuition would suggest. If you are not both publishing a DNSSEC DNSKEY, and using RFC5011 to advertise this DNSKEY as a new Secure Entry Point key for use as a trust anchor, you probably don't need to read this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-09 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 7 21:44:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48445124205 for ; Thu, 7 Dec 2017 21:44:14 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 vxLxbQK-R4n5 for ; Thu, 7 Dec 2017 21:44:12 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 438C71200FC for ; Thu, 7 Dec 2017 21:44:12 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id p84so6520170pfd.3 for ; Thu, 07 Dec 2017 21:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=8khzJx/DIp3nicWMc9qT2M6cOKxNC4xYUjKnJgYjG9k=; b=vYPGQCs1ShyhPSHF0po4gtDsy1R9CTdQE86b336tuC2GZQ0ZEdWlgIdjtYeRKY/+1d aFiAgl6Pyr/xSceMWuXIXpdSKQA1ItOfixGjZz2KibUGnydaXJt5rEBMDgbmf7PwDCGt zsrefczbH5eH5JL3oRgVn8TIDmTthxuD/Td17PXn8PmkW9YaY4A8HDQ3e0wiJmT54xLB iIlg3uO/CCts2SsHkPadLhcluZlbqX84GDuGOWPt2uDf/WophFMmK6kDZpBMG4Qkw3FP UOteu/uMtCjTdM8MveCb/PnlxfLDCBEpsr6x0XUwrKS5LAeTuPyU88j2rDV9TnwzMGX0 5fYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=8khzJx/DIp3nicWMc9qT2M6cOKxNC4xYUjKnJgYjG9k=; b=iVrTnq0WSJSXHOVkRywCnocr51nMG+Oj1erberI8zC1NTKkVehSd4ybN2qdhWjQ/Hk GrJ8NKvSbttEOFqvn8TKbzQVkSTAI7sZT9xVIZVHt9zyW+HBddRW9r9zLI529CeQ5aRt rVA0Vc//Y7iRfYF0u3gXVx1PVAZBtEyBgEgoq5A/RvJ4GM4qlHgW2N7qN9I9qTyBpInH AJq+UTgx7VWRPYrsZMbQN+jvQbtJKRxTlcPZn/1oT2GQAtGJDfR5HmrKHXhBfEdLy5c2 EAQpHGtlBmlqYzioH8mntY7un/Wq///Lt8NAcvBrUfDU/79Nr53ukwxCRHC14/M6UzsA ArMA== X-Gm-Message-State: AJaThX7B4yTnf3wS8mpNPldXAFfsq8uLiqGLgYzhduFcyAx4QN+GG1S3 Hd81XlsWh1mNPDnJSmWvXgdJ1Mg/ X-Google-Smtp-Source: AGs4zMaTqQDksey/p2lS41Xd85r24SbBkkcxSx4/CYM2VyYu7U4V73LENwkpcuOg4k+hOI9Bif6x0Q== X-Received: by 10.101.68.201 with SMTP id g9mr28299796pgs.149.1512711850925; Thu, 07 Dec 2017 21:44:10 -0800 (PST) Received: from [192.168.4.224] ([12.229.246.2]) by smtp.gmail.com with ESMTPSA id b10sm12093167pfj.20.2017.12.07.21.44.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Dec 2017 21:44:09 -0800 (PST) To: Wes Hardaker Cc: dnsop@ietf.org References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> From: Michael StJohns Message-ID: <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> Date: Fri, 8 Dec 2017 00:43:36 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 05:44:14 -0000 On 12/7/2017 7:53 PM, Wes Hardaker wrote: > Michael StJohns writes: > >> Much improved - but still some disconnects (all review is de novo): > That's Mike. All good comments. I've attached responses and actions > (or inactions) below and will push a new version shortly as well. > > Wes Hardaker > > > Table of Contents > _________________ > > > 4 TODO in 3 - sigExpirationTimeRemaining - two items: > ===================================================== > > "latestSigExpirationTime" -> lastSigExpirationTime.  and measured from > when?   I think its "when the addWaitTime calculation is run" or > "lastSigExpirationTime - now" > > + Response: I think it's fairly self evident from the text that it's > "when used", which is indeed at least during addWaitTime > calculation. But it's more conceptual and 'the amount of time > remaining' I think is pretty clear to mean "from now". I thought > about adding something like "from now" into the sentence, but that > didn't seem better to me and added unneeded or complexity to the > sentence. Suggestions? > > > > > > 6 WONTDO Delete 6.1.4 - activeRefreshOffset -  its a nonsensical value that is > ============================================================================== > > only valid from the resolver's point of view.   For a given > publisher/authoritative server - there will be as many > activeRefreshOffsets as there are resolvers so the publisher must > assume the worst case of activeRefresh. > > + Response: I disagree here. This was put in after a discussion with > Matthijs Mekking to specifically address the case where the polling > period may not end up right in time-step with the addHoldDownTime. > The end result is that when a RFC5011 resolver is polling at a > different frequency based on the activeRefresh time. We are > defining a minimum mathematically defined safety value and this > value is calculatable, so it should remain. There is a hint of > guidance text that says you can set it to activeRefresh for > simplicity if you want. But the math-line is before a full second > activeRefresh. But the value itself needs to be included to account > for the odd frequency slippage. > > TL;DR: this isn't a guidance document, it's a mathematical line > document   The problem is that the polling period is a resolver concept, not a publisher concept.   And there are as many different polling intervals (all consisting of different start times but with lengths approximately equal to the activeRefresh interval) as there are resolvers. Look.   Publisher publishes at time A -.000000001 (or any time before this) where A is the last expiration time of the old records.  Resolver First does an active query at A+.00000001, Resolver Last does a query at A + activeRefresh interval - .000000001.  All other well behaved resolvers will have made a query at or after the first resolver and at or before the last resolver (with a safety slop added in for lost packets and retransmits done under the fast query rate).    Resolver Last will then (along with all the other resolvers) wait at least addHoldDown time and then make one last query.  The relationship to when that last query is made to the resolver's perception of when the addHoldDownTime expired  can be different for each resolver, with the sole requirement that the resolver waited for the next query after the addHoldDownTime expired. A perfectly operating resolver with perfect clock and perfect connectivity and no outages MIGHT possibly keep a perfect interval between each query it makes (making your activeRefreshOffset meaningful), but 10000 resolvers ALL keeping perfect intervals? NWIH.   So for the purposes of this we assume that ALL resolvers addHoldDownTime expired just after their last query meaning that we assume that ALL resolvers waited at least another queryInterval after the addHoldTime before making the query that triggers trust anchor installation. the calculations represent is the worst case for any give resolver, but actually the overall best case numbers for the publisher.   The safetyFactor deals with the clock and query drifts from the large population of resolvers and moves the publisher slightly off their best case estimate. So the total interval from after the last RRSig expiration of the old stuff is  activeRefresh (the latest query from all well behaved resolvers after the last expiration) + addHoldDownTime (.0000001 after this is when the first resolver installs the trust anchor) + activeRefresh (when the well behaved and connected resolvers have installed the new trust anchors) + safetyFactor (when the guys who dropped a few packets installed during the process the trust anchors). You got it wrong.  It's not a matter of disagreement about whether this is guidance  vs math, its about choosing the parameters in a way that's meaningful from the publisher's point of view.  You picked data that is only meaningful in the context of a single resolver, but which reduces to activeRefresh for a large population of resolvers. Don't make it more complex than it needs to be. > > > 7 WONTDO 6.2.1 - replace activeRefreshOffset with activeRefresh - worst case > ============================================================================ > > value. (Wait Timer Based Calculation) > > > 8 WONTDO fix 6.2.1.1 delete the term for addHoldDownTime % activeRefresh - the > ============================================================================== > > "2 * activeRefresh" in the previous term covers both the activeRefresh > interval at the beginning of the acceptance period and the > activeRefresh interval at the end. > > > 9 WONTDO In 6.2.2 - same changes as for 6.2.1 and 6.2.1.1 (e.g. get rid of > ========================================================================== > > activeRefreshOffset throughout). > > > ,---- > |                         v          activeRefresh v > | addHoldDownTime                 v    activeRefresh v  safetyMargin  v > | > | |-----------------------|-------------------------------------|-------------------------------------|--------------------------|----------------| > | > |  lastSigExpirationTime^^^                 acceptanceStarts ^^^ > | acceptance begins to complete^^            earliestSafe^^^ > `---- > > After the second activeRefresh interval all of the well behaved and > well connected resolvers should have the new trust anchor. The > safetyMargin adds some space for poorly behaving or intermittently > connected resolvers or those with some drops in queries. > > > 10 DONE Section 6.3 has one too many activeRefresh terms in both formulas - > =========================================================================== > > here are the corrected ones: > > remWaitTime = sigExpirationTimeRemaining + activeRefresh + > safetyFactor > > remWallClockTime = lastSigExpirationTime + activeRefresh + > safetyFactor > > Basically, assuming no attacker, and no drops, all well-behaved > resolvers will see the revocation after one activeRefresh interval > from the time of publication.  Add the safety factor to take care of > the slackers.  This is a fine value for normal revocations where > you're pretty sure that the key hasn't been compromised. > > There is no hold-time timer for revocation - they take effect > immediately upon receipt and validation. > > > 11 WONTDO Guidance about key compromise > ======================================= > > In the case of a key compromise, I would suggest that the revoked key > be published for the same interval as you would use for adding a new > trust anchor.  (But of course, this won't actually matter all that > much if you only have a single trust anchor....) > > + Good advice to put in an general advice document in the future Yes and no.  How you do revocation depends on why you are doing revocation and what the downside of the revocation is if you don't get it right.  In the one in/one out scheme that the root uses you can use the shorter publication period. If you're dealing with a compromised key you need different guidance.  Both of these are guidance for the publisher based on different input conditions. Ignoring one over the other makes little sense. The math i gave you is correct for the input conditions you specified.  But the aren't the only possible input conditions.  This document started because you believed that the publishers weren't making the right assumptions about publication intervals and needed some guidance to explain what they needed to think about.  This seems to be the same class of misguidance.  If a publisher uses this guidance for a compromised key they might (probably will) be making a mistake. Later, Mike > > > 12 DONE Appendix A - fix the calculations to match up with the section 6 formulas. > ================================================================================== > From nobody Thu Dec 7 22:27:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF549124217 for ; Thu, 7 Dec 2017 22:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 51SUgJ69pg2i for ; Thu, 7 Dec 2017 22:27:20 -0800 (PST) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 6CF6D1201F2 for ; Thu, 7 Dec 2017 22:27:20 -0800 (PST) Received: by mail-wr0-x235.google.com with SMTP id z18so9767935wrb.8 for ; Thu, 07 Dec 2017 22:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l7n4I9kVkfvFd/6Pod2mA4mw8aSoCe7F0zdeZd8T7/w=; b=NprcCk3cYZlHg7bBjTFW4vAjKa8eOGuVZeK4sofyeyrf542mp6hVmGGga5nVNBnqAX Vxqkvm63GeASqsmXd4UMkjQiV3+Ez00ZtTXhT5Dg3qZvsMTrjt7ZMuNtkN2Hob4CeBiI 97D61nbl0j+TyfeEZ1WKJBM8/EsBvTwaE63tylEFKR5mMHk77cp301tjqLqMoqJlqkMa riHfGvPdxPTQIBytvuSv9a8a6sFmNWxrdnPCpfEqsczlLywiWUEPGZ77e7s8aBCJ2Nsd 4TW1Sq5GnKWK7+OJt4h4wvJp2nkCJZL7OfZUxX+0hke+8vZDpyPeohZA9DIvJsAJh8+R UPlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l7n4I9kVkfvFd/6Pod2mA4mw8aSoCe7F0zdeZd8T7/w=; b=NO/tTJasjhH9GxSHOoRBcXIczzZYp/D3tsBqvAJxtn1pfavNDaH+8iLc1ksaG8cKy4 33IgLj1Pg4lP9RHEBTMXTAHuyZY/w/qtqi7tGCMMPPTieUF5uIAOWOA0txq3YK/NFZSa nFsTWImO7UNm1mInyyTLOJlD8fmT/dH/mS/uPhO6hUa8Iuk160LSnRE3AIRm+QEVHs/V sW5l6GyUacUOKMfKqgxTmhSl2Aq0X1fUgMP7wU7FaaAG6isW+RQqrgLyo2kejcyx79Uu gkWFygr8mvqqqIq0aXRPo4xyWpAK3UDv/T8bRAUNn7xDK1nMDz+NIzsm2uRAFfI+CXgg xJbw== X-Gm-Message-State: AJaThX7v112FoG5CKMO8RvHQDfpevJ5J7X+NMzOtSwGiwwibUMqqIXC9 cQfzGOnROxSZV0knQweqV8+aTev55B5MWYbLU+vSww== X-Google-Smtp-Source: AGs4zMalXQTzUlJw59pHAcTvz5Lt7DdQxpiNOFU2bUOiJwCR0iOSO2I3zo/MWXSZuHcVfOWaEOvfHyyPXJ1driGyfZo= X-Received: by 10.223.185.3 with SMTP id k3mr26513672wrf.40.1512714438771; Thu, 07 Dec 2017 22:27:18 -0800 (PST) MIME-Version: 1.0 References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> In-Reply-To: <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> From: Michael StJohns Date: Fri, 08 Dec 2017 06:27:07 +0000 Message-ID: To: Wes Hardaker Cc: dnsop@ietf.org Content-Type: multipart/alternative; boundary="f403045fa52ac51dd9055fce4684" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 06:27:22 -0000 --f403045fa52ac51dd9055fce4684 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To try this out, let=E2=80=99s use a ttl of 28 hours and an expiration of 7= days to get an active refresh as below. Take an activeRefresh of 14 hours (giving a fast retry of 2.8 hours and an addHoldDown time of 30 days (720 hour). That gives you an activeRefreshOffset of 6 hours. A perfect resolver will make 51 queries in 714 hours and the last triggering query at 728 hours. Assume a 4% failure rate (to make the math easy) in queries and assume the first retry always works. Which adds approx two fast retry intervals to the time making the total time to do 51 queries 719.8 hour for an actual offset of .2 hours. The next and last query needed to take place to trigger the trust anchor installation will take place at 733.8 hours. The point is that retransmission drift makes the whole concept of activeRefreshOffset nonsensical in any population of resolvers with any losses at all. Mike --f403045fa52ac51dd9055fce4684 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To try this out, let=E2=80=99s use a ttl of 28 hours and = an expiration of 7 days to get an active refresh as below. =C2=A0

Take an activeRefresh of 14 hours= (giving a fast retry of 2.8 hours and an addHoldDown time of 30 days (720 = hour). That gives you an activeRefreshOffset of 6 hours. =C2=A0 A perfect r= esolver will make 51 queries in 714 hours and the last triggering query at = 728 hours. =C2=A0 =C2=A0

Assume a 4% failure rate (to make the math easy) in queries and assume the= first retry always works. Which adds approx two fast retry intervals to th= e time making the total time to do 51 queries 719.8 hour for an actual offs= et of .2 hours.=C2=A0 The next and last query needed to take place to trigg= er the trust anchor installation will take place at 733.8 hours.=C2=A0

The point is that retransmis= sion drift makes the whole concept of activeRefreshOffset nonsensical in an= y population of resolvers with any losses at all. =C2=A0

Mike



--f403045fa52ac51dd9055fce4684-- From nobody Sun Dec 10 11:28:54 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D67A1276AF for ; Sun, 10 Dec 2017 11:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 W-o6BrYk7q7l for ; Sun, 10 Dec 2017 11:28:50 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 7B7BF12422F for ; Sun, 10 Dec 2017 11:28:50 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id f9so10678087wmh.0 for ; Sun, 10 Dec 2017 11:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jOvKXjp/oFqhtudDblcSbJkWblh3vqilV+FEkYQU4Zc=; b=uMCvqnAeO8gUiDougrBsQoubgznog67rwdfa6KcZK6+Q2EMAsnJbMDBlmKnVSX8Mm2 OsvUkkwpGW0LXezufJ5ZRCN4pBkLwsVmUZ8S3ghIS0Q2ov9h4mrMDJN1m6j8mlrhoLUW XDgDl8BwpND1Qb1WBSvNVgvbjsQ1RBtDixcEXQlFxlfDUm681QlDRZFXqtZccIl08+4y 72TojaG5PzVd+qXb1VvpP6VXKWffVYKyROTI6fZvU++rJyrKBskFequ5WhYlsTpybXUX x8bIso6tu1qC4XiTNNqMBE6NIoUoL37/Jf8XLz/OINtyE77vODIdZAsvVl81+UKyQt0H 2iQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jOvKXjp/oFqhtudDblcSbJkWblh3vqilV+FEkYQU4Zc=; b=mBTMLRQU3VPIJxSf4L/5IBT+INlbj/M1D7s+zY9IRP+b9LQfenafxxgiE1i62R+zkz oYIN7H++RpaG03MMlq+zeC+0UYPjSzYvmcvSVI2CrGLBYC0Xab9OYU1I+4j2WRltXY0k iBIWgOIxB2I+q/TGrClaSkzyHBYNKQEVEOgUUS0QVHfCdPSNHGaFbUgFTwcbeIClRFTL MXC2zhT6yRwkzyR0RpVGiluwSVHIv++sLCUbfKrodfjcPk2zrQnexuv5W2YWtUQ+06o+ x4lrdHB/M+ftUbIotvuXu4GVZ2K3TwtOH5LGh/P/1r/Aaju4uJ9lQUWFUOq9xKadqvKt VRbg== X-Gm-Message-State: AKGB3mJp5HbRlOu60/jrzpcFLQUDsK6gHXm7RkOdMIGwwLPc6GBEEHmJ BBootJDJ88SLbSBNAtz93o13qJedy8E9bNYRNwo= X-Google-Smtp-Source: AGs4zMYmtx0HgUdeUQWE3JKWuan5l+qHf580cthzw6W+KJ1HDgRS4OFRjGWcftOsp5iM/OHS25pQcx6KWSUdXx1pdrY= X-Received: by 10.28.168.88 with SMTP id r85mr8877012wme.63.1512934128764; Sun, 10 Dec 2017 11:28:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.134.147 with HTTP; Sun, 10 Dec 2017 11:28:48 -0800 (PST) In-Reply-To: References: From: tjw ietf Date: Sun, 10 Dec 2017 14:28:48 -0500 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="001a114cd040504e180560016dac" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 19:28:52 -0000 --001a114cd040504e180560016dac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi The call for adoption for this has ended and the groups has requested adoption. I will contact the authors about updating their draft with the new name as well as addressing open issues during the call. tim On Thu, Nov 16, 2017 at 3:23 AM, tjw ietf wrote: > All > > The author has rolled out a new version addressing comments from the > meeting on Monday, and we feel it=E2=80=99s ready to move this along. > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 30 November 2017 23:59 > > Thanks, > tim wicinski > DNSOP co-chair > --001a114cd040504e180560016dac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

The call for adoption for this has e= nded and the groups has requested adoption.=C2=A0 I will contact the author= s about updating their draft with the new name as well as addressing open i= ssues during the call.

tim


On Thu, Nov 16= , 2017 at 3:23 AM, tjw ietf <tjw.ietf@gmail.com> wrote:
=
All

The author has rolled out a new version addressing comments from= the meeting on Monday, and we feel it=E2=80=99s ready to move this along. =

This s= tarts a Call for Adoption for draft-huston-kskroll-sentinel

The draft is available= here:

Please review= this draft to see if you think it is suitable for adoption by DNSOP, and c= omments to the list, clearly stating your view.

=
Please also indicate if you are wi= lling to contribute text, review, etc.

This call for adoption ends: 30 November 20= 17 23:59

Thanks,
tim wicinski=
DNSOP co-chair=

--001a114cd040504e180560016dac-- From nobody Sun Dec 10 12:37:01 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9885127522 for ; Sun, 10 Dec 2017 12:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akcin-net.20150623.gappssmtp.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 Xa6oRQtw4ajb for ; Sun, 10 Dec 2017 12:36:58 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 BDFCC127201 for ; Sun, 10 Dec 2017 12:36:58 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id f2so33442783qtj.4 for ; Sun, 10 Dec 2017 12:36:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akcin-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yZZ0yfETQJWoZ5GRBJ2V8TD8nqRLvUx63F7KmxOPb48=; b=q3jhZGnSwSC+8TEEc2cJE+Xx8jCrmZAa8rRAuJFkYXEeGBEY+ZO5eumR4yqU0sW8fN TS3RV+5jhlKgsmFVTzr/mzc1nLuGE/4G8Vqe01ZYWHKIcyhnIj6iHpm91pRs6sN6Pvuo Yu7kPoz1BprHhfrYhesUGTNqH8eRhcGgBfhxA0EgjFe9SI0SGGfhCe2EUX4DU64UWo0t a8t2fT23AtQJK6VWKuqAx/v3yd87JQWwnj1gKoP3sTemytG3qSsgK7haA5GfQX2tlODZ QK8loE1hFkpNuRYCguCoUJatPn3Le55LWXJjBFOg8k1ydN1iAneEeCPdOxgrAHrW+jN0 n3cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yZZ0yfETQJWoZ5GRBJ2V8TD8nqRLvUx63F7KmxOPb48=; b=BChWDAchNSrHHmMeTnC6PJ4QwC6L/mgyr4iOAv6MX8jeWPF56HUKsMULr+w6G95Jsw cYHGbOY2Jny4C+sMt+OrFG/es9rvlXt9B3DLQ2NZLVS2jkhN31zXgR2HaWSXb7hb055y YrDPaSu7/a8SvMrIxc3Qu5Si8uIxETmMUcCZIGE+z0TMpXX6Z9VxUWIqNw3GzDTcHEHS /sr2d9HAdST5yO2p1yQTLLR269w1eccrZGsuFH1bW6JwzBgNwo3uGV3bES9NJ11Zft8b miVot2qzTIP4iMZZnF72NvTnqFeyqPSHf7CrKvJwXwNY3cRw+caW2H2d9RhCge0THB8z /CuA== X-Gm-Message-State: AKGB3mIvidAhsHX3l9FjJitaioNTqKtWqfCtA5mq+qE+zwksf46KA4Hd s2wYXmew9xV+WaWVCYOGGU0GFIhIfPNixygZUPhLmA== X-Google-Smtp-Source: AGs4zMZOCEkETwiv5aI8ofukK1sodxMizPDYnREXiajwmnhFRsHzSpMri6ddsvsWOctUgQLP3I3q3ITCxDGN24ETiGY= X-Received: by 10.233.237.212 with SMTP id c203mr44829393qkg.323.1512938217763; Sun, 10 Dec 2017 12:36:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.41.47 with HTTP; Sun, 10 Dec 2017 12:36:57 -0800 (PST) X-Originating-IP: [172.1.155.184] In-Reply-To: References: From: Mehmet Akcin Date: Sun, 10 Dec 2017 12:36:57 -0800 Message-ID: To: tjw ietf Cc: dnsop Content-Type: multipart/alternative; boundary="001a1148b5fc098aca05600261ca" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2017 20:37:01 -0000 --001a1148b5fc098aca05600261ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption of this work and I'm willing to review and contribute as needed. mehmet On Thu, Nov 16, 2017 at 12:23 AM, tjw ietf wrote: > All > > The author has rolled out a new version addressing comments from the > meeting on Monday, and we feel it=E2=80=99s ready to move this along. > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 30 November 2017 23:59 > > Thanks, > tim wicinski > DNSOP co-chair > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --001a1148b5fc098aca05600261ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption of this= work and I'm willing to review and contribute as needed.

mehmet

On Thu, Nov 16,= 2017 at 12:23 AM, tjw ietf <tjw.ietf@gmail.com> wrote:
=
All

The author has rolled out a new version addressing comments from= the meeting on Monday, and we feel it=E2=80=99s ready to move this along. =

This s= tarts a Call for Adoption for draft-huston-kskroll-sentinel

The draft is available= here:

Please review= this draft to see if you think it is suitable for adoption by DNSOP, and c= omments to the list, clearly stating your view.

=
Please also indicate if you are wi= lling to contribute text, review, etc.

This call for adoption ends: 30 November 20= 17 23:59

Thanks,
tim wicinski=
DNSOP co-chair=

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--001a1148b5fc098aca05600261ca-- From nobody Sun Dec 10 17:21:58 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C66A312711E; Sun, 10 Dec 2017 17:21:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151295531772.21182.323628264618825298@ietfa.amsl.com> Date: Sun, 10 Dec 2017 17:21:57 -0800 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 01:21:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : A Sentinel for Detecting Trusted Keys in DNSSEC Authors : Geoff Huston Joao Silva Damas Warren Kumari Filename : draft-ietf-dnsop-kskroll-sentinel-00.txt Pages : 8 Date : 2017-12-10 Abstract: The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user to determine the trusted key state of the resolvers that handle the user's DNS queries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-00 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Dec 10 22:57:56 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD8A1270A7 for ; Sun, 10 Dec 2017 22:57:55 -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, HTML_MESSAGE=0.001, 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 3ZBnV_tuanAv for ; Sun, 10 Dec 2017 22:57:53 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73785120726 for ; Sun, 10 Dec 2017 22:57:53 -0800 (PST) Received: from localhost.localdomain (dhcp-153.access.lah1.vix.su [24.104.150.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C91B061FA2; Mon, 11 Dec 2017 06:57:52 +0000 (UTC) From: Paul Vixie To: dnsop@ietf.org Cc: Michael StJohns , Wes Hardaker Date: Sun, 10 Dec 2017 22:57:52 -0800 Message-ID: <10441571.LRbvcOIgNt@localhost.localdomain> Organization: none User-Agent: KMail/4.13.0.30 (Linux/4.13.16-202.fc26.x86_64; KDE/4.14.32; x86_64; ; ) In-Reply-To: References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart2147251.61dtZJkxrn" Content-Transfer-Encoding: 7Bit Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 06:57:55 -0000 This is a multi-part message in MIME format. --nextPart2147251.61dtZJkxrn Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday, December 08, 2017 06:27:07 AM Michael StJohns wrote: > To try this out, let=E2=80=99s use a ttl of 28 hours and an expiratio= n of 7 days to > get an active refresh as below. Mike, I very much appreciate the analysis of the text and the proposed = method that=20 you've done. I am picking this message as my entry point to this thread= even though=20 my comments are also applicable to Message-ID: <6d239b9a-fd1e-46a3- c705-6851dd8ffe0a@nthpermutation.com>. > Take an activeRefresh of 14 hours (giving a fast retry of 2.8 hours a= nd an > addHoldDown time of 30 days (720 hour). That gives you an > activeRefreshOffset of 6 hours. A perfect resolver will make 51 que= ries > in 714 hours and the last triggering query at 728 hours. >=20 > Assume a 4% failure rate (to make the math easy) in queries and assum= e the > first retry always works. Which adds approx two fast retry intervals = to the > time making the total time to do 51 queries 719.8 hour for an actual = offset > of .2 hours. The next and last query needed to take place to trigger= the > trust anchor installation will take place at 733.8 hours. >=20 > The point is that retransmission drift makes the whole concept of > activeRefreshOffset nonsensical in any population of resolvers with a= ny > losses at all. Authors, I suggest and request that you both model and simulate the pro= posed=20 method, along the lines Mike has done in this thread but with more than= one set of=20 parameters and conditions, in order that the second-set-of-eyes can be = readily=20 provided by more than one reviewer. This timing based approach to online DNSSEC signing key changes is subt= le beyond=20 anybody's expectations, and because it will be used by the root zone, i= t is vital that we=20 do more than simply whiteboard our proposed methods. --=20 P. Vixie --=20 P. Vixie --nextPart2147251.61dtZJkxrn Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

On = Friday, December 08, 2017 06:27:07 AM Michael StJohns wrote:

>= ; To try this out, let=E2=80=99s use a ttl of 28 hours and an expiratio= n of 7 days to

>= ; get an active refresh as below.

 

Mik= e, I very much appreciate the analysis of the text and the proposed met= hod that you've done. I am picking this message as my entry point to th= is thread even though my comments are also applicable to Message-ID: &l= t;6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com>.

 

>= ; Take an activeRefresh of 14 hours (giving a fast retry of 2.8 hours a= nd an

>= ; addHoldDown time of 30 days (720 hour). That gives you an

>= ; activeRefreshOffset of 6 hours. A perfect resolver will make 51 que= ries

>= ; in 714 hours and the last triggering query at 728 hours.

>= ;

>= ; Assume a 4% failure rate (to make the math easy) in queries and assum= e the

>= ; first retry always works. Which adds approx two fast retry intervals = to the

>= ; time making the total time to do 51 queries 719.8 hour for an actual = offset

>= ; of .2 hours. The next and last query needed to take place to trigger= the

>= ; trust anchor installation will take place at 733.8 hours.

>= ;

>= ; The point is that retransmission drift makes the whole concept of

=

>= ; activeRefreshOffset nonsensical in any population of resolvers with a= ny

>= ; losses at all.

 

Aut= hors, I suggest and request that you both model and simulate the propos= ed method, along the lines Mike has done in this thread but with more t= han one set of parameters and conditions, in order that the second-set-= of-eyes can be readily provided by more than one reviewer.

 

Thi= s timing based approach to online DNSSEC signing key changes is subtle = beyond anybody's expectations, and because it will be used by the root = zone, it is vital that we do more than simply whiteboard our proposed m= ethods.

 

-- =

P. = Vixie

--

P. Vixie

--nextPart2147251.61dtZJkxrn-- From nobody Mon Dec 11 01:01:03 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB44D1200F3 for ; Mon, 11 Dec 2017 01:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 rYuo9TuU36oX for ; Mon, 11 Dec 2017 01:00:54 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 3106A1287A0 for ; Mon, 11 Dec 2017 01:00:54 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 1543B2816FD for ; Mon, 11 Dec 2017 10:00:52 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 1043C28171A; Mon, 11 Dec 2017 10:00:52 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id D59DC2816FD for ; Mon, 11 Dec 2017 10:00:51 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id D28F76427BE0 for ; Mon, 11 Dec 2017 10:00:51 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id C4DC640044; Mon, 11 Dec 2017 10:00:51 +0100 (CET) Date: Mon, 11 Dec 2017 10:00:51 +0100 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20171211090051.qjoruin7nkdjsnvd@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000019, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.11.85116 Archived-At: Subject: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 09:01:02 -0000 During the discussions about draft-bortzmeyer-dname-root or about draft-wkumari-dnsop-internal, there have been many remarks about the risk for privacy if we delegate things to AS 112: unlike the root (or .arpa), AS 112 is managed by many different people we don't know and cannot know. So, leaked requests are more at risk of surveillance with AS 112. But I notice that draft-ietf-homenet-dot, currently in the RFC Editor queue, delegates home.arpa to AS 112, in its section 7 (unless I'm wrong, it will be the first delegation to the new AS 112, the one with DNAME, described in RFC 7535). Does it mean the privacy problem is solved? Or simply overlooked? Can we delegate RFC 6761 special-use domains such as .internal to AS 112? From nobody Mon Dec 11 01:10:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1801200F3 for ; Mon, 11 Dec 2017 01:10: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, 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 PVH0GkD8IWlx for ; Mon, 11 Dec 2017 01:10:21 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C6C1287A3 for ; Mon, 11 Dec 2017 01:10:21 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id A6A7661FA2; Mon, 11 Dec 2017 09:10:21 +0000 (UTC) Message-ID: <5A2E4B7C.50509@redbarn.org> Date: Mon, 11 Dec 2017 01:10:20 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Stephane Bortzmeyer CC: dnsop@ietf.org References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> In-Reply-To: <20171211090051.qjoruin7nkdjsnvd@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 09:10:26 -0000 Stephane Bortzmeyer wrote: ... > Does it mean the privacy problem is solved? Or simply overlooked? Can > we delegate RFC 6761 special-use domains such as .internal to AS 112? any AS112 operator can tell you that the world doesn't care about privacy, based on the amount of organizationally sensitive information that's leaked in queries for PTR in RFC 1918 address blocks. so, privacy was never my concern. rather, AS112 has no authoritative operator registry. we don't know who is running these servers, and we have no way to assure that they hear a request that they add more secondary DNS zones to such servers. so if we delegate more zones that way, there will be a lot of SERVFAIL except for servers who send REFUSED. either way we have to consider the matter. i think as long as we keep the traffic away from the ARPA and root servers, we should not care what response is received -- should be NXDOMAIN but could be pretty much anything. ideally we'd sign all of these zones with DNSSEC and put DS RR's into the delegations, to assure that poison wasn't getting believed by modern validating resolvers. but we should concern ourselves with the question: did the AS112 operators realize that we'd be adding zones over time, and will they see the new RFC and/or announcements here/elsewhere and know to update their configs? and will any of them consider this an imposition? -- P Vixie From nobody Mon Dec 11 01:18:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5031200F3 for ; Mon, 11 Dec 2017 01:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 kl5HQuKe8wSz for ; Mon, 11 Dec 2017 01:18:03 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 854EC1289B0 for ; Mon, 11 Dec 2017 01:18:02 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 14F4D28011B; Mon, 11 Dec 2017 10:18:01 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 0CDF3280124; Mon, 11 Dec 2017 10:18:01 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id EBB6328011B; Mon, 11 Dec 2017 10:18:00 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id E87F1642A7A1; Mon, 11 Dec 2017 10:18:00 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id DC75F40044; Mon, 11 Dec 2017 10:18:00 +0100 (CET) Date: Mon, 11 Dec 2017 10:18:00 +0100 From: Stephane Bortzmeyer To: Paul Vixie Cc: dnsop@ietf.org Message-ID: <20171211091800.wonjnvhl3xrx6r4s@nic.fr> References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A2E4B7C.50509@redbarn.org> X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.11.90916 Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 09:18:04 -0000 On Mon, Dec 11, 2017 at 01:10:20AM -0800, Paul Vixie wrote a message of 31 lines which said: > we have no way to assure that they hear a request that they add more > secondary DNS zones to such servers. so if we delegate more zones > that way, there will be a lot of SERVFAIL except for servers who > send REFUSED. either way we have to consider the matter. This problem was solved a long time ago by RFC 7535 (the new AS 112). > but we should concern ourselves with the question: No. Problem solved (check with sink.bortzmeyer.fr, which is delegated to the unspecting operators of AS 112 nodes). From nobody Mon Dec 11 01:26:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B0D128796 for ; Mon, 11 Dec 2017 01:26:30 -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 oTCSMRQyindJ for ; Mon, 11 Dec 2017 01:26:29 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927B31200F3 for ; Mon, 11 Dec 2017 01:26:29 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4E15B61FA2; Mon, 11 Dec 2017 09:26:29 +0000 (UTC) Message-ID: <5A2E4F43.9050401@redbarn.org> Date: Mon, 11 Dec 2017 01:26:27 -0800 From: Paul Vixie User-Agent: Postbox 5.0.20 (Windows/20171012) MIME-Version: 1.0 To: Stephane Bortzmeyer CC: dnsop@ietf.org References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> In-Reply-To: <20171211091800.wonjnvhl3xrx6r4s@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 09:26:31 -0000 Stephane Bortzmeyer wrote: > On Mon, Dec 11, 2017 at 01:10:20AM -0800, > Paul Vixie wrote > a message of 31 lines which said: > >> we have no way to assure that they hear a request that they add more >> secondary DNS zones to such servers. so if we delegate more zones >> that way, there will be a lot of SERVFAIL except for servers who >> send REFUSED. either way we have to consider the matter. > > This problem was solved a long time ago by RFC 7535 (the new AS 112). ok. -- P Vixie From nobody Mon Dec 11 07:30:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E172126D74 for ; Mon, 11 Dec 2017 07:30:31 -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] 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 KHj0DIQrhnxQ for ; Mon, 11 Dec 2017 07:30:29 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 87176126B71 for ; Mon, 11 Dec 2017 07:30:29 -0800 (PST) Received: from [10.32.60.148] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vBBFSpZS017043 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 11 Dec 2017 08:28:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.148] From: "Paul Hoffman" To: "dnsop WG" Date: Mon, 11 Dec 2017 07:30:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: [DNSOP] Please review in terminology-bis: QNAME X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 15:30:31 -0000 Greetings again. Some of the new terms added to the terminology-bis draft (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since RFC 7719 can expose what some (but not all) people perceive as lack of clarity in RFC 1034/1035. This week, we hope you will look at the definition in the draft for "QNAME". Please review the lengthy explanation and comment on the list if you think the definition should change. --Paul Hoffman From nobody Mon Dec 11 08:18:10 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4738A126D73 for ; Mon, 11 Dec 2017 08:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 mR-PzH7uyRB0 for ; Mon, 11 Dec 2017 08:17:43 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 6104F1270A0 for ; Mon, 11 Dec 2017 08:17:43 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id x28so17200339ita.0 for ; Mon, 11 Dec 2017 08:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fS9N3oT1GlOKGxoqx5DsIQGNRvAz43nLxYJQC+S3x9I=; b=PIfm2MmeRjbvnfRdXka3vJbMnTNh62QqDBrFSP+CnSJUE1iQke3ICmI+9jfPJFK1Kr Lzf7qvDYyPvwXa5wIiBR0Gs2PLmkOGqTRaEgmxCsVZf7TT8nNTYUgQboX/hOVz3rF1Sv f7JT/wzXKYAeKI6Kl9fBWN7lQLacor++T78ms= 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=fS9N3oT1GlOKGxoqx5DsIQGNRvAz43nLxYJQC+S3x9I=; b=Y+RbkNr8wPQNFsrMEOGHO6LlCwu1J8G3f2b9IbbWhXL1ls0r66GZ5iyqevmVLl6cac CMsnzlvNFaZ3Y0XKS+62Xo6EHiONKscskLbyH6Kt80PfwKIMrJbBwhWK3HNvpp3vQ4yp 2oTFn82a8VxLIUSg7/puw7EvJ5k7axn0FJs4kHOpAKkh0DLYn625aQFNG5nNlMh7AkaM o74iKvb2N57dReOAI7bVOpaICZWi4ziOyIn/AKmOUJDuWcQViiL9CVu9HGXekiDyY1+O WRrjYT88mqFNOprDECBmWKb1mbfzXbVC7WqXV6yB0OhEYa+NLpllXqjt0hSUpPobd/s6 7Grw== X-Gm-Message-State: AKGB3mLVzkGbrOwOh+NhA3RuDAQHh3bZl7RdxlYtCVWVrDymrJbZCXkD Tm9RjexRfn9/ZNaNEcMZFfMqyA== X-Google-Smtp-Source: ACJfBovZ5qu1OgYhVDsuMRqd9GNbbe28SHgErFx1lDtsbNk0C97E0bhLUa0oyTAPAT8pbEUG1g+g2w== X-Received: by 10.107.57.215 with SMTP id g206mr1296087ioa.194.1513009062156; Mon, 11 Dec 2017 08:17:42 -0800 (PST) Received: from [199.212.92.9] (135-23-173-35.cpe.pppoe.ca. [135.23.173.35]) by smtp.gmail.com with ESMTPSA id m34sm3962800iti.24.2017.12.11.08.17.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Dec 2017 08:17:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Abley In-Reply-To: <20171211091800.wonjnvhl3xrx6r4s@nic.fr> Date: Mon, 11 Dec 2017 11:17:35 -0500 Cc: Paul Vixie , dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 16:17:53 -0000 Hi St=C3=A9phane, On 11 Dec 2017, at 04:18, Stephane Bortzmeyer wrote: > On Mon, Dec 11, 2017 at 01:10:20AM -0800, > Paul Vixie wrote=20 > a message of 31 lines which said: >=20 >> we have no way to assure that they hear a request that they add more >> secondary DNS zones to such servers. so if we delegate more zones >> that way, there will be a lot of SERVFAIL except for servers who >> send REFUSED. either way we have to consider the matter. >=20 > This problem was solved a long time ago by RFC 7535 (the new AS 112). Note though that the homenet document specifically requests a = delegation. IANA are currently working through their process and trying to get AS112 = operators to add the home.arpa zone, to avoid it being lame. This is = apparently a good first thing to try because the idea of adding a DNAME = record to the ARPA zone is scary and expected to receive push-back from = root server operators. (I may be putting words into Kim's mouth by abbreviating the situation = that way, but my point is that the IANA team are aware of the disconnect = between the likely-lame delegation to AS112 vs. the approach this = working group documented in 7535 and are doing their best). There is some related mail on the as112-ops list hosted at OARC. I think = you need to subscribe to see the archive, so no deep link. https://lists.dns-oarc.net/mailman/listinfo/as112-ops Joe= From nobody Mon Dec 11 14:41:08 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969351289B5 for ; Mon, 11 Dec 2017 14:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 I_w71XBHwIMg for ; Mon, 11 Dec 2017 14:41:05 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 2BFB81272E1 for ; Mon, 11 Dec 2017 14:41:05 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 51CF53AC36C; Mon, 11 Dec 2017 22:41:02 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E831B16007A; Mon, 11 Dec 2017 22:41:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BE504160079; Mon, 11 Dec 2017 22:41:01 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 47SQj4C5LKO0; Mon, 11 Dec 2017 22:41:01 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id C0AE4160042; Mon, 11 Dec 2017 22:41:00 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> Date: Tue, 12 Dec 2017 09:40:58 +1100 Cc: Stephane Bortzmeyer , dnsop@ietf.org, Paul Vixie Content-Transfer-Encoding: quoted-printable Message-Id: <73B3C074-6B88-4BCC-8F0C-26D09066CD0A@isc.org> References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 22:41:07 -0000 You don=E2=80=99t add the DNAME to the ARPA domain because it does not = add the insecure delegation that is REQUIRED. You add the DNAME to the = HOME.ARPA domain if you really want to redirect the traffic. For some = reason IANA wants to make this more complicated than it needs to be. = You don=E2=80=99t need to contact the AS112 server operators (a = impossible task). You just contact the existing ARPA server operators = to install HOME.ARPA on those servers. Add each NS as the operator say = that their servers are reconfigured to support HOME.ARPA. This is what I would end up with. HOME.ARPA. SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2017121101 = 1800 900 604800 86400 HOME.ARPA. NS A.ROOT-SERVERS.NET. HOME.ARPA. NS B.ROOT-SERVERS.NET. HOME.ARPA. NS C.ROOT-SERVERS.NET. HOME.ARPA. NS D.ROOT-SERVERS.NET. HOME.ARPA. NS E.ROOT-SERVERS.NET. HOME.ARPA. NS F.ROOT-SERVERS.NET. HOME.ARPA. NS G.ROOT-SERVERS.NET. HOME.ARPA. NS H.ROOT-SERVERS.NET. HOME.ARPA. NS I.ROOT-SERVERS.NET. HOME.ARPA. NS K.ROOT-SERVERS.NET. HOME.ARPA. NS L.ROOT-SERVERS.NET. HOME.ARPA. NS M.ROOT-SERVERS.NET. HOME.ARPA. DNAME EMPTY.AS112.ARPA. Mark > On 12 Dec 2017, at 3:17 am, Joe Abley wrote: >=20 > Hi St=C3=A9phane, >=20 > On 11 Dec 2017, at 04:18, Stephane Bortzmeyer = wrote: >=20 >> On Mon, Dec 11, 2017 at 01:10:20AM -0800, >> Paul Vixie wrote=20 >> a message of 31 lines which said: >>=20 >>> we have no way to assure that they hear a request that they add more >>> secondary DNS zones to such servers. so if we delegate more zones >>> that way, there will be a lot of SERVFAIL except for servers who >>> send REFUSED. either way we have to consider the matter. >>=20 >> This problem was solved a long time ago by RFC 7535 (the new AS 112). >=20 > Note though that the homenet document specifically requests a = delegation. >=20 > IANA are currently working through their process and trying to get = AS112 operators to add the home.arpa zone, to avoid it being lame. This = is apparently a good first thing to try because the idea of adding a = DNAME record to the ARPA zone is scary and expected to receive push-back = from root server operators. >=20 > (I may be putting words into Kim's mouth by abbreviating the situation = that way, but my point is that the IANA team are aware of the disconnect = between the likely-lame delegation to AS112 vs. the approach this = working group documented in 7535 and are doing their best). >=20 > There is some related mail on the as112-ops list hosted at OARC. I = think you need to subscribe to see the archive, so no deep link. >=20 > https://lists.dns-oarc.net/mailman/listinfo/as112-ops >=20 >=20 > Joe > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Dec 11 15:16:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E50126D05 for ; Mon, 11 Dec 2017 15:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, 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 w8o_6TDJdkXP for ; Mon, 11 Dec 2017 15:16:51 -0800 (PST) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 6CDDB1289B5 for ; Mon, 11 Dec 2017 15:16:51 -0800 (PST) Received: from KIDA-6861.local (unknown [10.32.60.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp01.icann.org (Postfix) with ESMTPS id C096AE0CF2; Mon, 11 Dec 2017 23:16:49 +0000 (UTC) Date: Mon, 11 Dec 2017 15:16:46 -0800 From: Kim Davies To: Mark Andrews Cc: Joe Abley , Paul Vixie , dnsop@ietf.org Message-ID: <20171211231643.GA73777@KIDA-6861.local> References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> <73B3C074-6B88-4BCC-8F0C-26D09066CD0A@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73B3C074-6B88-4BCC-8F0C-26D09066CD0A@isc.org> User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: Re: [DNSOP] [Ext] Re: DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 23:16:53 -0000 Hi Mark, Quoting Mark Andrews on Tuesday December 12, 2017: > > HOME.ARPA. SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2017121101 1800 900 604800 86400 > HOME.ARPA. NS A.ROOT-SERVERS.NET. .. > HOME.ARPA. DNAME EMPTY.AS112.ARPA. It is unclear to me how this avoids having root servers process DNAME records. Given the process of consultation, coordination and testing support for DNAME records in the root servers (or relocating the .arpa authorities) is likely to take longer than is desirable to have home.arpa insecurely delegated, the delegation to AS112 was considered as the best short-term approach even if it is not without its own difficulties. kim From nobody Mon Dec 11 15:46:37 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F637128B91 for ; Mon, 11 Dec 2017 15:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 fTuTso8zp2cA for ; Mon, 11 Dec 2017 15:46:34 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 14C181242EA for ; Mon, 11 Dec 2017 15:46:34 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 4A8B13B1728; Mon, 11 Dec 2017 23:46:31 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 1255D16007C; Mon, 11 Dec 2017 23:46:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id F28B416007B; Mon, 11 Dec 2017 23:46:30 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MlTRgt7LHw01; Mon, 11 Dec 2017 23:46:30 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id EA091160042; Mon, 11 Dec 2017 23:46:29 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <20171211231643.GA73777@KIDA-6861.local> Date: Tue, 12 Dec 2017 10:46:27 +1100 Cc: Joe Abley , Paul Vixie , dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> <73B3C074-6B88-4BCC-8F0C-26D09066CD0A@isc.org> <20171211231643.GA73777@KIDA-6861.local> To: Kim Davies X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] [Ext] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 23:46:35 -0000 Firstly they are HOME.ARPA servers. Just because they are the same = physical servers it doesn=E2=80=99t mean that policy for the root zone = content has to apply to other zones on that server. Maintaining that = distinction is important. =20 Secondly a otherwise empty zone on these servers will fulfil the = requirements to provide a insecure delegation. Just drop the DNAME from = the zone contents below. All the servers involved can serve SOA and NS = records and return NXDOMAIN for names under HOME.ARPA. If you need to delegate to a different set of servers create a seperate = constellation of servers that you control directly or by contract. = Trying to re-use AS112 servers will never work reliably as you don=E2=80=99= t have agreements with *all* the operators. This also applies to the = operators of EMPTY.AS112.ARPA. As for DNAME, that is a requirement of DNSSEC which, in theory, all the = root servers support fully. Mark > On 12 Dec 2017, at 10:16 am, Kim Davies wrote: >=20 > Hi Mark, >=20 > Quoting Mark Andrews on Tuesday December 12, 2017: >>=20 >> HOME.ARPA. SOA A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. = 2017121101 1800 900 604800 86400 >> HOME.ARPA. NS A.ROOT-SERVERS.NET. > .. >> HOME.ARPA. DNAME EMPTY.AS112.ARPA. >=20 > It is unclear to me how this avoids having root servers process DNAME > records. Given the process of consultation, coordination and testing > support for DNAME records in the root servers (or relocating the .arpa > authorities) is likely to take longer than is desirable to have = home.arpa > insecurely delegated, the delegation to AS112 was considered as the = best > short-term approach even if it is not without its own difficulties. >=20 > kim --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Dec 11 16:50:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39EE127517 for ; Mon, 11 Dec 2017 16:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 vtGT_DZ95uvi for ; Mon, 11 Dec 2017 16:50:33 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 BBC3A126DFE for ; Mon, 11 Dec 2017 16:50:32 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id r39so43377925qtr.13 for ; Mon, 11 Dec 2017 16:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=PmF0r1TzaDf3q72x6CtGoM5yVLNpzV21np0DvJMNHtA=; b=uMMutzaWjXj1ONaQa8sorFOYBvlNQ2wP9WdJnzjVje2sVut8tsx7TMWMYc7OGiBQzu AMdyFLo7OeZEvSQAlSM94l8EGTGXoUUNi4tglMBDQawkcd1KM/zWt1R+2ke+mS1iOgaa zrCjzZi9SFNfT1id1UKjD0yr27NtElQR13n0dPNrbTBzpZmDWGhZUCmOvFhHHni9pGad w8a4athvikKEUoSq5jo8CXp/Me6emb54ltb0n215k19NFodYksQ/QcAZqpGaAkjfV1go 7G1Y1Er26K3j7n79iHr3mvMqYNuWKW8hbMmd1TiYc06NU/evyoDnOTACWBmNPkC+GE2J t/zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=PmF0r1TzaDf3q72x6CtGoM5yVLNpzV21np0DvJMNHtA=; b=TJ9d11GrQ/Xf9CjLTWuJeHXxmwnVSSHuzbvxp/cQ+pWVhUj6C8iuBp96ryMZhVzoHC g328It7nsvncRuD7/dRYWNClSQW6b/OncoqiQ9NO/xtxMS/SGO2QQ14COTdE6aThRqOi xzRFm9kFKN+MNHKk2LdII13VUj+OSOkAfxHAEwlWihgQnfdOxHFq+uj18KAK6kw9wpPm Pu32ozXxJVrPBzF6UeysNEpijdzDoGAhGHta9rXfve2uxYL2zqJ7x0l/Z5+bU1ZghWWN ynbkp1r8deI+2DP3X4OxlC15ibhfuQMkaxTJz+guqOLfORyMy4GhrrVpX+DC5wEJHAud ay9g== X-Gm-Message-State: AKGB3mIq0AEc0jedp90swjQC4y3E3D+0+aJhDr0yeM/i9PDpUwTamZjn ngBitVX2hH8wuRLkdwCkLNKsRQ== X-Google-Smtp-Source: ACJfBouC4WM6fsA2qWPCzDQ0PU/rddpv2z7//x3kAdHmm4ecKg7RtW7OTvobP9G9965Stwt5A15VSA== X-Received: by 10.55.92.65 with SMTP id q62mr3055482qkb.154.1513039831661; Mon, 11 Dec 2017 16:50:31 -0800 (PST) Received: from [10.0.30.153] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id v17sm4922695qkl.36.2017.12.11.16.50.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Dec 2017 16:50:30 -0800 (PST) From: Ted Lemon Message-Id: <1B37BBA1-D141-441A-855E-1ACFF2DC15BD@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A3E49A62-A1F0-4D7D-B1B5-07F18B001BDE" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 11 Dec 2017 19:50:29 -0500 In-Reply-To: <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> Cc: Stephane Bortzmeyer , dnsop@ietf.org, Paul Vixie To: Joe Abley References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 00:50:35 -0000 --Apple-Mail=_A3E49A62-A1F0-4D7D-B1B5-07F18B001BDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 11, 2017, at 11:17 AM, Joe Abley wrote: > Note though that the homenet document specifically requests a = delegation. Please do not read more into the document than was intended. What Mark = is saying looks to me like an accurate representation of what we = intended. The goal is simply for it to be the case that there is not = an unsigned delegation for home.arpa, which means that it has to point = _somewhere_. I am a bit frustrated to hear that this is turning into a = substantial amount of effort. It should be extremely simple. There = is no wrong answer for what the delegation looks like other than = "signed." --Apple-Mail=_A3E49A62-A1F0-4D7D-B1B5-07F18B001BDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Dec 11, 2017, at 11:17 AM, Joe Abley <jabley@hopcount.ca> = wrote:
Note though that = the homenet document specifically requests a delegation.

Please = do not read more into the document than was intended.   What Mark = is saying looks to me like an accurate representation of what we = intended.   The goal is simply for it to be the case that there is = not an unsigned delegation for home.arpa, which means that it has to = point _somewhere_.   I am a bit frustrated to hear that this is = turning into a substantial amount of effort.   It should be = extremely simple.   There is no wrong answer for what the = delegation looks like other than "signed."

= --Apple-Mail=_A3E49A62-A1F0-4D7D-B1B5-07F18B001BDE-- From nobody Mon Dec 11 17:03:12 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3A9128D2E for ; Mon, 11 Dec 2017 17:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Vab39y1lFFw3 for ; Mon, 11 Dec 2017 17:03:10 -0800 (PST) Received: from mail.hardakers.net (unknown [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41359126DFE for ; Mon, 11 Dec 2017 17:03:10 -0800 (PST) Received: from localhost (unknown [10.1.0.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 9DC4E25F7B; Mon, 11 Dec 2017 17:03:09 -0800 (PST) From: Wes Hardaker To: Michael StJohns Cc: Wes Hardaker , dnsop@ietf.org References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> Date: Mon, 11 Dec 2017 17:03:09 -0800 In-Reply-To: <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> (Michael StJohns's message of "Fri, 8 Dec 2017 00:43:36 -0500") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 01:03:11 -0000 Michael StJohns writes: Hi Mike, Thanks for explaining your thinking because I think, after reading it: we're actually in agreement but using different terms for where to put in the slop you're worried about. Specifically: > A perfectly operating resolver with perfect clock and perfect > connectivity and no outages MIGHT possibly keep a perfect interval > between each query it makes (making your activeRefreshOffset > meaningful), but 10000 resolvers ALL keeping perfect intervals? Yes, I agree. But, this is why I want the majority of the equation to be defining the mathematical perfect certainty. And then *after* that, add the operational slop factor (safetyMargin) to account for both problems and reality (you forgot to add "speed of light issues" in your text above, for example). Thus, I break the equation into two critical parts: addWallClockTime = lastSigExpirationTime + addHoldDownTime + activeRefresh ^ + activeRefreshOffset | | Precise Math | -----------------------------------------------------| Needed Fuzz | | + safetyMargin | v IE, if a perfect resolver hitting a RFC5011 zone with an activeRefresh that evenly divides into 30 days: 1) queries at T--- = lastSigExpirationTime - .000001 2) queries at T+1--- = lastSigExpirationTime - .000001 + activeRefresh 3) Notes that it just saw a new key (assuming worst case #1 is replayed) 4) starts timer 5) will query again at lastSigExpirationTime + 30 days - .000001 6) notes this is still in waiting period 7) will query again at lastSigExpirationTime + 30 days - .000001 + activeRefresh 8) now notes that it's been 30 days and accepts key There is only 1 activeRefresh in that sequence. And that's what's in the equation. Because the timing distance between #7 and #2 is still 30 days when queried to the perfect sub-nano second. Then there should be a bunch of delays inserted, network timeouts, etc. That's where the safetyMargin should come in and catch all the issues with the impreciseness of the real world. Now, if you want to add an activeRefresh to the already defined safetyMargin suggested term, I'm willing to consider that. But it shouldn't be listed as part of anything but the slop term for security analysis clarity. Would you like to add more time to the safetyMargin to deal with the non-perfect world, including clock drift because of time delays in a bunch of queries back to back or any other reason? Ending note about the precise timeline: when 30 days isn't divisible by the activeRefresh, then you need to add the other term we haven't talked about much which is the activeRefreshOffset which accounts for this case. Cheers, Wes From nobody Mon Dec 11 18:14:49 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E2C126D05 for ; Mon, 11 Dec 2017 18:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 oO6i2p-E8BHF for ; Mon, 11 Dec 2017 18:14:46 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 3B038127275 for ; Mon, 11 Dec 2017 18:14:39 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id g9so43770978qth.9 for ; Mon, 11 Dec 2017 18:14:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=vSmy0ORuom9eYbNR6Xa0eq1tq1baOgJ0cel0dDnyt6c=; b=PcMDqkf4DVRknOLRoGzDROpAfBHhXAOUmz2xhIk15gU92fx+CufnuYlFj5PL/tQnUJ JBQvNO6aQVS/uHw/QGDhLifoFJ0WWyG4Lxeziv3AWOclZLquXYoEJOQ9oDlfmwmkciTl F+0UCizZprhKbbbvpyxx+KZpNSWwxTQlWL4/D/bkmyapEJkz5R/ajFWd1Cbvr6iyc0Qb wQhHNHL6Ic6AFAwb6a7LIL3F1bD/ffBGsZO1RCv9sa35lReK2EgkKB4uvcq8RtgAbl7n ++EksWS3jZ2sGT/oKC6GId0pJ/cqaUYe6IcFeHIDZE0UhzAsJqOTZc4lupSFRbgLQIGs 7NdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=vSmy0ORuom9eYbNR6Xa0eq1tq1baOgJ0cel0dDnyt6c=; b=XOupDNV9db4pZesd7WG1sUUMMT1c9S9Q7a4+Vg8uKdbVWHDlV1MLdwhLgWTD1UdOOS Q22KmgtvvcMCykqc38aoHBIRvqXKTNJYZltIeeGzen6N/PYmE9k3CAF8xukC6S5PDjwY JvWhaFMPr5C17+ItDbNev5KQi5fJqDeHHi4SJAFsZA/ninGnLRtdnn19HpLmAY/M8LLT fkFMS7/Ld+OiV+DpdvXo16XyvsPMTuJse1Ag/MrkTUZ3F1a0bjE0u6MDuiC6BWNiMPCi MFVXGpQzrO+H1pZxd/NRJNm1CnwK+4Gta2ADP6hiOQoomfh30MmuMysrYPyqEJc8f5Mb RMBg== X-Gm-Message-State: AKGB3mIsaul/0duHTCilyMqe40+KAKA7YrfBpK0SVdkzmDc5BFb7Lerq 9xlcZwD7YI3EOEFC5OsXvT2oZ0jZ X-Google-Smtp-Source: ACJfBovbFaI0wek6vsdSCtOdfcSP+zWcOQepD4N6yMCOyoi76vGG8iENjsgSRuK0x3u8yRHPYKFb4A== X-Received: by 10.55.82.84 with SMTP id g81mr3506882qkb.263.1513044877773; Mon, 11 Dec 2017 18:14:37 -0800 (PST) Received: from ?IPv6:2601:152:4400:720f::1009? ([2601:152:4400:720f::1009]) by smtp.gmail.com with ESMTPSA id n24sm5044087qta.50.2017.12.11.18.14.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Dec 2017 18:14:36 -0800 (PST) To: Wes Hardaker Cc: dnsop@ietf.org References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> From: Michael StJohns Message-ID: <142cad85-1e0e-b4c9-1561-ad590984739a@nthpermutation.com> Date: Mon, 11 Dec 2017 21:14:35 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 02:14:48 -0000 On 12/11/2017 8:03 PM, Wes Hardaker wrote: > Michael StJohns writes: > > Hi Mike, > > Thanks for explaining your thinking because I think, after reading it: > we're actually in agreement but using different terms for where to put > in the slop you're worried about. > > Specifically: > >> A perfectly operating resolver with perfect clock and perfect >> connectivity and no outages MIGHT possibly keep a perfect interval >> between each query it makes (making your activeRefreshOffset >> meaningful), but 10000 resolvers ALL keeping perfect intervals? > Yes, I agree. But, this is why I want the majority of the equation to > be defining the mathematical perfect certainty. And then *after* that, > add the operational slop factor (safetyMargin) to account for both > problems and reality (you forgot to add "speed of light issues" in your > text above, for example ). (sigh - safety factor deals with speed of light issues....DUH) No, no, no, no, no. > Thus, I break the equation into two critical parts: > > addWallClockTime = lastSigExpirationTime > + addHoldDownTime > + activeRefresh ^ > + activeRefreshOffset | > | > Precise Math | > -----------------------------------------------------| > Needed Fuzz | > | > + safetyMargin | > v If you'd reorder this properly, you can probably get the right answer -  For the first part of the discussion assume no drifts or retransmits between (1) and (2) and between (3) and (4). 1) T == lastSigExpirationTime  and microscopically after this the time that the server sees the first query from any resolver starting their trust anchor installation. 2) T + activeRefresh  is the time at which the server sees the last query from the last resolver just starting their trust anchor installation. 3) T + activeRefresh + addHoldDownTime is the time at which the server sees the first query from any resolver finalizing its trust anchor installation. 4) T + activeRefresh + addHoldDownTime + activeRefresh is the time at which the server sees the last query from the last resolver finalizing its trust anchor installation. (1) is the earliest time any resolver can start its installation (assuming an attack) because its also the time when all of the old signatures expire. (2) is the time at which a resolver who had its last activeRefresh just before T (and because of that wasn't able to start its installation) will send its first installation query. Between (2) and (3) any given resolver may drift/retransmit with the result that any given resolver may end up making a query just before (3) placing its next and final query at (3) plus activeRefresh. Finally, to deal with drift and retransmits between (1) and (2), and between (3) and (4) we add a safetyFactor.    That deals with about 99.9999% of drift and retransmits but will never deal with the servers that have been offline or otherwise unable to get their queries completed.  The retransmits in a given clients addHoldDown period only really move the end point for a given resolver and don't affect the overall safetyFactor of the set of resolvers. > > IE, if a perfect resolver hitting a RFC5011 zone with an activeRefresh > that evenly divides into 30 days: > > 1) queries at T--- = lastSigExpirationTime - .000001 > 2) queries at T+1--- = lastSigExpirationTime - .000001 + activeRefresh Yes. > 3) Notes that it just saw a new key (assuming worst case #1 is replayed) > 4) starts timer > 5) will query again at lastSigExpirationTime + 30 days - .000001 No - from the servers point of view, the worst client (which is the only one the server cares about) will make its last query before trust anchor installation at lastSigExpirationTime + activeRefresh (when the last CLIENT saw its first valid update)  + 30 days -.0000001. > 6) notes this is still in waiting period > 7) will query again at lastSigExpirationTime + 30 days - .000001 + activeRefresh Nope.   The worst client will query again at (from the servers point of view) lastSigExpiration + activeRefresh + addHoldDown (30) + activeRefresh From a given client's point of view the last query can happen anywhere from (lastSigExpiration + addHoldDown + .00000001) to (lastSigExpriration + activeRefresh + addHoldDown + activeRefresh).   The server only cares about the worst (latest) case. > 8) now notes that it's been 30 days and accepts key > > There is only 1 activeRefresh in that sequence. And that's what's in > the equation. Because the timing distance between #7 and #2 is still 30 > days when queried to the perfect sub-nano second. Nope.  Not from the servers point of view. > > Then there should be a bunch of delays inserted, network timeouts, etc. > That's where the safetyMargin should come in and catch all the issues > with the impreciseness of the real world. Now, if you want to add an > activeRefresh to the already defined safetyMargin suggested term, I'm > willing to consider that. But it shouldn't be listed as part of > anything but the slop term for security analysis clarity. > > Would you like to add more time to the safetyMargin to deal with the > non-perfect world, including clock drift because of time delays in a > bunch of queries back to back or any other reason? > > > Ending note about the precise timeline: when 30 days isn't divisible by > the activeRefresh, then you need to add the other term we haven't talked > about much which is the activeRefreshOffset which accounts for this > case. And again. NO.  The retransmits over a given set of clients in the addHoldDown period will result in at least one client (the "worst" client) ending up making a query just before the expiration of ITS addHoldDown timer.   Assuming the worst case of at least one client making a query just before the lastSigExpirationTime and that same client drifting/retransmitting enough to make a query just before its addHoldDown time the activeRefreshOffset is a useless value to calculate. Later, Mike > > Cheers, > Wes From nobody Tue Dec 12 08:44:09 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73B31286B2 for ; Tue, 12 Dec 2017 08:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 5-FvwFyJkXpj for ; Tue, 12 Dec 2017 08:44:06 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 613F71200FC for ; Tue, 12 Dec 2017 08:44:06 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id b11so13764198pgu.13 for ; Tue, 12 Dec 2017 08:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=IafGPiC5KqOBDaI0FJsCGY/XvzQGZyRTaoxDrSJ+Unc=; b=eEBNz/kdui7g5CQ4RGEdb77ah19VfdPRCnBpNT2rRjVzDWOu4H7gbZRSSThpxpNf/p ucJO9DPAx8zkPylrishqZUjKaxRP1OXN/M0LQ12lVy/EBI+p4J2JwyoNt/WZAQZxRsFc zFpTstjJFvhbhhO7sCcBPKYfYtOGj0fMgaRLQPN8j5YzN3FpL6qd4wW93CXS7kAofSB/ u4UPZw36IVXji7rix+k7LHTEjD0hjeFi6+LGybGovreeXDma2c0vs8OsPkimV/R2oNSW mn+6UiQFVNel36RdbvYFYK2CdLT3sKnZLxiPAfHCZQqwR6MAwJ8cSvZFoD7WrR369Om9 Eakw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=IafGPiC5KqOBDaI0FJsCGY/XvzQGZyRTaoxDrSJ+Unc=; b=NimD/cc0tDyZd1wI9o1FmYPp39/HhnV01XOcMIXTkRk6za7vYeAmfSM9970fru4+AT LDao9fuPzjYdLZf5Rgycly78uYNJrZJdiWTMOrhHLls4ffmUkLaBkpCepySMwMqkxpY8 luDTdqEYNf66acInp9obFUGzHeZv5CD/U6nzs6ZIbd2b+jl0Ima6HVZTnwnQ9K71+Om5 SHeLnXjra8i3+rVH+SwbmF4+wRcmTFrytH3oBW03KNl14a3fVqx0Q7TQrmNtg5QtZi49 9Mvw55s96O65v7LQQjtHukW5smDTmUk/HT8zUpnyB2+R80E4VxqgeT0k3hhjP3LxP50k ZHZg== X-Gm-Message-State: AKGB3mJiSD/90OLKpf/Sk+Taag6R9J166FpZ97eHodopqtEBlAWSBrtk uQA3SP6fxW9wXccYdtET85lJu4NKIYKrS6C4eLae4mPx X-Google-Smtp-Source: ACJfBovcjyDrZ8eCbKm87JK4QihcF5LwzbYGh9qIgBspVlMBSpJPVEEajOeRRe89L8CiBQElvBY5WMogjV+HUqwlBlw= X-Received: by 10.99.96.71 with SMTP id u68mr2456485pgb.389.1513097045406; Tue, 12 Dec 2017 08:44:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.139.5 with HTTP; Tue, 12 Dec 2017 08:44:04 -0800 (PST) In-Reply-To: <151295531772.21182.323628264618825298@ietfa.amsl.com> References: <151295531772.21182.323628264618825298@ietfa.amsl.com> From: Bob Harold Date: Tue, 12 Dec 2017 11:44:04 -0500 Message-ID: To: IETF DNSOP WG Content-Type: multipart/alternative; boundary="94eb2c03cae6e704de0560275be9" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 16:44:09 -0000 --94eb2c03cae6e704de0560275be9 Content-Type: text/plain; charset="UTF-8" On Sun, Dec 10, 2017 at 8:21 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : A Sentinel for Detecting Trusted Keys in DNSSEC > Authors : Geoff Huston > Joao Silva Damas > Warren Kumari > Filename : draft-ietf-dnsop-kskroll-sentinel-00.txt > Pages : 8 > Date : 2017-12-10 > > Abstract: > The DNS Security Extensions (DNSSEC) were developed to provide origin > authentication and integrity protection for DNS data by using digital > signatures. These digital signatures can be verified by building a > chain of trust starting from a trust anchor and proceeding down to a > particular node in the DNS. This document specifies a mechanism that > will allow an end user to determine the trusted key state of the > resolvers that handle the user's DNS queries. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-00 > > > Looks good to me. One minor typo: 4. Sentinel Test Result Considerations paragraph 6 "If the resolver is non-validating, and it has a single forwarder clause, then the resolver will presumably mirror the capabilities of the forwarder target resolver. If this non-validating resolver it has multiple forwarders, then the above considerations will apply." "it" at end of the third line should be deleted. -- Bob Harold --94eb2c03cae6e704de0560275be9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Sun, Dec 10, 2017 at 8:21 PM, <internet-drafts@ietf.org>= wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= A Sentinel for Detecting Trusted Keys in DNSSEC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Geof= f Huston
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Joao Silva Damas
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Warren Kumari
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dnsop-kskroll-sentinel-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-12-10

Abstract:
=C2=A0 =C2=A0The DNS Security Extensions (DNSSEC) were developed to provide= origin
=C2=A0 =C2=A0authentication and integrity protection for DNS data by using = digital
=C2=A0 =C2=A0signatures.=C2=A0 These digital signatures can be verified by = building a
=C2=A0 =C2=A0chain of trust starting from a trust anchor and proceeding dow= n to a
=C2=A0 =C2=A0particular node in the DNS.=C2=A0 This document specifies a me= chanism that
=C2=A0 =C2=A0will allow an end user to determine the trusted key state of t= he
=C2=A0 =C2=A0resolvers that handle the user's DNS queries.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/

There are also htmlized versions available at:
https://tools.ietf.org/html/dra= ft-ietf-dnsop-kskroll-sentinel-00
https://datatracker.ietf.o= rg/doc/html/draft-ietf-dnsop-kskroll-sentinel-00



Looks good to me.=C2=A0 One minor typo= :

=C2=A04. Sentinel Test Result Considerationsparagraph 6

"If the resolver is non-validating, and it has a= single forwarder
clause, then the resolver will presumably mirror th= e capabilities of
the forwarder target resolver. If this non-validat= ing resolver it
has multiple forwarders, then the above consideration= s will apply."

"it" at end of the third line should b= e deleted.

--=C2=A0
Bob Harold


--94eb2c03cae6e704de0560275be9-- From nobody Tue Dec 12 09:24:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FAA1294BC for ; Tue, 12 Dec 2017 09:24:40 -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, SPF_PASS=-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 t-VRkWZGpPUU for ; Tue, 12 Dec 2017 09:24:39 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CAFF1200FC for ; Tue, 12 Dec 2017 09:24:39 -0800 (PST) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 79BE321DE1; Tue, 12 Dec 2017 09:24:38 -0800 (PST) From: Wes Hardaker To: Michael StJohns Cc: Wes Hardaker , dnsop@ietf.org References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> <142cad85-1e0e-b4c9-1561-ad590984739a@nthpermutation.com> Date: Tue, 12 Dec 2017 09:24:37 -0800 In-Reply-To: <142cad85-1e0e-b4c9-1561-ad590984739a@nthpermutation.com> (Michael StJohns's message of "Mon, 11 Dec 2017 21:14:35 -0500") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 17:24:41 -0000 Michael StJohns writes: > 2) T + activeRefresh=C2=A0 is the time at which the server sees the last > query from the last resolver just starting their trust anchor > installation. > 3) T + activeRefresh + addHoldDownTime is the time at which the server > sees the first query from any resolver finalizing its trust anchor > installation. There is where we disagree. Given 2, where you state "last query from the last resolver is just starting", I argue that exactly an addHoldDownTime beyond that is when that *exact same resolver* will finish because it will have sampled the first at (2) and again at exactly T + activeRefresh + addHoldDownTime and accept it, per 5011: Once the timer expires, the new key will be added as a trust anchor the next time the validated RRSet with the new key is seen at the resolver. And the last query from the last resolver will be at T + activeRefresh + addHoldDownTime. > Between (2) and (3) any given resolver may drift/retransmit with the > result that any given resolver may end up making a query just before > (3) placing its next and final query at (3) plus activeRefresh. Please forget drift in the top half of the equation. There is zero drift in the mathematically precise section. We will deal with drift, delays, and everything else in the safetyFactor alone, with many terms or concepts within it to get it right. >> 5) will query again at lastSigExpirationTime + 30 days - .000001 > No - from the servers point of view, the worst client (which is the > only one the server cares about) will make its last query before trust > anchor installation at lastSigExpirationTime + activeRefresh (when the > last CLIENT saw its first valid update)=C2=A0 + 30 days -.0000001. Yes, I said that in 6 stating that it was *still waiting*. IE, #5 was supposed to describe the second to last query. >> 6) notes this is still in waiting period Let me put together something, per Paul's request, to work at this from another angle where one of us can be shown right or wrong.=20 [... retry, delay text by me deleted ...]=20=20 > And again. NO.=C2=A0 The retransmits over a given set of clients in the > addHoldDown period will result in at least one client (the "worst" > client) ending up making a query just before the expiration of ITS > addHoldDown timer. Assuming the worst case of at least one client > making a query just before the lastSigExpirationTime and that same > client drifting/retransmitting enough to make a query just before its > addHoldDown time the activeRefreshOffset is a useless value to > calculate. If you want to put an extra activeRefresh into the safetyMargin to account for drift, I'm willing to do so. Or we can insert a new term labeled "driftSafetyMargin" and define it as activeRefresh if you want. But that goes below my math line, not above it (and we can relabel safetyMargin as retryFailureSafetyMargin). >From a purely security analysis point of view, the first thing we have to agree upon is the precise moment at which all clients in a perfect world, with *no errors at all* (no drift, no retries, no transmission line delays, no CPU processing delays, no clock failures, etc). Once we have this line in the sand in place, then we can introduce real-world correctional elements to account for reality sneaking into our perfect world. I'm trying to talk only about the perfectionists world line in the sand first, and then introduce needed operational components *after that line*. You keep inserting "drift" (eg) everywhere in the process of this argument, which I absolutely agree needs to be dealt with. But below my perfect-world line only. The way I keep reading everything you've written is that your perfect line includes two activeRefreshes, which I (still) argue is incorrect. As I said last time and this time, I'd be happy to insert a "drift" term, but lets please label it what it is. If you agree with that, I'll make that change and push. --=20 Wes Hardaker USC/ISI From nobody Tue Dec 12 10:02:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31881275F4 for ; Tue, 12 Dec 2017 10:02:01 -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, SPF_PASS=-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 Cu2jDKktdfsI for ; Tue, 12 Dec 2017 10:02:00 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9331294DC for ; Tue, 12 Dec 2017 10:02:00 -0800 (PST) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 37F0F20770; Tue, 12 Dec 2017 10:01:58 -0800 (PST) From: Wes Hardaker To: Paul Vixie Cc: dnsop@ietf.org, Michael StJohns , Wes Hardaker References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> <10441571.LRbvcOIgNt@localhost.localdomain> Date: Tue, 12 Dec 2017 10:01:57 -0800 In-Reply-To: <10441571.LRbvcOIgNt@localhost.localdomain> (Paul Vixie's message of "Sun, 10 Dec 2017 22:57:52 -0800") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 18:02:02 -0000 Paul Vixie writes: > This timing based approach to online DNSSEC signing key changes is > subtle beyond anybody's expectations, and because it will be used by > the root zone, it is vital that we do more than simply whiteboard our > proposed methods. I have a thought about a demonstration. Will try to work on it later today. -- Wes Hardaker USC/ISI From nobody Tue Dec 12 11:34:46 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E062129524 for ; Tue, 12 Dec 2017 11:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 l5WwdR1ja_sG for ; Tue, 12 Dec 2017 11:34:41 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 76A1A129510 for ; Tue, 12 Dec 2017 11:34:41 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id 33so50279004qtv.1 for ; Tue, 12 Dec 2017 11:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=LP36JAHfFpGD2WFya/ZZurwzjr8PA2695Z76fNhVLAg=; b=LLZPcGZLkZP+ORIXEb9g1S4/L3AeDbLwdvHTreqvPq84z28mPy/1ITQ+outZQAXLF5 IJJN1AGcR1lp6DoLd2o21kHAS2E8CE/nbvLFUNKjuOrmZEZeMJdX/kk2qveMSYXD9vYL 0w3fK5fcnh/7sBIfOXRbQf8q82zuw2Vv0EUWRDe9fqoYfNgEIDU4SAl58puLjiqKDqmp 4y9syUyhO+nyy76H/8o+zyTUyvP+OueGYEltBWyUbJhIboi4IrpiyYsp6XyVmMPPpVBk Fc158zf6LMDZb5J4xyxHCBnN/50/i6UdEL5w9gwelVO84Ag1+NQKQDvdkD19PNgf9RDT 8Y6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=LP36JAHfFpGD2WFya/ZZurwzjr8PA2695Z76fNhVLAg=; b=XekYn4k0Beb71GnF//U+pWAIvURl3M+l6wP68PJqktFuoJxjCKIuzyORFjusAP9vXv jolob5/ViFptlnjxzOlVoLtZYjfvq9nb/LZiEKfRIN9HbZ7bTo0AL9obrHR5yxicwzCF T6LVdNJymKAGV2KNtnXv9fqDlkPFPWqgOIQ5d9xKJQqxL2WH+kHaETGN9RZG0ZQYIXwa gtWu4Rq81OPIWl6ULgwc5jMeH1xUXNG4b3ro+6vamhGzSNm7WpZHZZuhrBDsPvFE1q9Q CU7TjDdwRL5iGxtDitKtvrXZU0bLyHXlDMdiq8/EKIsFLXoKgyemuVODFNAZZRDy+gMA JrHQ== X-Gm-Message-State: AKGB3mI6RXLGu4nJ/pAT/3sIqrGZefjAL/NSmgFqfbE+VthynPveooww tlK+f2nFmvPUsIqkoid+bJvEbUW9 X-Google-Smtp-Source: ACJfBovLw8VBM1KQYRKrQnq/mRU32pFe8cLGavmTljCqBht6+DjyVUFBUh9xGueUejgrHN0xr787VA== X-Received: by 10.55.78.15 with SMTP id c15mr1574629qkb.105.1513107279968; Tue, 12 Dec 2017 11:34:39 -0800 (PST) Received: from ?IPv6:2601:152:4400:720f::1009? ([2601:152:4400:720f::1009]) by smtp.gmail.com with ESMTPSA id c2sm6036625qkf.20.2017.12.12.11.34.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 11:34:38 -0800 (PST) To: Wes Hardaker Cc: dnsop@ietf.org References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> <142cad85-1e0e-b4c9-1561-ad590984739a@nthpermutation.com> From: Michael StJohns Message-ID: <1ca3daed-d521-0fcd-d1e7-eef2b781707b@nthpermutation.com> Date: Tue, 12 Dec 2017 14:34:38 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------83FD11E17F27E5447AA1F40C" Content-Language: en-US Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 19:34:44 -0000 This is a multi-part message in MIME format. --------------83FD11E17F27E5447AA1F40C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/12/2017 12:24 PM, Wes Hardaker wrote: > Michael StJohns writes: > >> 2) T + activeRefresh  is the time at which the server sees the last >> query from the last resolver just starting their trust anchor >> installation. >> 3) T + activeRefresh + addHoldDownTime is the time at which the server >> sees the first query from any resolver finalizing its trust anchor >> installation. > There is where we disagree. Given 2, where you state "last query from > the last resolver is just starting", I argue that exactly an > addHoldDownTime beyond that is when that *exact same resolver* will > finish because it will have sampled the first at (2) and again at > exactly T + activeRefresh + addHoldDownTime and accept it, per 5011: > > Once the timer expires, the new key will be added as a trust anchor > the next time the validated RRSet with the new key is seen at the > resolver. > > And the last query from the last resolver will be at T + activeRefresh + > addHoldDownTime. Seriously no. This isn't this hard.  You need to stop thinking about what's happening from the point of view of one client and think about how the server views the behavior of the collection of clients. Dealing with your "attack" scenario and assuming no retransmissions for any client before it gets a response to its first query, the earliest time that the server can assume that the first client can start its addHoldDown timer is right after T (the lastExpirationTime).   The latest time that the server can assume that the last client will start its addHoldDown timer is the activeRefresh interval after T. (Assume a queryInterval of 14 hours and a set of 840 clients evenly distributed with their refreshes happening one a minute - the last client (#840) will make its query at T + activeRefresh and start its addHoldDown timer then). So dealing only with that last client the server has to wait at least T + activeRefresh before it assumes that the client has started its addHoldDown and T + activeRefresh + addHoldDown before the client has finished its addHoldDown and is about to make its last query. The best case scenario (from the servers point of view) is when that same client has its last query before its addHoldDown time expires at just under the activeRefresh interval (e.g. if the expiration is at noon, and the active refresh is 1 hour, then the best case if the last query was at 11:00:00.00001) causing the query after the addHoldDown time to occur at 12:00:00.00001.   The worst case scenario is when ANY client has its last query at .00001 before the addHoldDown time expires, making the final query happen at the activeRefresh interval after the expiration or in the example at 12:59.59.99999. For a given client assuming no query losses, there are  FLOOR (addHoldDown/activeRefresh) queries in the addHoldDown interval (between when the client starts its timer and when it goes off). The difference addHoldDown - (FLOOR (addHoldDown/activeRefresh) * activeRefresh) is this activeRefreshOffset interval you keep trying to put in.  However, we do assume losses and we do (and MUST) assume the worst case that at least one client out of 10K, 100K or 1M is going to end up doing fast queries and changing that difference such that they end up with their last query before their addHoldDown timer occurs JUST before it expires. > >> Between (2) and (3) any given resolver may drift/retransmit with the >> result that any given resolver may end up making a query just before >> (3) placing its next and final query at (3) plus activeRefresh. > Please forget drift in the top half of the equation. There is zero > drift in the mathematically precise section. We will deal with drift, > delays, and everything else in the safetyFactor alone, with many terms > or concepts within it to get it right. And here's where you go off the rails.   You don't need to include the safety factor to deal with the (2) to (3) interval as retransmit can't reduce the addHoldDown period, but can reduce - for a given client - the number of queries in the period.  Retransmits and drift also can change *when* in that interval the given client produces its last query before expiration - e.g. cause a "phase shift". > >>> 5) will query again at lastSigExpirationTime + 30 days - .000001 >> No - from the servers point of view, the worst client (which is the >> only one the server cares about) will make its last query before trust >> anchor installation at lastSigExpirationTime + activeRefresh (when the >> last CLIENT saw its first valid update)  + 30 days -.0000001. > Yes, I said that in 6 stating that it was *still waiting*. IE, #5 was > supposed to describe the second to last query. > >>> 6) notes this is still in waiting period > Let me put together something, per Paul's request, to work at this from > another angle where one of us can be shown right or wrong. > > [... retry, delay text by me deleted ...] > >> And again. NO.  The retransmits over a given set of clients in the >> addHoldDown period will result in at least one client (the "worst" >> client) ending up making a query just before the expiration of ITS >> addHoldDown timer. Assuming the worst case of at least one client >> making a query just before the lastSigExpirationTime and that same >> client drifting/retransmitting enough to make a query just before its >> addHoldDown time the activeRefreshOffset is a useless value to >> calculate. > If you want to put an extra activeRefresh into the safetyMargin to > account for drift, I'm willing to do so. Or we can insert a new term > labeled "driftSafetyMargin" and define it as activeRefresh if you want. > But that goes below my math line, not above it (and we can relabel > safetyMargin as retryFailureSafetyMargin). > > > From a purely security analysis point of view, the first thing we have > to agree upon is the precise moment at which all clients in a perfect > world, with *no errors at all* (no drift, no retries, no transmission > line delays, no CPU processing delays, no clock failures, etc). Once we > have this line in the sand in place, then we can introduce real-world > correctional elements to account for reality sneaking into our perfect > world. I'm trying to talk only about the perfectionists world line in > the sand first, and then introduce needed operational components *after > that line*. You keep inserting "drift" (eg) everywhere in the process > of this argument, which I absolutely agree needs to be dealt with. But > below my perfect-world line only. The way I keep reading everything > you've written is that your perfect line includes two activeRefreshes, > which I (still) argue is incorrect. As I said last time and this time, > I'd be happy to insert a "drift" term, but lets please label it what it > is. If you agree with that, I'll make that change and push. > *sigh* No.   You screw up the analysis doing it that way because it doesn't account for the possible "phase shift" that can happen with a client during its addHoldDown period. I've been using "sigExpire + activeRefresh + addHoldDown + activeRefresh + safetyFactor" because its actually easier to calculate.  The actual formula is "sigExpire + (activeRefresh + retransSlop) + addHoldDown + (activeRefresh + retransSlop)"  where retransSlop is about 1/2 the safety factor. Both the interval after sigExpire and before addHoldDown and the interval after the last activeRefresh require a safety factor to account for retransmissions.   The addHoldDown interval does not because retrans and drift result in a phase shift within the interval, but do not affect the length of the total interval. A "perfect" system will behave the way you've described - but adding a safety factor while ignoring the phase shift brought on by retransmits within the addHoldDown interval will not characterize the actual system. I hope this is visible.  The first group is the "perfect" one where we start at random point in the interval [0..activeRefresh].  The second group is the one with retransmits inside the add Hold down and where the signature expired just after the last refresh.  The third is Wes' perfect with the queries starting just as the sigPeriod expires.  Wes would add the saftety factor at the end of the third one and call it done.  The second one represents the actual worst case to which we'd add the safetyFactor to account for drift and retransmits for the two activeRefresh intervals. Can we stop now? Mike --------------83FD11E17F27E5447AA1F40C Content-Type: multipart/related; boundary="------------F04449CC833D970FC77547E9" --------------F04449CC833D970FC77547E9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/12/2017 12:24 PM, Wes Hardaker wrote:
Michael StJohns <msj@nthpermutation.com> writes:


2) T + activeRefresh  is the time at which the server sees the last
query from the last resolver just starting their trust anchor
installation.
3) T + activeRefresh + addHoldDownTime is the time at which the server
sees the first query from any resolver finalizing its trust anchor
installation.

There is where we disagree.  Given 2, where you state "last query from
the last resolver is just starting", I argue that exactly an
addHoldDownTime beyond that is when that *exact same resolver* will
finish because it will have sampled the first at (2) and again at
exactly T + activeRefresh + addHoldDownTime and accept it, per 5011:

   Once the timer expires, the new key will be added as a trust anchor
   the next time the validated RRSet with the new key is seen at the
   resolver.

And the last query from the last resolver will be at T + activeRefresh +
addHoldDownTime.

Seriously no.

This isn't this hard.  You need to stop thinking about what's happening from the point of view of one client and think about how the server views the behavior of the collection of clients.

Dealing with your "attack" scenario and assuming no retransmissions for any client before it gets a response to its first query, the earliest time that the server can assume that the first client can start its addHoldDown timer is right after T (the lastExpirationTime).   The latest time that the server can assume that the last client will start its addHoldDown timer is the activeRefresh interval after T.

(Assume a queryInterval of 14 hours and a set of 840 clients evenly distributed with their refreshes happening one a minute - the last client (#840) will make its query at T + activeRefresh and start its addHoldDown timer then).

So dealing only with that last client the server has to wait at least T + activeRefresh before it assumes that the client has started its addHoldDown and T + activeRefresh + addHoldDown before the client has finished its addHoldDown and is about to make its last query.

The best case scenario (from the servers point of view) is when that same client has its last query before its addHoldDown time expires at just under the activeRefresh interval (e.g. if the expiration is at noon, and the active refresh is 1 hour, then the best case if the last query was at 11:00:00.00001) causing the query after the addHoldDown time to occur at 12:00:00.00001.   The worst case scenario is when ANY client has its last query at .00001 before the addHoldDown time expires, making the final query happen at the activeRefresh interval after the expiration or in the example at 12:59.59.99999.

For a given client assuming no query losses, there are  FLOOR (addHoldDown/activeRefresh) queries in the addHoldDown interval (between when the client starts its timer and when it goes off).  The difference addHoldDown - (FLOOR (addHoldDown/activeRefresh) * activeRefresh) is this activeRefreshOffset interval you keep trying to put in.  However, we do assume losses and we do (and MUST) assume the worst case that at least one client out of 10K, 100K or 1M is going to end up doing fast queries and changing that difference such that they end up with their last query before their addHoldDown timer occurs JUST before it expires.  



Between (2) and (3) any given resolver may drift/retransmit with the
result that any given resolver may end up making a query just before
(3) placing its next and final query at (3) plus activeRefresh.

Please forget drift in the top half of the equation.  There is zero
drift in the mathematically precise section.  We will deal with drift,
delays, and everything else in the safetyFactor alone, with many terms
or concepts within it to get it right.

And here's where you go off the rails.   You don't need to include the safety factor to deal with the (2) to (3) interval as retransmit can't reduce the addHoldDown period, but can reduce - for a given client - the number of queries in the period.  Retransmits and drift also can change *when* in that interval the given client produces its last query before expiration - e.g. cause a "phase shift".




   5) will query again at lastSigExpirationTime + 30 days - .000001

No - from the servers point of view, the worst client (which is the
only one the server cares about) will make its last query before trust
anchor installation at lastSigExpirationTime + activeRefresh (when the
last CLIENT saw its first valid update)  + 30 days -.0000001.

Yes, I said that in 6 stating that it was *still waiting*.  IE, #5 was
supposed to describe the second to last query.


   6) notes this is still in waiting period

Let me put together something, per Paul's request, to work at this from
another angle where one of us can be shown right or wrong. 

[... retry, delay text by me deleted ...]  


And again. NO.  The retransmits over a given set of clients in the
addHoldDown period will result in at least one client (the "worst"
client) ending up making a query just before the expiration of ITS
addHoldDown timer.  Assuming the worst case of at least one client
making a query just before the lastSigExpirationTime and that same
client drifting/retransmitting enough to make a query just before its
addHoldDown time the activeRefreshOffset is a useless value to
calculate.

If you want to put an extra activeRefresh into the safetyMargin to
account for drift, I'm willing to do so.  Or we can insert a new term
labeled "driftSafetyMargin" and define it as activeRefresh if you want.
But that goes below my math line, not above it (and we can relabel
safetyMargin as retryFailureSafetyMargin).


>From a purely security analysis point of view, the first thing we have
to agree upon is the precise moment at which all clients in a perfect
world, with *no errors at all* (no drift, no retries, no transmission
line delays, no CPU processing delays, no clock failures, etc).  Once we
have this line in the sand in place, then we can introduce real-world
correctional elements to account for reality sneaking into our perfect
world.  I'm trying to talk only about the perfectionists world line in
the sand first, and then introduce needed operational components *after
that line*.  You keep inserting "drift" (eg) everywhere in the process
of this argument, which I absolutely agree needs to be dealt with.  But
below my perfect-world line only.  The way I keep reading everything
you've written is that your perfect line includes two activeRefreshes,
which I (still) argue is incorrect.  As I said last time and this time,
I'd be happy to insert a "drift" term, but lets please label it what it
is.  If you agree with that, I'll make that change and push.


*sigh*

No.   You screw up the analysis doing it that way because it doesn't account for the possible "phase shift" that can happen with a client during its addHoldDown period.

I've been using "sigExpire + activeRefresh + addHoldDown + activeRefresh + safetyFactor" because its actually easier to calculate.  The actual formula is

"sigExpire + (activeRefresh + retransSlop) + addHoldDown + (activeRefresh + retransSlop)"  where retransSlop is about 1/2 the safety factor.

Both the interval after sigExpire and before addHoldDown and the interval after the last activeRefresh require a safety factor to account for retransmissions.   The addHoldDown interval does not because retrans and drift result in a phase shift within the interval, but do not affect the length of the total interval.


A "perfect" system will behave the way you've described - but adding a safety factor while ignoring the phase shift brought on by retransmits within the addHoldDown interval will not characterize the actual system.




I hope this is visible.  The first group is the "perfect" one where we start at random point in the interval [0..activeRefresh].  The second group is the one with retransmits inside the add Hold down and where the signature expired just after the last refresh.  The third is Wes' perfect with the queries starting just as the sigPeriod expires.  Wes would add the saftety factor at the end of the third one and call it done.  The second one represents the actual worst case to which we'd add the safetyFactor to account for drift and retransmits for the two activeRefresh intervals.

Can we stop now?


Mike


--------------F04449CC833D970FC77547E9 Content-Type: image/png; name="fmbkofhbidcmlebd.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="fmbkofhbidcmlebd.png" iVBORw0KGgoAAAANSUhEUgAAAkEAAACTCAIAAAAGD1r3AAASDElEQVR4nO3dv2scR9gH8DPY jkn0moNXDpLfYBSQQVhgDmHweQjhFFKIcIWLVKkOBE+jRl1SGA5S2GqCniaNU1xjUDoXhqe9 Qn9AUOViinOnUuWV8xa7t7d7Oul+7N7OzM730+S02r3M7M4z39v16rZmAAAA/FRL//Dx48da kOr1+mAwsHQIlnF8fGx7nwHAMrybbRyXybBut9vtdi21xKZWq9Xv9223YgHeNRgAIijeYiHD jPFwVHnXYACIoHiLhQwzxsNR5V2DASCC4i0WMswYD0eVdw0GgAiKt1jeZ9hwOMz/Jt6Nqh9/ /NGvBgMsoZDqds08s00lO74ifmfY2dnZ8fFx/vfxLsPW19f//vtv260AWK3j4+OzszPbrSjY PLNNo9G4vLwspTne8zvDer1ep9PJ/z7eZVi9Xj89PbXdCoDV6nQ6vV7PdisKNs9ss7W1hfvv 54QMMwYZBuAkZBjM5GOGaa119MrBDNMiom9fI2n+8pBhXkkf8lmHP/P7IsaKz1zLsEKqGxlW rBIzTHjy8AspRURK8bTDfn39ZDOS6NVKMkxz3JwbGzBuOU20XPPkkmnbjpq/PGSYV9KHXIhk vOD6YMgsiVdWioiIZo+tqik+wxyobmRYsVafYZpJKWJthFniH5VSJHp0vIUU69F6YowRJiaK f4g2iAaPcDy44mHy/v37g4OD/tJOjtrt3d320U6jcXpKR+3d3Xa73a7VdnePTvr9k6Ojkw9H 7aMP/X7/w1H75OSovbvbPjrp9/sn7fb4Px9Gyz+ctHeTbdtH7fZRapN4rQ/9k/ZuO365tLW1 NWSYo4SJRgM2M2JTryczLDXIR0UxfWXWqZW1UFxS8WLWUe2oa9Ovp3777bfff/89Z3V/iH9w pbobjcbp6entbX/8+DEybE4rz7DxZxchEqM5VXVCioVJkURLtI7rkEiS9aPNNRNL/Hr8Ueft 27cbGxutHPb3m82nm1//T33n//73aXO/1WrtP9/cfD5+0Xy6+bS533y6ubm5+bTZbEY/P9+s PXz48OHm82a0wmh58+nm02Z22/hX0e+TX+3vP9/cfL50s+/du/fnn38We6SgOPFA1qkRm349 PrVSamKQ68ywz560RUUyWRGaSY2XJ58L85/sO+Dg4GBnZydndY/q0pXqrtfrjUbj9pavra0h w+ZUxrVELZSUomZSRNEZVrrQhKIM0+OQytSvZmKOXxd2LVEzkYgW2ny+f9JuS9KU9GdkzcTM JFNaOJpzxsuTxB41fvyr7H7IOcvgWqKzkkGVGr1CJOnXE2MsPcivb3jbytHgZGHi7Ae8imRY nmuJ0w6EE9XdwrXEQq08w4SJMxkWXUkk0dkDrZmIhZklcx5mhBUxM0XXHhUxk6oVmGHMrNTm 8/3+SVsRM7EIE5EkDTCao//h9RYm80iyPDvK05tM7AdkWFUlgyoaw+MRm32dmUmzg3zKhoqi 64rxBfVkZaNZRRfiR/+ojAwbmXYgnKhuZFixSr4vUXNyiIu4YO/gfYnlQIZBCFy7L7EQyLBi lX5vvdYiM29QnRcyDKDCkGEwk49/HzaGDAOoMGQYzOR3hg0Gg0Kyx7sMW19f/+eff2y3AmC1 +v1+9abyeWabZrOJ70uck98ZVhTvMsy7BgNABMVbLGSYMR6OKu8aDAARFG+xkGHGeDiqvGsw AERQvMVChhnj4ajyrsEAEEHxFmsywzqdzoLfSlYFjUaj79Wo+uGHH2Z+5Vol/fvvv7abYEeY Hf/06ZPtJhTPu9nGcZkM6/f7y30vme8ODg78ugtoZ2dnb2/P9m6zoFar2W6CBd99990333xj uxUWPH78+NmzZ7ZbUTDvZhvH1WavAu5phXo5olYLccQeHh5ub2/bboUFlfz7MChWiDNCBSDD goIMA7hJiDNCBbiWYeU8vdq4l2HldNzBDCun48gwmMmtGQHmVHyGOfB823kUn2E+dHwlGeZD x5FhMBMyzEtKqeXvS3T1+bbzqNVqy2/sbcd/+eWXjY2NADt+cHDw/v1729UGTkOGeenZs2cz HwV7CzefbzuPnPcletrxb7/99quvvgqw4xsbG2/fvrVdbeA0ZJiXWjmuJTr7fNt55LmW6G/H c15L9LfjuJYIMyHDvJQ3w5x8vu088maYnx0vIMP87DgyDGZChnkpT4Z5zbX7Esvh4H2J5UCG wUwhzggVgAwLCjIM4CYhzggVgAwLCjIM4CYhzggV0O/3r66ubLfCgu+//952Eyz49OnTr7/+ arsVFnS73Y8fP9puBTgNGQYAAL5ChgEAgK+QYQAA4CtkGAAA+AoZBgAAvkKGAQCAr5BhAADg K2QYAAD4ChkGAAC+QoYBAICvMhn233//5XnOnr9ev34d4Fc3DYfDTqdje98DwDLevXtnewpx QibDut1up9NZ/snh3mo0Gv3wvkJ3MBjkesI9AFhydna2tbVlewpxwmSGdbtdSy2xqRXk18AP BgOUAYCPULwJZJgxyDAA8AqKN4EMMwYZBgBeQfEmkGHGIMMAwCso3gQyzBhjXr58eXZ2ZrsV Zbu4uNjY2LDdCgBY2MXFxdramu1WWNDv909PT9NLkGHGGPPixYuJ/RKC8/PzR48e2W4FACzs /Pz87t27tlthQa/X63Q66SXIMGOQYQDgFWRYwscM01rrYt/RtQzTInJ7F4vYB8gw36SP+qwR kPl98SUDdjmYYeXMWlYzTHiyh0JKEZFSPK1n19dPNiMptmnFZ5jmuE839mLcfZrovubJJdO2 zb8PkGG+SR91IZLxguvjIbMkXlkpIiKaPbzAdSvJMB9mLRsZppmUItZGmCX+USlFokddElKs R+uJMUaYmCj+Idog2j/C8f5zKcOEiUYNNMLxRFGrKcVijDDL6PBqJpFUN0fdJzHj7mshlWxL TMSpTcY7k1Tq/7ocZJjTJsbVeOSnXk9mWKpYRqNr+sqsUytrobg048Wso7GXc4DB6uTNMG9n LQsZNo5nIRKjOVUtQoqFSZFES7SO64dIkvWTHckSvy7+PGxvb68WpPX19WL3JBQqLgidGvnp 1+NTK6UmikVnyid70hYV22RlaSY1Xp6ZqsA55+fnd+7csT1/2PHTTz+ld0UZ1xK1UFJCmkkR RfGcLhChKMP0OKQydaeZmOPXbl1L1EwkorOzxOQHZM3EzCRTujmacMbLk9gfvef4V9mdmXNX 4DzMZdPGlRBJ+vXEMEsXy/UNb1s5Gp8sTJz9oIgMc1TO8zB/Zy0L52HCxJkMi64kkuhsX3R0 /sksmfMwI6yImSm69qiImVTNtQxjZhVd5olayCJMRJL0wmiOWn29m8kkkizPjob0JhM7ExlW YdPGlapF516p15lJJ1ssUzZUFF1XjC/MJysbzSq6oD/6x2lkmNsKyDA/Zy3r9yVqTnrh0oV2 1+5LLAcyDMBTDt6XWA7rGWaM1iIz78EsGzIMADyCDEv4+PdhxUOGAYBHkGEJZJgxxjSbzQC/ LxEZBuCpi4uLhw8f2m6FBciw6YL93vonT57YbgUALCzY760fDoeXl5fpJcgwYwLOsDDLAMB3 KN4EMswYZBgAeAXFm0CGGYMMAwCvoHgTyDBjkGEAAbr562sX+OPVQt5k8fdB8SYyGdbr9Wx/ FZYdDx48+Pz5s61jYMuXL1/u3btne98DwDLwZaeR2uxVoKKC/Sh3eHi4vb1tuxUW1Ov1AP8O 0hhTq02b6IRqo0doTPnO8WumD5sF38TcdBQWfJ9gi/c6ZFi4gi0DZFhobsqw6V9fu2CGLfQm 5uYMW+h9gi3e65Bh4XKwDMp5FKyDGVZOx13LsHJ6bW7PsKlfXxt99W3WbRk295uY2zNs7vdx sHhtQYaFayVl4MOjYFeSYT50vPgM86HX5qYMW1BRw6aQo4AMSyDDwpW3DLx9FGzeycjbjuea Pb3ttUGGVRoyLFyDweD+/ftWb60C8IlTj07++uuvbU8hTkCGhSvnRzl/HwWb8wO1vx3Pcwbg b68NzsMqDRkWrgIyzM9HwRaQYX52PG+G+dlrgwyrNGRYuIItAwfvSyyHa/cllgYZVmHIsHAF WwbIsNBMz7D4XhKduV1FmHj6XSQ3DpsF3+eGe+sXe5Ngi/c6ZFi4gi0DZFhobsiw9BXK+Gsx brl6eXOGLfY+t/592LxvEmzxXocMC9dwOPzjjz9st8KCN2/e/Pzzz7ZbYcHOzk6Azys3xty9 e3fK0lE0pG9XuSU2/vrrr1evXuV/n+lHYcE3uby8RIZFkGEQnOFweHV1ZbsVFkw8ADcc0zue jo3U7Sq33EVSyPustjHhQYYBAICvkGEAAOArZBgAAPgKGQYAAL5ChgEAgK+QYQAA4CtkGAAA +AoZBgAAvkKGAQCAr5BhAADgK2QYAAD4ChkGAAC+QoYBAICvkGEAAOArZBgAAPgKGQYAAL5C hgEAgK+QYQAA4CtkGAAA+AoZBgAAvkKGAQCArzIZNhgMukF69+7dcDi0dQwsOj09tb3vAWAZ vV7P9vzhhEyGdbvdVqtl+9BYsLW11e/3LR0CawaDQb1et73vAWBhx8fHW1tbtqcQJ0xmWLfb tdQSm1qtVpgZhjIA8BGKN4EMMwYZBgBeQfEmkGHGIMMAwCso3gQyzBhkGAB4BcWbQIYZY0yz 2Tw7O7PdirJdXFxsbm7abgXAynU6HdtNKNg8GRbdZ15Kc2xChhljzIsXL05PT223omzn5+eP Hj2y3QqAlavVqvaHsPNkWL/fb7Va5bTHImSYMcgwgEpDhlWYjxmmtdbFvqNrGaZF5PYuFrEP kGG+SR/1WSMg8/viS8YvrmVY/gJHhiVKzDDhycMmpBQRKcXTDtf19ZPNSIptWvEZpjnu0429 GHefJrqveXLJtG3z7wNkmG/SR12IZLzg+njILIlXVoqIiGYPr6opPsNsFzgyLLH6DNNMShFr I8wS/6iUItGj4ySkWI/WE2OMMDFR/EO0QXTQheNB4VKGCRONGmiE44miVlOKxRhhltGY1Uwi qW6Ouk9ixt3XQirZlpiIU5uMdyap1P91Ocgwp02Mq/HIT72ezLBUsYxG1/SVWadW1kJxacaL WUdjL+cAc0euDHOywJFhiZVn2PgzhxCJ0ZyqFiHFwqRIoiVax/VDJMn6yehgiV8Xfx62t7dX CxIyzG1xQejUyE+/Hp9aKTVRLDpTPtmTtqjYJitLM6nx8sz86z3bdWZNCPffl3EtUQslJaSZ FFH0mSNdIEJRhulxSGXqTjMxx6/dupaomUhEZ2eJyQ/ImomZSaZ0czThjJcnsT96z/Gvsjsz 567AeZjLpo0rIZL064lhli6W6xvetnI0PlmYOPtBsToZtvS2bhY4zsMSK88wYeJMhkVXEkl0 9gDp6KSaWTLnYUZYETNTdO1RETOpmmsZxswquswTtZBFmIgk6YXRHLX6ejeTSSRZnh3i6U0m diYyrMKmjStVi869Uq8zM2m2WKZsqCi6rhhfmE9WNppVdEF/9I/TyLARNwscGZYo+b5Ezcmh celCu2v3JZYDGQaByJNhbkKGJUq/t15rkZk3lpYNGQZQYciwCvPx78OKhwwDqDBkWIUhw4wx 5uXLlwF+XyIyDALx+vVr200oGDIsgQwzJuDvrX/y5IntVgDAwubJsOFw+Pnz53LaYxEyzJiA MyyEPx8BqB4UbwIZZgwyDAC8guJNIMOMQYYBgFdQvAlkmDHIMADwCoo3kcmwXq9n9cu9rHnw 4EEI//g54cuXL/fv37e97wFgGY1Gw/YU4oSq/dkEzC/Yj3KHh4fb29u2W2FBvV4P8O8gTRX/ PgwSOLThQoaFBhkG1YNDGy4HM6ycB1g7mGHldNy1DCun1wYZVmk4tOFaSYbZfr7tPFaSYT50 vPgM86HXBhlWaTi04cqbYU4+33YeeTPM247nyjBve22QYZWGQxuuwWBw9+5dq7dWQanu3Llj uwnW2K42WBUc2nDlPA9z8/m288h5HuZvx/Och/nba4PzsErDoQ1XARnm3vNt51FAhvnZ8bwZ 5mevDTKs0nBow+XgfYnlcPC+xHK4dl9iaZBhFYZDGy5kWGiQYVA9OLThQoaFBhkG1YNDG66r q6vj42PbrbDgzZs3r169st0KC7a2tgJ8XrlBhlUaDi0EZzgcXl5e2m6FBYPBwHYT7Ai24yFA hgEAgK+QYQAA4Kv/B1U03NA6gQH6AAAAAElFTkSuQmCC --------------F04449CC833D970FC77547E9-- --------------83FD11E17F27E5447AA1F40C-- From nobody Tue Dec 12 13:04:17 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6B712896F for ; Tue, 12 Dec 2017 13:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 8cUziVMp3BXZ for ; Tue, 12 Dec 2017 13:03:49 -0800 (PST) Received: from mail.hardakers.net (unknown [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457501279E5 for ; Tue, 12 Dec 2017 13:03:49 -0800 (PST) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 7D36220E09; Tue, 12 Dec 2017 13:03:47 -0800 (PST) From: Wes Hardaker To: Michael StJohns Cc: Wes Hardaker , dnsop@ietf.org References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> <142cad85-1e0e-b4c9-1561-ad590984739a@nthpermutation.com> <1ca3daed-d521-0fcd-d1e7-eef2b781707b@nthpermutation.com> Date: Tue, 12 Dec 2017 13:03:47 -0800 In-Reply-To: <1ca3daed-d521-0fcd-d1e7-eef2b781707b@nthpermutation.com> (Michael StJohns's message of "Tue, 12 Dec 2017 14:34:38 -0500") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 21:04:01 -0000 Michael StJohns writes: > A "perfect" system will behave the way you've described - but adding a > safety factor while ignoring the phase shift brought on by retransmits > within the addHoldDown interval will not characterize the actual > system. Ah ha! So, you do actually agree that my description of the perfect case is true, which means we really have been in violent agreement about the "perfect" line in the sand. [as I've said: I absolutely understand the point your making about real world issues, such as timing drifts] And as I said in the last message, I agreed that a delay/phase-shift made sense and I'd be happy to produce a new term for it. Ideally I'd like to add that into the safetyMargin because it reflects real-world conditions, and I was trying to contain that to just one particular term. But I understand you don't want it buried in there, so I'll create a new term to deal with timing phase shifts and add that before the existing safetyMargin. > Can we stop now? I think so as I believe I can add words that we'll both agree to. But I've said that before, so... The only remaining questions, just to double double be sure: 1) "is one activeRefresh period long enough to account for the slop associated with time clock drifts?" I'd argue yes, as any clock that drifted longer than an activeRefresh (min = 1hr) is a seriously broken clock. I think you agree. 2) "is one activeRefresh period long enough to account for network delays and other elements, aside from 'retries and missing queries'?" I think you and I agree on this too, that one should be sufficient to cover network delays too. -- Wes Hardaker USC/ISI From nobody Tue Dec 12 14:20:58 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496FE1279E5 for ; Tue, 12 Dec 2017 14:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 CMLjJO0LsmtZ for ; Tue, 12 Dec 2017 14:20:55 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 22E4C127444 for ; Tue, 12 Dec 2017 14:20:55 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id u10so1149879qtg.2 for ; Tue, 12 Dec 2017 14:20:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=wrlbLMj/cSckAaL2W2P12n2/jQTS7lqoPmNLzjR8SAA=; b=G3sbLMR41G1okWtrQZQCaokzMk5jOrAwf8wguGFhPuuc2PeoVO9Hrg1FbpKRxwmtFj qwUk3PhBUuQMopkIgAPwOhAMdTpMAR7XJsEw+0X5uoSRx5RSrfejzd3OfeLYMMOt/J7K mP1fLBUhibFXqtGcMfvzL4ihFszVYTiuck9Wb9f7eywdSVK7w0n3de+E3pUrQk/xFPh/ Y5DmLxirYnuIfsiKRS2zI/iwT+Ep7icEuxFjDOo6kbJKN59mYaqrakx3JsT0+d797Ey3 OzlwsfRfpVT9q/agTj9w+RwSDuQuQN10+YWR5wRVKsEcgt4nnk/mOFij6eMYLNPSlOCR IIsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=wrlbLMj/cSckAaL2W2P12n2/jQTS7lqoPmNLzjR8SAA=; b=Pvn7yDGiEKQOJIRcgDT60ykeOoNb4jpWfUIDfgYxutP3kwLsvw6+Mxkn+rxdbrGYIc UYWgQjeeXHXp8YF7kTjgrcDV4lNcbh6Y3MRLZn0RorLdWNqDtFwhMuvdd3EcV3OmcKjq PL1rME41qF0CptO6kkFQ1T6CP1FUHvzP1W8ycd8CMUsqLjXMn6Koj0xBdEml7mQNE/vy HPDMfU6Ig7+HbG0afpYQzmSd6ltp9uUIkHwOuLGsHFc+GBaPeVLHS68+H1cJuw+QXJrF ikR0+nxiAqX2KhEQll2GXJGulBou66MRCSPdxJSpTraDcLx4atwa5M4Z6UOrATlglUaj wu4w== X-Gm-Message-State: AKGB3mJ3CYy4JOzUFo/Id0DkjVu8IXoJDO0sXy/A/dyZIk6ZP0StGjSZ SpKds7d3YWcVnprNBluYhkTRGYgq X-Google-Smtp-Source: ACJfBouBotfc5Zt0b7Jl1a1thwkOjHP8ttZZVisExRbvlqvu7CvcwaPhBiC1jQrvRuQZEnvvLstEWQ== X-Received: by 10.55.176.66 with SMTP id z63mr7519008qke.149.1513117253691; Tue, 12 Dec 2017 14:20:53 -0800 (PST) Received: from ?IPv6:2601:152:4400:720f::1009? ([2601:152:4400:720f::1009]) by smtp.gmail.com with ESMTPSA id o24sm144844qkl.22.2017.12.12.14.20.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 14:20:52 -0800 (PST) To: Wes Hardaker Cc: dnsop@ietf.org References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> <142cad85-1e0e-b4c9-1561-ad590984739a@nthpermutation.com> <1ca3daed-d521-0fcd-d1e7-eef2b781707b@nthpermutation.com> From: Michael StJohns Message-ID: <26d61092-942a-16bc-e939-ed9400a17a29@nthpermutation.com> Date: Tue, 12 Dec 2017 17:20:51 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EF8DC5EC144F823F96E10184" Content-Language: en-US Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 22:20:57 -0000 This is a multi-part message in MIME format. --------------EF8DC5EC144F823F96E10184 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/12/2017 4:03 PM, Wes Hardaker wrote: > Michael StJohns writes: > >> A "perfect" system will behave the way you've described - but adding a >> safety factor while ignoring the phase shift brought on by retransmits >> within the addHoldDown interval will not characterize the actual >> system. > Ah ha! So, you do actually agree that my description of the perfect > case is true, which means we really have been in violent agreement about > the "perfect" line in the sand. [as I've said: I absolutely understand > the point your making about real world issues, such as timing drifts] This is what you got out of all of that?   What I said was that doing any analysis starting from the "perfect" model would not lead you to the right place.  Your description of the perfect case is correct in its behavior and totally irrelevant to figuring out the final answer. > And as I said in the last message, I agreed that a delay/phase-shift > made sense and I'd be happy to produce a new term for it. Ideally I'd > like to add that into the safetyMargin because it reflects real-world > conditions, No - it doesn't.  Please look at the diagrams I provided and think about them for a day before responding.    I think you're still confusing system behavior with client behavior. > and I was trying to contain that to just one particular > term. But I understand you don't want it buried in there, so I'll > create a new term to deal with timing phase shifts and add that before > the existing safetyMargin. No - please don't. Please use the math I gave you.  It is correct. Here's the whole diagram including retransmits in all the possible places and assuming a best case start compared against a "perfect" model with the same best case start: The only effect of the retransmissions within the addHoldDown time is to shift when the final query happens.  In a pool of 10K clients, you'll get a percentage of those clients taking an entire activeRefresh interval after THEIR addHoldDown expires. In no case does any calculation that involves an "activeRefreshOffset" provide a worst case analysis. In no case does a "phaseShift" term provide any value over assuming that the addHoldDown expires just after the last query in the addHoldDownInterval. So again: sigExpiration + activeRefresh + addHoldDown + activeRefresh + retransmission slop/aka safetyFactor. > >> Can we stop now? > I think so as I believe I can add words that we'll both agree to. But > I've said that before, so... > > > The only remaining questions, just to double double be sure: > > 1) "is one activeRefresh period long enough to account for the slop > associated with time clock drifts?" > > I'd argue yes, as any clock that drifted longer than an activeRefresh > (min = 1hr) is a seriously broken clock. I think you agree. I don't know why you think this matters.  Assume that drift + retransmissions is enough to get the phase shifted to the worst case (e.g. just before the end of the addHoldDown period for at least one client) and we're done with this analysis. > > 2) "is one activeRefresh period long enough to account for network > delays and other elements, aside from 'retries and missing queries'?" > > I think you and I agree on this too, that one should be sufficient to > cover network delays too. > Again, I don't know why you think this matters.   If this is the safety factor, then no - you're asking the wrong question.  If this is just about accounting for the actual time to accomplish a query then you only have to account for the round trip delays for the query before the addHoldDown and the round trip delays for the query after.  Any delays during the addHoldDown time only cause the phase to shift.  Those delays are more than covered by a single fastQuery interval and can be ignored with any reasonable safetyFactor. For the safetyFactor you want to consider how large the pool of queriers and how often the queries fail to figure out how big to make the safety factor.  This ends up looking like a cumulative distribution function and you're looking to pick a cutoff far enough along the curve that you get most (tm) of the clients having completed the installation before moving on. https://en.wikipedia.org/wiki/Binomial_distribution#/media/File:Binomial_distribution_cdf.svg for example. Later, Mike --------------EF8DC5EC144F823F96E10184 Content-Type: multipart/related; boundary="------------4F073AA3A2B1ED39D4F6E971" --------------4F073AA3A2B1ED39D4F6E971 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/12/2017 4:03 PM, Wes Hardaker wrote:
Michael StJohns <msj@nthpermutation.com> writes:


A "perfect" system will behave the way you've described - but adding a
safety factor while ignoring the phase shift brought on by retransmits
within the addHoldDown interval will not characterize the actual
system.

Ah ha!  So, you do actually agree that my description of the perfect
case is true, which means we really have been in violent agreement about
the "perfect" line in the sand.  [as I've said: I absolutely understand
the point your making about real world issues, such as timing drifts]

This is what you got out of all of that?   What I said was that doing any analysis starting from the "perfect" model would not lead you to the right place.  Your description of the perfect case is correct in its behavior and totally irrelevant to figuring out the final answer.

And as I said in the last message, I agreed that a delay/phase-shift
made sense and I'd be happy to produce a new term for it.  Ideally I'd
like to add that into the safetyMargin because it reflects real-world
conditions,
No - it doesn't.  Please look at the diagrams I provided and think about them for a day before responding.    I think you're still confusing system behavior with client behavior.


and I was trying to contain that to just one particular
term.  But I understand you don't want it buried in there, so I'll
create a new term to deal with timing phase shifts and add that before
the existing safetyMargin.
No - please don't. Please use the math I gave you.  It is correct.  

Here's the whole diagram including retransmits in all the possible places and assuming a best case start compared against a "perfect" model with the same best case start:




The only effect of the retransmissions within the addHoldDown time is to shift when the final query happens.  In a pool of 10K clients, you'll get a percentage of those clients taking an entire activeRefresh interval after THEIR addHoldDown expires.

In no case does any calculation that involves an "activeRefreshOffset" provide a worst case analysis.
In no case does a "phaseShift" term provide any value over assuming that the addHoldDown expires just after the last query in the addHoldDownInterval.

So again:

sigExpiration + activeRefresh + addHoldDown + activeRefresh + retransmission slop/aka safetyFactor.







Can we stop now?

I think so as I believe I can add words that we'll both agree to.  But
I've said that before, so...


The only remaining questions, just to double double be sure:

1) "is one activeRefresh period long enough to account for the slop
   associated with time clock drifts?"

   I'd argue yes, as any clock that drifted longer than an activeRefresh
   (min = 1hr) is a seriously broken clock.  I think you agree.
I don't know why you think this matters.  Assume that drift + retransmissions is enough to get the phase shifted to the worst case (e.g. just before the end of the addHoldDown period for at least one client) and we're done with this analysis.


2) "is one activeRefresh period long enough to account for network
   delays and other elements, aside from 'retries and missing queries'?"

   I think you and I agree on this too, that one should be sufficient to
   cover network delays too.

Again, I don't know why you think this matters.   If this is the safety factor, then no - you're asking the wrong question.  If this is just about accounting for the actual time to accomplish a query then you only have to account for the round trip delays for the query before the addHoldDown and the round trip delays for the query after.  Any delays during the addHoldDown time only cause the phase to shift.  Those delays are more than covered by a single fastQuery interval and can be ignored with any reasonable safetyFactor.

For the safetyFactor you want to consider how large the pool of queriers and how often the queries fail to figure out how big to make the safety factor.  This ends up looking like a cumulative distribution function and you're looking to pick a cutoff far enough along the curve that you get most (tm) of the clients having completed the installation before moving on.  https://en.wikipedia.org/wiki/Binomial_distribution#/media/File:Binomial_distribution_cdf.svg for example. 

Later, Mike



--------------4F073AA3A2B1ED39D4F6E971 Content-Type: image/png; name="hpfhbdffhkmlphbe.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="hpfhbdffhkmlphbe.png" iVBORw0KGgoAAAANSUhEUgAAAnEAAABRCAIAAAAy3GdwAAAPGUlEQVR4nO3dP2gbVxwH8LMb 4gyOKwxpLapgUWwoHdwG0VS8BmxjikzQWDA4UMcJ/DoIkdGDhzdWm38UOnsReCoeCg86echQ 6GIyZXiDunXU6PE63El3T9Yf++509076foZYvj/Wu6f37qv7k3uOCwAAAElwRs3odrvlctmZ P5eXl2l+ADPj8vIy648OAO6qUCh0Op2sdxszaGSmdjqdcrmcZlFsIKWUUmZdilxC1QHkyM7O ztXVVdalmEHIVAOCITJUHUCOIFOnBJlqQDBEhqoDyBFk6pQgUw0IhshQdQA5gkydEmSqQUp5 enqadSnS9u+//w6ZqkgIIhLE2piueWCC5/T0dA6rDiCnXrx4MYeZmsi+rtvtjnkLZKpBSrm3 t5d1KdL28OHDDx8+DE5VRKr/QzMJQaxcrchxhGA1uPje3t4cVh1ATq2urv7+++9ZlyJVHz58 ePjw4ZAZ99zX7e/v//3336PeBZlqkFJub29nXYq0PXjw4P3794NTFTlCCEFKu5qJtdaaiXWv /Q3a3t6ew6oDyKlCoXB2dpZ1KVL1/v37Bw8eDJlxz33d+NPmyFQDMjXQ/9LGWpHXzrTuT78F mQqQI8jUwD33dbOdqf62J8W2TNVKqfHbl0QFjMtU/3sbE7FiZu+LHJG61dSQqfkRbjSTGpAx P+HuBhmyLVNT2NdNyNQ77+uszFTFRvX1LhGLoVeEby8fXnPoF4moks/U/lXukZsw7gr54JRh 68avgOGZek/I1PwINxpFpIIJt5uTMcVfWAgiIprcOsFeyWeq9fu6kZl6TzZlqn/1V7uKuXcx WAhBJPxLxIJ1cInYdRUTU7C8v4JX+Yr9DyfhTF1fX5fRHNYqlVKpUmv6v5RKlUql4jilUu1Q ysOKU6o1pZTNWuWwKWWzVimVKrVDKeVhpRL86E9vHlZKTqlUq9QqtUqlZq7iv2zKw0op9K7R LC4uHh8fR19fSinl+vr6Dz/8kOBnAclQTNTrNEavCb0ezNRQR+vdvjF8YVahLqkVservHjWT IOLgvcEqjx8/rtVqEXt7Pvd1x8fHi4uLEVcO2djYsCVTg+8iiki5uheszCRYMQlSIy4R+8v7 XZeJlf86+ePU6JkqpZTNZq1Sa0rvXyn7bUjKQ781hBZo+ksfVpxSqVSqHA5M7831/kJ41q2/ 33+bKBYXF3/++ecYWy2llOvr699//32CnwUkx+9POtRrwq+DQ08hBjqaNrqeeVCrWTgiWDI4 dya8H8zh2ynBLsvLy9EzVco87uuOj48XFhZibLLvyy+//Ouvv0ZVbNrnfrWifrf0vsgSq3Cn G36J2OjLod5q07lfzURKaXO3Y36pZ2Lm3m5mcDNvXyE3v1gYs8yajFkPOPc7w4Y1S0Wkwq/H dLTbK4YXdpzQkv5PZlZM3F8XmWqnOOd+c7qvm8Fzv4qJjUz1z/wqDtVS+BLxwCkpxYKYmUhp V5EgZhKOVZnKzMI7r+YVj5XqXeX2jg365R2ymcOukIcP1kOzBmoSmQqjDGuWwvGOTUOvx3S0 ISsK8s4D6/CS3rsJ7/qNEEHTRabaKG6m5nBfN4OZatLBmSFrrrfEydT8GnHfb3Ax278gp3jM 5TFkKkCO2HbfbwpG3/d7v32dtZnqulorNfEG6lQhUwPG18HJl8eQqQA5gkwN3HNfZ3Gm2geZ GghdVfOvnRAyFWBGIFMD99zXIVPvQUp5cnKSdSnS9ubNmyFPhQ63M+/aydh2dnBwcHBwMPWy AkASqtXqvD1Dv9vtvnnzZsiMe+7rpJSdTmfUuyBTDd6t0lmXIpdQdQA5grHepgSZakAwRIaq A8gRZOqUIFMNCIbIUHUAOYJMnRJkqgHBEBmqDiBHkKlTMi5TC4VC/Mc45cvOzo5EMETyyy+/ VKvVrD/AtL148WLI1EPv+ae3nkzarA19VOlPP/0U/3nLuXNwcBD/jxwdHZ2cnMT/O/mSSKtb W1v7888/s95tzKCRmeq67vn5+TQahOXG3NAFY7x79257ezvrTy9tw4cfGPmg8N5Dxk2rq6vP nj1LpbwWcRxnyNRXlcqr/o/mfuXp08r+K9l8VXGcp0/3Xw0ujqoL3LPVjX9oLUQ2LlMB7s7r qFmXIm2j/muvI4QQ1Hvm2q0xIUwbGxtv375NobRWcZxhOx9U3R0kUnU49zslyFRIhm2Zmv1w 7rcfFJ6TYEin6kYFA6puokSqDpk6JchUSEbymWr9EMfuhEdQDXtQuPeQcVPywZCHqhsXDKi6 sRKpOmTqlCBTIRmxMnVg3Gx/4BPHEYKVd1KrN5SY0v2h7UPPOel/Rfema0XCEYKp92js8Cq6 92xsRYLijpidyJA+sYIht1U3PBjuCVUXGTJ1SpCpkIyjo6NyubwT1e5utbpZ3Kzuev/u7Ozs bhWLW/6LlZVgVnWzuFmt+ktvFZ2VlZWV4tbA9N5c7y+EZw38/d3drWJxK3KxFxYWnj17Fnl1 z9LS0pMnTyKvntOqcxwn8rp9S0tLn332WeTV57nqVldX//jjj6x3GzMImQrJODk5OTo6uoqk 3ajXW612q15vXbXq9ZY3tf+qVa83GvVGo1Fv+b+12+12u91fpt2oN9rG9Haj3mj3/4Ix6+qq 3aqH3il4wwg++eST3377LfLqnmKxuL+/H23d/Fad4ziR1+1bW1t7+fJltHXnvOq+/fbbKxyn TgEyFZIR59xvToc4di0495vfqsv83O+cV90Ozv1OBzIVkmHbfb/pyDxT8yvzTM0vZKrNkKmQ DGRqQPXuUunfBaOYeOSdKQiGAKruDhKpOmTqlCBTIRnI1IBxYk9rJuZxZ/wQDAFU3R0kUnXI 1ClBpkIyzs7Ozs7Osi5F2paWlv7555/BqeEhjpXSisYPcfz11183m82pl9Uy44MBVTdGIlWH TJ0SZCpAdBcXFzc3N4NTw3s37y6YsXu3q6urOXzK9Pn5+ZCpqLo7SKTqLi8vu93uVMs5n5Cp AAAAyUCmAgAAJAOZCgAAkAxkKgAAQDJGZmq32y0UCs78mcObV70niAJALpTL5az3GTDSyEzt dDpz+MnN53+yLJfLc3jzJEBOOUk8RwmmBJlqQKYCgOWQqTZDphqQqQBgOWSqzZCpBmQqAFgO mWozZKpBSvnu3busS5G2UqmETIVZdX19nXUREjYxU29ubj5+/JhOYWAAMtUgpdze3s66FGn7 9NNPkakwq2bvqG7iFp2fn79+/TqdwsAAZKoBmQowY5CpkKa8Z6rWetjYgFHZlqlaKTV++5Ko AGRqToQ/7EkfvDE/4W6SL7ZlavxOjUy1WUaZqthoVYqEICIhhg6ee3v58JrDhlyILPlM1exv 08hNCDZ/cOxgzcNHEzbXjV8ByNScCH/YikgFE243A2OKv7A3VAlNblUzJflMzbpTI1Ntlm6m 6t6o84pZ+b8KIYiEPyaRYN1bSLnGyPWseuv7rVSx32atyVTFRL3SuYr9PZjjCMHKdRU53lcG zaS0a2xmeEim/nStSDhCMPUqIbxKUJMkQu8aDTLVRgPNKWjtodeDmRrqIL1GNXxhVqGupBX5 3bHXyog4bqOyR6xMtbJTI1NtlmqmBl/RFJFydS9YmUmwYhKkvGW09hY1dxm91TUTK/918sep hUJhJ6rd3Wp1s7hZ3fX+3dnZ2d0qFrf8FysrwazqZnGzWvWX3io6KysrK8Wtgem9ud5fCM8a +Pu7u1vF4lbkYj9+/BiZaiW/H+hQaw+/Dg49hRjoINroMuZBrWYRRIG/X2etmYT3g3ncuJu5 4zhO5K5hZ6eeuEVfffXVjz/+mHXFz6m0z/1qRf3u7X0hJlbhzqvIy1RtJKaxTwj1+ilk6jff fHMVSbtRr7da7Va93rpq1estb2r/VatebzTqjUaj3vJ/a7fb7Xa7v0y7UW+0jentRr3R7v8F Y9bVVbtVD71T8IYRrKysIFNto5lIKW20fEWkwq/HdJDbK4YXdpzQkv5PZlZM3F93ljI1ctew s1NP3KKTk5ODg4OsK35OpZqpiomNTPXP/CoOdV7NRKyYWQ0ep7qKBTEzkfJOjzCTcKw596uZ iJmFd37OKx4rxUSkVO8Yo1/eIZvZO1roTx84WA/NGqjJmLs/nPu10LDmJBzv2DT0ekwHGbKi IO88sA4v6b2b8K67CBE0udnJ1Mjr2tmpce7XZhne96uDM0zWXLex7b7fdCBTYYbZdt9vfMhU m2X6f2m0VmrifeWpQqYCzBhkKqQp7/8/NWHIVIAZg0yFNCFTDVLKvb29rEuRNmQqzLC1tbWs i5AwZKrNkKkGKeXp6WnWpUjb2toaMhVm1c3NTdZFSNjETO10OpeXl+kUBgYgUw0Y6w0ALDd7 Z7NnCTLVgEwFAMshU22GTDUgUwHAcshUmyFTDchUALAcMtVmIz+b//7779GjR3Gek5lH5XL5 119/TfMDsMGTJ0+eP3+edd2n6rvvvvv888+zLkXaSqXS1lb050LnVLlczroICXv06FHW+wwY adz3nevr68jPycyv2btLcKJSqXRxcZF1xaeq0WgsLy9nXYq0ffHFFy9fvsy6FGmL87xfO338 +DHrfQaMhHMIMI/nfs/OzgqFQtalSNvGxsbbt2+zLkXacKYU0oTWBtZlqp74wEp/3KLoLMzU FLbatkxNYZNdZCqkC60NppCpmnsD5fLInaY/TMqtkZeDUXZHiz1iylQy1fqtTj5Trd9kF5kK 6UJrg3iZqphI9PaXiv3xxBxHCFauqygY/Vp5o18LQRwaycr70Z+uFQlHCCYmpt6A2b1V/Jfe SH/Bu0YQN1PzudWxMjWfm+wiUyFdaG3gLi8vO/NnYWEh6yKkbQ432ZN1D4M5gtYGsY5TNRMp pRWFR8g2xspmJmYOhsrV/jWy/nELa2O6OWizMct1dUIjscc8Ts3pVsc5Ts3pJrs4ToV0obVB 7ExlZiFIua4iQczESjERKeXtDDULx98laiZixcyqvzPVTKzD081dbXgVxcT2ZGoOtzpupuZw k11kKqQLrQ2su+83BRbe95sC2+77TQcyFdKE1gbI1HmBTAWYNrQ2QKbOC2QqwLShtYH7+vXr brebdSlSdXFxUSqVsi5F2p4/f35ycpJ1KdKGTIU0obXBnLq+vs66CGnrdDrz9uXJncsPGjKE TAUAAEgGMhUAACAZ/wMsy+pBl93EVAAAAABJRU5ErkJggg== --------------4F073AA3A2B1ED39D4F6E971-- --------------EF8DC5EC144F823F96E10184-- From nobody Tue Dec 12 16:04:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337801270AE for ; Tue, 12 Dec 2017 16:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZtoFYxlPWOJM for ; Tue, 12 Dec 2017 16:04:35 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0074.outbound.protection.outlook.com [104.47.93.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 37D32126CBF for ; Tue, 12 Dec 2017 16:04:33 -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=IksMfvEBTKBSF3CS+MT9x3rZ3wIsUxM3XEYCKMdDcTE=; b=Uww9zm+wu+AbF24iJMANLYvT4E/uJzpafcq8+MocRQa/7TS+Iztc5adXSS1JzZpq4VXWq+ark6t/HkEH9Z/72zHM66uF37UdLuj+JsbHJjeSGRyDME6xLEp+NcKAP3Tipb3h/3xYNoAFIl9PyNrHmsiCQb/YsK1kPNwdBdg5rq8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from [192.168.10.101] (12.188.91.2) by TY1PR04MB0701.apcprd04.prod.outlook.com (10.163.246.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Wed, 13 Dec 2017 00:04:29 +0000 From: Geoff Huston Message-Id: <468B0CBD-A9A2-475B-AADE-E80BDCAD3F7B@apnic.net> Content-Type: multipart/signed; boundary="Apple-Mail=_40C581C8-3283-441E-8AB4-8747D7894D6A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Wed, 13 Dec 2017 11:03:44 +1100 In-Reply-To: Cc: IETF DNSOP WG To: Bob Harold References: <151295531772.21182.323628264618825298@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.4.7) X-Originating-IP: [12.188.91.2] X-ClientProxiedBy: MWHPR2001CA0017.namprd20.prod.outlook.com (10.172.58.155) To TY1PR04MB0701.apcprd04.prod.outlook.com (10.163.246.23) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ca421243-42e2-4ee3-cc09-08d541bd154a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:TY1PR04MB0701; X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0701; 3:bbdDm0gfma0nt0kRMrgow+HUn2/TFDi160lWbncMahcfnw3cBSZP/bL/YZfBq1mZXzfBPM466/LMWk932Cb2FBwwYw5K3QWfutggzkumoo/bO4fkTOauF79RPKk7p+WBIjAQYjJreaCCuo180tC3RO5Clpk6lFF2SR7xGzjuhiVZKOjqcGKYLBx+HVY+bRhLoSSYdsLaeI1WqlN/zmEPdL2u7w2Y3892Zp5X9OUE8n8+cdLAlhmSPR2EEeabZ5ln; 25:FF+fEsVVnfl8XwmDHZD8IoQAjkP2RUOzcVuqYq03Ylb4lfZcUBmzKB08GWICI/TdSYKV+bvW+DGEAUEbs57bVWdKLC82lPe/BoGaByQ+dEhuH+43qkjctkxxn2Hx84F5RCv/hNvcHrR+lXYCXp1WFzbpSS5KfKlU7JnffVXmEq5vR6el+gyCiQltkx2i9I7Q1Ivs2wSW17HquvdIWOiFpE2H5+nHdPeEDG0Ec9AzQ2Ng9PLcLwhKTpGsHWzQlUnonAhHm+NsZk9aVtXRpmmqc5iQIjYfaRppkMdKzwI8FUS6oJDVXOhCPoF4BdgkoXlKSThnJfno8tSX2tvHOhJRn4c/0d8NLuL0L+18gwXSFEs=; 31:JXaXRbZYAEFSOfjItvLAF+RBme5IVZOpNnGCPBcNjDgLBaNSPFrxub2aLqdJvAUijRHAPmC0wuwNAoxrOabyiH1CrPDodov3QlHNUP6iRt0e7skadX+FX10NsXnIygd68R+1wchieidMGC6c4uuUOFdCGtVD7LFGyLWd17PFxZSEnefksnj/MDzvGb9BCOqx6xrun9B4eEkpN+LAe02+EC4YXvTVQabMQHVcqtJYRic= X-MS-TrafficTypeDiagnostic: TY1PR04MB0701: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(192374486261705)(177329092695168); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231023)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:TY1PR04MB0701; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:TY1PR04MB0701; X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0701; 4:dQnBKQmTVShY8ocPfc9fYseTMV4SmPU4+p09TTX0EvIVi87WxoKHLwOsTGnA5U0Lg1lJRoZAoCb9F9ucPhygzV+MQ0D+bJehCnUSoSv9PuAYbT5hmuIw2AzLA8IQGzVEC1NCPjDEldsjt7eoo86Zrcw1l53H0wZCwgmz08VzPW5sLDzTrT5riQH0hSlcAFEINsI9W6dAFtyDsTr/UintZYVACXVzpZ4t4XVJuBS6xMVnoYPQq0ngXeAcf9G4+prDN2wlq85QHEoZCuDUlqqr+J+DUDk+9rerHdwHqMMTp1PSMmLmHK+3xgl9cb53XwKR/lOxtlB809Fi6e+VV2sNOVajjNu3CsfKXu8qYuq9qkQZlz1RLQrNy9b90wWwiASS X-Forefront-PRVS: 052017CAF1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(39830400002)(346002)(376002)(366004)(24454002)(377424004)(189003)(199004)(8936002)(8676002)(57306001)(478600001)(606006)(82746002)(81156014)(7736002)(8656006)(36756003)(25786009)(52116002)(16576012)(316002)(86362001)(81166006)(84326002)(117156002)(16586007)(83716003)(16526018)(33964004)(59450400001)(53936002)(77096006)(229853002)(236005)(90366009)(54896002)(106356001)(6486002)(6306002)(4326008)(2171002)(6246003)(966005)(97736004)(33656002)(6666003)(5890100001)(105586002)(76176011)(230783001)(6116002)(2950100002)(69556001)(66066001)(4001150100001)(50226002)(568964002)(2906002)(68736007)(5660300001)(6916009)(53546011)(3846002)(386003)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:TY1PR04MB0701; H:[192.168.10.101]; 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: =?us-ascii?Q?1; TY1PR04MB0701; 23:i4WNeM3Lw1KiAwUgBBQ5Rr2CqolnTXFOcZVs1rImd?= =?us-ascii?Q?jPEmnNqyGgNH/guMFwsK942IME4ANpCyxCkvtfyfbkspVAjtPMLF0c1nXMdN?= =?us-ascii?Q?EIV46FcR2am0pHQA3se7Hvd4fJBmWcM0Hk7JJNtuUpckuQK3TiD3Pyp5maAb?= =?us-ascii?Q?jUuPbqbuGLalki0oBMWbEHBHTWTpeTX7pZwFL9pxYIHRAjXaIkyoM2AIxndg?= =?us-ascii?Q?3XDv5kmyQkLzHAC5joyvcxUMSBWo2kPwS1id5GVfMghMdn0/PjOUmGJux1V2?= =?us-ascii?Q?3URac2T+z52GgZNg8kcNPTGFb817f4+KG7Oh/oAg3NSXMuwjS0wcLdwBhbZn?= =?us-ascii?Q?/y0Xp0em48UP8tfihrnPYIBKNTZVhaQuJUVOoNJfZwQt7UbtjhzNeiR31oJ2?= =?us-ascii?Q?2HjnqemrnapNGtj0JZRItmXizJTqmKd56Z5UmGYsHsX890X/WJVVbLd8T/A/?= =?us-ascii?Q?tHmCtk3/ho01H0IkGMAtC8oGAv/FF1VMkRPbCFlBOXOPkfWbv9bBrZVBfvUT?= =?us-ascii?Q?6HCgWValEpZgo09LSgBIfGuIxM3jqZqk863tsxtPlxARbhcI5zToqoCxSo70?= =?us-ascii?Q?Agj1DhyFzZ05RXFjPvs4cAnQIGjnAM54BRQjoXQtfw7AQC+BmgQaGbRRP7nL?= =?us-ascii?Q?rC4BKV6M1rmcmELpZueIiCAfST5KPYvLl9YrgyOUYMFwjwPnHFnyjW1gKumH?= =?us-ascii?Q?SSeoE80BmlmEM+Yf/UYe8YOQzlwNUgAIIvcAZvs62zUNbxEtISAa8R8zfIWV?= =?us-ascii?Q?6Op3hk8U0QDmCgYc6ARkr3ZdofpxEfyvum9z6cciX7jOWNuY4D/pSTSW3N2H?= =?us-ascii?Q?V71IOYIVAO2F2xXv9nJlndCcDaNEEjoUmr4OnlpWHYhAVPnjTw4I8BJYTKWv?= =?us-ascii?Q?HcCzjhEZhw7N87TLR8mTb+OlC2Mt3sU0+mJf1ZuSSEdnI+rUHnxWVCnD2E7e?= =?us-ascii?Q?BIqDNnSzLismc7WpOdxpDML5uLwNcQRQoDhRlgkE9YgS7fptSjPpLZ5pgWPd?= =?us-ascii?Q?iIoLIIHXD51XzMqS/dSbmdqh99rSefIBjbhmtDNHlA4fAk3WtydeQaEYW4Tl?= =?us-ascii?Q?MuZcAFfZ4RA45xYQv89NTjSLEAKlI6K8jk3xWhCrJ+0eYev8CyMVBfwQQrbZ?= =?us-ascii?Q?Tms9UvpG1hjRNXBbsDXWqttIBNU1WREE8QLLhg2uwuNfUmpRwn0QxT4jJ2tQ?= =?us-ascii?Q?cdLCTNqwutcHdj84SmyygWbbEVvPBjKLEhDh4YHYKKcHxviOhEmiJXB4i6cB?= =?us-ascii?Q?Y004Od9YIJyVP2K8j8MWt5TlqLqVqyYGOB0Yp9017Yn4q6SoDQkpincRy9Vd?= =?us-ascii?Q?LaMpfTudce8YMaYd5LwUE5F3TDMsqciR8+XaWme0s0VOe6nstkHKMVPctfy3?= =?us-ascii?Q?ZffYdDgkGHxjIpfoUHrG91qE55MRekLXeqMOm5m9Ka8QVF1GnGRng0tqiljg?= =?us-ascii?Q?hk9onbWe8InYHYxAhIt1mOmxPND3r6OvgI4TJTgwg0rOb9fQZ5NkdwYjbMIO?= =?us-ascii?Q?b1rF5hYdlYzAv3QIzPo6/N1qCpJKzsyFvDIuTDsZ3oRBb8gBBDGTeAE?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0701; 6:GFMmDPQAkFL+6rzKyAq6E+TkukmKoWwe9xtZh8t7BHwFuFdGWgg72nxTipw1KEL+z0S90uGNLsaITLRQ2KOT41h3HIivSwvCtUaVTN9WjTR6JDgCSIC0mR35qMKXavpfKFCH6XeOxbr5RUnGJY/Z341Bmk6WYeCbpHp9Fv61JOgANTOsY/78eUr6/v7VWo0WYlBdBa4ZqXDpF6JdAFI88J3UExdn24vjxpjTFibykmVfGIalSGZUxsnPFCj+kEJZcl4ACtv5F1hUJ/uoKnGJHIl4ERmgDxIcJ34RHELYVaG6zwjMRmhOkLQPXqKjpdDOXrAgwfwwsPacxFb8Wg/V/E4X6HJo/OSCArRPooi9kRU=; 5:AEdAxzbWhqOUQ5YMMr5nJ7jmAK3FSuihAalxceNRLWx91qr8Xa/7jKwyQOteNJaocK6yBrKWz49lvbYgaEng9/O9pVhO4oWz3sH+VJtfWaucYYJpCBKh5HTKNC6GAs8OWAVyAm2K8ZY8rl4/i6D2hEBosHB7k9xS0FJDphmOK6I=; 24:jKd0a7IgRwcrI6RVhKmztYOu3RX3lh/c4R92/VqPZGwZ/vcRIuxG4oFQ/j9c4kHXuuBQ9jcOpe71WkWF1aEYCdiplzfe83xadEAre1nChDQ=; 7:/p8Xag48C7ZVPtGnoPlzxtUvRGTJBng13Haw1gAui5kXDaBMJaupdC2+Y/AA9CwYhsz8v6D0h1VnRYRnbRCYGsTW7dmRD0ZaDSJTbOWmKqOj+gqwOEXJJq2vjvM1Q0WN8a+sL5Ye7AxiiOTmHUmXxIvni7ExnNgTv616MB1F4r2KCrWP4/l8hsXwOshlf1TyyEWdbkUP0zXZilv5csvhQe//5HHgZVO2RW/qIjx0C/wTo19Q7AmD+yreaYn40Gjy SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2017 00:04:29.7140 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ca421243-42e2-4ee3-cc09-08d541bd154a X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR04MB0701 Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 00:04:40 -0000 --Apple-Mail=_40C581C8-3283-441E-8AB4-8747D7894D6A Content-Type: multipart/alternative; boundary="Apple-Mail=_656A1A67-5470-4366-8710-2BAC0570CF12" --Apple-Mail=_656A1A67-5470-4366-8710-2BAC0570CF12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 13 Dec 2017, at 3:44 am, Bob Harold wrote: >=20 >=20 > On Sun, Dec 10, 2017 at 8:21 PM, > wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Domain Name System Operations WG of = the IETF. >=20 > Title : A Sentinel for Detecting Trusted Keys in = DNSSEC > Authors : Geoff Huston > Joao Silva Damas > Warren Kumari > Filename : draft-ietf-dnsop-kskroll-sentinel-00.txt > Pages : 8 > Date : 2017-12-10 >=20 > Abstract: > The DNS Security Extensions (DNSSEC) were developed to provide = origin > authentication and integrity protection for DNS data by using = digital > signatures. These digital signatures can be verified by building a > chain of trust starting from a trust anchor and proceeding down to = a > particular node in the DNS. This document specifies a mechanism = that > will allow an end user to determine the trusted key state of the > resolvers that handle the user's DNS queries. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ = >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-00 = > = https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-00= = >=20 >=20 >=20 > Looks good to me. One minor typo: >=20 > 4. Sentinel Test Result Considerations > paragraph 6 >=20 > "If the resolver is non-validating, and it has a single forwarder > clause, then the resolver will presumably mirror the capabilities of > the forwarder target resolver. If this non-validating resolver it > has multiple forwarders, then the above considerations will apply." >=20 > "it" at end of the third line should be deleted. noted - =E2=80=9Cit" will be removed in the next version Geoff --Apple-Mail=_656A1A67-5470-4366-8710-2BAC0570CF12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 13 Dec 2017, at 3:44 am, Bob Harold <rharolde@umich.edu> = wrote:


On Sun, Dec 10, 2017 at 8:21 PM, = <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Domain Name System Operations WG of the = IETF.

        Title          =  : A Sentinel for Detecting Trusted Keys in DNSSEC
        Authors         : = Geoff Huston
                    =       Joao Silva Damas
                    =       Warren Kumari
        Filename        : = draft-ietf-dnsop-kskroll-sentinel-00.txt
        Pages          =  : 8
        Date          =   : 2017-12-10

Abstract:
   The DNS Security Extensions (DNSSEC) were developed to = provide origin
   authentication and integrity protection for DNS data by = using digital
   signatures.  These digital signatures can be verified = by building a
   chain of trust starting from a trust anchor and proceeding = down to a
   particular node in the DNS.  This document specifies a = mechanism that
   will allow an end user to determine the trusted key state = of the
   resolvers that handle the user's DNS queries.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-00
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-00



Looks good to me.  One minor typo:

 4. Sentinel Test = Result Considerations
paragraph 6

"If = the resolver is non-validating, and it has a single forwarder
clause, then the resolver will presumably mirror the = capabilities of
the forwarder target resolver. If this = non-validating resolver it
has multiple forwarders, = then the above considerations will apply."

"it" at end of the third line should be deleted.


noted - =E2=80=9Cit" = will be removed in the next version


Geoff



= --Apple-Mail=_656A1A67-5470-4366-8710-2BAC0570CF12-- --Apple-Mail=_40C581C8-3283-441E-8AB4-8747D7894D6A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCBiMw ggULoAMCAQICCAhuuVM6E+ncMA0GCSqGSIb3DQEBCwUAMHQxFzAVBgNVBAMMDkFQTklDIFN0YWZm IENBMSAwHgYDVQQLDBdJbmZyYXN0cnVjdHVyZSBTZXJ2aWNlczEWMBQGA1UECgwNQVBOSUMgUHR5 IEx0ZDESMBAGCgmSJomT8ixkARkWAkNBMQswCQYDVQQGEwJBVTAeFw0xNzA4MTAwMjIwMTBaFw0x ODA4MTAwMjIwMTBaMHQxEzARBgoJkiaJk/IsZAEBDANnaWgxFTATBgNVBAMMDEdlb2ZmIEh1c3Rv bjEOMAwGA1UEKgwFR2VvZmYxDzANBgNVBAQMBkh1c3RvbjENMAsGA1UECwwETGFiczEWMBQGA1UE CgwNQVBOSUMgUHR5IEx0ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIOwbKnNbjM6 or3dzySKJobuQ8XIySQJH+n6uUWTbgl53PEpwHaEtKTefpN4Al+iY340CSSlBJdxWoDoB9e/0s/G sAFCpUMJFOy+RN+eyUOhqd+rU6ny18A5C0b9ZZL8ZZ+xo6L2L6GUBf+hmmQ3L5Eebd4AHPw5FD7g kUjWBhzbf/HXrN+/ZJ6jNm8/0bdLjeH69yIaP12yTO3onubkUDj97GEr795ur+w/wMo0cN5kubPL 7nraIiUyayv5g/s/Xf119tytvIyjV4176iXs+92zk1Wb2Ce0tOHdwcXEd7rMJjnW48Hsvg4FkXKM 44L69MJfupibWYfZCKzWuYfN+TECAwEAAaOCArcwggKzMB0GA1UdDgQWBBTE/QiQY/ek5gTClQLg CUilYtD3sDAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaAFO6+jwAhhzC7rcE2SgicSseILPLfMIG2 BgNVHS4Ega4wgaswgaiggaWggaKGgZ9odHRwOi8vY2EuYXBuaWMubmV0OjgwODAvZWpiY2EvcHVi bGljd2ViL3dlYmRpc3QvY2VydGRpc3Q/Y21kPWRlbHRhY3JsJmlzc3Vlcj1DTj1BUE5JQyUyMFN0 YWZmJTIwQ0EsT1U9SW5mcmFzdHJ1Y3R1cmUlMjBTZXJ2aWNlcyxPPUFQTklDJTIwUHR5JTIwTHRk LERDPUNBLEM9QVUwggEuBgNVHR8EggElMIIBITCCAR2ggaCggZ2GgZpodHRwOi8vY2EuYXBuaWMu bmV0OjgwODAvZWpiY2EvcHVibGljd2ViL3dlYmRpc3QvY2VydGRpc3Q/Y21kPWNybCZpc3N1ZXI9 Q049QVBOSUMlMjBTdGFmZiUyMENBLE9VPUluZnJhc3RydWN0dXJlJTIwU2VydmljZXMsTz1BUE5J QyUyMFB0eSUyMEx0ZCxEQz1DQSxDPUFVonikdjB0MRcwFQYDVQQDDA5BUE5JQyBTdGFmZiBDQTEg MB4GA1UECwwXSW5mcmFzdHJ1Y3R1cmUgU2VydmljZXMxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQx EjAQBgoJkiaJk/IsZAEZFgJDQTELMAkGA1UEBhMCQVUwDgYDVR0PAQH/BAQDAgTwMEsGA1UdJQEB /wRBMD8GCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwQGCCsGAQUFBwMVBgorBgEEAYI3CgMM BgkqhkiG9y8BAQUwGwYDVR0RAQH/BBEwD4ENZ2loQGFwbmljLm5ldDANBgkqhkiG9w0BAQsFAAOC AQEArDL8qy5Q85UmbpnkM1Gv6hiCTjwSbx5bp174KLHKw/B4i9c2wZcH4C2rmVTj9u5l/aghRK2v 6k0js8DoPIeCMehXGOvJYpf/etmk8lZIikemoNhDcAVQbhpEu38lCHaISX8QSiHBnsnAWIO/AcjJ WO90HA0gjcNGKncCkKbpPE/JvPQrEqrlqYif/h1khsmNaTCN4YxOTnfGL6vHRt0uLEafDW+eJQBx MbxBjm/REZJy3Z9i6ZVSqfSYtakrzIZDd49FLEhgMzt45R24hgD7OuOOwhzO+O+humiXljcU/Obb KD68/R3pB1hKKkxJHFmLvDW8AXxLRSTcWDKo7wr15zGCAzMwggMvAgEBMIGAMHQxFzAVBgNVBAMM DkFQTklDIFN0YWZmIENBMSAwHgYDVQQLDBdJbmZyYXN0cnVjdHVyZSBTZXJ2aWNlczEWMBQGA1UE CgwNQVBOSUMgUHR5IEx0ZDESMBAGCgmSJomT8ixkARkWAkNBMQswCQYDVQQGEwJBVQIICG65UzoT 6dwwCQYFKw4DAhoFAKCCAYcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTcxMjEzMDAwMzQ1WjAjBgkqhkiG9w0BCQQxFgQUcNXhLML/ufNUpXuAqZ0TSzGFcSUwgZEG CSsGAQQBgjcQBDGBgzCBgDB0MRcwFQYDVQQDDA5BUE5JQyBTdGFmZiBDQTEgMB4GA1UECwwXSW5m cmFzdHJ1Y3R1cmUgU2VydmljZXMxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxEjAQBgoJkiaJk/Is ZAEZFgJDQTELMAkGA1UEBhMCQVUCCAhuuVM6E+ncMIGTBgsqhkiG9w0BCRACCzGBg6CBgDB0MRcw FQYDVQQDDA5BUE5JQyBTdGFmZiBDQTEgMB4GA1UECwwXSW5mcmFzdHJ1Y3R1cmUgU2VydmljZXMx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxEjAQBgoJkiaJk/IsZAEZFgJDQTELMAkGA1UEBhMCQVUC CAhuuVM6E+ncMA0GCSqGSIb3DQEBAQUABIIBAH0GMnJmqS+WHV3qZZcBVUrr7XetCtBLAxzJxDiL MBlrorRab078G7aTsL6B+tIjANvri5AUi1Bv/0LY/SfP0a/6iQD9QKl1YnMV4zL5d5G0UBV3Q9n3 aWBNnELftGBU/TkkVAvKvcMeCk+UBj5QxCZcWO3aRv2SPkkq1fTxIIEo7yak1Yl6tP0K1fLyDqNx /sZ4YRyODuZLNrFqDue2wdIdkprsugiKLGOc5U20mEmRvJHw0voMIqXryRmSfNs1rDfHuj8MSYzY TMprSsmfqxhG0f4gsyD4jLL4hSxuWDblWU438YPyRGJzma7XZ0Eu87hxE8dPPnPwyB+GtegKhpwA AAAAAAA= --Apple-Mail=_40C581C8-3283-441E-8AB4-8747D7894D6A-- From nobody Tue Dec 12 23:41:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1156812751F for ; Tue, 12 Dec 2017 23:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.366 X-Spam-Level: * X-Spam-Status: No, score=1.366 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no 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 3552mvNICwA5 for ; Tue, 12 Dec 2017 23:40:58 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 058801274D2 for ; Tue, 12 Dec 2017 23:40:53 -0800 (PST) Received: from CNNIC-THINK (unknown [218.241.103.198]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CZoNyD2TBaldQ7AA--.30971S2; Wed, 13 Dec 2017 15:40:51 +0800 (CST) Date: Wed, 13 Dec 2017 15:40:50 +0800 From: "zuopeng@cnnic.cn" To: dnsop X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 166[cn] Mime-Version: 1.0 Message-ID: <2017121315404971736813@cnnic.cn> Content-Type: multipart/related; boundary="----=_001_NextPart338202861278_=----" X-CM-TRANSID: AQAAf0CZoNyD2TBaldQ7AA--.30971S2 X-Coremail-Antispam: 1UD129KBjvJXoW7ArW3Cr1xZryfJr4xAr1UKFg_yoW5JF13pF ZaqF4DJr1kJFW8GaykZw4kWFWFvFn3JFy7AFsxGrZIvr4YgFyavrWjkw4UuFsrAr47tr4S vrWqkr48AFn0yaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUULEb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487M2AExVA0xI80 1c8C04v7Mc02F40Eb7x2x7xS6r4j6ryUMc02F40En4AKxVAvwIkv4cxYr24l5I8CrVAqjx CE14ACF2xKxwAqx4xG6cxCj2AI6xk0xcxE6r17Mc02F40Ew4AK048IF2xKxVWUJVW8JwAq x4xG6xAIxVCFxsxG0wAqx4xG6I80eVA0xI0YY7vIx2IE14AGzxvEb7x7McIj6xIIjxv20x vE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xv r2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07MxkIec xEwVAFwVW8CwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02 F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_Jr ylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7Cj xVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI 0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxU k2jyUUUUU X-CM-SenderInfo: x2xr1vlqj6u0xqlfhubq/ Archived-At: Subject: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 07:41:01 -0000 This is a multi-part message in MIME format. ------=_001_NextPart338202861278_=---- Content-Type: multipart/alternative; boundary="----=_002_NextPart650556128501_=----" ------=_002_NextPart650556128501_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgIGV2ZXJ5b25lLA0KIA0KIEhlcmWhr3MgYSBwcm9ibGVtIGFib3V0IENETiB0cmFmZmljIHNj aGVkdWxpbmcuICBTbyBmYXIgYXMgSSBrbm93LCBtYW55IGJ1c2luZXNzIGNvbXBhbmllcyB1c2Ug bXVsdGktQ0ROIHRvIHNwZWVkIHVwIHRoZWlyIHdlYnNpdGVzIGFuZCB0aGUgQ0ROIHByb3ZpZGVy cyBoYXZlIHJlcXVpcmVtZW50cyBmb3IgcHJlY2lzZSB0cmFmZmljIHNjaGVkdWxpbmcgZXNwZWNp YWxseSBpbiB0aGUgcnVzaCBob3VyIG9mIHRyYWZmaWMuIA0KICAgICAgICANCiBBcyBDRE4gcHJv dmlkZXJzIHVzdWFsbHkgbWFuYWdlIGF1dGhvcml0YXRpdmUgRE5TIGZvciB0aGVpciBjbGllbnRz LCB0aGUgbW9zdCBjb21tb24gbWV0aG9kIGZvciByZWFsLXRpbWUgdHJhZmZpYyBzY2hlZHVsaW5n IGlzIHRvIGNoYW5nZSB0aGUgQSByZWNvcmRzIG9mICBDRE4gbm9kZXMuIEl0IGRvZXMgaGF2ZSBz b21lIHBvc2l0aXZlIGVmZmVjdHMuIEJ1dCBiZWNhdXNlIG9mIHRoZSBsYWNrIG9mIEROUyBwcm90 b2NvbCBzdXBwb3J0IChlc3BlY2lhbGx5IG9uIHRoZSByZWN1cnNpdmUgc2VydmVyIHNpZGUpLCBh IENETiBjb21wYW55IGNhbqGvdCBzY2hlZHVsZSB0cmFmZmljIHZlcnkgcHJlY2lzZWx5LiANCiBG b3IgZXhhbXBsZSwgYSBDRE4gcHJvdmlkZXIgY2Fuoa90IHNjaGVkdWxlIDcwJSBvZiB0cmFmZmlj IHRvIG5vZGUgQSBhbmQgMzAlIG9mIHRyYWZmaWMgdG8gbm9kZSBCLiAgRXZlbiB0aG91Z2ggaXQg cGxhY2VzIHRoZSBhZGRyZXNzZXMgb2YgYm90aCBBIGFuZCBCLCBpdCBjYW6hr3QgZGV0ZXJtaW5l IHJlY3Vyc2l2ZSBzZXJ2ZXKhr3MgcmVzcG9uc2UgdG8gY2xpZW50cy4gRm9yIGV4YW1wbGUsIHNv bWUgcmVjdXJzaXZlIHNlcnZlciBtYXkgcm91bmQtcm9iaW4gdGhlIGFkZHJlc3MgdG8gY2xpZW50 cy4NCiANCkZvciBiZXR0ZXIgcHJlY2lzZSBDRE4gdHJhZmZpYyBzY2hlZHVsaW5nLCBJIGhhdmUg YW4gaWRlYSB0aGF0IGRlZmluZXMgMyBuZXcgcmVjb3JkcyBmcm9tIGV4dGVuZGluZyAzIGV4aXN0 aW5nIEROUyByZXNvdXJjZSByZWNvcmRzOiBBLCBBQUFBIGFuZCBDTkFNRSwgYnkgYWRkaW5nIGEg obB3ZWlnaHShsSBhdHRyaWJ1dGWjrGFzIGJlbG93Og0KICAgWzxvd25lcj4gPHR0bD4gPGNsYXNz PiBDTkFNRSA8dGFyZ2V0Pl0gIC0+IFs8b3duZXI+IDx0dGw+IDxjbGFzcz4gQ05BTUVYIDx3ZWln aHQ+IDx0YXJnZXQ+XSANCiAgIFs8b3duZXI+IDx0dGw+IDxjbGFzcz4gQSA8YWRkcmVzcz5dICAt PiAgWzxvd25lcj4gPHR0bD4gPGNsYXNzPiBBWCA8d2VpZ2h0PiA8YWRkcmVzcz5dDQogICBbPG93 bmVyPiA8dHRsPiA8Y2xhc3M+IEFBQUEgPGFkZHJlc3M+XSAgLT4gIFs8b3duZXI+IDx0dGw+IDxj bGFzcz4gQUFBQVggPHdlaWdodD4gPGFkZHJlc3M+XQ0KIA0KVGhlIHJlYXNvbnMgZm9yIGRvaW5n IHRoaXMgYXJlIDoNCigxKSBCeSBhZGRpbmcgobB3ZWlnaHShsSBpbiBDTkFNRVgsIGEgbXVsdGkt Q0ROIHVzZXIgY2FuIG1hbmFnZSB0aGUgdHJhZmZpYyByYXRpbyBhbW9uZyBkaWZmZXJlbnQgQ0RO IHByb3ZpZGVycyBieSBpdHNlbGYgZWFzaWx5Lg0KKDIpIEJ5IGFkZGluZyChsHdlaWdodKGxIGlu IEEvQUFBQSwgYSBDRE4gcHJvdmlkZXIgY2FuIG1hbmFnZSB0aGUgdHJhZmZpYyByYXRpbyBhbW9u ZyBkaWZmZXJlbnQgbm9kZXMgYnkgaXRzZWxmIGVhc2lseS4NCiANCiBGb3IgY29tcGF0aWJpbGl0 eSwgYW4gYXV0aG9yaXRhdGl2ZSBzZXJ2ZXIgc2hvdWxkIHBsYWNlIHRoZSBDTkFNRVgvQVgvQUFB QVggcmVjb3JkcyBpbiBhZGRpdGlvbmFsIHNlY3Rpb24gaW4gYSBETlMgcmVzcG9uc2UgZm9yIGEg obBBL0FBQUGhsSBxdWVyeS4gQSChsHdlaWdodC1hd2FyZaGxIHJlY3Vyc2l2ZSBzZXJ2ZXIgc2hv dWxkIG1ha2UgdXNlIG9mIHRoZSChsENOQU1FWC9BWC9BQUFBWKGxIGluIHRoZSBhZGRpdGlvbmFs IHNlY3Rpb24gdG8gbWFuYWdlIHRoZSBhbnN3ZXIgdG8gY2xpbmVudHMgYWNjb3JkaW5nIHRvIHRo ZSB3ZWlnaHQgb2YgZWFjaCBSUi4gQSChsHdlaWdodC1ub3QtYXdhcmWhsSByZWN1cnNpdmUgc2Vy dmVyIGNhbiBqdXN0IGlnbm9yZSB0aGVzZSBSUnMgYW5kIHN0aWxsIHdvcmsgbm9ybWFsbHkuDQog DQogSGVyZSBpcyBhbiBleGFtcGxlOiAgSWYgYSBDRE4gcHJvdmlkZXIgY29uZmlndXJlcyBBWCBy ZWNvcmRzIGZvciChsHd3dy5leGFtcGxlLmNvbaGxIGFzIGJlbG93IHdoaWNoIGluZGljYXRlcyCh sDEuMS4xLjGhsSBzaG91bGQgYWNjb3VudCBmb3IgODAlIGluIHJlc3BvbnNlIHdoaWxlIKGwMi4y LjIuMqGxIGFjY291bnRpbmcgZm9yIDIwJS4gIEEgobB3ZWlnaHQtYXdhcmWhsSByZWN1cnNpdmUg c2VydmVyIHNob3VsZCByZXBseSB0byBjbGllbnRzIGFjY29yZGluZ2x5Lg0KICAgICAgQW55IGNv bW1lbnQgb3IgYWR2aWNlIGlzIGhpZ2hseSBhcHByZWNpYXRlZCENCiAgICAgVGhhbmsgeW91ISEN CiANCg0KDQoNCnp1b3BlbmdAY25uaWMuY24NCg== ------=_002_NextPart650556128501_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable =0A
= =0A=0A=0A=0A=0A=0A=0A=0A

Hi  everyone,

=0A

 

=0A

 Here=A1=AFs a prob= lem about CDN traffic=0Ascheduling.  So far as I know, many=0Abusiness companies use= multi-CDN to speed up their websites and the CDN=0Aproviders have require= ments for precise traffic scheduling especially in the=0Arush hour of traf= fic. 

        

 As CDN providers usually manage aut= horitative=0ADNS for their clients, the most common method for real-time t= raffic scheduling=0Ais to change the A records of  CDN nodes. It does= have some=0Apositive effects. But because= =0Aof the lack of DNS protocol support (especially on the recursive ser= ver=0Aside), a CDN company can=A1=AFt schedule traffic very precisely.&nbs= p;

 For example, a=0ACDN prov= ider can=A1=AFt schedule 70% of traffic to node A and 30% of traffic to no= de=0AB.  Even though it places the addresses=0Aof both A and B, it ca= n=A1=AFt determine recursive server=A1=AFs response to clients. For example, some recursive server may=0Around-robin the address = to clients.

=0A

 

=0A

For better precise=0ACDN traffic scheduling, I have an i= dea that defines 3 new records from extending=0A3 existing DNS resource= records: A, AAAA and CNAME, by adding a =A1=B0weight=A1=B1=0Aattribute=A3=AC= as below:

=0A

   [<owner>= ; <ttl> <class> CNAME <target>]=0A ->&nbs= p;[<owner> = <ttl> <class> CNAMEX <weight>=0A<target= >] 

=0A

 = ;  [<owner> <ttl> <class> A <address>]=0A&nbs= p;->  [<owner> <ttl> <class> AX <weight>=0A<address>]

=0A

   [<owner>=0A<ttl> <class> AAAA <address>]  ->  [<owner>=0A<ttl> <class> = AAAAX <weight> <address>]

=0A

 

=0A

The reasons for doing this are :

=0A

(1) By adding =A1=B0weight=A1=B1 in CNAMEX, a mu= lti-CDN user can=0Amanage the traffic ratio among different CDN providers = by itself easily.

=0A

(2) By adding =A1=B0weight=A1=B1 in A/AAAA, a C= DN provider can=0Amanage the traffic ratio among different nodes by itself= easily.

=0A

 

=0A<= p class=3D"MsoNormal" style=3D"line-height: 15.75pt; margin: 0cm 0cm 0.000= 1pt; text-align: justify; font-size: 10.5pt; font-family: Calibri, sans-se= rif;"> For compatibility, an authoritative server= should place the=0ACNAMEX/AX/AAAAX records in additional section in a DNS= response for a =A1=B0A/AAAA=A1=B1=0Aquery. A =A1=B0weight-aware=A1=B1 rec= ursive server should make use of the=0A=A1=B0CNAMEX/AX/AAAAX=A1=B1 in the = additional section to manage the answer to clinents=0Aaccording to the wei= ght of each RR. A =A1=B0weight-not-aware=A1=B1 recursive server can=0Ajust= ignore these RRs and still work normally.

=0A

 

=0A

 Here is an example:  If a CDN provider= configures AX=0Arecords for =A1=B0www.example.com=A1=B1 as below= which=0Aindicates =A1=B01.1.1.1=A1=B1 should account for 80% in response = while =A1=B02.2.2.2=A1=B1=0Aaccounting for 20%.  A =A1=B0weight-aware= =A1=B1 recursive server should reply to=0Aclients accordingly.

=0A

=

=0A

      Any comment or advice is highly appreciated!

     Thank you!!

=0A

 

=0A
=0A

=0A
zuopeng@cnnic.cn
=0A<= /html> ------=_002_NextPart650556128501_=------ ------=_001_NextPart338202861278_=---- Content-Type: image/png; name="InsertPic_.png" Content-Transfer-Encoding: base64 Content-ID: <_Foxmail.1@84e99d90-6022-97b1-dcf6-d1d7c2a7401b> iVBORw0KGgoAAAANSUhEUgAAApEAAANTCAYAAAD2fEbAAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAGiJSURBVHja 7d19kBznYd95VAHF2gKKVfrvVHUVCwWXLSamKNCSbKrqIvNy+oOWIR5kHo8AF5Rg+46FJEwZqpMN QBAiiCBF5qAEjhQRIheMSoojJKHPerlzIEWOIcU5b3KRvJbJwdo5USyVIiOmLK0oUgJtXtXcPDO9 2NnZeelnprunXz6/qm/hZXamu5/u7f7O87rtAx/4wDYAAAAgBoUAAAAAEgkAAAASCQAAABIJAAAA EgkAAAASCQAAAJBIAAAAkEgAAACQSAAAAJBIAAAAkEgAAACARAIAAIBEAgAAgEQCAACARAIAAIBE AgAAACQSAAAAJBIAAAAkEgAAACQSAAAAJBIoDTtvWGjv2nVjW1k0hxt3LrQXFpxzACCRUz5Etm/b 1t42lB3tnaSiROcmn/Nx48KO3udvn59E7rph+5bj3Lmws731tQ2237Dr+r7euGtXe2F78tqOne2h xzfnY8z1Wrl+/Omukf5raweJBAASOfXDe+DBuv7Q9XBJHs47iheP3kN+e3thZ2+7N+7a2d4xIE5Z Hkf3nM9JsHbu2Cw/68favz+D+zfsZ/qFc/DaDT+/MGXZ1VEi+9/j9xwASGQmYnH9YVTTGpv4MurI yhzKoitDAzVqeR7HvCSyJ31bxad3HfaJ5ZD9GybWu25YaO/YsW3oz9ZZImcRTxIJACQymweLWshN 7NyxbX5ylaFETjqOeUjk9S8sI44z7NP6dThq/wYlNEjkzkQu+69hEkkiAYBE5vpQSZoIRz3U+/ud Demjt7lv3eafHdUM22vKXGej+XYmWRrxedf71g1rFt3UdDx4nNsy6VM3sfyu70s2/VNjjmND0jbv Q57nbb1fXhqJGSWRvWtuY/s9ibyxPSiX00jkputloH/qpv6Y/X0uk21uOpfbR9T2T/o9Gnhto8y3 dnOYdL6GbXf7DTtHSuS48xt7vACABkhk76E5XAiGNx1uH/4A3L59c3++gf59o2pBetuYUkiG1Gr1 HnbD9m9Ys+iI486ohi5t+W16Lcvm7AnHsXHe+sQr5/M2KIBTSeSAiK5L5GB5T1sTObRcRvRP7e1L 5+fW/wz7MXANpv49Gln2o79MhM8ZJZGjtzt4LtOf3zTHCwBogEROqoXs1kwMeW3w/4eK27AHU+fn hj3wppWn0QOEhtSizEEi05bfXCWy4POWp0QOfv5MEjmsz+aw62i9tnJMOcdcB+H/tsjcmDIeJ5FD fz9mPL9pjhcA0ACJTFMLOazZa0tNy1BJ2/qw2txcNnuTcfi8NCOX5yGRMeU3V4ks+LzlLpF9tdOz 1USO2u7k2sNZroPBbe+6YcfYshonkcN+P2Y9v5OOFwDQAImcNH3MWMkaeJimkZH1f2/PaKBDzOfN TyLTlV+ZJTLz85Zjn8jNr4dt5CGRA7XcI87ltNdB/8+nmWpqlESOOm+znt9JxwsAaIBEjuubF1uD ElWjlfHoYzWR+Upk1udt4peXhYWNfrXjRmdvqq1b2FKWvZHp29s7CqmJzOb3aPC6Dp89af9nlcjY 80siAaDhEjnuQb5zx+aRoWn6SqWVkdHzA05XYzSsz9f1bd+wM7M+kdPuX9ryK0oiB49jXudt1NRD gzVvMfNE7hzR5L09Q4kc2scwhVTFXgfrn7kwoSl7nESO+vxhUhtzfkkkADRcIkc9NLbI4bC591KP fh424nPrpOa9bUz3UBo2MKi3jWFNjsOm80nXzLgrxcM8bS3UuJGsmUvkhOMo33kbUlb92xwxqGOY RI6Tt1QSuW3Y4LEhq+KkkKrY62DSXJppJXLYdtf7P057fkkkADRYIsevmz186bgd2+Lmtxs3j92k +fLihWTw84aL4ea1mMPPbOzjpDnzZukPOKn8tu5bdvNnjjuOsp+3UWtnD5WfMdfuTH0iN5XRuHkT J18raa6DwWtiVL/R0XOLDq9N3LGp/DbKLOb8xh4vAKCmNZEAUkik2jYAAIkEQCIBACQSQC5s7fZA JAEAJBIAAAAkEgAAACQSAAAAJBIAAAAgkQAAACCRAAAAIJEAAAAgkQAAACCRAAAAAIkEAAAAiQQA AACJBAAAAIkEAAAAiQQAAACJVAgAAAAgkQAAACCRAAAAIJFlY8++Y6/eve/E7QlHd995/DQAVJ7k vrZn38mbPOwAkMisxPEdJ3cHYdy7eGbl5ntO/3Dfuz+yFjj1sc+9fO5TX2wDQNVZv6/97OEPvvA3 /uf3f+ev3/3+x/bccXKvBx8AEjkF4Vv56+99cPXWxTMvBmFc/uNn2yIidc+3/vx77Sc/++/bb7n/ 7PeDUN5096n37HnrowseggBI5KSax8637444Lodv5X/4J9/0RBGRxiYI5cnHPvvSLQc/cHX3244d 8CAEQCKHyWPnm/ZP3/fwk+Hb95e++qeeHiIiSYJM/spDn3whtM6ELj4eiABI5LpA7jv26je+8+Gn H//tf/cjjwsRkeEJrTNv/uVHnw/dfTwUATReIjsCedvPHH7kqqZrEZHJeeGla92BOLcuPnjCgxFA YyXy1vsevPPnf/Uff+f57/3Ak0FEJCLv/ehnXnjzLz3yGx6OABonkWE+tJ+7/0P/NXyrFhGR+Lz7 3L9ae8Pig+/2gATQGIncc/fpV73hnQ//l9BZXEREpsvLf/lKe/97HvuOPpIAGiGRYRT2m9758H8y 76OIyOwJrTlhsI1R2wBqL5Fh4tww75lbv4hINmk9+2ftW+598BselABqK5GhFvLme05/10AaEZFs s3jqye/v3ndiv4clgFpK5BvuO/Ohf/DJz7/odi8ikm3URgKorUSGCcX33vvgC6EjuIiIZB+1kQBq KZGdG9uRX/vwb/3QbV5EJJ+EAYt7F8+seGACqJVEhhubEdkiIvnm5ntO/zC0/HhoAqiFRIYbWrix ub2LiOSbB85efHH3vhOHPTQB1EIiNWWLiBSTL331T9u3Lp5Z9tAEUAuJ3HvozO987st/5O4uIpJz wuDFH9//3lc8NAHUQyL1hxQRKSyvvevUy2F5WQ9OAJWXyNcdOP3tr3/reXd2EZEC8rOHP/jCnn0n b/LgBFB5ifyJX3zfj8L6riIikn/2vfsja7v3nbjdgxNApSUyLHUY+ue4rYuIFJNfeeiTL+x+27ED HpwAqi2R7zi5+9bFM5Y6FBEpKKb5AUAiRUQkOiQSAIkUEZHokEgAJFJERKJDIgGQSBERiQ6JBEAi RUQkOiQSAIkUEZHokEgAJFJERKJDIgGQSBERiQ6JBEAiJSrbtm27Tt2PM00ZjPq5vMpocNv92xi2 zbzOV97nf9bPr/r7q5AHzn6KRAIgkeIh2X9ck+Rw0v8Nil2R5T9KJKty/meV3qq/v0ohkQBIpJRK Isp+fJMkMo1k5r1/RUlknteAmsjyh0QCIJHiIRlxfFWQyDT7lMW2SWRzfz9CSCQAEjlw4x98QI7q gzbN67H7Ma6P27jPntRnbtw+D/t77EMyTZ/BmDJI+/mTji8PCUhT60cimyeBJBIAiWygRI77+6yv T/vwielzF1NTNuoY0uz7LH0GY8sgpqYvi3MQ8/NllchR12XW2y66z2dT3l+FkEgAJDJCRoqSyDQ1 aWlqCkfV1sUKR4wYzVoTOOlnyySRs5ZVHpJSlETmPYCERJY/JBIAiRxy48/rzywfPjEjiIuWyDwf vmWRyDxrYmfZv7wlsohBO0VcR2V/fxVCIgGQyCE3/ipLZBbN2bOIURMkMva1eUnkuOsky+2WcQoh Epl/SCQAEpniIZz1v2eVkLz7RE4jKzHbjxXFMvWJrMI8kTHXWxbbnfcURlV6f51CIgGQyAghyOrf aSQqzcjrUZ83bpTyuNHYk7Y96rOn2f8052GW0dmjji9muzFlO61sTHN9pj3+rIUmZpt5HF+aci37 +0kkABJZY4lseppQgyIis4dEAiCRcj1NWrJNRGYLiQRAIkVEJDoPnL1IIgGQSBERiQuJBEAiRUQk OiQSAIkUEZHokEgAJFJERKJDIgGQSBERiQ6JBEAiRUQkOiQSAIkUEZHokEgAJFKi0pQJyWOWthv3 M3mW/6glCIs4X3me/1mXDaz6+6sSk40DIJFSOomY93FNksNJ/zcodkWWf55rZxdx/tOUb53fX6WQ SAAkUkolEWU/vkmSUJRElEEiizouElnOkEgAJFIylZi6H18VJDLNPmWxbRKZ/furFBIJgEQO3OwH H5Cj+qBN83rsfozr4zbusyf1mRu3z8P+HiMxk/Z/mjJI+/mTji8LSZv0cySymONsyvvLHBIJgESO uOEP+/usr0/70InpcxdTUzbqGNLs+yx9BmPLIKamL4tzEPPzZZXIUddl1tvOW5JIZHlDIgGQyAgZ KUoi09SkpakpHFVbFyscMWI0a03gpJ8tk0TOWlZ5yElRElnE6GMCWe6QSAAkcshNP68/s3zwxIwg Lloi83zwlkUi86yJnWX/8pbIIgbtFHEdlf39VQiJBEAih9z4qyyRWTRnzyJGTZDI2NfmJZHjrpMs t1u2OSgJZDEhkQBIZIqHcNb/nlVC8u4TOY2sxGw/VhTL1CeyCvNExlxvWWy3yM+f9fdn3u+vU0gk ABIZIQRZ/TuNRKUZeT3q88aNUh43GnvStkd99jT7n+Y8zDI6e9TxxWw3pmxHfU4e8pj2+LOWmJht Znl8sRJX5veTSAAkssYS2fQ0pSlORGYLiQRAIuV6mrIutojMHhIJgESKiEh0Hjh7kUQCIJEiIhIX EgmARIqISHRIJAASKSIi0SGRAEikiIhEh0QCIJEiIhIdEgmARIqISHRIJAASKVFpylySMauSjPuZ PMs/zWoqeZ2vSSsJ5bn9IlaDsX735JgnEgCJlNI+pOZ1XJPkcNL/zXvt7LyWPUy7/TyvlSI+fxY5 rfr7Y0IiAZBIyVQi6n58kyQmb8lJs39FSWSaMiqqBrRs17eaSAAkkkTKHB9SZTy+Kkhkmn3KYtsk sr7vTxMSCYBEDtx4Bx+Qo/qgTfN67H6M6+M27rMn9Zkbt8/D/h77kMqiz9q49097fHk8hNPU+jVN ItNcP1kduz6R+bw/TUgkABKZ4uE06cGc9vVpb/4xfe5iaspGHUOafc+zT1xsH8OY48v6IVxWiRx1 XWa97aIHFhX5+U1+f5qQSAAkMkJGipLINDVpaWoKR9XWxQpHjBjNWhM46WfLJJGzllUeklCURM5r dPqs57UqEkciAZDIikpkXn9mefOPGUFctETm+fAri0TOa3RyzPbzkMhZar7zOm59ItuFlMlgSCQA EjnkxltlicyiOXuWB3cTJDL2tXlOsZPHHI1ptpnXsZPIYt6fJiQSAImMeCBm9e9ZJSTvPpHTyErM 9mNFsUx9IqswT2TM9ZbFdoscnV7GKZSq9P4sQyIBkMgIIcjq32kkKs3I61GfN26U8rjR2JO2Peqz p9n/NOdhltHZo44vZrsxZTvtw36a6zPt8WctFDEj4tOcx6zKoKjyTXNey/5+EgmAROYokU1P3ed/ FJFsQiIBkEi5nqasiy0is4dEAiCRIiISnQfOXiSRAEikiIjEhUQCIJEiIhIdEgmARIqISHRIJAAS KSIi0SGRAEikiIhEh0QCIJEiIhIdEgmARIqISHRIJAASKVFpyoTkMUvLjfuZPMt/1BKDRZyvSctR 5rn9vJf1m/Xzq/7+tDHZOAASKZlLVtWPa5IcTvq/QYkqsvzzXDs77fbzvFbK/vlVf39MSCQAEimZ SkTdj2/SQ7qoh3gZJDJNGRVVA1qWzyeRAEgkiZQpJabux1cFiUyzT1lsm0TW7/0xIZEASOTAzXbw ATmqD9o0r8fux7g+buM+e1KfuXH7POzvMRIzaf+nKYO0nz/p+LKQtEk/RyLbqa6fvMuhLJ9f9feP C4kEQCJH3HCH/X3W16e96cf0uYupKRt1DGn2Pc8+cbF9DGOOL+uHb1klctR1mfW2ix5YVKQkZfH5 JBIAiSSRmbyedh/S1KSlqSkcVVsXKxwxYjRrTeCkny2TRM5aVnnIQVESOa/R6UUJUhkErswCGUIi AZDIITfdvP7M8sYfM4K4aInM88FXFomc1+jkmO3nIZGz1HwXcfxl+fy6C2QIiQRAIofceKsskVk0 Z88iRk2QyNjX5jnFTh5zNKbZ5jyOvSyf3wSBDCGRAEhkxAMxq3/PKiF594mcRlZith8rimXqE1mF eSJjrrcstlvk6PR5f/6sv7/zfn+WIZEASGSEEGT17zQSlWbk9ajPGzdKedxo7EnbHvXZ0+x/mvMw y+jsUccXs92Ysh31OXnIY9rjz1oiYkbEpzmPWR1/nqvhpFkVqErvJ5EASGSOEtn01H3+RxHJJiQS AImU62nKutgiMntIJAASKSIi0Xng7EUSCYBEiohIXEgkABIpIiLRIZEASKSIiESHRAIgkSIiEh0S CYBEiohIdEgkABIpIiLRIZEA6iGRb3104cf3v/cVt3URkWLyKw998oXdbzt2wIMTQKUlMvATv/i+ H73w0jV3dhGRArLv3R9Z273vxO0enAAqL5GvO3D621//1vPu7CIiBSR0IQpdiTw4AVReIvcunllZ /uNn3dlFRArIa+869fKeu0+/yoMTQOUl8paDDz711O9+xZ1dRCTnvPyXr7RDP3QPTQC1kMgwSjCM FnR7FxHJN1/66p+G5uxlD00AtZDI0KwSmlfc3kVE8o3pfQDUSiID+kWKiOSb0JT9U/e8/yX9IQHU SiI734yP/NqHf+uHbvMiIvlEUzaAWkpkmHT85ntOf/f57/3AnV5EJIcsnnry+50v7Ps9MAHUSiID N9196j0nH/vsS271IiLZpvXsn7VvuffBb3hYAqilRKqNFBHJJ2+5/+z399xxcq+HJYBaSqTaSBGR 7POF5VZ77+JDv+dBCaDWEhl44zsf/vLn/+CZv3LrFxGZLd/68++13/xLj35zz75jr/agBFB7iQzN 2j996KH/HPrwiIjIdAlT+vytv/2P/kIzNoDGSGRXJN9xcvd/97/879/WP1JEZLocfN+F7958z+m7 PSABNEoiuyLZ+fb85l9+9Pmvf+t5TwMRkZQJNZBBIN/0rof+jocjgEZK5HqN5M+864Pf+L2v/Mlf ejSIiIxP6AMZmrDVQAJovER2RfLu0696w30P/ceP/It/ey18wxYRka0JS8d2B9HoAwmARG7m9Ytn Pvymdz289tTvfsXTQkQkSRiEuO/dH1nbu3hmxShsACRyTPP2LQcffCpMnPu5L/9RW82kiDQ1oeYx LGUYVqLZve/E7R6EAEhkGpm84+TevYfO/M5P3nXqWriJhtrJF1665qkiIrVOEMdf+/Bv/fDme07/ MNQ8WgsbAImcVibf+uhCuImG2smf+MX3/eg1bz/ebdYJ/MpDn3zh3Ke+2AaAKnLqY597ef1+FqQx 3N8ScTyi2RoAicyB0KzT5W3HDuy+8/hpIA9ufueHfuO/f+9v/1/KArmx78TR9fsZaQRAIoGacOhC 69OLS62r9z/+7ILyAACQSAATOfh4a29HINuBg4+v7lcmAAASCWAiHXm8tC6RHVaUCQCARAIYS6h5 7BPILvc92bpD2QAASCSAkYSax0GJDP0jlQ0AgEQCGMqwWsiNvpGtvcoIAEAiAWzh0IUrFzvCuDxU JC+0Pq6MAAAkEsBYgjR25PGwsgAAkEgAJBIAQCIBkEgAAEgkUCaJXLpy+b6lp29XFgAAEgmARAIA SCQAEgkAAIkESCQAACQSqLREXmg9d/Cjrd3KAgBAIgGQSAAAiQRAIgEAIJFAmSRyqXWVRAIASCSA WIlsKwcAAIkEQCIBACQSAIkEAIBEAiXi/sefXehI5DVlAQAgkQBSEwbUhNHZygIAQCIBkEgAAIkE QCIBACCRmDs7d2xrb9s2yI72zl03tof93PYbdm39/x07r//fjTsX2tv7PmvHwo2VGahy8PGv3bS4 1Fp1XQAASCSQRiL7JHBDGLe3F3ZuCOCGbG4WzP7337hrZ3tHn2jeuGtXe2H7ViEtK/ctPX37wSeu XHZdAABIJDCFRF7//+0L7V2JAPZ+bqEjhZtrIzdJZLcWcrN8VgkSCQAgkcCMEjkohOs/d+PCjk21 kcNqIod9HokEAIBEogkSmQjhep/G6xLZbaLeeM+WPpFdyRzef7LsHHx8df+9Tzz9adcFAIBEAhlL 5IYo9mopR71/1w3bRw7SKSuLS63DixdaH3ddAABIJDCtRI5ozu4J5kZt5Kj3b3xGdWokSSQAgEQC M0rk8IE1g83W29vbt4+RyEQ2SSQAACQSDZDIkVP89Evkem1k30CabhP2ENGsymjtjkQePbj0zDnX BQCARAJpJHJwsvG+Gshxsnl9YvG+/9/8edWa7ufQUut0wHUBACCRAEgkAIBEAiCRAACQSKBELC61 zod+kcoCAEAiAaSXyAutj4cR2soCAEAiAZBIAACJBEAiAQAgkUCZJHKpdem+J1t3KAsAAIkEECGR Vy7ft/T07coCAEAiAZBIAACJBLKktyzhjvbOXdVZVSZPDj5BIgEAJBKYyLClDBsl0d31vzeWZly8 8MxzBx//2k2uDQAAiQRGCtTO9o6KrW2deRmEmti+dcK7EvnR1m7XBwCARAIj2HXD9k0C1URCTez2 G3ZdP34SCQAgkSgNN+5caG/ftq29rcuO9s7uv3v9EHvNqdvaOxY2RG6wn+L6z2zr/4zrryW1iQvr 29je3h5+dkAOB4Vx/TPXBWrY54QaynHb3tjXvteTbWw0E4fPXX99c63n+ONaL5cx7x+x7UmfvbH9 rTWxJBIAQCJRDoFcl5mk32FPXDakZpJEDr5/UAgHP2/j/RtyNCiMG2I7KKPDRW7ktrufMbw5fEPi Nl7vvnfMcXX7Zw6+3vf+7usx2x6x35vKeeD/FpdaBhgBAEgkSiCRQ2RnmCSOlMhh7++rQVuXv03v H6xlHPIZgwNqhn5Oym33y+ngPmzer41tDBsVvun1iXI9ZtsT9ru/DPo/n0QCAEgkyiORw2QpWiK3 bW62TejJ1lb5C/TXvG1tyh4mnqMkcvS2+9832Nyct0SO3Xbq/d7axE0iAQAkEuWQyBxqIjd9/giJ 3Pj/yTI2XiLTj97ub0Yfelx9n5eFRI7cdor97or1kKmNSCQAgESiHBI50Oy6UUu2IUP9Tcuj+kyO mstxlERe/9whg0oGRySPlMgJ2x4nzJP7RCbHOdgnctPAnAiJHLbtkWW29bMDYUBNGFjjugUAkEiU QyQHR2ePbZbdPHp7k8xt2zraeJxEXh+93N/3cUQt3egazTHbHhwdvam5OMXo6k3HPXx09cga2jHb nrjfA+VLIgEAJBLVkMqClhocJoxFzQ05qravDIxqyiaRAAASCRL5gdFzQxYhdmWVyMFlDjdJ5ONf u2lxqbXqGgUAkEg0ViKHzQ1ZvKyVsyZyFPctPX37wSeuXHaNAgBIJIAoiVxcIpEAABIJgEQCAEgk gFwl8snWHYtLrUvKAgBAIgGkpiOQhxcvtD6uLAAAJBIAiQQAkEgAJBIAABIJlEsij3Y4rywAACQS QGoOLbVOB5QFAIBEAiCRAAASCYBEAgBAIoESsbh05VzoF6ksAAAkEkB6ibzQ+ngYoa0sAAAkEgCJ BACQSAAkEgAAEgmUiEMXWp8++PjqfmUBACCRAFKzuHTl8n1LT9+uLAAAJBIAiQQAkEgAJBIAABIJ lEoiW6sHH//aTcoCAEAiAaSXyAut5w5+tLVbWQAASCQAEgkAIJEASCQAACQSKJNELrWu3f/4swvK AgBAIgHESGRbOQAASCQAEgkAIJEASCQAACQSKBFhQE1HIq8qCwAAiQQQJ5EXWs8pCwAAiQRAIgEA JBIAiQQAgEQCJeK+padvX1y6cllZAABIJAASCQAgkQBIJAAAJBIgkQAAkEigyiwutQ4vXmh9XFkA AEgkABIJACCRAEgkAAAkEiiXRB7pcF5ZAABIJIDUHFpqnQ4oCwAAiQRAIgEAJBIAiQQAgEQCJWJx qfVIh+PKAgBAImvOjQs72tu2L7R37bqx3f33zoX29m3b2ws7e/9Gw66H7vnf1t62bUd7Z+ea2Ph3 umsijMwOI7SVJQCARNaYXTdsb2/bsbO9SSD6hLJq7Lyhuvteqi8VXWnc1t6x0JHIgX+TSAAAiSzr Q3zXzvaO8NDuk7tctjMgjL3t9mqfij3eXe2F7Rs1XzOJT4UFuHzX4Mb56J2jdOen6RKZxfUMACCR U8vdju3bcxeibi1kn3ht1DgV25Sd1UN3sFk+1XZ3kM5R18b2G3a1+8u2/9/juPeJpz/dkcgDJJJE AgCJLPwBvqMjcaEmKF+Z27lj2yZpjG22LN3DO1oiO2Ws5nL4l5h+gQw11hG14gefuHL5vqWnb1eW AAASWTA7d4QajF5tRp4yt95s3l/D1BXLiopVrERW+VjzFMgtXRwiy4hEAgBI5Dwe4uGhndT6DA56 mes+JTWUXenaVGO53nS3tfluo6ZzeBP5ps8dkNmx+5D0F13//HXR3pDI0Z+70dQ4hBmEsr8Wd/B4 pym/cZ+39fVkFPXgdgaOZdL5yIogkXnu37ifG+yisbn8+85J5P4NXn+9AUc7N13vaa7nYdvdfExb jzvL85bmONJsN235ZX2801xXANAciexrSuzdMMvRr6p3o964ofcL7mDfwhuH1KIOvn+QwT54wx58 12Ux+fzBn+9JZOdz+mVszHRF42out0rcVtb3p1sWg9IxOG1SRPml+bxNNYfheNf/vP7gHhwUE3c+ ZmFxqbVy8PHW3qz37/oXgP7ZBIb8jgwrq1HHm37/Nr+3JzpTXs9DrslhA5eyPm9pjyNmu6nKL4fj TbNdAGicRPb6Qw4Xj3kTHjhba/16NQELKQZhjKtZHfvQHSYFo/5v2+QHUxqJjC2XweO6se/hFlt+ aT9v4//H18BMcz5iuP/x1qvDCjUdeTwSmrE7f14NA2vC37Pcv5FyPay2KkoiJ+zfiCb9/t/VmOt5 8Fq4vo3Bc57xeUt7HDHbTVN+eRxv2u0CQGMkcvDb+agat/kJ7saDsddsuFED0P+A2Nwcla7JODOJ 3CIP+UvkZlHZNrT5Lqb80n7eqFqeoZK7Lfsm/IHaxyCO7UGy3L/wc2l+F+IlcvIXtcGuEzG/K2n2 cZiQ5nHe0hxHzHbTll/Wx2tBBAAkcqI0bPT/K8X+XR90EZpfO+KTyNmuGxZmFt/smrOLl8jBFV5G 1RymKb+Yzxv3/4PHn/cXkY4wHh0tkbPvX8xxTNWcneIaiOl7N1Ei+/Zn2FRTeZ638X0/47abtvyy Pt6Y8wYAzZDIITVS5esX2euHFPpt9h6UO7c8EIY1x85ac3N9wMQYsZ6HRI4U2mESmaL8Yj4v7cN0 mvMRy/2PP7swrDYyy/3LryYy/verdz1un7o5u/94BqdUKvK8DTuOmO3GlF+Wx0siAZDILTf0HSNG MJerX+T27Ts25pXcvn3LA6G/qXbwWBZGPFgnNmeneLjMKpHj9m/8wyy9nEwqv9jPS/MwneZ8TEPS L/K6QIZJx7Pcv2F9Iq+f4xt2zjawZsz+jepuMO6aTSOR69teGNG3MuvzlvY4YrYbVZOb4fGSSAAk ckuN1rAbaPn6RfYPCNkxpH/V9VG0EUsqpmnOntQnLFoiBx5E4wZKjD5vW+fa3Njf8NmbBxBMKr/Y z0slQVOcj2kIA2zufeKZa+sSGUZoZ7l/w5YDHTbieFDEN6Z1ml4i04xgjpbIIaPN8zxvaY8jZrtx 3QGyO14SCYBEDt48B/vBDc5pWIY5I/tWLxm3nvLW+RiH1zAM7QM6ZMqW7UNrOzdka+L8cSPm7evv zD+tqG/0Yezf/sbxb3pApyi/NJ83agqi0SI++XxkwcGlZ851m7Fz2r+tP7d9TK1W/89sXAux5RfO x8LC1vlFt3Q5SHk9D+7nuEEuWZ63tMeRZrux5zer4512uwBQ65pIxNXQXpctU3yUivXayPCn8gAA kMiGsucdJ3fv3nfi9g5Hd995/PTNB09/Yu/imZUi6W8CG3xtvaN+0fuE8bzlVy88qxwwiXBP6bLv xOFwn9lz9+lXue8CIJFVlcZ9x24LN/Vwg3/N24+3b1088+IvvPsja6c+9tmXz33qi+3f/Nf/ob38 x8/OhWFzyAWBnNf+AJiNcE8JPHD2U937zGvvOvXynv0nXtm7+NDvhS+ue/advMl9GQCJLDG77zxx x95DZ37nx/e/95W3/t1za+GmHm7wIiJF5+W/fKX9heVW+9THPvfyzx7+4As33f33XwgtIIQSAIks S43jO07u/ut3v/+xcIO+69c/tva5L/9R9+YtIlKmPP+9H3RbQIJQvu7A6W93ayg1ewMgkXOQx33H Xn3LwTNPvOldD689+dl/371Bi4hUIV//1vPdGspbDn5g7aa7T71nz1sfXfBQA0Ai85bHzs228y3+ 0Tfc99BfLH3m919R6ygiVc0LL11rn3zssy91ZPJqGJTjwQaARObE37j7/X/v5ntOf/fsP/vCtXDz FRGpQ771599rP3D24ou33PvgN0Lfbg84ACQyI8JNNfQh+t9+46kfaLYWkbqm9eyftUPf7jCrRJhh woMOAImcgZ++7+Enw0019CESEWlCwqwSP/+r//g7b3rXQ3/Hww4AiYwkjFp84zsf/vLjv/3vfuSR IiJNS+jvfeTRf/7d8EXaAw8AiUwrkPtO3vQz7/rgNz7/B8/8lUeJiDQ54Yt0+EJtOiAAJHICYcmw n7v/Q/9V87WISC/hC3X4Yh3mxfXwA0Aih3Dr4oMn9r37I2tGXouIbE74Yv3mX370+fBF2wMQAIns 443vevjiez/6mRc8KkREhid8wd7/nse+c+t9D97pIQiARHZ4w+KD7373uX+15hEhIjI+YcDN3/rb /+gv9txxcq8HIYBGS2RomgnfrK08IyKSLmFy8jf/0qPfDMu/ehgCaKREhk7ioY+PPpAiInH5wz/5 ZvuN73z4aetuA2icRIYb308feug/hxUaREQkPp/4P//gR6E/uQcigEZJZJj3zDyQIiKzJQxIDDNb eCgCaIREvuG+Mx/6B5/8/Itu/yIisydMjWbqHwC1l8gwovAt95/9vtu+iEg2ef57P2jfeujM81a1 AVBribzl3ge/oR+kiEi2WfrM779yy8EzT3g4AqilRO7ed2L/4qkn1UKKiGScME3a3nsffMG0PwBq KZFqIUVE8stnvrTyV29458Of94AEUCuJvOnuU+85+dhnX3KbFxHJL6HPudVsANRGIsOckDffc/q7 ofO3iIjkly999U/bty6eWfaQBFALiVQLKSJSXELf89AH3YMSQKUlMnTyDp29rY0tIlJMQt/z0Afd gxJApSVSLaSISPF56989t9b5En+bhyWAykrk6+99cPUP/+Sb7ugiIgXmN//1f2jffPD0JzwsAVRS IvfsO3nTzx7+4Atu5yIixSYMZAwDGsPARg9MAJWTyJ+65/S5f/Kvfk9nSBGROeSuX//Y2u47T9zh gQmgchJpcnERkfnlyc/++/Zfv/v9j3lgAqiURIZR2Tffc/qHbuMiIvOJUdoAKimRu/edOPzA2U+9 6DY+XbZt29bF8YvILLl18cyLe95xcreHJoDKSOQtBx986qnf/Yo7+JQhkSRSJIuEL/PhS72HJoDK SOTrDnxAf8gJabokkUSR/NPtF3mXfpEAKiSRe/afeMUqNeNDIkmkSN4Ja2m//t4PWEsbQDUkMgyq +akCBtVMkpA0r/fT/3/Dfm7Se8e93v8z414bfD1m3wf3Nc3npP382OMft/0qHL9IXfL1bz3fft09 p7/toQmgEhK5e9+J23/h3R9ZK/ONdZi4jHot69fH/V+a19Nsf9zxxZbNNMeXZvtlPX6RuuU1bz/e 9tAEUBWJLPXI7CwkcVJN47T7keb1rCR2lv2q8/GL1C1GaAOokkQePfWxz75c1htqHjWNw34+TXNv 7H5msf9py2hcc/M0+12l4xepU/7m/We/v+eOk3s9OAGUXyLvPH763Ke+WNobahESGbvNtO/JYv9n LTMSKVKthO5FoZuRByeA0kvkT9x16uxjT10u9U01pk9kmubasvWJjN1W1p8/7z6Rsxy/SN1iDW0A lZHIoiYaz2N09rDX+v8d+960o4xj359m5Pe4/4spl5jtjyvDqhy/SN1iwnEAJHKISMzy+rQ/KyJS pZBIACSyL1kLpJoqEalrSCQAEikiItF54OxFEgmARIqISFxIJAASKSIi0SGRAEikiIhEh0QCIJEi IhIdEgmARIqISHRIJAASKSIi0SGRAEikiIhEh0QCIJGSKnWfPH3csohplrCM2Y5IHWKycQAkUqJS dwmatGb3rGVBIqUuIZEASKREhUTOVhaWwpS6hEQCIJESlSZL5ODr0zZlk0ipQ0gkABLZ3lw71P/n sD5y07weux/j+uCN++xJffrG7fOwv8dI1qT9n6YM0n7+pOOL3f64/yeRIr2QSAAkcowYTBKHtK9P Ky/jmk/TNK2m2a9R8jhJpqbZ/9gymLQ/Mcc3y3lIc95nuc5EqhgSCYBEtssjkWlq0tLUFI6qrYsV ohgxnLUmcNLP1kUi6z7KXZoTEgmARA6Rgqz/nEVeRolIms8oWiKzOAcxr1dJIrMYlCNSppBIACSy XQ+JzKI5O/Yzs5SiKknkuPMw7f6LVC0kEgCJHCMJWf87dsBK0X0i0wjOtH0i00hXVfpEpj2e2PMr UqWQSAAkMoXAZPXvNBKVZuT1qM8bN0p53GjsSdse9dnT7H+a8zDL6OxRxxez3UmfP+ocxxyTvpFS 9ZBIACRSuiEzIhITEgmARIpaMRGJDokEQCJFRCQ6D5y9SCIBkEgREYkLiQRAIkVEJDokEgCJFBGR 6JBIACRSRESiQyIBkEgREYkOiQRAIkVEJDokEgCJFBGR6JBIACRSRESiQyIBkEgREYkOiQRAIkVE JDokEgCJFBGR6JBIACRSRESiQyIBkEgREYkOiQRAIkVEJDokEgCJFBGR6JBIACRSRESiQyIBkEgR EYkOiQRAIkVEJDokEgCJFBGR6JBIACRSRESiQyIBkEgREYkOiQRAIkVEJDokEgCJFBGR6JBIACRS RESiQyIBkEgREYkOiQRAIkVEJDokEgCJFBGR6JBIACRSRESiQyIBkEipTLZt29ZFROafB85+ikQC IJFSjZBIkfKERAIgkVKqkESRaoREAiCRUqqQSJFqhEQCIJEDmSQx415fb24dbHbt//ew10e9f/A9 /dsft51x/z9pHyYd+6htjNv+qJ+Z9rPzKn8RSR8SCYBEZpRRUjhMZEa9Pur9o34u7ftH7UOMSKU5 vjTbj/nMtPuRRfmLSFxIJAASmXHG1YYN+9k0QpNWItPU5s1yXDHHPa2w5imRsdsSkdEhkQBIZIaZ tqax/9/jBGzUn6M+f9L2pjm+aQWVRIrUKyQSAInMKHlIzCR5LFoiY49vmm2TSJFqhEQCIJEZZVaJ iX19mv6FWTdnV61PZOy2RGR0SCQAEpmRxKy/NolhPzvqveO2m2Z097j9mqZcJn3GLKOzh/1MVttP +38ikj4kEgCJHCIis7wuItKEkEgAJLIvBFJEJF1IJAASKSIi0Xng7EUSCYBEiohIXEgkABIpIiLR IZEASKSIiESHRAIgkSIiEh0SCYBEiohIdEgkABIpIiLRIZEASKSkSlNWeIlZkWjcz8xSvqNW1yni fOR9fmf9/Kq/v04xTyQAEikeou12Kjmc9H+T1uqepXzTLIVZ5vM7q/RW/f11DIkEQCKlFJJR9uOb JJFpJHPW7RclkXmeYzWR9QmJBEAixUM0xfGVQSLTbDOLYyeRzb3+Y0IiAZDI9ubal/4/h/VRm+b1 2P0Y1wdu3GdP6lM3bp+H/T32IZqmz2BMGaT9/EnHl4ckpKkVJJHlkzgSmV1IJAASOebBPOnBnfb1 aR9OMX3uYmrKRh1Dmn2fpc9gbBnE1PRlcQ5ifn5eEjnqusvz9yCvbTTx/XUKiQRAItvlkcg0NWlp agpH1dbFCkmMGM1aEzjpZ8skkbOW1TTbL0oi8x5AQiLrExIJgEQOeShn/WeWD6eYEcRFS2SeD+ey SGSeNbFpPz8PiSxi0E4R10nZ31+nkEgAJLJdD4nMojl7FjFqgkTGvpaXRI67DrIs/zJOIUQiyxMS CYBEjnlIZ/3vWSUk7z6R08hMzPZjRbFMfSLLME9kzPWUxXaLlMi0x1PW9zcxJBIAiUwhBFn9O41E pRl5Perzxo1SHjcae9K2R332NPuf5jzMMjp71PHFbDembKeVkZjtj9unrK79tNvMYhvTXB9lfz+J BADzRDY2HooiEhMSCYBEitoVEYkOiQRAIkVEJDoPnL1IIgGQSBERiQuJBEAiRUQkOiQSAIkUEZHo kEgAJFJERKJDIgGQSBERiQ6JBEAiRUQkOiQSAIkUEZHokEgAJFJSpSkTkscsfTfuZ2Yp31FLEBZx PvI8v7MuG1j199ctJhsHQCKlNJIx7+OaJIeT/m9Q/LIs3zzXzi7i/KYpvzq/v44hkQBIpJRCMsp+ fJMkIivJKINEFiWnJLLaIZEASKRkIjl1P74ySGSabWZx7CQy+/fXMSQSAIlsb6596f9zWB+oaV6P 3Y9xfeDGffakPnXj9nnY32MkZ9L+T1MGaT9/0vFlIXGTfo5E5lPOdX1/HUIiAZDIMQ/mSQ/utK9P +1CK6XMXU1M26hjS7PssfQZjyyCmpi+LcxDz8/OSyFHXXZ6/B3n/zjXx/XUIiQRAItvlkcg0NWlp agpH1dbFCkmMGM1aEzjpZ8skkbOW1TTbL0oiixh9TCDrERIJgEQOeShn/WeWD6aYEcRFS2SeD+ay SGSeNbFpPz8PiSxi0E4R10nZ31+nkEgAJLJdD4nMojl7FjFqgkTGvpaXRI67DrIs/7LNQUkgyxUS CYBEjnlIZ/3vWSUk7z6R08hMzPZjRbFMfSLLME9kzPWUxXaL/PxZfz/m/f4mhkQCIJEppSxviez/ mTQrlKQZnZ12NPakbY/67Gn2P815mGV09qjji9luTNmO+pxprr+0x5e1xMRsM4ttpF2Vp0rvJ5EA YJ7IxkZTnYjEhEQCIJGiZkVEokMiAZBIERGJzgNnL5JIACRSRETiQiIBkEgREYkOiQRAIkVEJDok EgCJFBGR6JBIACRSRESiQyIBkEgREYkOiQRAIkVEJDokEgCJFBGR6JBIACRSRESiQyIBkEgREYkO iQRAIkVEJDokEgCJFBGR6JBIACRSRESiQyIBkEgREYkOiQRAIkVEJDokEgCJFBGR6JBIACRSRESi QyIBkEgREYkOiQRAIkVEJDokEgCJFBGR6JBIACRSRESiQyIBkEgREYkOiQRAIkVEJDokEgCJFBGR 6JBIACRSRESiQyIBkEgREYkOiQRAIkVEJDokEgCJFBGR6JBIACRyTtm2bVuXmNcnvWfWbRZxvPPa fhHnTKRJeeDsp0gkABI5TymJeb3KEpn2mMt+vkikSC8kEgCJnLOUzPJ6Vu8p0zHbP5FqhEQCIJEl FhYSaf9EyhoSCYBERkpEmn6M45o9J/3MqNdjP3dUU/g0+9//72n2PaZ8J5V92mNMU05lKz+RKoVE AiCRGWWUVGX571H/l8Xrk7Y1Sqxi93VaeUqzf7OW/zzLT6RqIZEASGTGGVcbNasEzSI5WUhQ2vdM qq2ctlxjyj1N+Zex/ESqEhIJgERmmFlq6uogkVnU9E3a93HNzbOUSxnKT6RKIZEASGRGmVUiqi6R eTdnT9pnEilSbEgkABKZg9CM+r/YPoYksp3p9ufdJzKrshApQ0gkABKZkUSsv5Z2lO/g3ye9Pulz R33GuH2btP/D/j/t/w2+HrP/acs27f6P+pmylZ9IlUIiAZDIISIwy+siIk0IiQRAIvtCIEVE0oVE AiCRIiISnQfOXiSRAEikiIjEhUQCIJEiIhIdEgmARIqISHRIJAASKSIi0SGRAEikiIhEh0QCIJEi IhIdEgmARIqISHRIJAASKanSlGX6Ypa1HPczs5TvqCUSizgfk5ZzzHP7syyLmcX5bcL7s4zJxgGQ SKnsQyzr45okh5P+b1CysizfUSJZ1PlNc/xZbzcvQW3i+/MIiQRAIiUTyaj78U2SnKwkqAwSmaYM iqoBLdv1qyZyIyQSAImUyj7Eijy+Mkhkmm1mcewksr7vzzIkEgCJbG+ufen/c1gfrWlej92PcX3g xn32pD514/Z52N9jH2JZ9Gkb9/5pjy+Ph3SaWsG6SWSa6yMrQdInMp/3ZxkSCYBEjnl4TXpwp319 2odDTJ+7mJqyUceQZt/z7DMX28cw5viyfkjPSyJHXXd5/h4M/kyeIlPE5zf5/VmGRAIgke3ySGSa mrQ0NYWjautihSRGjGatCZz0s2WSyFnLaprtFyWReY0+n+X3MK9tNPH9WYZEAiCRQx7KWf+Z5cMh ZgRx0RKZ58OxLBKZ9+jleUnkLDXbeWw/L2EikdmFRAIgke16SGQWzdmzPNibIJGxr+UlkeOugyzL P48pjPIuv7wljERuhEQCIJEpHphZ/XtWCcm7T+Q0MhOz/VhRLFOfyDLMExlzPWWx3TxGn89y/ee1 nZjyLOv75xESCYBEppSyvCWy/2fSrFCSZnR22tHYk7Y96rOn2f8052GW0dmjji9muzFlO60MxGx/ 3D5lde2nHfGe5jxlsR959/ec5ktemd9PIgGQyDlKZNNT9/kfRSTbkEgAJFIasy62iGQXEgmARIqI SHQeOHuRRAIgkSIiEhcSCYBEiohIdEgkABIpIiLRIZEASKSIiESHRAIgkSIiEh0SCYBESqo0ZRqg mAmfx/3MLOU7amLvIs7HpEne89x+3pNpz/r5VX9/1jHFDwASKZlJVtWPa5IcTvq/vJc9zGvFmrTb z/NaKPvnV/39eYREAqiMRN588PQnfvNf/4daCkyV0tSayKLWli6DRKYpg6JqQMvy+SRya37loU+8 sPttxw54cAIovUTuvvP46XOf+mKtBaYKIZHD/68IiUyzzSyOnUTW7/155Bfe/ZG13ftO3O7BCaDR Etlf+9L/57A+SNO8Hrsf4/rAjfvsSX3qxu3zsL/HSM6k/Z+mDNJ+/qTjy0LiJv1cEyQyzfWRp/SV 6fOr/v4sQiIBVEci9504HPrg5P1AGfb3WV+f9qEQ0+cupqZs1DGk2fc8+8zF9jGMOb6sH87zkshR 112evweDP0MiSWTIrYtnXtzzjpO7PTgBlF8i33bsQOiDk/cDZZ4SmaYmLU1N4ajaulghiRGjWWsC J/1smSRy1rKaZvtFSWReo8/LJEgEMpv81D2nf7hn37FXe3ACKL1E7rnj5N6/ef/Z7+f5UMnrzywf DDEjiIuWyDwfjGWRyLxHL89LImep2c7jdzGvEMhs8sJL19o/8Y73/chDE0A1JPLu06967V2nXs7z wVJlicyiOXsWMWqCRMa+lpdEjrsOsiz/PKYwmqcgEcjs0nr2z9qvO/CBb3hoAqiERAZu+p9OvfD8 935QyAMmj3/PKiF594mcRmZith8rimXqE1mGeSJjrqcstpvH6PNZrv+8j2+W3895v7/ofO7Lf9S+ 5dCZ3/HQBFAZidy7eGZl+Y+fzeWmOG+J7P+ZNCuUpBmdnXY09qRtj/rsafY/zXmYZXT2qOOL2W5M 2Y76nGmuv7THl7VExIx4T3OeZt2HIlbDSbMqUJXeX3T+4W9+4ZXX3vW+hzw0AVRGIsNNK9y82pJ5 6j7/o4hkF9P7AKicRIabVrh5uYVnm6asiy0is+flv3yl/ZO/+L5re9766IKHJoDKSGS4af3kXaeu hZuYiIgUn9ClKHQt8sAEUCmJDOxdfOj3vrDccicXEZlDTn3scy/v3nfiqAcmgMpJZG/lmosvupWL iBQfK9UAqKxEatIWEZlP/vBPvtl+/b0PrnpYAqikRAZuOfjgU0/97lfc0UVECsyvffi3frh734kj HpYAKiuRYZT2PqO0RUQKS2j92Xvvgy9YLxtApSWyWxt574PfCEtviYhI/ln6zO+/csvBM094UAKo vESqjRQRKSZqIQHUSiIDpvsREck//+CTn3/xDfed+ZCHJIDaSOSeO07ufcv9Z7/vFi8ikk+e/94P 2jffc/q7VqgBUCuJVBspIpJvTj722ZduuvvUezwgAdROIkMfndBXx7yRIiLZJgxe/OlDD/1ntZAA aimRgTBiMIwcdMsXEckui6ee/P7ufSf2ezgCqK1EhtrInzn8yNXQd0dERGbP8h8/2967eGbFgxFA rSUyEcnbfv5X//F3NGuLiMyWb/3599pveOfD/2XP3adf5cEIoPYSGbj57vff90tnPvE9jwARkeny wkvX2j93/4f+6559J2/yUATQGIkMvOldH3zsNz71u9q1RUSmyC/+2vnv3nrfg3d6IAJonEQG3vjO h7/8+T945q88DkRE0ue9H/3MC7cuPnjCwxBAYyUyTEdx66Ez3/z6t573VBARSZF/+cX/9Fc/feih 3/YgBNBoieyK5DtO7n7zLz/6vBHbIiLjE0Ziv/GdDz9tPkgAJHJdJO84uTdM/fOHf/JNTwkRkSH5 F1/4f37YFUgjsQGQyAGR3Hfs1eEG+ZkvregjKSLSl9AH8k3v+uBn1UACIJGjRLJzg3zDOx/+fLhh emyISNMTpvHpjsI2iAYAiUxHuGGGG2e4gYqINDFhIvEwD6RpfACQyFiR7Nw4ww3UyG0RaVrCAJru SjQmEgdAIqds3u7cQF934PS3Tz722ZfUSopI3RNqHxdPPfn9sBa2ATQASGQG3HT3qffccvADax/5 F//2mjW3RaRuCVOchS/Lf+N/fv93du87sd9DDgCJzLJWsvOt/PWLZz68994HX3jqd7/iqSMilU/4 Unz2n33h2q2Hzjwfvix7uAEgkbk2cR979S0HH3zqLfef/X7oNyQiUsV88neW/yp8KX7dgdOParoG QCKLlMk7Tu4N/YZ+9vAHX/iH//zfvBL6EomIlDlhQYVf+/Bv/fDme07/cO+hM78ZvhR7oAEgkXOr mTx502vvet9DoS/RW//uubXHnrrctvKNiJQlX/rqn7ZPfexzL9+6eObF19/74OrufSeOkEcAJLJ0 Qnnstp+469TZcKN+7V2nXg6jHM996ovd6TJaz/6Zp1mN8u21l9v/x1dN/yTlSrjXfGG51Q73nbt+ /WNrr3n78XZHHpc74nh0zztO7nafBkAiqyCUd59+VRjluPvO46dDs/ct9z74jeSG/uK+d39kDdXm fzz5yRfvPf/V/2//3/+XLykPzJsf3//eV8L9Jdxr9i4+9HvhvrP7zhN3uBcDIJF1kst3nNzdkcvb UW1+/sy/efTex5/+i4OPP/39Nx1ZOqBMME+saQ2ARAIV4uDjq/sXn2j9oENLeQAAQCKBCJH82k2L S60fHVpqfUl5AABAIoEt3P/4swuB8PeOOB5evND6bOfP1fs+2frJzp9/eehC6/fXXwcAACQS6HJo qXV6cenKufD3gx9t7T504ZnnO+L46fDv+5aevr3z+g8Wl5754/Ca8gIAgEQC2w4+3rpt8ULrufsf b12fX+/QhSt/ce9S65+u/zsI5uITz/zR4lLravh55QYAAIlEgwlN1KHZusOB/v8/tNT6+uITrU8O /NzyoSee+UdBJEOTt/IDAIBEoqF0ZPCRQxeuXNzy/0+0vtd57T/2/19oyu7839rBx1v/Q088e83f AACARKJBdJuxl1pX+5uxA/c//pVXdQTxWhDG8PcB6TwcBPL+Tz7734Q+k52/Xxr8GQAASCRQU9ab se97snXHCLlcCYIY5oscfH3xQuvj67WQ3b6Snc8J0wEpVwAAiVQIqDkd8TsfZHDEa0e6ry+1joY/ twroV14VBuKsC2boTxlqNMMobmULACCRQE0Jstdrxh7eDL0ukN0+kB1ZHPYzg03h6/8OAqqMAQAk EqgZ3WbsjhgOa8buk8jl9dd7NY7Dm6o7P3d8cenK5eti2Rt4E5rBz5uYHABAIoEakdQynp/wM2vr NYzrtZKjf/bK5TBReb+khtHe4f8NuAEAkEigBoTaxd6k4qNrCZPaxKvX//346v7+2sZBgmz2ais3 T0DeXQGn9/97lT0AgEQCFaU3bc/kwS89aWxd2nhfdxT32ljxDO/pyunmmsfks64OG+ENAACJBCpA b1qe8c3Y3Z/r9XM8t/n/rlwe14cy+ZlzwyYtDzWRQTDHNYkDAEAigRLSbcYOE4SnGOzS68+4eUnD 3lQ/41enSWosV4Yth9ht8g5LJnY+24AbAACJBCpAInBXB/ssjiKI4GA/xjA6e9RUP1t+rrss4tbR 3Mmo8FAbujy4Qg4AACQSKBlJzeIj6YSzW5vYHlZb2B0k89HW7hQSergnisNrHJMJzK8acAMAIJFA SUlWkllN24Tc7b/Y+fmhn9WrRTyaTlzDmtqjm7+T5vUwMfkB5wkAQCKBEjFq6p1J0hkEcLhgru4f 9drWbfeWRRw3GCdp+l5NW0sKAACJBAogCF//JODpJPLKuTA6e6QYTpjqZ7Mkbl4WcfRnXrkc9tWA GwAAiQTmTNIvcSVWzML8kOPmdOxO9TNhnslNIhsmHB8zUXnfds93B/Sk6HMJAACJBHKgbzT23ink 8+qodbKT149PmupnmHim6UvZ+ZkjMaPIAQAgkUCGhNrE2Gbsnnz2mqvH/cy4gTcj35Mso5hGDkMt ZzLg5ohzCQAgkUBxAhlq85aneW8icMsptnE1ttl5Y1nEyc3riXSuxNZ4AgBAIoEpSORrbVxz9AQ5 PJpqWcTeVD9Hpvj88+G9aX421Ir2pglqXRpcjxsAABIJZEjS9/D49O/vDm45muLnDqSd6mezGHYn Ml8dtizimGMKo8VXpxVjAABIJDBe7KZuxu77jOU0I69jp/rpJ5kbMqo5PJkw/WrMqHAAAEgkkE7M 1madHqfzGdfSNh3HTvUzsJ2j45ZFHH6MvTkn066YAwAAiQQmS9nyrKOZ12sI0/58b/7H6VeaSfo7 Rr0/mbpoJTS7m5gcAEAigdkE8niaybwnS+Tq/jCIJf3Pd6f6WZl2e0mTeHQTdZDHQxeuXOzVZBpw AwAgkcAU4pdNM3afjEZOIj7bttfnhBy3LOLY/e2tC77XtQAAIJFASpKRzssxI53HkTQvH4gSud5U PzNtPzSLTzPSuyfR3drTq+OWaQQAgEQCA/IV0/w8UQi70+jE1eoFgQxNyxnJ8NHpRLK1N9RIzjK1 EQAAJBKNIOmPOFUz8BiRa8cOVkmzTGKq49lYFnHvdPvf3Y/lILQG3AAASCQwWvhWsmrG7pPSqQbJ pJ1bMsXnhLkgV6eVwKRcwmTpK1nJNQAAJBK1YZY+hGME7si0zdLd/emQyX6EPpYpl0UccyxHZ6nV BACARKJ2rE+4nXVNW7K04FR9CpMR1itZ7EffsogHZvmc+55s3ZFMTH7AdQMAIJFoNFkJ1nCJbF2a ZYRzbwnEbOZsXBflWactSqY/Wp1lQnQAAEgkKk+QoVlHQo/57JmkLZn8+3CG+3N01nXAe+IdBtxc uRya/01MDgAgkWgcG83Y2YtQspTgTCOsg0DO2pdxyGdeyqyvZa+5fiWLSdkBACCRqATdZuwLredC P788Pj/pP7g82z7OLqIjPvNqFiO/Eyk9kuXnAQBAIlFqutPWZFzLN/D5oen4fAafsxJqTDMV3OvL Imbb3zIIpWsLAEAiUVuylqiRkpqBVGU51c/m/btyLsspjZKJzVdi1wkHAIBEohJ0B4WEZuycm1+z qkFMhHc5+3K4vizikSzLtrdW+JXLBtwAAEgkakV34u0MmplTSOS1LEQqkb21PKQsqT1cC9P2ZHzs j/TWDM/2cwEAJBKYC93BLhdaz+W9DnQyl+LVrD6vV7uXzwTf3RHgMyyLOOZzD3QH3OQ0cAkAQCKB QujNbVjMKOIwwXiW/Q3zmOpn0+fnVDubrB0eBtwcdQ0CAEgkKklPlIoZ9JE052a2okvS7Hw1r/1d 7yc6y+o6oz+7O6XQSpDUvGuAAQAkEsha6g7k0WQ7ijyan5OBOnvz2ue81g/vieSzC8nqO8sG3AAA SCQqwfrk2lnPtThB+FazFr7ulDw5TPUzsN/Hw8jqXD+/W+OZnwwDAEgkkAlJDdgjRW0vGU19LevP 7U31k5/g9cnq5TxlNTSZ96Q++6ZzAACJBDISomKbsXuS1G0WXslJTtfybg4uoua2O+DmQuu5vGtW AQAkEphFhvYWLK5HQu1nHp8d+loWUYPXrS3sToWUn7D2RstfuRzKyoAbAACJRGnoyNyledR0hb6L oe9fXoKa51Q/g8eRlwxviGS3djUsD7mSx4AeAACJBGJl63BPTIqv4Qq1a3lNsN2d6udC67kijiMR vDA1z+ECztfRogc/AQBIJDAgP/Npxu4TorU8a9WKHN2crLyzVsTyhcka4VfzWpkHAEAigQkSd+Vy Xs3JKQV2LefjO1fkCjBF1uom0rpa1KTwAAASCawLz5EwofW8tt9dmzvnaXiK2MYgvcnTixG7ZHnK S2GbJiYHAJBI5E6yNGAhTa9jJPZo3rK1MdVPcf0915dFzKuv5/Cy7Na4roTz6voGAJBI5Ckdc2vG XieZ2PxIAbJ6qejJuvNcFnHMcYaa5auhv6RrHACgEJCHbBwtuol3xH6sFDHCOBnNfL5wSV5qnS66 nNfltQg5BwCQSDSI6yOIS9DsGZY7LKIfX5FT/Ww9xuJrfJOuCivzEGcAAIlETQkDacpQS9Vdym+p tVrYcXen+im+/2cidIXP6Rj6gCYDfC4bcAMAJBKYVSCPl6EZO9mXA0FyCtze+SKn+tkszOvLIhY/ mXu3SX1OAg0AIJGoAUnN39WyjN7t7MsjgUJFbql1aY7He76oJRiHCXt3wE2Bo8UBACQSNaDIJfnS 0mtqLW61lXlM9TNk+6vzOgfrXyLmVRsLACCRqCC9UcLzq4UbxjyaWPNcpzudyM13UFOyQtByqBGd l0wDAEgkKsJ6DVSR8xVOlpnuKivXChfXAiY3T7cPreV51ogm83Mul+maAACQSJSIeTehjhHbMJfh ylyEek5T/fRT5LKIY2W2Wxvc2ut3BQBIJDAoCo+EWqcS7teRuQ0yCeI058FFSU3s3FeWSQYbXS16 NR8AAIlEiZnHsnsREjm36XaCvJZhnswgkGU4P+u1s6HfrN8bACCRaDh9zdgHyrh/oT/evAa4hFq3 IuenHEdZBjz1akavXA611gbcAACJRIMJ/e3K2IzdJ5Fr86qBS5qS18ogS4nsL5dh2p1kX8531zMv yVyiAAASiQLZaCYt51J3yTQza3OW7Mvz7o+4zryWRRwj+EfKtD8AABKJQgTt2YXQv63MK5PMe+WY RJSOz3t09MD+hBVlVsvSlLz+RaRso/oBACQS+cnI3JbWq5LAJXNnrpSqXMKAnxKdu6SGdLVMsg0A IJHIgbI3Y6+TTHQ999HRZVpHPFDGwVBJ/9FLYSBS2a8rAACJxPQP+7nPO5hS3lbKMMF1MtXP4TKV zfq0TGUb2BJqI4PgGnADACQSNSMRovPll91ubdu1MvT9CzV+ZZnqZ2C/5ros4pj9OlyVLyoAABKJ FIRBNGEwTRXm90v6Iq6WQ2jLM9XPEGG7VMbJv9drSsvQHQEAQCIxuwhVpnaobLV/ZZrqZ/N57U6D VMrzmgy4WalCzTcAkEiFgBH0BqlUZ/Rsdy3vEtWwJSvGPFLGsirzQKlQexu+DAQJN+AGAEgkKkbZ 5hZMuc+XwjyRZdmfpHm2VFP9bC6vsPJQ+fptbpLwC63nDj7+tZv8TgIAiUQFWG/urNqqIr19Lpdw zHMJxsnnuTzLIk74MnO1TF8OAAAkEiPoNSWWsxl2tBB1+29eK50ElXCqn36SPohrZa7t6w6YutB6 rsyyCwAkEo0nmWqlUs3YiWiEpuPlMpZn6FvqnM/6JaFbO74cyrJq1yYAkEjUnr5m7L0VlN+jZRzR uz7VT+nLrwJzgSZrt3+8N89lObsIAACJRCMp6/yBKff9fFmbO4P0lH2apK7sdgexlL/vYfcLQ3df q/dlBwBIJOookKFJc6WqTYVdUXuydUcZ9y2IeRXkvKzLIg7f19X9ycTkpVkLHABIJBrHxuCK6tbs 9EZBl3NOwWROxtL11xxRjsfD/IyVuG4f/9pNoUayqrXnAEAiUXmCNAR5qKwEB5lYal0ludldD1UR s16f087+Xmh92oAbACCRKFZujlSllmy0RHabNi+VeR97q/+Ud6qfzWJWvXlCkz6xK1VoigcAEonK U4U5AlMKxPGyL8/Y7XN6ofXxSon5hdZzVVp2MPlCVLlJ8gGARKKK8rVc5WbsdZJavlIPsEhq90o/ 1c/m66PcyyIOY31N8KrU+gIAiUQVBbIyAyhSHMtqFQYFdZtbKzR4KVkWcaVqQpbUsK+WvXYaAEgk KkcyEGWtDv3HEtFpV2FQRVhKsmojia9fKxXr8hCa4ZPlOy9VqUkeAEgkyi4zoRn7SD2EuLU31DpV YV97Ta3Vq/2t8hyioTayV1Nd7X6/AEAiMXdCTVhdmrHXBafsa1Ovk9SaVmaqn03XTbdWr5rNw6G/ bOgnWfZVgwCARKK0JLV2lViRJL0gdGuaKjM4KGlirdwqK1VaFnHEtX9bMuCmFjXwAEAiUaAEVHOQ xGSJbF2qkthUbaqfYSIWRppXcv97A27C78B5E5MDAIlESnrN2OWekHtKKatUzWoiMqVeXWfydVTd 7hBBHntTQl25bMANAJBITBKXitcgjRaCsORdteZeTMS3UlP9bN3/6iyLOFaGu83z1T0PAEAikbNo dZuxV+s4+fJ9T7buqOKSjVXrx7nlS0lSm1r1lWGS5TKvVrWfJwCQSOQsLK1HqjJ6eYpjOxr6t1VO fis61c8WAavYsojDj6O1NxxHuJbcLwCARGLjAVnLZuw+iTxfxYd/laf62VL+FR0ktPl8dJekXA5f tgy4AQAS2Xi6otKrYancdDIRErNS1SbVMNVP1ZtR69RVIvl9+XiQybp+6QIAEom0gnW+rs3Yfcd4 raq1eWG+wjrU4lV1WcQx5+Vo0t9zr/sIAJDIxtHrcxeases7hUkiL5WdKqc7OOVC67kaiddyXZqC kwFbV+tciw8AJBJbWG/GDg/COh9nMrK20vNe9qaYqUcNXpWXRRzzJSU01T/ivgIAJLIRdPt11aCZ dKK09CZPr/QDPpnq52g9vrx05+ys1frUvWO6cjkIsgE3AEAia816M1wTVuKo6hrUW89Xtaf62XQ8 17tR1GtgSjILwEqd1pwHABKJ69SxJmjCg3216oMfNqb6qU8tV9WXRRxzvR2pwwTrAEAisfUh15ue pHITb88gX9fqIF+hX2edVkxJzs1yHSfvXq9pDULpngMAJLIWbKwe0ox+W91VRpZaK7WQ/+7I5voM SOmen5osizjm2Fbqds4AgEQ2kGS1jcY0YyfidaQuc2B2RwHXZKqfgXN0IHQ5qOMXm9B1JOmTe6kJ /Y8BgETWlCBTTasVSUY1H6/N8YSpfmo4aKPuMwUk1+FqXaZpAgAS2SiZqm9tz4TjrlU/wqquAT6J Oi2LOOF3sFEtAQBAIiv/gO41YzdxtGhvRHN9ppGpw8Tpo4+tdVv3Oq3x9Djrx1jHLwIAQCLrKVKX mriaRiLPa/U6pvpN9TNwrdZqWcQx1+VKqFU2MTkAEokyP5QPN7EZO5BMqL5cv3N65XKdl6oMX3rC HJL1/oLz7EKvj3IQZgNuAJBIlO5Bdb0Ze29DBbp2U+LU+bgGr9sm9B0Mg75666I383cUAIlEeR9Q ta/RGXv8vUnVazfZczL35Wqdz11dl0Ucfj67/Vyv1mkAGACQyGoLZFh6baXJfa66axjXdDBRXaf6 2Xz+rpwLcyw24VrtfjHonNM6TUcFACSyig+k3koZa01vIustd1jP/mZ1rWXtp87LIg4/3u6a9suh r6QBNwBIJOYkT1cuN71Go66ru2wc3+r+JtTSbXwhasYk3Yk4n++1ItS/KR8AiUSpBLI3RYpyaB2o s2QltVa1nepn4Fw2boaB5Pe4sYPiAJBIFEy39q1BtTYTHsKP1H1uzO5UPw1Z/aTuyyIOI5miKkxM fsD9DQCJRN7itKxjfo9QC1n3h28Yed+USeS7Na/dqXCaNYI5+WK42sTFAgCQSBQnkMdDzZSyuF4e q3WvkU2m+llpjlDVf1nEkQLd+d0OX4xMTA6ARCLjh2vSjN2wh+v4h27rWkNkuVFS1eQvS2HKo+60 VX7PAZBIZCNM3dGcK3Wf7iVOqrs1Vo2ooUum+jncMJm63NRJ9JP5Xxuxmg8AEomc6fWL04w9+KAN c+015FhrPQp9+Ben5iyLOOZL0lVfHAGQSMzyMNnbxD5ik8Wq2+x3tBlC1Zvqp3nX/ur+MNCmqX0E k/kzV+q8hjoAEonc5OF6M/Zh5TEoka3lMD1Kg6S5MVP9DH5ZaFot7OAXiN4sBFcuG3ADgEQiRpTC PIiXlMXQsllr0mofoUtDE/sI6g+86V5Q+9kIAJBIZEDSJ6pRopReLLr95RrVvNukgURbj90E+4lI Huj2E21QDTwAEoloSerWvqxqxh5OsspH42pom/yloonLIo74MrE3GXBz1L0AAInEsAfmI00ZeTxl +Rxv4mCDJk7100/SN7Dxg0ySmvjQxH++6VINgESijzB4ItQ0aMYeJxNXLjaxj1wQyCZ/uWjqsojD y+LZheT3YNmAGwAkEr1m7M5Dsu7rQWcgUyuhj2AjJaqBU/30o6/wlt+F4z2xbu1VHgBIZLMfCOc1 Y6cQ7aXWtaY24zVVoPsx+f6gWK/u784lq4YWAIlsJhvN2Jqmxj8wuwMLVpssUE1dDnCzTDd3WcSR vxcXWs8pEwAksmGs9/UydUcaeWjeEoBDvmwsN16aequ5XG16reyW+0iQ6wtXLhpwA4BENkWMwqjb DsoilUSGSZcfaXgZrKmxtizicJHsdvc4H7o96DcKgETWnGTOQ83YKQm1kE3v+5WMyj3setCPeEy5 HFVTC4BE1rrWoDva9moT10Se4eF41colrcNqrtd/h0zMP/ILatLP2mwPAEhkDUlqlM4riyjpvqYc upNNX3VN9LAs4sSyWTVJOwASWSO66+B2+3PpAJ/+gdjc9aOHXD8r5gbcVB5HexNv+30a8eXrUugK otsMABJZ+Zt6ryZJM/ZUoqDm9gPJ0pimc9mEZREnXTNXznW/fHy0tVt5ACCRlX3YhWZsD7spxCmM Oj2qLNb7u5lwe/OXs6SPsamyxv0OHfEFFgCJrO5N/HDoo6TZbaqyWyYI68LUHVBiqp+hcm3t+XEk 3UKuNnH9eQAkssIP/m4z9pppN6aWSGsm92G6oxHlYlnEySLZm6x9RfcQACSyOhJ0qekTZc/40DMi efP1ZKqfoV/WurW0y7o+TC6npB/pZTXaAEhk2R/4mrGnl8iwOklHwpXFgFhfaD2nLEZ/6VDrP5lu zW3nOjJFEgASWe4H2l7lMbWEHzcYaWi5rLquRpaNabRiysqgJAAksow36CuXTccyG5b6G3lthWlb jiuLEeVjXfr0X3Y7X0aSATdHlQcAElmOb/hhSo0VtSEzl6PJtYdgqp/xWBYxtry6g/+Wg3i7ZwEg kfP8Zt9rxl4jP5mIQNtDbWTZmOpn3O9hMqWNSbbTX1NJzf+y2RAAkMg5EWqINDVmIgGhmW1VWQzH VD9pfhctizhVmXUH3PgSDIBEFn0DPh4eWsoik7I8EERJWYwVJPP9TS4nU2xFf4Hrzopw1ZcUACSy sBvv127qNWObMiObh7/BI2OvN1P9pMKa9dPez1p7w/VlcCAAElmI9HQnOiY92ZXnJTUhE8rIPH+p sCzitAIe1iW/cjn0ldQlAEDlJPLGXbvaC9u3tbdt29besXBju6zvDfJ48IneaNlZtotNZXqVII3n 4NIz50zNElVWJq6PFsnuIK7z3ZkSDFICUBWJvHFhR1fE1okRsiLfG5p97n2itRZusLNsF5trQEKZ KovxhEmi17+8YLIM3bv0tGURp/9Sd8RqQAAqIZE37lxob+9I2PYbdrXXxSytkBX53uRb+kq4wc6y XQzI0dLTt4cHvrJIIUZPhKl+NDWmIXzR637hM/I47n7c17pynR0723V9L4CKS+Smm8EMQpb3e0On 82E1QVWTyLJ1G0gz8li3getldcmydVHlZT37SHbu2BCwTS0uKaSs/73998YyvxcAicz9veMmM66S RJax20DSB+toHtutoRQdDf393MgiysyyiDMRupt0JW3bjvbOXfG/e1V8LwASmdl7Jy2rVhWJLGu3 gdCUPWpKFt0GBr/MfO2mxQvPmOonUoJCmYW5SJXHdOy6Yft1IYsdcNP/3lm2W+R7AZDIzN4bJi8e N9KzinJTpnK+94lnrqVZ0o9EJtdjR4iMnI2Vb8sizkJ/rV7sPJxqIgES2ViJDA+f3mCG0XPOkcjp 35tM2n417+3WSiInNP9jZLkdN4BrintFX2tAv5CHAYax751lu0W9FwCJzOS9k5qxSWQWEtldcu1S 3tutE6HM7n3iaUtETlN2T1y5bFWWiN/X6wPaNtfodVdQ6s1UcT72vbNsN+/3AiCRmb033CAPXXjm Yh3lpizlnKw//kje2y3+oZvfyPdhU/3Ma8R91bAsYhy9JuHt7YWdw/uKhy8zQcyHdUcZ995Ztpvn ewHUWCJ7HaVHP+iyfG//0mmzbJdEjn9veAilHfBQ9nIudNL7zoN7XYTmNeK+qiS131fT9MNtMpPu e+uEmt1uP92+FafSvneW7Wb9XgAVlcj1/ivbhrF9ob0raZIYdoMo+3tJ5Pj3hu4CaSeDLrNEFj3y vbv05tIz5+Y14r7yItkpO10CJstY2j6F4Ytgb4Wb1f2x751lu1m9F0CFJbJsdAcu1HxeuTJIZNLn tJ12IujKTKVUQNkG8Q4CXoZzOvfynqI5fn31qbJNvF+m63eSjA1+uQ7X5LTvnWW7Me8FQCJzJawG 0oSmrjJ0G0hEaCWL7TZR0Aen+mmiRJZx8vw831ukkA+lbwWYwd/XKrwXAInMje6kxKHTfU2XldNt oG4S2fp4/zQrTZPIsk6en9d7q3MffXYhXJthOqVxU6MBIJG1wvJoxRL6pYW+fbWT9YJkbnCqn6Y2 Z8/z2Jtc5hPvp0uto70BN+n6PAMgkZWl24zdueEZsVnoQ+ZSECESOd1712vO1/uUkkgSWbovislI eEtOAiSytpg7bm4SWctl6IoUi2FT/ZDI6d8b2/xKItOIZG+9d5O8AySyloQJxcetvIB8xD1MmF3H YytSLLpz9CWTtZPI2Y89SDmJzOP3/SuvCmUbul+knY0BAIksPd35zbrN2G5sRRK6D9R1HeMiR773 j3DPa7tNk8iYGjMSGX2/Deu+r9SxBQIgkQ1DM/ZcHyZH61T7a+R7TSSyIzehhrwj57eRyNx+94/0 JiZPV8YASGQpSZbce0RZzOFBMjA9DWYuy8NNLoMsZa47GCTlIDsSOR3ry8o2/boFSGR1vw0fDit+ aMaeW/mvqInIrCwPhH69JDK7pvxQSx7KtKiJ95t4zkKtb3fZ06Vnzvk9BkhkZVgf1EFi5se9Tzxz zXRKWV3PX3lVXQcpjRXHnJvyg+DoQlDEtdttEbrkfgCQyEoQbliasedYAxGm/FhqXVUWmV7Ty/r2 5nKdroU/lUfe1++Vc91aSWUNkMiSP2xDp+4VzdjzfDiv7j90ofVpZZEdYUSxefhyuV8cdb8orKwP GOgIkMjyykuvD86aZbjm/rB4RE1w1mLeum19qh9kLOidLzyhpkxZFHYdXzXoDiCRJZSXuDngkOdD 2TJoOcj5mn5l2bO+vGSY21R5FPZlfyUMblIDDJDIsjxgNWOX51ysqg3OoVxN9ZMb61PSxC6LiGnF /dmFQxeuXAxf/H0xAkjkfL/Z6iBfqodD51xcUxa5yPnhIJLKIh96S0zGLYuIDMr8Qus5XzoBEjnP h+tyh+NOfhmEXt+9/AS92+zauKl+Cv4C5F5S+D1jdX9vhZvV/coDIJFFC+TxcON34ktzPo6EZipl kVv5msQ9T6Hp9dezZF/xXz73hhrJMFpeeQAksqAbj2bs8klOdz44NTk5YaqfQkT9QBAaffWKJfRH DRUC4Uuovu0Aicz5hnO96ck313JJ5GWjXPMjGQCi5j3v6zgMYtL/dD739d4AsmWDnAASmRs6wZdV IsM0NG7++ZexWrICvqSuGg0/t2v8aNKtYK/yAEhkpnT7z4Rm7I+2djvhZXrwdpujDPzI+wtUd2oU 83AWcJ+5zX1mfoQWjWRictc6QCIzrSFYseJBWW/6aofzxlQ/hZb10V7Tqj568xH5br/3VStgASQy EzRjl/2Ba/m43B+syQhiZVHYdX3JdT3PioMwtdWVy2ElLDIPkMjIm0fr0nofu/XmJX3uynJ+urXC l3pi3zrQe9iqIS5IbFb0FyvqOu9207gaBjUpj7le8+e7173uBQCJTEMije0gjsmyhjq6l+7GfuVy co76WQn99kwenOsD9RFT/RSHZRFLc90fMY8nQCLT3jAODMiJWsjynaOjQySybUBCEVKjW0fBX5jC HKiXlEU5hH5Yq4d7DkAi+wXl+DA5MQ9heUj6522RSLWQ+ZJ0JbiaPFCPmzO1sDLfVM7JlyjlPp/7 zkp/X9Vu96fuOtzuPQCJ/MD1PjDDarmuac4o1Xla3Xx+DELIT2S6/YQPJBMyr/WXuy9XhcnLWjL9 TOgD3LbM5/x+F8Jgm/V+831da0zGD5DIEf3tOg9PTdqlk8hH+s6R6VBye2iGmrChfVC7mIC8sPvS ucE+wMpl7udjbXNLiEFnAIm80Hqur3brshtDOUmaVJMaYuuY5yuS3ZrIlSFfrp5TPkVI/KYvTNe7 2CifuX6J3dIvW+0wQCK3JTeEVX1cKnGu1oycL4Zuk+qmL1jhodn6tLLJVyCTptMRtcBaR+byBbbX rWBolyfnBMhBIvfsO3bb7n3Hjr/mzhMXX/P245fLymsPPPR/v+XXL/6/Zd7HH7vz+Pnd+04c2bPv ZONr3/THm4NI9jXhme6nGJFMBjGtDUqL638e56NbK788Suz1zQYylMiOPL66Iz6XOiz/2NtPPLL7 bccOdATodszEkSCSnTJdDWW6562P6guI4kSyt4b8NaPhi5eXZIL9fpk8qmzmdT5arw7Xf6+rwaY+ w1f1zwYykMhQUxZEZ/edJ3xbzolu7W5H0PMSyfC5HWk9nEhraWtnS1NL/PYT50J51f26S5rzNN3N SV6SQR1B5M8rky33q/3hy/U8fv9v/V//ycrPHX/q2df/8oe/Ouf70COhHFQwoLISGS7ertzccXKv wslbJHs1k5nfkPcdu+01d55Y+bG3H/942IYa4FQcDeXVvfZz6G4QavLn9YAc5Gf/3j9tlUPeT3x6 953HT2dZ3t0vTp0vBGXvevPmX/3EagW+XF3qnZ9juU6Ptn6/6l4PnS/Xzb4PhcqFE58O5ZF3uQO5 SGS4iMPDTsEUQ09asrtZdG/IOYlQI2pEeuW3GrpzZPR5r+4+kO88cdEDcgv7g6Rk0b0jaT1ZTr44 HVW2GXDniTuS8xO6NJ3Lo3YsbKMnTO5Xw67ncB6UByolkeGB58ItsDayc5MOZHLjCbXIbsjZPNje fnzm5eoSgXzO71OaGsRu945L05Vz54Gr5ibn83PiaBa/E5vO292nX5XlF7YafqF9dbd8OuWkPFAh iTyx5qIt9Oa8PzRflO2zmk5XSmbs0uELWRzrsxdMUc7LBLKA89Ptr3fseFk/r65frrQMojISuecd J3eHmhOFUqhE3h5kI5PPyrBW0wOz2yx6ePpzkU1tZpNI+mNfi/z9ORzOlfIr5/nJ+4ta7cs86Z6k LEAikbtEzio+yE7ICX0xYpGMqj+q7Mp5fsYL6Yk1o5CLFXeARJJIElkBieyNND2xX1lGS8rFMJI9 fTnrMlDm8zNSjjxrIu4lx9vKASQSJLJREkluiriGlXO5zw+JJJEgkSCRJJJEkkiQSBIJkEgSCRJJ IkEiSSRAIkkkiSSRJFL5kUgSCcxbIn/sF/xiFy2Rfy0rifwFElkWifxr5KaQa1g5D9zMt21rl+n8 kEgSiYZJ5H+bs0SGm1w/w/5/XjfIeWyvzBJZlXOVZn9IJIms+/2qahI5S4VFFc7L4D5Ou10SCRI5 4pd32C9VGUQxDympmkRW6VzlsU9lkMgmSnyZJLIqvwOD56HuElnVe9O0kEiQyIhfsrLdlJsokVU6 V3WVyKZKfFkksmr3q/X/r7tEVvneRCJBInOStTS/jOO+ZY+rrRn1DT1NUwOJrM65qpNENlniyyyR Zf0dGPX3pkhkmc9LFrX0JBIkcsZf/mkfYuNuttNuj0SW81xlfb7KJpFV+MJVp+bsKv0OkMjyn5dZ zg2JBInM+Zc/zTd0EulcNUEi5ynxWZyHJkhklr8DeXXnaKJE5nVvIpEgkRX6Zh97gyWR1T9XeZyn ukpkWR+UTZLIrH8HshoF3HSJzOO8kEiQyBxvzFlI3aTaFRJZ73NVx4E1TXxQlk0iq3i/KuKeVYfR 2VW7N5FIkMgR35pjaknGfdNOMw1KTH+uIr/ZV2WeyKadq6qPzq6qxJd5nsiy/g5M2te6SWSVzouB NWicRFqxplisWFPS81KyeSLr/qCc9hq27GGxWPaweEgkKiWRfrGLl0hrZ9dPIslNMdewciaRJBIg kSSSRJJIkEgSCRIJEgkSSSLJDYkkkSSSRIJEgkSSSBJJIp0fEkkiARJZU4m88/j5zucdUa5ZPCxP PLJ737HjJJJEgkSSSIBE1l4iO591tCM/55RrFjfuE5/ulOd+EkkiQSJJJJBGIvcde3Xngr2qUKop kXvuOLn3NXeeWFGuM5bjWx9dCL8He+4+/SoSSSJBIkkkkEIikwv2apBJBVOQRL7t2IGO+F0s202+ 2Q/K2Zqyu79HnXMazq3yjH1gxtUAz1pjjHzPD4kkkWicRLopFyws50IzdFafF2rPOjed5TAoJNSo KeOIsuuUVxDITvldmvnLga4F0z4wnwuCkbqcZxwAhejzk1klQ+dZszZLbX8j7knd+/mJNWWBykhk EMggkgqmqBvE8dWsa36DDIUHa+ezrwWhDE1+mEgop2uz1kBePwe6FsSX2b6TN4Xfh7j3HLstnDvl V8D5yfiaDl/Wdt954g5lO+5L0ok7svhSCxQmkYGkSdQo37y/1Ycmz5ybnsNDNvQZw3hCOWX/AFBL FikVy9Ochyy6HyC/8zPy96PzjAkzSijbMde2GTdQRYlMasguBZnUJJpbjcuyB1/Nz3NvgM6lIDl+ j9L8Pkz3hapXzic+HboPKOfynZ8JYmpg1GjJzmzQJVCoRPZdxIeTJtFVzZ1ZcWItacK+zcXXlIfB sePJeb/crTVLaiibTviSGppHs/p9CP1QdeHInOfyvF91B9h0rgFfqIfcMzrlEtM/GCidRPZ/E9Xk mVGzqY7kja2V7F0Dx44TyITOl9TQzy77mjNdODK7XxUgMX0D2tpN/qIVatITcW9rvUCtJBIAgPxr 4Br8RWvfiaOa9kEiAQAAQCIBAAAAEgkAAAASCQAAABIJAAAAEgkAAAASCQAAAJBIAAAAkEgAAACQ SAAAAJBIAAAAkEgAAACQSAAAAIBEAgAAgEQCAACARAIAAIBEAgAAgEQCAAAAJBIAAAAkEgAAACQS AAAAJBIAAAAkEgAAACCRAAAAmJ3/HzMXDr89vKzAAAAAAElFTkSuQmCC ------=_001_NextPart338202861278_=------ From nobody Wed Dec 13 00:18:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EEF124B17 for ; Wed, 13 Dec 2017 00:18:38 -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] 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 pABYep8ri5Vg for ; Wed, 13 Dec 2017 00:18:36 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 44BB31241FC for ; Wed, 13 Dec 2017 00:18:36 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 955EB31CBA; Wed, 13 Dec 2017 09:18:33 +0100 (CET) Received: by godin (Postfix, from userid 1000) id B10DAEC0B81; Wed, 13 Dec 2017 09:18:23 +0100 (CET) Date: Wed, 13 Dec 2017 09:18:23 +0100 From: Stephane Bortzmeyer To: "zuopeng@cnnic.cn" Cc: dnsop Message-ID: <20171213081823.GA8970@laperouse.bortzmeyer.org> References: <2017121315404971736813@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2017121315404971736813@cnnic.cn> X-Transport: UUCP rules X-Operating-System: Ubuntu 16.04 (xenial) X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 08:18:38 -0000 On Wed, Dec 13, 2017 at 03:40:50PM +0800, zuopeng@cnnic.cn wrote a message of 1343 lines which said: > For example, a CDN provider can’t schedule 70% of traffic to node A > and 30% of traffic to node B [...] adding a “weight” attribute First, the obvious question: why reinventing RFC 2782? From nobody Wed Dec 13 00:43:48 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44FA12700F for ; Wed, 13 Dec 2017 00:43:47 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 IIbqKeFt774a for ; Wed, 13 Dec 2017 00:43:46 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1FB6120726 for ; Wed, 13 Dec 2017 00:43:45 -0800 (PST) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 4ADBE9FB57; Wed, 13 Dec 2017 08:43:42 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id BC25CAC3D37; Wed, 13 Dec 2017 09:43:42 +0100 (CET) Date: Wed, 13 Dec 2017 09:43:42 +0100 From: bert hubert To: Stephane Bortzmeyer Cc: "zuopeng@cnnic.cn" , dnsop Message-ID: <20171213084342.GA30523@server.ds9a.nl> References: <2017121315404971736813@cnnic.cn> <20171213081823.GA8970@laperouse.bortzmeyer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171213081823.GA8970@laperouse.bortzmeyer.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 08:43:48 -0000 On Wed, Dec 13, 2017 at 09:18:23AM +0100, Stephane Bortzmeyer wrote: > > For example, a CDN provider can’t schedule 70% of traffic to node A > > and 30% of traffic to node B [...] adding a “weight” attribute > > First, the obvious question: why reinventing RFC 2782? Implementing this worthwhile capability can be done in four ways/places: 1) Get browsers to honour RFC 2782 2) Get resolvers and auths to support a weighted A/AAAA record (as proposed in this thread) 3) Serve up multiple copies of the same A record, and weigh like this: www IN A 1.2.3.4 www IN A 1.2.3.4 www IN A 10.11.12.13 And hope that record shuffling will deliver the 2:1 ratio 4) Get authoritative servers to serve A/AAAA with weighted frequency and short TTL Getting browsers to move is a 5 year project at least. You could get the resolver/auth landscape moving somewhat more quickly ('we know these people'), but it will still take a long time and support will be spotty. The 'multiple IP address listings' thing is done in practice, but some server remove duplicates, so it doesn't work that well. And the last possibility is what CDNs are actually doing. It does not quite spread out traffic perfectly, but it is good enough. In PowerDNS Authoritative Server 4.1.1 (upcoming in January), this looks like: @ IN LUA A "wrandom{{2, '1.2.3.4'}, {1, '10.11.12.13'}}" Or even: @ IN LUA A "whashed{{2, '1.2.3.4'}, {1, '10.11.12.13'}}" Which will keep the same IP address going to the same record. This is documented in https://powerdns.org/auth-4.1.1-docs/lua-records.html - which also lists things like @ IN LUA A "closest{'1.2.3.4', '10.11.12.13'}" which will attempt to serve up the geographically closest address. Bert From nobody Wed Dec 13 01:31:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421FE1270A7 for ; Wed, 13 Dec 2017 01:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 oQ1maTGoxFPd for ; Wed, 13 Dec 2017 01:31:11 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6EA124217 for ; Wed, 13 Dec 2017 01:31:09 -0800 (PST) Received: from CNNIC-THINK (unknown [218.241.103.198]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0DJ0Ohb8zBagNo7AA--.24784S2; Wed, 13 Dec 2017 17:31:07 +0800 (CST) Date: Wed, 13 Dec 2017 17:31:06 +0800 From: "zuopeng@cnnic.cn" To: "bert hubert" , "Stephane Bortzmeyer" Cc: dnsop References: <2017121315404971736813@cnnic.cn>, <20171213081823.GA8970@laperouse.bortzmeyer.org>, <20171213084342.GA30523@server.ds9a.nl> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 166[cn] Mime-Version: 1.0 Message-ID: <201712131731058457451@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart722701125202_=----" X-CM-TRANSID: AQAAf0DJ0Ohb8zBagNo7AA--.24784S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Zw47Jry7Kry7JFW7tr4Utwb_yoW8Cw18pF WfurZIkrs8WFyxuFWDu3WUGa4Fka47uFyxJr98W3yjvw45W3W7Wr1UGF4jvFy7JF10kayf tr48Jrn5Gas0vaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmIb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG62kEwI0E Y4vaYxAvb48xMc02F40E42I26xC2a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87 Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAY jxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07Mx8GjcxK6IxK0xIIj40E5I8CrwCY02 Avz4vE14v_GFWl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAq x4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y6r 17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF 7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14 v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6VACY4xI67k04243AbIYCTnI WIevJa73UjIFyTuYvjxUyLZcUUUUU X-CM-SenderInfo: x2xr1vlqj6u0xqlfhubq/ Archived-At: Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 09:31:14 -0000 This is a multi-part message in MIME format. ------=_001_NextPart722701125202_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 dGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIQ0KDQpBY2NvcmRpbmcgdG8gbXkgdW5kZXJzdGFuZGlu ZywgaGVyZSBhcmUgMiBtYWluIGRpZmZlcmVuY2VzIGJldHdlZW4gUkZDMjc4MiBhbmQgdGhpcyBp ZGVhIDoNCg0KKDEpIFJGQzI3ODIgZG9lcyBub3Qgc29sdmUgdGhlIHByb2JsZW0gb2YgdXNpbmcg bXVsdGktQ0ROICAobXVsdGlwbGUgQ05BTUUgY2Fubm90IGNvZXhpc3QpOw0KICAgIGhlcmUgd2Ug Y2FuIHVzZSBtdWx0aXBpbGUgd2VpZ2h0ZWQgQ05NQUVYcyAobmVlZCB0byBjb2V4aXN0IHdpdGgg Q05BTUUpIHRvIGFjY29tcGxpc2ggdGhpczsNCiAgICBiZXNpZGVzLCB3ZWlnaHRlZCBDTkFNRVhz IGNhbiBjb250cm9sIHRyYWZmaWMgcmF0aW8gYW1vbmcgc2V2ZXJhbCBDRE4gcHJvdmlkZXJzOw0K DQooMikgUkZDMjc4MiByZXF1aXJlcyBicm93c2VyJ3Mgc3VwcG9ydDsNCiAgICBVc2luZyB0aGlz IG1ldGhvZCwgYSBicm93c2VyIGhhcyBubyBpZGVhIGFib3V0IHdlaWdodGVkIEFYL0FBQUFYcy4g DQogICAgSXQgcmVxdWlyZXMgbm8gY2hhbmdlIG9mIGJyb3dzZXJzLg0KDQoNCg0KenVvcGVuZ0Bj bm5pYy5jbg0KIA0KRnJvbTogYmVydCBodWJlcnQNCkRhdGU6IDIwMTctMTItMTMgMTY6NDMNClRv OiBTdGVwaGFuZSBCb3J0em1leWVyDQpDQzogenVvcGVuZ0Bjbm5pYy5jbjsgZG5zb3ANClN1Ympl Y3Q6IFJlOiBbRE5TT1BdIEFzayBmb3IgYWR2aWNlIG9mIDMgbmV3IFJScyBmb3IgcHJlY2lzZSB0 cmFmZmljIHNjaGVkdWxpbmcNCk9uIFdlZCwgRGVjIDEzLCAyMDE3IGF0IDA5OjE4OjIzQU0gKzAx MDAsIFN0ZXBoYW5lIEJvcnR6bWV5ZXIgd3JvdGU6DQo+ID4gIEZvciBleGFtcGxlLCBhIENETiBw cm92aWRlciBjYW6hr3Qgc2NoZWR1bGUgNzAlIG9mIHRyYWZmaWMgdG8gbm9kZSBBDQo+ID4gIGFu ZCAzMCUgb2YgdHJhZmZpYyB0byBub2RlIEIgWy4uLl0gYWRkaW5nIGEgobB3ZWlnaHShsSBhdHRy aWJ1dGUNCj4gDQo+IEZpcnN0LCB0aGUgb2J2aW91cyBxdWVzdGlvbjogd2h5IHJlaW52ZW50aW5n IFJGQyAyNzgyPw0KIA0KSW1wbGVtZW50aW5nIHRoaXMgd29ydGh3aGlsZSBjYXBhYmlsaXR5IGNh biBiZSBkb25lIGluIGZvdXIgd2F5cy9wbGFjZXM6DQogDQoxKSBHZXQgYnJvd3NlcnMgdG8gaG9u b3VyIFJGQyAyNzgyDQogDQoyKSBHZXQgcmVzb2x2ZXJzIGFuZCBhdXRocyB0byBzdXBwb3J0IGEg d2VpZ2h0ZWQgQS9BQUFBIHJlY29yZCAoYXMgcHJvcG9zZWQNCmluIHRoaXMgdGhyZWFkKQ0KIA0K MykgU2VydmUgdXAgbXVsdGlwbGUgY29waWVzIG9mIHRoZSBzYW1lIEEgcmVjb3JkLCBhbmQgd2Vp Z2ggbGlrZSB0aGlzOg0Kd3d3IElOIEEgMS4yLjMuNA0Kd3d3IElOIEEgMS4yLjMuNA0Kd3d3IElO IEEgMTAuMTEuMTIuMTMNCkFuZCBob3BlIHRoYXQgcmVjb3JkIHNodWZmbGluZyB3aWxsIGRlbGl2 ZXIgdGhlIDI6MSByYXRpbw0KIA0KNCkgR2V0IGF1dGhvcml0YXRpdmUgc2VydmVycyB0byBzZXJ2 ZSBBL0FBQUEgd2l0aCB3ZWlnaHRlZCBmcmVxdWVuY3kgYW5kDQpzaG9ydCBUVEwNCiANCkdldHRp bmcgYnJvd3NlcnMgdG8gbW92ZSBpcyBhIDUgeWVhciBwcm9qZWN0IGF0IGxlYXN0LiBZb3UgY291 bGQgZ2V0IHRoZQ0KcmVzb2x2ZXIvYXV0aCBsYW5kc2NhcGUgbW92aW5nIHNvbWV3aGF0IG1vcmUg cXVpY2tseSAoJ3dlIGtub3cgdGhlc2UNCnBlb3BsZScpLCBidXQgaXQgd2lsbCBzdGlsbCB0YWtl IGEgbG9uZyB0aW1lIGFuZCBzdXBwb3J0IHdpbGwgYmUgc3BvdHR5Lg0KIA0KVGhlICdtdWx0aXBs ZSBJUCBhZGRyZXNzIGxpc3RpbmdzJyB0aGluZyBpcyBkb25lIGluIHByYWN0aWNlLCBidXQgc29t ZQ0Kc2VydmVyIHJlbW92ZSBkdXBsaWNhdGVzLCBzbyBpdCBkb2Vzbid0IHdvcmsgdGhhdCB3ZWxs Lg0KIA0KQW5kIHRoZSBsYXN0IHBvc3NpYmlsaXR5IGlzIHdoYXQgQ0ROcyBhcmUgYWN0dWFsbHkg ZG9pbmcuIEl0IGRvZXMgbm90IHF1aXRlDQpzcHJlYWQgb3V0IHRyYWZmaWMgcGVyZmVjdGx5LCBi dXQgaXQgaXMgZ29vZCBlbm91Z2guDQogDQpJbiBQb3dlckROUyBBdXRob3JpdGF0aXZlIFNlcnZl ciA0LjEuMSAodXBjb21pbmcgaW4gSmFudWFyeSksIHRoaXMgbG9va3MNCmxpa2U6DQogDQpAIElO IExVQSBBICJ3cmFuZG9te3syLCAnMS4yLjMuNCd9LCB7MSwgJzEwLjExLjEyLjEzJ319Ig0KIA0K T3IgZXZlbjoNCiANCkAgSU4gTFVBIEEgIndoYXNoZWR7ezIsICcxLjIuMy40J30sIHsxLCAnMTAu MTEuMTIuMTMnfX0iDQogDQpXaGljaCB3aWxsIGtlZXAgdGhlIHNhbWUgSVAgYWRkcmVzcyBnb2lu ZyB0byB0aGUgc2FtZSByZWNvcmQuDQogDQpUaGlzIGlzIGRvY3VtZW50ZWQgaW4gaHR0cHM6Ly9w b3dlcmRucy5vcmcvYXV0aC00LjEuMS1kb2NzL2x1YS1yZWNvcmRzLmh0bWwNCi0gd2hpY2ggYWxz byBsaXN0cyB0aGluZ3MgbGlrZSBAIElOIExVQSBBICJjbG9zZXN0eycxLjIuMy40JywgJzEwLjEx LjEyLjEzJ30iDQp3aGljaCB3aWxsIGF0dGVtcHQgdG8gc2VydmUgdXAgdGhlIGdlb2dyYXBoaWNh bGx5IGNsb3Nlc3QgYWRkcmVzcy4NCiANCiAgICAgQmVydA0KIA0KIA0KIA0KIA0K ------=_001_NextPart722701125202_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable =0A

=0A

=
On Wed, Dec 13, 2017 at 09:18:23AM +0100, Stephane Bortzme= yer wrote:
=0A
> >  For example, a CDN provider can=E2= =80=99t schedule 70% of traffic to node A
=0A
> >  and= 30% of traffic to node B [...] adding a =E2=80=9Cweight=E2=80=9D attribut= e
=0A
>
=0A
> First, the obvious question: why re= inventing RFC 2782?
=0A
 
=0A
Implementing this wor= thwhile capability can be done in four ways/places:
=0A
 =0A
1) Get browsers to honour RFC 2782
=0A
 
=0A=
2) Get resolvers and auths to support a weighted A/AAAA record (as pr= oposed
=0A
in this thread)
=0A
 
=0A
3) Se= rve up multiple copies of the same A record, and weigh like this:
=0A=
www IN A 1.2.3.4
=0A
www IN A 1.2.3.4
=0A
www IN A = 10.11.12.13
=0A
And hope that record shuffling will deliver the 2= :1 ratio
=0A
 
=0A
4) Get authoritative servers to = serve A/AAAA with weighted frequency and
=0A
short TTL
=0A 
=0A
Getting browsers to move is a 5 year project at lea= st. You could get the
=0A
resolver/auth landscape moving somewhat= more quickly ('we know these
=0A
people'), but it will still tak= e a long time and support will be spotty.
=0A
 
=0AThe 'multiple IP address listings' thing is done in practice, but some=0A
server remove duplicates, so it doesn't work that well.
= =0A
 
=0A
And the last possibility is what CDNs are actu= ally doing. It does not quite
=0A
spread out traffic perfectly, b= ut it is good enough. 
 
=0A
In P= owerDNS Authoritative Server 4.1.1 (upcoming in January), this looks
= =0A
like:
=0A
 
=0A
@ IN LUA A "wrandom{{2, '1.= 2.3.4'}, {1, '10.11.12.13'}}"
=0A
 
=0A
Or even:=0A
 
=0A
@ IN LUA A "whashed{{2, '1.2.3.4'}, {1, '10= .11.12.13'}}"
=0A
 
=0A
Which will keep the same IP= address going to the same record.
=0A
 
---------= -----> [zuopeng]  :  so far as i know, many CDNs already use = similar methods as you mentioned in PowerDNS 4.1.1 
-------= -------> [zuopeng]  :  but  i think only the &= nbsp;Authoritative Server change is not enough,  support = on the recursive server is also very important .
-------------= -> [zuopeng]  :   because the resolver determines t= he reponse to clients.

=0A
This is documented in = https://powerdns.org/auth-4.1.1-docs/lua-records.html
=0A
- which= also lists things like @ IN LUA A "closest{'1.2.3.4', '10.11.12.13'}"=0A
which will attempt to serve up the geographically closest addres= s.
=0A



 
= =0A
     Bert
=0A
 
=0A
&nb= sp;
=0A
 
=0A
 
=0A
=0A ------=_001_NextPart322565235456_=------ From nobody Wed Dec 13 01:50:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9752B126BF0 for ; Wed, 13 Dec 2017 01:50:34 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 iWMZkq94xh4b for ; Wed, 13 Dec 2017 01:50:28 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338F8124B17 for ; Wed, 13 Dec 2017 01:50:27 -0800 (PST) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 502919FB57; Wed, 13 Dec 2017 09:50:16 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id EDBCDAC3FFA; Wed, 13 Dec 2017 10:50:15 +0100 (CET) Date: Wed, 13 Dec 2017 10:50:15 +0100 From: bert hubert To: "zuopeng@cnnic.cn" Cc: Stephane Bortzmeyer , dnsop Message-ID: <20171213095015.GC30523@server.ds9a.nl> References: <2017121315404971736813@cnnic.cn> <20171213081823.GA8970@laperouse.bortzmeyer.org> <20171213084342.GA30523@server.ds9a.nl> <201712131736325755287@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201712131736325755287@cnnic.cn> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 09:50:34 -0000 On Wed, Dec 13, 2017 at 05:36:32PM +0800, zuopeng@cnnic.cn wrote: > so far as i know, many CDNs already use similar methods as you mentioned in PowerDNS 4.1.1 > but i think only the Authoritative Server change is not enough, support on the recursive server is also very important . > because the resolver determines the reponse to clients. This is true. A typical resolver will serve around 50,000 to 2,000,000 users (although this is rare). This means that for 60 seconds, you shift around 'a hundred thousand' potential users. In practice, this appears to be good enough from what I hear. Or let me put it another way, before we burden the DNS protocol with another record type we have to add downgrade/workaround/DNSSEC support for, we should have numbers that say it solves a problem. CDNs could maybe chime in. Bert From nobody Wed Dec 13 01:58:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F54127B60 for ; Wed, 13 Dec 2017 01:58:10 -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] 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 7RsJ511h2dkG for ; Wed, 13 Dec 2017 01:58:08 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 77161126C26 for ; Wed, 13 Dec 2017 01:58:08 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 4FA0D31CBA; Wed, 13 Dec 2017 10:58:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id 26F13190888; Wed, 13 Dec 2017 10:55:34 +0100 (CET) Date: Wed, 13 Dec 2017 10:55:34 +0100 From: Stephane Bortzmeyer To: "zuopeng@cnnic.cn" Cc: bert hubert , Stephane Bortzmeyer , dnsop Message-ID: <20171213095533.tpd52wo6xy7v6qct@sources.org> References: <2017121315404971736813@cnnic.cn> <20171213081823.GA8970@laperouse.bortzmeyer.org> <20171213084342.GA30523@server.ds9a.nl> <201712131731058457451@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201712131731058457451@cnnic.cn> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 9.1 X-Charlie: Je suis Charlie User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 09:58:11 -0000 On Wed, Dec 13, 2017 at 05:31:06PM +0800, zuopeng@cnnic.cn wrote a message of 130 lines which said: > (2) RFC2782 requires browser's support; Client support. This is even worse, there are much more HTTP clients than browsers. > Using this method, a browser has no idea about weighted AX/AAAAXs. > It requires no change of browsers. But it requires change in all resolvers. One may wonder which will be the fastest path. From nobody Wed Dec 13 02:25:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61E3126BF0 for ; Wed, 13 Dec 2017 02:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 WPPZIf0qaFbF for ; Wed, 13 Dec 2017 02:25:32 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 4F9A7126B7F for ; Wed, 13 Dec 2017 02:25:32 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id t8so3926521wmc.3 for ; Wed, 13 Dec 2017 02:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k/1f0Rsg3pqV+ZN0oIGi0f48IgQqfgXv7XoX/RbihH0=; b=rZHVYdt4SsMuuK1dH2wgwKnNGQ/YcnVJthURXouX3qVLs6ACmzRRs4wL0EsVbVbbMa lkERXWr69bCmL1Aeelc/0O+NpglOflMzADrL6l0ocAPaVO7+4j249Wwp9W7yqHzEL2Zv 76b8McyVcEZYkoFBWLG7H3Dv9yOufpCB4V+cMk1maM/cup9/f1KyOEARgO43lHdOf3Cn H37PZR+gjztwTR7uyJj0hKjqVJziMZfMckaX6p7MM0TTmu5/VnDLRhg3CWbMM7QuuwZr vJIugSXns9qgHjrI2E5ivhFneHxAr8H+y3+NlbSIjfvZ85cNRSzxpGr31de8M9HaKZWa 4Bqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k/1f0Rsg3pqV+ZN0oIGi0f48IgQqfgXv7XoX/RbihH0=; b=rV/6P+lCNFXzNPYkme8othNZZK88GIZeRixLML8EEs+Zj7GR/DzBqmdkl2YeOJoM4k dAR2MvHbYN9cfbOLXCxhhHrY3H2FjIC+T2m2gvsll38j2i7Ta3wYLrCqljzdRLZJysQW Or63jT7KHnKYNEIniA0TVb5cX0O/7IcF6NfS1CNgdRhxsULGKEpAG7OkFfyeqqBaxocm BbcitNqoUedTQQNXPXqQZM5oK4tNVCaqu1NjbERpnuox4Qj9jE4EYBHCULmahF5iJfHj WZAR9fJ4jB5qisAbx7+5NjFVjzCmQXnLKQxlTQKK00wTHLevhFCX1ehlY2RrXGG+hIR3 P22w== X-Gm-Message-State: AKGB3mIlKF4wxgepkBRwvWtikvlaQs7eJV+Gepg4o3e/MN9G7UGy0gRn YMi0+NOsNL4mYHxMH/Z2PWPf5rJ0fWPT69NiUWs= X-Google-Smtp-Source: ACJfBou18k1pyq/XKE4sA13VKZOWtNqJYch7eFqYZZJI8tb6cvIUSPWCd6/3cI+0/u6F1LTqkLrGexZchkYfaPNtH3c= X-Received: by 10.80.169.115 with SMTP id m48mr7017809edc.118.1513160730839; Wed, 13 Dec 2017 02:25:30 -0800 (PST) MIME-Version: 1.0 References: <2017121315404971736813@cnnic.cn> <20171213081823.GA8970@laperouse.bortzmeyer.org> <20171213084342.GA30523@server.ds9a.nl> <201712131731058457451@cnnic.cn> <20171213095533.tpd52wo6xy7v6qct@sources.org> In-Reply-To: <20171213095533.tpd52wo6xy7v6qct@sources.org> From: Lanlan Pan Date: Wed, 13 Dec 2017 10:25:20 +0000 Message-ID: To: Stephane Bortzmeyer Cc: "zuopeng@cnnic.cn" , dnsop , bert hubert Content-Type: multipart/alternative; boundary="94eb2c0de3b2d98e250560362fed" Archived-At: Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 10:25:34 -0000 --94eb2c0de3b2d98e250560362fed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Stephane Bortzmeyer =E4=BA=8E2017=E5=B9=B412=E6=9C=8813= =E6=97=A5=E5=91=A8=E4=B8=89 =E4=B8=8B=E5=8D=885:58=E5=86=99=E9=81=93=EF=BC= =9A > On Wed, Dec 13, 2017 at 05:31:06PM +0800, > zuopeng@cnnic.cn wrote > a message of 130 lines which said: > > > (2) RFC2782 requires browser's support; > > Client support. This is even worse, there are much more HTTP clients > than browsers. > > > Using this method, a browser has no idea about weighted AX/AAAAXs. > > It requires no change of browsers. > > But it requires change in all resolvers. One may wonder which will be > the fastest path. > something like ANAME ? ANAME can let resolvers choose IP for clients. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --94eb2c0de3b2d98e250560362fed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 13, 2017 at 05:31:06PM +0800,
=C2=A0zuopeng@cnnic.c= n <zuopeng@cnn= ic.cn> wrote
=C2=A0a message of 130 lines which said:

> (2) RFC2782 requires browser's support;

Client support. This is even worse, there are much more HTTP clients
than browsers.

>=C2=A0 =C2=A0 =C2=A0Using this method, a browser has no idea about weig= hted AX/AAAAXs.
>=C2=A0 =C2=A0 =C2=A0It requires no change of browsers.

But it requires change in all resolvers. One may wonder which will be
the fastest path.
something like ANAME ?
ANAME can let resolvers choose IP for clients.

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
=E8=87=B4=E7= =A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanl= an
--94eb2c0de3b2d98e250560362fed-- From nobody Wed Dec 13 02:33:12 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A47A126BF0 for ; Wed, 13 Dec 2017 02:33:11 -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] 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 vIQBndcMGLvm for ; Wed, 13 Dec 2017 02:33:09 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 E76AE1241F3 for ; Wed, 13 Dec 2017 02:33:08 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id CF78731CBA; Wed, 13 Dec 2017 11:33:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id AEAB5190888; Wed, 13 Dec 2017 11:29:02 +0100 (CET) Date: Wed, 13 Dec 2017 11:29:02 +0100 From: Stephane Bortzmeyer To: Kim Davies Cc: Mark Andrews , dnsop@ietf.org, Paul Vixie , Joe Abley Message-ID: <20171213102902.d4lypaz3azyvfylf@sources.org> References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> <73B3C074-6B88-4BCC-8F0C-26D09066CD0A@isc.org> <20171211231643.GA73777@KIDA-6861.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171211231643.GA73777@KIDA-6861.local> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 9.1 X-Charlie: Je suis Charlie User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 10:33:11 -0000 On Mon, Dec 11, 2017 at 03:16:46PM -0800, Kim Davies wrote a message of 22 lines which said: > the delegation to AS112 was considered as the best short-term > approach even if it is not without its own difficulties. Interesting information, thanks. But the original question was about privacy. Was it considered or do people in charge felt it was, as Paul Vixie mentioned, a false problem here? From nobody Wed Dec 13 03:42:42 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCCE127869 for ; Wed, 13 Dec 2017 03:42:41 -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 nWrHbBRoiaBM for ; Wed, 13 Dec 2017 03:42:38 -0800 (PST) Received: from off-send01.osa.jprs.co.jp (off-send01.osa.jprs.co.jp [IPv6:2001:218:3001:17::10]) (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 917CF12704A for ; Wed, 13 Dec 2017 03:42:38 -0800 (PST) Received: from off-sendsmg01.osa.jprs.co.jp (off-sendsmg01.osa.jprs.co.jp [172.23.8.61]) by off-send01.osa.jprs.co.jp (8.14.4/8.14.4) with ESMTP id vBDBgaVi031045; Wed, 13 Dec 2017 20:42:36 +0900 Received: from off-sendsmg01.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 0ABEF180064; Wed, 13 Dec 2017 20:42:35 +0900 (JST) Received: from localhost (off-cpu05.osa.jprs.co.jp [172.23.4.15]) by off-sendsmg01.osa.jprs.co.jp (Postfix) with ESMTP id EEA12180062; Wed, 13 Dec 2017 20:42:34 +0900 (JST) Date: Wed, 13 Dec 2017 20:42:34 +0900 (JST) Message-Id: <20171213.204234.76214525553211985.fujiwara@jprs.co.jp> To: marka@isc.org Cc: paul.hoffman@vpnc.org, dnsop@ietf.org From: fujiwara@jprs.co.jp In-Reply-To: <56BEBCFA-D6BA-4BD1-8B95-190375A57C06@isc.org> References: <707A270D-94DA-4651-84DC-409FAA6793F7@vpnc.org> <56BEBCFA-D6BA-4BD1-8B95-190375A57C06@isc.org> X-Mailer: Mew version 6.5 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1690-8.1.0.1062-23526.006 X-TM-AS-Result: No--17.922-5.0-31-10 X-imss-scan-details: No--17.922-5.0-31-10 X-TMASE-MatchedRID: OG1R3ABYgXVCXIGdsOwlUu5i6weAmSDKZggZX8gYmrWo+b+yOP0oGOpE FRRvN3IB96TYN1fO8g5GZriJw3SdwS9ZO3Tqscr3vHKClHGjjr303H/AL/kEgKq9wgXVNwtgwhq t+ExJxk9DH3mncZiZz0QrLyfCx79pMKdTZQIXfrK5kfgtJfb41bQ0n3DEfu2Tayjbe4qUImMWmI 05cBtyEmUAHvSQ6dDi1Wp8KUPhaLX0GGSQQaBfERLuW4a3q2WGZijLrBI/sgWKS8s/FMqmOAB8L 4mI6Eq2lv+ZOeQz9IgcOfC+voH6NBgHZ8655DOP0gVVXNgaM0r9b0xgYrma7X1qym0z6Q4r8Bdx bGBwPnKxmoQAAdv2lPoLR4+zsDTtX28xNpU0U3NLeKtw9gociTBCOBIFrFX7wXaFagMDdCK4O7l fYktFJQ== Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 11:42:41 -0000 VGhhbmtzLg0KDQp0ZXJtaW5vbG9neS1iaXMtMDg6DQp8IEluLWJhaWxpd2ljazogQW4gYWRqZWN0 aXZlIHRvIGRlc2NyaWJlIGEgbmFtZSBzZXJ2ZXIgd2hvc2UgbmFtZSBpcw0KfCAgICBlaXRoZXIg c3Vib3JkaW5hdGUgdG8gb3IgKHJhcmVseSkgdGhlIHNhbWUgYXMgdGhlIHpvbmUgb3JpZ2luLg0K DQpPaywgSW4tYmFpbHdpY2sgaW4gdGVybWlub2xvZ3ktYmlzLTA4IG1heSBiZSByZXN0cmljdGl2 ZSBiZWNhdXNlICJ0aGUNCnpvbmUgb3JpZ2luIiBpcyB1bmNsZWFyLiBJIGludGVuZGVkIHRoYXQg InRoZSB6b25lIG9yaWdpbiIgaXMgdGhlIHpvbmUNCm9yaWdpbiBvZiBwYXJlbnQgem9uZS4gVGhl IHNlbnRlbmNlIG5lZWRzIG1vcmUgd29yZHMuDQoNCk5FVw0KDQogIEluLWJhaWxpd2ljazogQW4g YWRqZWN0aXZlIHRvIGRlc2NyaWJlIGEgbmFtZSBzZXJ2ZXIgd2hvc2UgbmFtZSBpcw0KICAgICAg IGVpdGhlciBzdWJvcmRpbmF0ZSB0byBvciAocmFyZWx5KSB0aGUgc2FtZSBhcyB0aGUgb3JpZ2lu DQogICAgICAgb2YgdGhlIHpvbmUgdGhhdCBjb250YWlucyB0aGUgZGVsZWdhdGlvbiB0byB0aGUg bmFtZSBzZXJ2ZXIuDQoNCi4uLiBiYWQgZW5nbGlzaCB0ZXh0IC4uLiBwbGVhc2UgZml4Lg0KDQot LQ0KS2F6dW5vcmkgRnVqaXdhcmEsIEpQUlMgPGZ1aml3YXJhQGpwcnMuY28uanA+DQoNCj4gRnJv bTogTWFyayBBbmRyZXdzIDxtYXJrYUBpc2Mub3JnPg0KPiBUaGUgdGV4dCBmb3IgImluLWJhaWx3 aWNrIiBpcyB0b28gcmVzdHJpY3RpdmUsIGl0IGRvZXNuonQganVzdCBjb3ZlciBOUyByZWNvcmRz IG9yDQo+IGdsdWUgcmVjb3Jkcy4NCj4gDQo+IEluLWJhaWx3aWNrIHJlZmVycyB0byByZWNvcmRz IHRoYXQgaW4gdGhlIG5vcm1hbCBjb3Vyc2Ugb2YgRE5TIHJlc29sdXRpb24NCj4gd291bGQgaGF2 ZSBiZWVuIHJlcXVlc3RlZCBvZiBieSB0aGUgc2VydmVyIHRoZSBjdXJyZW50IHJlc3BvbnNlIGlz IGZyb20uDQo+IGUuZy4gaWYgeW91IGFyZSBxdWVyeWluZyBhIC5jb20gc2VydmVyIHRoZW4gYWxs IHJlY29yZHMgaW4gdGhlIHJlc3BvbnNlIHRoYXQgZW5kDQo+IHdpdGggLmNvbSBhcmUgaW4tYmFp bHdpY2suDQo+IA0KPiBNYXJrDQo+IA0KPj4gT24gNSBEZWMgMjAxNywgYXQgNToyNyBhbSwgUGF1 bCBIb2ZmbWFuIDxwYXVsLmhvZmZtYW5AdnBuYy5vcmc+IHdyb3RlOg0KPj4gDQo+PiBHcmVldGlu Z3MgYWdhaW4uDQo+PiANCj4+IFNvbWUgb2YgdGhlIG5ldyB0ZXJtcyBhZGRlZCB0byB0aGUgdGVy bWlub2xvZ3ktYmlzIGRyYWZ0IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWRuc29wLXRlcm1pbm9sb2d5LWJpcy8pc2luY2UgUkZDIDc3MTkgY2FuIGJlIGEgYml0 IHRyaWNreS4gVGhpcyB3ZWVrLCB3ZSBob3BlIHlvdSB3aWxsIGxvb2sgYXQgdGhlIGRlZmluaXRp b25zIGluIHRoZSBkcmFmdCBmb3I6DQo+PiAtIEluLWJhaWxpd2ljaw0KPj4gLSBPdXQtb2YtYmFp bGl3aWNrDQo+PiAtIEluLWRvbWFpbg0KPj4gLSBTaWJsaW5nIGRvbWFpbg0KPj4gUGxlYXNlIHJl dmlldyB0aGVzZSB0ZXJtcyBhbmQgY29tbWVudCBvbiB0aGUgbGlzdCBpZiB5b3UgdGhpbmsgdGhl IGRlZmluaXRpb25zIHNob3VsZCBjaGFuZ2UuDQo+PiANCj4+IC0tUGF1bCBIb2ZmbWFuDQo+PiAN Cj4+IFtbIEFzIGEgcmVtaW5kZXIsIHdlIGFza2VkIHRoZSBmb2xsb3dpbmcgbGFzdCB3ZWVrLCBi dXQgZ290IG5vIHJlcGx5OiBGb3IgdGhlIHBhc3QgbWFueSB2ZXJzaW9ucyBvZiB0aGUgdGVybWlu b2xvZ3ktYmlzIGRyYWZ0IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWRuc29wLXRlcm1pbm9sb2d5LWJpcy8pLCBTZWN0aW9uIDIgaGFzIGRlZmluaXRpb25zIG9m ICJHbG9iYWwgRE5TIiBhbmQgIlByaXZhdGUgRE5TIiwgYmFzZWQgb24gdGhlIGZhY2V0cyBsaXN0 ZWQgaW4gIk5hbWluZyBzeXN0ZW0iLiBUaGlzIHdhcyBkaXNjdXNzZWQgaGVhdmlseSBvbiB0aGUg bGlzdCBlYXJsaWVyLCBidXQgaXQgaXMgYWxzbyBhIHByZXR0eSBiaWcgY2hhbmdlLCBzbyB3ZSB3 YW50IHRvIGJlIHN1cmUgdGhhdCBpdCBpcyB3aGF0IHRoZSBXRyB3YW50cy4gUGxlYXNlIHJldmll dyB0aGVzZSB0ZXJtcyBhbmQgY29tbWVudCBvbiB0aGUgbGlzdCBpZiB5b3UgdGhpbmsgdGhlIGRl ZmluaXRpb25zIHNob3VsZCBjaGFuZ2UuIF1dDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBETlNPUCBtYWlsaW5nIGxpc3QNCj4+IERO U09QQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ru c29wDQo+IA0KPiAtLSANCj4gTWFyayBBbmRyZXdzLCBJU0MNCj4gMSBTZXltb3VyIFN0LiwgRHVu ZGFzIFZhbGxleSwgTlNXIDIxMTcsIEF1c3RyYWxpYQ0KPiBQSE9ORTogKzYxIDIgOTg3MSA0NzQy ICAgICAgICAgICAgICBJTlRFUk5FVDogbWFya2FAaXNjLm9yZw0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRE5TT1AgbWFpbGluZyBsaXN0 DQo+IEROU09QQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZG5zb3ANCj4gDQo= From nobody Wed Dec 13 13:46:10 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315BC126DEE for ; Wed, 13 Dec 2017 13:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 rCBxjxmYm5Nr for ; Wed, 13 Dec 2017 13:46:07 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 EFCBC126D73 for ; Wed, 13 Dec 2017 13:46:06 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id m11so22391085iti.1 for ; Wed, 13 Dec 2017 13:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CVlsBCPEbXUL9xnH0bMvigwLSJKBF1NH9S11t0FK/v8=; b=UOTNKyE+0dk35RHKbN/4TKuBPUnREKT64r9OVrLY8j2aQXmWUSTtT9LctPgvr+ylEX n6JX4tbKmHt5uPeKkuE3oiBWss5V2sXxhmiuYkru5jIG5n2V4zRrjbsKen2MjH0S1fUJ Lse+gXtifivL9WoZ7pXpF7O1neSF2TTv7uxPE= 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=CVlsBCPEbXUL9xnH0bMvigwLSJKBF1NH9S11t0FK/v8=; b=sk+hAAgXUTvWN1tsXrCMAjPjwazXdZ8yHbPKFrv+B4brbH0Si3qk9f+IoV7vwpn/+U 436ltns7SFxWDWqkJrjXN6KFa4FtwQIYsQsuV530+Eapk9plESjcl96iraCzk1bePzhq Z95BQMvSmbdU6daJBQO54fovLBE4r7ZrMSqj1HE78RPqFSjNHORsbCDWenOqKzJ4okm6 Pw/m60uyu8zJSX6W+7rr3b709/fHKRyyk8jY9ua3UjfPEYnymSrrE/q7dzMnGoz3gfgE x61tAGI834+RhBQWI1q/fmAeYzpbRHl5JE+CZ/ZF5oWV0CVMu+/wFUt/V/QGtG+nxnVP laug== X-Gm-Message-State: AKGB3mJuEs9uK3U7Oyg66lb/TAZ0eS8njV45lUb1uqrLo+dfwTiW4CVH KMVYFIpNFhIGkP9YMfMAjFe+RI06yl8= X-Google-Smtp-Source: ACJfBovN8+0dxpxgTsRGX8aFu1p5F55420SnTH1v2sVR6swZrURDedyGAxsxlzlrkp9YhjLBudeK3A== X-Received: by 10.36.9.146 with SMTP id 140mr609938itm.54.1513201566299; Wed, 13 Dec 2017 13:46:06 -0800 (PST) Received: from [199.212.92.9] (135-23-173-35.cpe.pppoe.ca. [135.23.173.35]) by smtp.gmail.com with ESMTPSA id i82sm1297840iod.6.2017.12.13.13.46.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 13:46:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Abley In-Reply-To: <1B37BBA1-D141-441A-855E-1ACFF2DC15BD@fugue.com> Date: Wed, 13 Dec 2017 16:46:00 -0500 Cc: Stephane Bortzmeyer , dnsop@ietf.org, Paul Vixie Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> <1B37BBA1-D141-441A-855E-1ACFF2DC15BD@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 21:46:09 -0000 On 11 Dec 2017, at 19:50, Ted Lemon wrote: > On Dec 11, 2017, at 11:17 AM, Joe Abley wrote: >> Note though that the homenet document specifically requests a = delegation. >=20 > Please do not read more into the document than was intended. What = Mark is saying looks to me like an accurate representation of what we = intended. The goal is simply for it to be the case that there is not = an unsigned delegation for home.arpa, which means that it has to point = _somewhere_. I am a bit frustrated to hear that this is turning into a = substantial amount of effort. It should be extremely simple. There = is no wrong answer for what the delegation looks like other than = "signed." So it's fine if the delegation is secure (which is I presume what you = mean by signed) but lame? The document actually specifies quite clearly that the delegation "MUST = NOT include a DS record" which seems to be different from what you are = saying. It also specifies that the delegation "MUST point to one or more = black hole servers", which is pretty vague language following a MUST. I appreciate that the intention of homenet may well have been clear, but = the text in section 7 is definitely not clear. I think actually it would = have been reasonable for IANA to send it back as ambiguous before it got = to the RFC Editor queue. Joe= From nobody Wed Dec 13 14:09:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875711274A5 for ; Wed, 13 Dec 2017 14:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 itZDk7pLuj-0 for ; Wed, 13 Dec 2017 14:09:21 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 47402128954 for ; Wed, 13 Dec 2017 14:09:18 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id DC6D83AF56F; Wed, 13 Dec 2017 22:09:15 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C906B160041; Wed, 13 Dec 2017 22:09:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B151716007E; Wed, 13 Dec 2017 22:09:15 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id p7eOy7v7225c; Wed, 13 Dec 2017 22:09:15 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id AF168160041; Wed, 13 Dec 2017 22:09:14 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: Date: Thu, 14 Dec 2017 09:09:12 +1100 Cc: Ted Lemon , Paul Vixie , dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> <1B37BBA1-D141-441A-855E-1ACFF2DC15BD@fugue.com> To: Joe Abley X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 22:09:23 -0000 Section 7 says: "In order to be fully functional, there must be a delegation of = 'home.arpa' in the '.arpa' zone [RFC3172]. This delegation MUST NOT be = signed, MUST NOT include a DS record, and MUST point to one or more = black hole servers, for example BLACKHOLE-1.IANA.ORG and = BLACKHOLE-2.IANA.ORG. The reason that this delegation must not be signed = is that not signing the delegation breaks the DNSSEC chain of trust, = which prevents a validating stub resolver from rejecting names published = under 'home.arpa' on a homenet name server." Thats a INSECURE DELEGATION and machines that return NXDOMAIN for = *.HOME.ARPA. Note it says =E2=80=9Cfor example=E2=80=9D. The names of = the servers the zone is delegated to are NOT proscribed there, just the = functionality. RFC 6303 has similar requirements and IANA was able to co-ordinate those = delegation. "As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA namespaces, = the zones listed above will need to be delegated as insecure = delegations, or be within insecure zones. This will allow DNSSEC = validation to succeed for queries in these spaces despite no t being = answered from the delegated servers.=E2=80=9D Mark > On 14 Dec 2017, at 8:46 am, Joe Abley wrote: >=20 > On 11 Dec 2017, at 19:50, Ted Lemon wrote: >=20 >> On Dec 11, 2017, at 11:17 AM, Joe Abley wrote: >>> Note though that the homenet document specifically requests a = delegation. >>=20 >> Please do not read more into the document than was intended. What = Mark is saying looks to me like an accurate representation of what we = intended. The goal is simply for it to be the case that there is not = an unsigned delegation for home.arpa, which means that it has to point = _somewhere_. I am a bit frustrated to hear that this is turning into a = substantial amount of effort. It should be extremely simple. There = is no wrong answer for what the delegation looks like other than = "signed." >=20 > So it's fine if the delegation is secure (which is I presume what you = mean by signed) but lame? >=20 > The document actually specifies quite clearly that the delegation = "MUST NOT include a DS record" which seems to be different from what you = are saying. It also specifies that the delegation "MUST point to one or = more black hole servers", which is pretty vague language following a = MUST. >=20 > I appreciate that the intention of homenet may well have been clear, = but the text in section 7 is definitely not clear. I think actually it = would have been reasonable for IANA to send it back as ambiguous before = it got to the RFC Editor queue. >=20 >=20 > Joe > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Dec 13 14:15:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23731126D85 for ; Wed, 13 Dec 2017 14:15:05 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 6V_Eby2P_B8o for ; Wed, 13 Dec 2017 14:15:03 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 C34901205F0 for ; Wed, 13 Dec 2017 14:14:56 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id d4so5697498qtj.5 for ; Wed, 13 Dec 2017 14:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dd8vQ+NwJxd6SirZ2NKrKPWpDdcFt1Xgdglju75hEk8=; b=v1Vpd6KpFbsMo7pA2aXbzAV1IbAGN0H5DOG4j6PI0Mac+4JflKnuORa042fqYzJwt5 +vtBbzbZJj8+DKuMMN7SuR1cvBLuh3mETyyIPyWCHxawwxDjk3S7HYYlSq9W+p9ZXysu nvPWaxZ9/glwg+nhZy21J46cOHirDHKii6YXpbQ9WilRynTQBzUoJflGQqQBkDUco+tA YL0wZu/e+jZWQ660IIsOqcAw+HgD1aGV2zIAMDWOdL2NfueB4R7jHQA9+IRfjjXoAc7i rAqSIe9BrknfW1skVgoRNxk72iGA5btAv3tH9jj4kqQDQjxWWfWdEpSA2GFGdLjRVZrM cQJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=dd8vQ+NwJxd6SirZ2NKrKPWpDdcFt1Xgdglju75hEk8=; b=lOchcDQwU1nzqm8wUvZyP3ADU8f+qamCA2XmGkpokdD4vtEUaMtuPtKZTRpTUnJb4/ Rips41EH5Q4bWRnJDWYlUGCdwSFd3DO5ELMgUxzXCG6YeZ6YHhvXTWE1Xg2M7RDu2Srr UxuCa60XLL7rwD7j0lk+KL/RgDmk3EobIK21cP5IcL/2Jb1ZZcbbWL+6QVOotNPhzH29 0X5AGyV2CJklm7TzOPSY+yZJNvGqYTvBCc5PS7gyqL20BuRIXiNXV7H+hSDy8d4yR+Ga auXy073fAzMwf9qKl0JtsZ+wlqu7pVw0PNT+bxsWJhlaywTbNXHvTETzF55searODPR5 f0Hw== X-Gm-Message-State: AKGB3mLgSYhXn1iVhIY8PzqNIinGkF4279WmWLxZbpC9XdsiLG4udcbF G9Ed1smqIPxfeO+iWc2EDwSod4w9bNY= X-Google-Smtp-Source: ACJfBotx2B0/GH8RlNiN0RFxbLwSZu0LJzbmBM91x1fAfjd8rezv6pcOMM3JnjY5GXnUbnb/m3rmDQ== X-Received: by 10.237.63.121 with SMTP id q54mr13522072qtf.337.1513203295930; Wed, 13 Dec 2017 14:14:55 -0800 (PST) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id a17sm1706839qkj.6.2017.12.13.14.14.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 14:14:55 -0800 (PST) From: Ted Lemon Message-Id: <23CF8A88-F530-426D-A6A9-4B80AF28D603@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8A4C44B3-0598-4E5A-9B06-EF4C3E2D29FD" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 13 Dec 2017 17:14:54 -0500 In-Reply-To: Cc: Stephane Bortzmeyer , dnsop@ietf.org, Paul Vixie To: Joe Abley References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> <1B37BBA1-D141-441A-855E-1ACFF2DC15BD@fugue.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 22:15:05 -0000 --Apple-Mail=_8A4C44B3-0598-4E5A-9B06-EF4C3E2D29FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 13, 2017, at 4:46 PM, Joe Abley wrote: > The document actually specifies quite clearly that the delegation = "MUST NOT include a DS record" which seems to be different from what you = are saying. It also specifies that the delegation "MUST point to one or = more black hole servers", which is pretty vague language following a = MUST. I second-guessed myself on the double negative in the previous message. = What I meant, and what I believe the document clearly says, is that = there must be a delegation, and it must not be signed. The point of = this is to avoid either a secure denial of existence (the status quo) or = a secure delegation. Either of these would completely prevent = home.arpa from working for a validating stub. > I appreciate that the intention of homenet may well have been clear, = but the text in section 7 is definitely not clear. I think actually it = would have been reasonable for IANA to send it back as ambiguous before = it got to the RFC Editor queue. Can you point to the actual ambiguity? The reason we said "one or more = black hole servers" was to leave it up to the operator of .arpa to = decide which black hole servers and how many of them. That was a = deliberate choice, not an omission. --Apple-Mail=_8A4C44B3-0598-4E5A-9B06-EF4C3E2D29FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Dec 13, 2017, at 4:46 PM, Joe Abley <jabley@hopcount.ca> = wrote:
The document = actually specifies quite clearly that the delegation "MUST NOT include a = DS record" which seems to be different from what you are saying. It also = specifies that the delegation "MUST point to one or more black hole = servers", which is pretty vague language following a MUST.

I second-guessed = myself on the double negative in the previous message.   What I = meant, and what I believe the document clearly says, is that there must = be a delegation, and it must not be signed.   The point of this is = to avoid either a secure denial of existence (the status quo) or a = secure delegation.   Either of these would completely prevent = home.arpa from working for a validating stub.

I appreciate that = the intention of homenet may well have been clear, but the text in = section 7 is definitely not clear. I think actually it would have been = reasonable for IANA to send it back as ambiguous before it got to the = RFC Editor queue.

Can you point to the actual ambiguity?   The reason we = said "one or more black hole servers" was to leave it up to the operator = of .arpa to decide which black hole servers and how many of them.   = That was a deliberate choice, not an omission.

= --Apple-Mail=_8A4C44B3-0598-4E5A-9B06-EF4C3E2D29FD-- From nobody Wed Dec 13 14:57:01 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEAE1274A5 for ; Wed, 13 Dec 2017 14:56:59 -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 (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 T0wv2jAtENX0 for ; Wed, 13 Dec 2017 14:56:57 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 E281E1201F8 for ; Wed, 13 Dec 2017 14:56:56 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id i4so2703944uab.5 for ; Wed, 13 Dec 2017 14:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xbp+sIqC5X696nVk4K8MiuuQnzkl+1LOjI+VLGPPL9Y=; b=yQUVM+hlDqKF7ljnke3Bffsm/Og9xeLmkqaHh36yiImQawODli4W8mvGL6CucMKmKZ lH5B5j5/6PZ0Gddr7rwyjH4hS3wQ/z2h/y1vuZ787D3jVm+nCHs1VEj0adkNVyEoJWLK SJtEe0xfNmgRqSydJ/eShnEENQWv0NWD9U01G3nwfnT5IaViNlgeZi9S92LOrxTXxomp 6r4U7QxdrdC79PwgpYOj+81alAVCtOb4S7iV5CDnda0zZSZWZ6EkfCYx4CzyPbfx/+I0 yO9AvpJOA9/RcJfYM+CcO3uSdLTL6Qy+QAtFDaIC89oP39rzXBnPOh9TEZnT+/RTVGHw eDVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xbp+sIqC5X696nVk4K8MiuuQnzkl+1LOjI+VLGPPL9Y=; b=MN7mi/vc7beQWqUM83PIHunXPtDJH0kvH4AYKMhDNDOvxtJynzHq8kILoXdFqcSJgg Zhw6OJLrOL9IzdmkgW7kFb8DiOI/7ROdzR8r20nIuWe2UhgaZPUmU3pJZEFvoDOXGAzN P2dT7E0pC6gE0yYFpJvwMGOL+hphBKMGSaImnXi7E22CCop7ColZVR3HuUqe+LnCEVjW MxvYikQAfEitiD/zaP+OpMiXkvR0bDv3fbXwN16nzN/+yHE89pqM7Db7A7QckJabKcS0 JrIwAahqs9Q4mTpdTIv2alznyENbQcu2eHtyATeqb+SfbDExA3Cklmw4l6YfQ0IrRSMN 5lXA== X-Gm-Message-State: AKGB3mLwg8fY9IjBz1eKKr5MpT/mrRY3ZFW1haMQXHRDkXo9vUdz7tGB 2gG3Jp1j6tesC35c8heQ/0LWHuRbOmbXo/OE4dgF7A== X-Google-Smtp-Source: ACJfBotikkg0H/mhrStDAIsd+D3CqZsAxYUPz6JtxrJDm7wZrJ+Ht8OPg7AZ6Uks3+Y2BmJoIqKBlZaxkczrQwvoj+o= X-Received: by 10.159.61.196 with SMTP id e4mr10206593uaj.156.1513205815891; Wed, 13 Dec 2017 14:56:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.91.2 with HTTP; Wed, 13 Dec 2017 14:56:55 -0800 (PST) X-Originating-IP: [2001:dc0:2001:210:144e:9de0:5fc0:815c] In-Reply-To: <20171213.204234.76214525553211985.fujiwara@jprs.co.jp> References: <707A270D-94DA-4651-84DC-409FAA6793F7@vpnc.org> <56BEBCFA-D6BA-4BD1-8B95-190375A57C06@isc.org> <20171213.204234.76214525553211985.fujiwara@jprs.co.jp> From: George Michaelson Date: Thu, 14 Dec 2017 08:56:55 +1000 Message-ID: To: fujiwara@jprs.co.jp Cc: "marka@isc.org" , dnsop WG , Paul Hoffman Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 22:56:59 -0000 feels like a concrete example in a.b.c.example.com terms would help define both in-baliwick, and out-of-baliwick, for the cases. On Wed, Dec 13, 2017 at 9:42 PM, wrote: > Thanks. > > terminology-bis-08: > | In-bailiwick: An adjective to describe a name server whose name is > | either subordinate to or (rarely) the same as the zone origin. > > Ok, In-bailwick in terminology-bis-08 may be restrictive because "the > zone origin" is unclear. I intended that "the zone origin" is the zone > origin of parent zone. The sentence needs more words. > > NEW > > In-bailiwick: An adjective to describe a name server whose name is > either subordinate to or (rarely) the same as the origin > of the zone that contains the delegation to the name server. > > ... bad english text ... please fix. > > -- > Kazunori Fujiwara, JPRS > >> From: Mark Andrews >> The text for "in-bailwick" is too restrictive, it doesn=E2=80=99t just c= over NS records or >> glue records. >> >> In-bailwick refers to records that in the normal course of DNS resolutio= n >> would have been requested of by the server the current response is from. >> e.g. if you are querying a .com server then all records in the response = that end >> with .com are in-bailwick. >> >> Mark >> >>> On 5 Dec 2017, at 5:27 am, Paul Hoffman wrote: >>> >>> Greetings again. >>> >>> Some of the new terms added to the terminology-bis draft (https://datat= racker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since RFC 7719 can be= a bit tricky. This week, we hope you will look at the definitions in the d= raft for: >>> - In-bailiwick >>> - Out-of-bailiwick >>> - In-domain >>> - Sibling domain >>> Please review these terms and comment on the list if you think the defi= nitions should change. >>> >>> --Paul Hoffman >>> >>> [[ As a reminder, we asked the following last week, but got no reply: F= or the past many versions of the terminology-bis draft (https://datatracker= .ietf.org/doc/draft-ietf-dnsop-terminology-bis/), Section 2 has definitions= of "Global DNS" and "Private DNS", based on the facets listed in "Naming s= ystem". This was discussed heavily on the list earlier, but it is also a pr= etty big change, so we want to be sure that it is what the WG wants. Please= review these terms and comment on the list if you think the definitions sh= ould change. ]] >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Wed Dec 13 16:31:31 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E521124B18 for ; Wed, 13 Dec 2017 16:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 cBJe_zqxSCpd for ; Wed, 13 Dec 2017 16:31:26 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 10B5A1200F1 for ; Wed, 13 Dec 2017 16:31:26 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id t1so7240415ite.5 for ; Wed, 13 Dec 2017 16:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MK/AL29EpMWVblqLBt42WHzuzH0RduJQpYQcUIfZlGU=; b=DkmX6UaKp1Nh5SGzVPV4FxIGDti/AOniAC9FN5ONNW/7OCEvW6G32/E9N0SQvy85UB 0APCiJWEOyJKe59ECKdt4QZ8l3ds8IoktKDXZjk8ZctlObf0ihZ6sPW3446noFKMnBS7 wfkfM/BVLuXDAGxNMJNnwq33qENYfMvfnLwUc= 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=MK/AL29EpMWVblqLBt42WHzuzH0RduJQpYQcUIfZlGU=; b=E8qjyGi0jFANOBqcdhEx2hn22Ogulv8mPIinW5IdCkEK/jLo6e0UO4odbxDOMCdiwT hHuzO0Yw5IyOzPbe7LM/sjHe+NE2QuOw+nuVlvPE0befMeS69U6r1uokSLtAi93972yc dvDZgZq1Zjj8o85KtXb3P5WSIB7O81mPjT2Py2D+ukC5BGebz+PwoUX6xqKSHFvlXbh3 ZdBLbiOYIXdERlpdqr2OLgPOhwgDEe7g92BluW4ehNWyLXnZdcZicSj6wch8WaD99fQ0 sFxrOQCQIBHUFcWQAmowpWlqq8tU3MYBW+I06TFBMctjXaMc76j9uJbX4DEXKpk2PlM/ ALGA== X-Gm-Message-State: AKGB3mL391zpWEOl0oZVzHybWODd+iiCAn7qp28TD+xW5IHXy5ShTpuN vhSqQQRKahXzyohe0/JbzXQP5w== X-Google-Smtp-Source: ACJfBovgITTIb/2owda+Vnl54jLeqg1xjb8W8x0BZbwaLBgzX7DR3ztSm0oZb2w9gIqNGOY/B9W8kw== X-Received: by 10.36.175.19 with SMTP id t19mr1062886ite.67.1513211485314; Wed, 13 Dec 2017 16:31:25 -0800 (PST) Received: from [199.212.90.109] (23-233-21-69.cpe.pppoe.ca. [23.233.21.69]) by smtp.gmail.com with ESMTPSA id s73sm80952ioe.47.2017.12.13.16.31.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 16:31:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (15C114) In-Reply-To: <23CF8A88-F530-426D-A6A9-4B80AF28D603@fugue.com> Date: Wed, 13 Dec 2017 19:31:22 -0500 Cc: Stephane Bortzmeyer , dnsop@ietf.org, Paul Vixie Content-Transfer-Encoding: quoted-printable Message-Id: <09515131-DD1B-4FC9-90F6-C088173857BA@hopcount.ca> References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> <1B37BBA1-D141-441A-855E-1ACFF2DC15BD@fugue.com> <23CF8A88-F530-426D-A6A9-4B80AF28D603@fugue.com> To: Ted Lemon Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 00:31:27 -0000 Hi Ted, > On Dec 13, 2017, at 17:14, Ted Lemon wrote: >=20 > Can you point to the actual ambiguity? The reason we said "one or more b= lack hole servers" was to leave it up to the operator of .arpa to decide whi= ch black hole servers and how many of them. That was a deliberate choice, n= ot an omission. The ambiguity is (for example) that "point to" is not a well-defined phrase,= given that we have two documented ways of doing this in the AS112 project, a= nd neither is "black hole server" which from the examples seems it refers to= servers made available from the AS112 project, but which examples surely ar= e non-normative. This no doubt sounds pedantic to many, but I think (a) that a certain precis= ion is warranted in directions to the IANA and (b) given that the obvious in= terpretation is not possible to implement accurately (the problems with new d= elegations to the original AS112 servers having been well documented) ambigu= ity is in fact *required* in order for anything to happen here. Joe= From nobody Wed Dec 13 16:40:33 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDED01243FE for ; Wed, 13 Dec 2017 16:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 Tdv2_UDCZFbm for ; Wed, 13 Dec 2017 16:40:31 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 D61721200F1 for ; Wed, 13 Dec 2017 16:40:30 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id f143so7161081itb.0 for ; Wed, 13 Dec 2017 16:40:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n37gpuq8t3mLEHAz6MmWZ2EZobsem26SivJSfSNCB/c=; b=UpeiBKyJ0aMck74L4x6xSISlHReB9eAHfSTz3HYUHcwsKlVtNMcFRHTxCISblniQpT ebUcdTV6ABL/5Ok3k2uKjrJXlEkKok66RCqcO+L4oFNJjUzEjlqWYi21cF2YsisX/GBC 4dtKpV+30KKwGdY/c2thgqBqASQsllqG5t4WQ= 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=n37gpuq8t3mLEHAz6MmWZ2EZobsem26SivJSfSNCB/c=; b=CkVZlEB6vJRHaCNTqdBeQ4C7pWbX14Fr7ggm8HRK+iogUopWm94jC62o/hhtuzLWly tsmiwy9zwsCdhxzBV1VMgqxDm2mRNTWIlChgN9UODunPADHnK4TgBTnz3UlB893txHcR ZIti2WVzoL4eXpFrqLlaCbOKe6QF2USC0QZAkWXsddF3WzD6J0NYAb7gGeNAc4vPE9RX 9m5RyFbRFoxRlrLQW3cMPFp4DJ7lju0CWoQqbLod9ss990yYgrziHpIR9t/OtBb/hXO2 orjHYWYuGVdWqUESlJStCi/fp7E1pnswQyy2JzcK1IXBCOoMB5pn33yQDWEHjrvVEqhO nF2A== X-Gm-Message-State: AKGB3mKjHrtJ0gNbXbf+BnqMr5mGXarE2m5szG9ZEyKNSvmpDL6ror9A ZVFcc2WMuWK7jBxFeInzV5etPw== X-Google-Smtp-Source: ACJfBosb3CXf30I0/s9FBclHCs1eP9xGuXLevh9K/XFwNotd0ACsi+gbNKO2A+87SZ3v54GawGUQEA== X-Received: by 10.107.12.81 with SMTP id w78mr5186489ioi.148.1513212030044; Wed, 13 Dec 2017 16:40:30 -0800 (PST) Received: from ?IPv6:2607:f2c0:101:3:ed87:79de:2316:6021? ([2607:f2c0:101:3:ed87:79de:2316:6021]) by smtp.gmail.com with ESMTPSA id 23sm1410972iot.58.2017.12.13.16.40.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 16:40:28 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (15C114) In-Reply-To: Date: Wed, 13 Dec 2017 19:40:27 -0500 Cc: Ted Lemon , Paul Vixie , dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4F78AA27-9D66-4921-AB44-62EB01148B1D@hopcount.ca> References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> <1B37BBA1-D141-441A-855E-1ACFF2DC15BD@fugue.com> To: Mark Andrews Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 00:40:33 -0000 Hi Mark, > On Dec 13, 2017, at 17:09, Mark Andrews wrote: >=20 > Section 7 says: Yes, I know. I read it. > RFC 6303 has similar requirements and IANA was able to co-ordinate those d= elegation. Apart from the zones originally delegated to the AS112 project, I couldn't f= ind a zone specified in 6303 that is delegated at all, actually. Admittedly I didn't check all of them (I got bored after 0.in-addr.arpa, 127= .in-addr.arpa, 2.0.192.in-addr.arpa and d.f.ip6.arpa). Here's an example: monster:~]% dig @b.in-addr-servers.arpa 0.in-addr.arpa soa +norec +dnssec ; <<>> DiG 9.11.2 <<>> @b.in-addr-servers.arpa 0.in-addr.arpa soa +norec +dn= ssec ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64980 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;0.in-addr.arpa. IN SOA ;; AUTHORITY SECTION: in-addr.arpa. 3600 IN NSEC 1.in-addr.arpa. NS SOA RRSIG= NSEC DNSKEY in-addr.arpa. 3600 IN RRSIG NSEC 8 2 3600 20171228213500= 20171208080001 51846 in-addr.arpa. D167CxX3WV8Cygq3JHJ8Ik4VUo5qGbEqxGq68vyi= l2QMhf9O7DjyU3sn q3S9kR+TJ7yQJPsfzy6Qqygft2Jnr0pujDspruYyKcFfx5WbO2X7pTxQ zFS= jjHspZPCJ5ZVNoML/3aFYcqvBeYZWViZB8zCuyYZWF6YXtDppXukz 3GQ=3D in-addr.arpa. 3600 IN SOA b.in-addr-servers.arpa. nstl= d.iana.org. 2017102477 1800 900 604800 3600 in-addr.arpa. 3600 IN RRSIG SOA 8 2 3600 20171231104329 2= 0171210060001 51846 in-addr.arpa. a7/wJ7RcUM9MOV3M0+0i9MUgOF4Yw6VqUIuR7ItN70= CuM8qoCYGi+0/F bRiiHPeRFgFD92Shgb7pwRsM2lYh53jheWAZSOg8wOdNMaF+eiEolErv wpBu= DoZM/m1mlAZ26BiN2BKDDh22AXj/76KA+pgIa+J3y2kQHYsNKEmB pvg=3D ;; Query time: 22 msec ;; SERVER: 2001:500:87::87#53(2001:500:87::87) ;; WHEN: Thu Dec 14 00:39:19 UTC 2017 ;; MSG SIZE rcvd: 492 [monster:~]%=20 Joe= From nobody Wed Dec 13 17:19:20 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6B61243FE for ; Wed, 13 Dec 2017 17:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 dw2TPZd6rLNX for ; Wed, 13 Dec 2017 17:19:17 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 DC6BA1274A5 for ; Wed, 13 Dec 2017 17:19:16 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id A7EA33B530C; Thu, 14 Dec 2017 01:19:14 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 79F8B16007F; Thu, 14 Dec 2017 01:19:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 523D2160048; Thu, 14 Dec 2017 01:19:14 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id UrtyT2WAsmUM; Thu, 14 Dec 2017 01:19:14 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 057B3160041; Thu, 14 Dec 2017 01:19:12 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <4F78AA27-9D66-4921-AB44-62EB01148B1D@hopcount.ca> Date: Thu, 14 Dec 2017 12:19:10 +1100 Cc: Ted Lemon , Paul Vixie , dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5D14A9E9-2B1E-45E7-B7FC-C355A6FA7145@isc.org> References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> <1B37BBA1-D141-441A-855E-1ACFF2DC15BD@fugue.com> <4F78AA27-9D66-4921-AB44-62EB01148B1D@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 01:19:19 -0000 Looks like we need to open a ticket for those. But the ones people = actually have internal zones in are correct. Check the RFC 1918 = delegations. I know these started out being delegated to blackhole = servers before the parent zones were signed by this isn=E2=80=99t rocket = science. [rock:bin/tests/system] marka% dig 10.in-addr.arpa = @f.in-addr-servers.arpa +dnssec ; <<>> DiG 9.12.0rc1+hotspot+add-prefetch+marka <<>> 10.in-addr.arpa = @f.in-addr-servers.arpa +dnssec ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15498 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 1a755958649b4ee4edf6fe055a31cb4dc97ce57a3c818987 (good) ;; QUESTION SECTION: ;10.in-addr.arpa. IN A ;; AUTHORITY SECTION: 10.in-addr.arpa. 86400 IN NS blackhole-2.iana.org. 10.in-addr.arpa. 86400 IN NS blackhole-1.iana.org. 10.in-addr.arpa. 3600 IN NSEC 100.in-addr.arpa. NS = RRSIG NSEC 10.in-addr.arpa. 3600 IN RRSIG NSEC 8 3 3600 = 20171229130507 20171208140001 51846 in-addr.arpa. = WcpA1d1GIL2vC22QrTf6V3wni22+aD8XlTgSR3K8WAvf7vWfz1NcUIeW = 8fiRVj2tTq7rJlnxdoTtTheM1COZrZCdxhBa2wHHnte8k4MlD+p5Wiza = 5NjitvL/ASp2VPAdOfEofsJSgWHyQ1C4obCsYGMxux3dgv7ePdYiPzgr 9hE=3D ;; Query time: 411 msec ;; SERVER: 2001:67c:e0::1#53(2001:67c:e0::1) ;; WHEN: Thu Dec 14 11:52:29 AEDT 2017 ;; MSG SIZE rcvd: 342 [rock:bin/tests/system] marka%=20 [rock:~/git/bind9x] marka% dig 17.172.in-addr.arpa +dnssec @r.arin.net ; <<>> DiG 9.12.0rc1+hotspot+add-prefetch+marka <<>> 17.172.in-addr.arpa = +dnssec @r.arin.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1672 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;17.172.in-addr.arpa. IN A ;; AUTHORITY SECTION: 17.172.in-addr.arpa. 86400 IN NS blackhole-1.iana.org. 17.172.in-addr.arpa. 86400 IN NS blackhole-2.iana.org. 17.172.in-addr.arpa. 10800 IN NSEC 170.172.in-addr.arpa. NS = RRSIG NSEC 17.172.in-addr.arpa. 10800 IN RRSIG NSEC 5 4 10800 = 20171227213540 20171213203540 40857 172.in-addr.arpa. = kLq3ev/dBxW/4NEDxBJlksmE6nXI7CZC84D17ZLsLzo4jThantJea5fw = UTdtR/YFt0kFAYtNv3gTkHn8E48wQV/50rExb5Kg4iKTSCol84S6o6p0 = Lt6lKslVCt8qPIjonScKmJhly9WlO/mPqsFu7xNoK4wFGs2p+hOMcvkQ oN8=3D ;; Query time: 320 msec ;; SERVER: 2001:500:f0::63#53(2001:500:f0::63) ;; WHEN: Thu Dec 14 12:17:37 AEDT 2017 ;; MSG SIZE rcvd: 326 [rock:~/git/bind9x] marka%=20 [rock:bin/tests/system] marka% dig 168.192.in-addr.arpa +dnssec = @r.arin.net ; <<>> DiG 9.12.0rc1+hotspot+add-prefetch+marka <<>> = 168.192.in-addr.arpa +dnssec @r.arin.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3764 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;168.192.in-addr.arpa. IN A ;; AUTHORITY SECTION: 168.192.in-addr.arpa. 86400 IN NS blackhole-1.iana.org. 168.192.in-addr.arpa. 86400 IN NS blackhole-2.iana.org. 168.192.in-addr.arpa. 10800 IN NSEC 0.169.192.in-addr.arpa. = NS RRSIG NSEC 168.192.in-addr.arpa. 10800 IN RRSIG NSEC 5 4 10800 = 20171227213323 20171213203323 57162 192.in-addr.arpa. = Pg7l5KbT8lU7pbZJf/W1CeKM68b9gp8Nck0e+IsiJ08kcjHPXyVg6juu = 1f5eLDbbq7SeqR8yMxu9BKf4FqXhgzsqTxXB5AdwCNIBLEHwbWSIurqy = nFiTD1upf3PbiSmheqLGz2n3kCqgMS+/dVapW4y2JQsDMEBp1Q/Y5ux/ UpY=3D ;; Query time: 293 msec ;; SERVER: 2001:500:f0::63#53(2001:500:f0::63) ;; WHEN: Thu Dec 14 12:03:18 AEDT 2017 ;; MSG SIZE rcvd: 329 [rock:bin/tests/system] marka%=20 > On 14 Dec 2017, at 11:40 am, Joe Abley wrote: >=20 > Hi Mark, >=20 >> On Dec 13, 2017, at 17:09, Mark Andrews wrote: >>=20 >> Section 7 says: >=20 > Yes, I know. I read it. >=20 >> RFC 6303 has similar requirements and IANA was able to co-ordinate = those delegation. >=20 > Apart from the zones originally delegated to the AS112 project, I = couldn't find a zone specified in 6303 that is delegated at all, = actually. >=20 > Admittedly I didn't check all of them (I got bored after = 0.in-addr.arpa, 127.in-addr.arpa, 2.0.192.in-addr.arpa and = d.f.ip6.arpa). Here's an example: >=20 > monster:~]% dig @b.in-addr-servers.arpa 0.in-addr.arpa soa +norec = +dnssec >=20 > ; <<>> DiG 9.11.2 <<>> @b.in-addr-servers.arpa 0.in-addr.arpa soa = +norec +dnssec > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64980 > ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 >=20 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;0.in-addr.arpa. IN SOA >=20 > ;; AUTHORITY SECTION: > in-addr.arpa. 3600 IN NSEC 1.in-addr.arpa. NS SOA = RRSIG NSEC DNSKEY > in-addr.arpa. 3600 IN RRSIG NSEC 8 2 3600 = 20171228213500 20171208080001 51846 in-addr.arpa. = D167CxX3WV8Cygq3JHJ8Ik4VUo5qGbEqxGq68vyil2QMhf9O7DjyU3sn = q3S9kR+TJ7yQJPsfzy6Qqygft2Jnr0pujDspruYyKcFfx5WbO2X7pTxQ = zFSjjHspZPCJ5ZVNoML/3aFYcqvBeYZWViZB8zCuyYZWF6YXtDppXukz 3GQ=3D > in-addr.arpa. 3600 IN SOA = b.in-addr-servers.arpa. nstld.iana.org. 2017102477 1800 900 604800 3600 > in-addr.arpa. 3600 IN RRSIG SOA 8 2 3600 = 20171231104329 20171210060001 51846 in-addr.arpa. = a7/wJ7RcUM9MOV3M0+0i9MUgOF4Yw6VqUIuR7ItN70CuM8qoCYGi+0/F = bRiiHPeRFgFD92Shgb7pwRsM2lYh53jheWAZSOg8wOdNMaF+eiEolErv = wpBuDoZM/m1mlAZ26BiN2BKDDh22AXj/76KA+pgIa+J3y2kQHYsNKEmB pvg=3D >=20 > ;; Query time: 22 msec > ;; SERVER: 2001:500:87::87#53(2001:500:87::87) > ;; WHEN: Thu Dec 14 00:39:19 UTC 2017 > ;; MSG SIZE rcvd: 492 >=20 > [monster:~]%=20 >=20 >=20 > Joe --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Dec 13 17:25:43 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C9A12421A for ; Wed, 13 Dec 2017 17:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 ehoCabfI6hqn for ; Wed, 13 Dec 2017 17:25:41 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 44E8D1200F1 for ; Wed, 13 Dec 2017 17:25:41 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id g80so333859lfg.0 for ; Wed, 13 Dec 2017 17:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-transfer-encoding; bh=qfZWxtDbNk85JdKMZVsPONmprTK+lIix8pz6kMtsNS0=; b=FbJ52mnxl9XqDupDrZEI5hHzu0ddOuU1N0JF1NgrJS2GX8y3hI85Ti/L4WEqzzOx/V 6EQedxjNIpRJwka22t+JVvpWwyTb3cnCXo9PGrm5t5kwAzOE4PkodE0UDE39COFTf3eU qwzhUqEmQYayTwIPYPUtWsB0Y6vGd9UfI91Vc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-transfer-encoding; bh=qfZWxtDbNk85JdKMZVsPONmprTK+lIix8pz6kMtsNS0=; b=VVL1mfMkC9WQfziRDi/KGCdLKnrA2eQLg2G6Let+0CHg+vrjjptO8PP/4i1t7m9fyf GgLj6vHLpArM9Xk7FNx23Tb2KYmkgReQMUx+Dg98Gch2PmNu0zFTBfCH4aXfMXiBfJHs thewuX4HirvwYaZx33f4WXfCFWWBunLOzkqMXM4KTfe0NyoOKaB3yphkMSt/n5Ivm4kl 48Bh22Pc+K0GpmUZj868k4Hdc8Axo1MdjNjZ2YwP41zSXhzHYlVtsMqQxwTQdsjv+5bN pvsSki6rOmXzlvlNZtVFerFr1s+us8S3jD9mxJARk8rWJwjkrVls4qgC/2gyLpmDoZXX 4brA== X-Gm-Message-State: AKGB3mJ7ZuoJ2bjPbpn7c3xz+ForwQRv6fU2QjdtPjTmYJz2065HWHwQ JIHU7+MVOLCnXPi3cZ6ap/ESjbGzChOzjfrA4BhA4A== X-Google-Smtp-Source: ACJfBovAnDPrPxdpzRxrf2segWm12qqn6HjBIbzFtxWf7HgivYHAwDLVOLls0V69tptUjfgTjjojsRV3JR50Rtrc4z0= X-Received: by 10.46.92.9 with SMTP id q9mr2549757ljb.78.1513214739473; Wed, 13 Dec 2017 17:25:39 -0800 (PST) From: Joe Abley Mime-Version: 1.0 (1.0) References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> <1B37BBA1-D141-441A-855E-1ACFF2DC15BD@fugue.com> <4F78AA27-9D66-4921-AB44-62EB01148B1D@hopcount.ca> <5D14A9E9-2B1E-45E7-B7FC-C355A6FA7145@isc.org> In-Reply-To: <5D14A9E9-2B1E-45E7-B7FC-C355A6FA7145@isc.org> Date: Wed, 13 Dec 2017 20:25:38 -0500 Message-ID: <6866658498418370982@unknownmsgid> To: Mark Andrews Cc: Ted Lemon , Paul Vixie , "dnsop@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 01:25:43 -0000 Hi Mark, [I'm typing this on a phone. It's going to look horrible in a real mail client. Sorry about that.] On Dec 13, 2017, at 20:19, Mark Andrews wrote: > Looks like we need to open a ticket for those. But the ones people actua= lly have internal zones in are correct. Check the RFC 1918 delegations. I= know these started out being delegated to blackhole servers before the par= ent zones were signed by this isn=E2=80=99t rocket science. The zones originally delegated are not rocket science, agreed. The others are difficult to do unless you don't mind them being lame for a hard-to-measure population of end-users. Isn't that what we are talking about? I can't tell whether you disagree with that or whether you think lame is ok= . Joe From nobody Wed Dec 13 17:37:02 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818D91243FE for ; Wed, 13 Dec 2017 17:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 5e-7o1YIFnFS for ; Wed, 13 Dec 2017 17:36:58 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4D28F12421A for ; Wed, 13 Dec 2017 17:36:57 -0800 (PST) Received: from CNNIC-THINK (unknown [218.241.103.198]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0DZ4Ny31TFacL88AA--.30678S2; Thu, 14 Dec 2017 09:36:55 +0800 (CST) Date: Thu, 14 Dec 2017 09:36:54 +0800 From: "zuopeng@cnnic.cn" To: "Lanlan Pan" , "Stephane Bortzmeyer" Cc: dnsop , "bert hubert" References: <2017121315404971736813@cnnic.cn>, <20171213081823.GA8970@laperouse.bortzmeyer.org>, <20171213084342.GA30523@server.ds9a.nl>, <201712131731058457451@cnnic.cn>, <20171213095533.tpd52wo6xy7v6qct@sources.org>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 166[cn] Mime-Version: 1.0 Message-ID: <201712140936540174818@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart676342848718_=----" X-CM-TRANSID: AQAAf0DZ4Ny31TFacL88AA--.30678S2 X-Coremail-Antispam: 1UD129KBjvdXoWrKF4xGFy7ZFW8Zr15Wry7Awb_yoWkArb_uF ZxZryxCr98Xr1Igw4xKFsagr9xCa48WF1DJ3yUXan7uryfA3s8Jr48tFyfWF4xtFyqyFs8 Gr18Jr4Utw12gjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbykYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I 8E87Iv6xkF7I0E14v26r4UJVWxJr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG6xAI xVCFxsxG0wAqx4xG6I80eVA0xI0YY7vIx2IE14AGzxvEb7x7McIj6xIIjxv20xvE14v26r 1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij 64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07MxkIecxEwVAFwV WkMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_ JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x 0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWU JVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8Jw CI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2KfnxnUUI 43ZEXa7IU82iiDUUUUU== X-CM-SenderInfo: x2xr1vlqj6u0xqlfhubq/ Archived-At: Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 01:37:01 -0000 This is a multi-part message in MIME format. ------=_001_NextPart676342848718_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 DQogDQpGcm9tOiBMYW5sYW4gUGFuDQpEYXRlOiAyMDE3LTEyLTEzIDE4OjI1DQpUbzogU3RlcGhh bmUgQm9ydHptZXllcg0KQ0M6IHp1b3BlbmdAY25uaWMuY247IGRuc29wOyBiZXJ0IGh1YmVydA0K U3ViamVjdDogUmU6IFtETlNPUF0gQXNrIGZvciBhZHZpY2Ugb2YgMyBuZXcgUlJzIGZvciBwcmVj aXNlIHRyYWZmaWMgc2NoZWR1bGluZw0KDQoNClN0ZXBoYW5lIEJvcnR6bWV5ZXIgPGJvcnR6bWV5 ZXJAbmljLmZyPuS6jjIwMTflubQxMuaciDEz5pel5ZGo5LiJIOS4i+WNiDU6NTjlhpnpgZPvvJoN Ck9uIFdlZCwgRGVjIDEzLCAyMDE3IGF0IDA1OjMxOjA2UE0gKzA4MDAsDQogenVvcGVuZ0Bjbm5p Yy5jbiA8enVvcGVuZ0Bjbm5pYy5jbj4gd3JvdGUNCiBhIG1lc3NhZ2Ugb2YgMTMwIGxpbmVzIHdo aWNoIHNhaWQ6DQoNCj4gKDIpIFJGQzI3ODIgcmVxdWlyZXMgYnJvd3NlcidzIHN1cHBvcnQ7DQoN CkNsaWVudCBzdXBwb3J0LiBUaGlzIGlzIGV2ZW4gd29yc2UsIHRoZXJlIGFyZSBtdWNoIG1vcmUg SFRUUCBjbGllbnRzDQp0aGFuIGJyb3dzZXJzLg0KDQo+ICAgICBVc2luZyB0aGlzIG1ldGhvZCwg YSBicm93c2VyIGhhcyBubyBpZGVhIGFib3V0IHdlaWdodGVkIEFYL0FBQUFYcy4NCj4gICAgIEl0 IHJlcXVpcmVzIG5vIGNoYW5nZSBvZiBicm93c2Vycy4NCg0KQnV0IGl0IHJlcXVpcmVzIGNoYW5n ZSBpbiBhbGwgcmVzb2x2ZXJzLiBPbmUgbWF5IHdvbmRlciB3aGljaCB3aWxsIGJlDQp0aGUgZmFz dGVzdCBwYXRoLg0Kc29tZXRoaW5nIGxpa2UgQU5BTUUgPyANCkFOQU1FIGNhbiBsZXQgcmVzb2x2 ZXJzIGNob29zZSBJUCBmb3IgY2xpZW50cy4NCg0KLS0tLS0tLS0tLS1benVvcGVuZ10gaXQgaXMg bm90IGxpa2UgQU5BTUUuIEJ1dCBBTkFNRSBoYXMgc2ltaWxhciBmdW5jdGlvbiB3aXRoIENOQU1F LCBhZGRpbmcgYSB3ZWlnaHQgYXR0cmlidXRlIGZvciBBTkFNRSBtYXkgYWxzbyBtYWtlIHNlbnNl Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRE5T T1AgbWFpbGluZyBsaXN0DQpETlNPUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kbnNvcA0KLS0gDQroh7TnpLwgIEJlc3QgUmVnYXJkcw0KDQrmvZjok53l hbAgIFBhbiBMYW5sYW4NCg== ------=_001_NextPart676342848718_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
=
=0A
 
<= div>From: Lanlan Pan<= /div>
Date: 2017-12-13 18:25
<= b>CC: zuopeng@cnnic.cn; <= a href=3D"mailto:dnsop@ietf.org">dnsop; bert hubert
Subject: Re: [DNSOP] A= sk for advice of 3 new RRs for precise traffic scheduling


<= div class=3D"gmail_quote">
Stephane Bortzmeyer <bortzmeyer@nic.fr>=E4=BA=8E2017=E5=B9= =B412=E6=9C=8813=E6=97=A5=E5=91=A8=E4=B8=89 =E4=B8=8B=E5=8D=885:58=E5=86= =99=E9=81=93=EF=BC=9A
On Wed, Dec = 13, 2017 at 05:31:06PM +0800,
=0A zuopeng@cnnic.cn <zuopeng@cnnic.cn> wrote
=0A a me= ssage of 130 lines which said:
=0A
=0A> (2) RFC2782 requires brow= ser's support;
=0A
=0AClient support. This is even worse, there are = much more HTTP clients
=0Athan browsers.
=0A
=0A>   =  Using this method, a browser has no idea about weighted AX/AAAAXs.<= br>=0A>     It requires no change of browsers.
=0A=0ABut it requires change in all resolvers. One may wonder which will be<= br>=0Athe fastest path.
something like ANAME ?
ANAME can let resolvers choose IP for clients.

=
-----------[zuopeng] it is not like ANAME. But ANAME = has similar function with CNAME, adding a weight attribute for ANAME may a= lso make sense.
=0A
=0A_____= __________________________________________
=0ADNSOP mailing list
=0A= DNSOP@ietf.org
= =0Ahttps://www.ietf.org/mailman/listinfo/dnsop
= =0A
--
=E8=87= =B4=E7=A4=BC  Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0  P= an Lanlan
=0A
=0A ------=_001_NextPart676342848718_=------ From nobody Wed Dec 13 17:45:49 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A400B127137 for ; Wed, 13 Dec 2017 17:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 fHJ_ct3zYZL4 for ; Wed, 13 Dec 2017 17:45:45 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 78EC51270AE for ; Wed, 13 Dec 2017 17:45:45 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id g10so6143183qtj.12 for ; Wed, 13 Dec 2017 17:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oZWSEjRdfXwCGf5vaCJ7M5gXgobcVBh4bvaOCWGt9SE=; b=Yc5SDQbmYY86vD9pAPqO2qIrTc9n7f8y1YTfyc2IB9yHpSqOQiyYEFWa7a+jLz8CaB U0mFVb5VXwsIL/5Sxgk0VXUNnG0bEHUhuF7xKOOWfmyB0OKmavAki1YXgPZvC7PCWv9P PF27hEHbNm2QfshyemRpGAUBCotGCE5A11ZJQm+rp13Oe2ePVbYFNaojXrmuP2d1Rhsl NbXVs045wRsZQ8ac5mMaf4RUOwHqHntenA3rz0N0xV7fiGeJmTPRpliod8zdLTSVxrZR yZJ4W0YXTEqbK7A0yKMz7U/PZ51P8dx7ZBDwATNcwbwHdcf1Z1pit1QGk9CdgRJieYFF 9dKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=oZWSEjRdfXwCGf5vaCJ7M5gXgobcVBh4bvaOCWGt9SE=; b=txEne3/AS2c/77gYEdvsSnJc3pIwdSwBbC0Dk6yTFLE7E3a9x1/siSJdMJu63FLOc1 2jHY0I5vv/flh4uAlMD384oe3qnJNIum61IP3SuJ5Xn+Al940ByiNul5AgJbXckpRjaD 43lN1vvru+lpPU8cQ/G3UvfLf6buVtDtaRlP33Fr5soVy7uYoeNK8qr62SK13Nb7zWvd OxDnqi3TU86cDg7HhDXVMqd6SHfSa7fWJAhWOjn+B+rqSS9dXtfKMOQZY97X73MP2YIF 2mbtnKDgIHvw8IjWHSL8ueUGZoLoRpckqlBEW4eGVEX0yvOZSwQKCcHUThOvFdjzC/IU 7rWQ== X-Gm-Message-State: AKGB3mJqFwYzF2roFvCOF5ynMU0HPKU3I0hpILgVNQe0oribDRUNHzqB 9T3SXAHnf+hgeZ7Gw8g5tIJbWA== X-Google-Smtp-Source: ACJfBouGIP5E4pIADXSk1zdmifjXVn+b5vlJS1qYNxJpkW/UVtc1Y+NWJMUPRT1Fx3aRhMK3V7x44Q== X-Received: by 10.200.40.15 with SMTP id 15mr13645869qtq.74.1513215944522; Wed, 13 Dec 2017 17:45:44 -0800 (PST) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id a72sm1766904qkc.60.2017.12.13.17.45.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Dec 2017 17:45:43 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5A91B03C-36E7-471B-9D1A-E26A22FA9C40" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 13 Dec 2017 20:45:42 -0500 In-Reply-To: <09515131-DD1B-4FC9-90F6-C088173857BA@hopcount.ca> Cc: Stephane Bortzmeyer , dnsop@ietf.org, Paul Vixie To: Joe Abley References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> <1B37BBA1-D141-441A-855E-1ACFF2DC15BD@fugue.com> <23CF8A88-F530-426D-A6A9-4B80AF28D603@fugue.com> <09515131-DD1B-4FC9-90F6-C088173857BA@hopcount.ca> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 01:45:48 -0000 --Apple-Mail=_5A91B03C-36E7-471B-9D1A-E26A22FA9C40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 13, 2017, at 7:31 PM, Joe Abley wrote: > The ambiguity is (for example) that "point to" is not a well-defined = phrase, given that we have two documented ways of doing this in the = AS112 project, and neither is "black hole server" which from the = examples seems it refers to servers made available from the AS112 = project, but which examples surely are non-normative. What is wanted is that there be a delegation in .arpa for home.arpa that = isn't signed, so that DNSSEC validation will not fail when an answer is = presented to the stub that is different than what's in the .arpa zone. = There is never a valid use case where a query actually goes to a server = to which home.arpa is delegated from the authoritative servers for = .arpa. We just need for .arpa not to say something that contradicts = what the locally-served zone says. This is the same behavior that is necessary for e.g. 10.in-addr.arpa, in = order that a local DNS service can provide answers within that zone = without the actual from-the-root delegation authentically contradicting = what that server is saying. IOW, if you think that what is being requested here is different than = what's needed for 10.in-addr.arpa, we've failed to communicate. The = issue is that we hadn't really thought about the secure denial of = existence problem prior to the dot-home work. --Apple-Mail=_5A91B03C-36E7-471B-9D1A-E26A22FA9C40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Dec 13, 2017, at 7:31 PM, Joe Abley <jabley@hopcount.ca> = wrote:
The ambiguity is = (for example) that "point to" is not a well-defined phrase, given that = we have two documented ways of doing this in the AS112 project, and = neither is "black hole server" which from the examples seems it refers = to servers made available from the AS112 project, but which examples = surely are non-normative.

What is wanted is that there be a delegation = in .arpa for home.arpa that isn't signed, so that DNSSEC validation will = not fail when an answer is presented to the stub that is different than = what's in the .arpa zone.   There is never a valid use case where a = query actually goes to a server to which home.arpa is delegated from the = authoritative servers for .arpa.   We just need for .arpa not to = say something that contradicts what the locally-served zone = says.

This is = the same behavior that is necessary for e.g. 10.in-addr.arpa, in order = that a local DNS service can provide answers within that zone without = the actual from-the-root delegation authentically contradicting what = that server is saying.

IOW, if you think that what is being requested here is = different than what's needed for 10.in-addr.arpa, we've failed to = communicate.   The issue is that we hadn't really thought about the = secure denial of existence problem prior to the dot-home work.

= --Apple-Mail=_5A91B03C-36E7-471B-9D1A-E26A22FA9C40-- From nobody Wed Dec 13 17:53:44 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6924012421A for ; Wed, 13 Dec 2017 17:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 QovNaUv-vKA6 for ; Wed, 13 Dec 2017 17:53:41 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 47CC61243FE for ; Wed, 13 Dec 2017 17:53:41 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id ADE893AF9C1; Thu, 14 Dec 2017 01:53:34 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 76A3216007F; Thu, 14 Dec 2017 01:53:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6100B160048; Thu, 14 Dec 2017 01:53:33 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mzWgUW7tyVof; Thu, 14 Dec 2017 01:53:33 +0000 (UTC) Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 63D9D160041; Thu, 14 Dec 2017 01:53:32 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Andrews In-Reply-To: <09515131-DD1B-4FC9-90F6-C088173857BA@hopcount.ca> Date: Thu, 14 Dec 2017 12:53:30 +1100 Cc: Ted Lemon , Paul Vixie , dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> <1B37BBA1-D141-441A-855E-1ACFF2DC15BD@fugue.com> <23CF8A88-F530-426D-A6A9-4B80AF28D603@fugue.com> <09515131-DD1B-4FC9-90F6-C088173857BA@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 01:53:43 -0000 > On 14 Dec 2017, at 11:31 am, Joe Abley wrote: >=20 > Hi Ted, >=20 >> On Dec 13, 2017, at 17:14, Ted Lemon wrote: >>=20 >> Can you point to the actual ambiguity? The reason we said "one or = more black hole servers" was to leave it up to the operator of .arpa to = decide which black hole servers and how many of them. That was a = deliberate choice, not an omission. >=20 > The ambiguity is (for example) that "point to" is not a well-defined = phrase, given that we have two documented ways of doing this in the = AS112 project, and neither is "black hole server" which from the = examples seems it refers to servers made available from the AS112 = project, but which examples surely are non-normative. >=20 > This no doubt sounds pedantic to many, but I think (a) that a certain = precision is warranted in directions to the IANA and (b) given that the = obvious interpretation is not possible to implement accurately (the = problems with new delegations to the original AS112 servers having been = well documented) ambiguity is in fact *required* in order for anything = to happen here. And if IANA didn=E2=80=99t understand the instructions they had a = opportunity during the RFC creation process to request clarification. = It is a explicit step in the process to try to prevent issues like this. = IANA could have done the delegation at that point in time and had it in = place before the RFC exited the RFC publication process and even asked = =E2=80=9CIs this correct?=E2=80=9D. IANA make similar queries for = registry entries. Creating a delegation is a operation that happens millions to times a = day around the world as is setting up name servers to serve a zone. As for =E2=80=9Cpoint to=E2=80=9D read it as =E2=80=9Cdelegated to=E2=80=9D= if you want to nit pick. Also IANA was NOT instructed to delegate to = the AS112 servers. IANA was instructed to delegate to back hole servers = and a example of which, the AS112 servers, was presented. Mark > Joe > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Dec 14 09:39:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD21128B27 for ; Thu, 14 Dec 2017 09:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 8o7VlqvmHyhd for ; Thu, 14 Dec 2017 09:39:19 -0800 (PST) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 4C210127871 for ; Thu, 14 Dec 2017 09:39:19 -0800 (PST) Received: from jurassic.lan.banu.com (unknown [115.118.214.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id CCE9E56A086D; Thu, 14 Dec 2017 17:39:15 +0000 (GMT) Date: Thu, 14 Dec 2017 23:09:13 +0530 From: Mukund Sivaraman To: dnsop@ietf.org Message-ID: <20171214173913.GA18100@jurassic.lan.banu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: [DNSOP] CLIENT-SUBNET bis appetite? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 17:39:21 -0000 Any appetite for it? Don't throw things at me.. I ask because the current thing is slowly getting more widely deployed and there are design issues that can do with a ECS2 that breaks from ECS1 protocol. I ask because I'm once again having to deal with myriad implementation cases and dislike it. Mukund From nobody Thu Dec 14 10:01:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B60F129431 for ; Thu, 14 Dec 2017 10:01:06 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 TMOctYjW65Ta for ; Thu, 14 Dec 2017 10:01:04 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6022B12704A for ; Thu, 14 Dec 2017 10:01:01 -0800 (PST) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id BC3169FB57; Thu, 14 Dec 2017 18:00:59 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id BEDCDAC4293; Thu, 14 Dec 2017 19:00:58 +0100 (CET) Date: Thu, 14 Dec 2017 19:00:58 +0100 From: bert hubert To: Mukund Sivaraman Cc: dnsop@ietf.org Message-ID: <20171214180058.GC4176@server.ds9a.nl> References: <20171214173913.GA18100@jurassic.lan.banu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171214173913.GA18100@jurassic.lan.banu.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [DNSOP] CLIENT-SUBNET bis appetite? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 18:01:06 -0000 On Thu, Dec 14, 2017 at 11:09:13PM +0530, Mukund Sivaraman wrote: > Any appetite for it? Don't throw things at me.. I ask because the > current thing is slowly getting more widely deployed and there are > design issues that can do with a ECS2 that breaks from ECS1 protocol. I > ask because I'm once again having to deal with myriad implementation > cases and dislike it. Could you elaborate what you dislike most? The biggest thing we are noticing is that while it does great things to getting to a server the content provider likes, it unavoidably drives doen cache hitrates a lot, introducing a latency penalty. The operators we see deploying ECS have tens of thousands of subnets which all need to be mapped to only a few servers. But you still end up with tens of thousands of cache entries and therefore tiny cache hitrates. Such things could be addressed by answering with lists of subnet masks to which this answer would also apply, but this makes little sense operationally I think. Can you share your ideas for ECS2? Bert From nobody Thu Dec 14 10:10:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0002E129413 for ; Thu, 14 Dec 2017 10:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 5hoSrngYYl_f for ; Thu, 14 Dec 2017 10:10:12 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 6003012704A for ; Thu, 14 Dec 2017 10:10:12 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id g53so5933702wra.2 for ; Thu, 14 Dec 2017 10:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RuscjWVGd67xS0MAh10N67skU6Am/n1hYeQLXn5WqZo=; b=WDPZLF5BFi5lyHxWFXiF7X4pD9zXTMIoQoV1jgXKzhFJbQbyQaI3C/EzUnK6kzbOHE UYH5qbng+PixmlQxw4X3rkIUXowB/fG47SkSqObkxzAZ0uwwP+qQqOxDznRJQ1kXMnGd IYoY00rq5fdxenRwriXuWkwEQ63lFP3ts/xht4TH5BjjKeSQyQiE4aCF6qQfl0HBoOnq qZQY2gJ738/DnzJarhtL3bTus21IMHgaoux4Tl6wembtnlC6N8w++Kq4SLvweV2iUY8Y teTk2ALVg6hk0tAXhS7vjNZdd1RKxwo3U055M4VzhBEBOckI8vmWbaYl1tws3BmvIppq 21Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RuscjWVGd67xS0MAh10N67skU6Am/n1hYeQLXn5WqZo=; b=IifErP3lfx5Myp4FdDCoRLDPZuoLpI5QhXg+cvaXi2lcuEzKpHuCXK5gXFznJFelLK rhEGzHCwdTWeO5r5JRhNwOUqb6t2vaJSW/mCUl3wAHbdFtNSDSyfvR2KOHyT9NHUw+UH 8IFiQZ8EqMHJH2SlYUQCPkNhEFldf6Eyk1Vx2qspbhprSpzR9Wy2tJ44DW9OTbQzwb2S GNFPB9TEFdHxpukbec1jRMHJ+27quJ7FZ0DsrgUjmR8wyvipu+R8/TCNS8TawmXyx05l ohL7GP7j/lXVZN7dU8f+6n2zu91qKToZttBXLVPTeTvunpSDdUKcVotY2mZiPZrCrheH IMjA== X-Gm-Message-State: AKGB3mLp4u0hTIRGAGUZlDlC83wHsEp5PO/whwUA6qB9GETfBN+AuFlr JxpV6k6XwTd+LndAB+ozxqtBatkY0Vgr/0HL0nlWOgZW X-Google-Smtp-Source: ACJfBovSi+R4n+zwB+nigmD02Fr2lrsf3rc3QcRV1EYrDSx38st8LtuzM50+ulHZ1LgW7/hehx5m1M5Kd2lY42g76n4= X-Received: by 10.223.135.243 with SMTP id c48mr6398351wrc.140.1513275010672; Thu, 14 Dec 2017 10:10:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.149 with HTTP; Thu, 14 Dec 2017 10:09:30 -0800 (PST) In-Reply-To: <20171214173913.GA18100@jurassic.lan.banu.com> References: <20171214173913.GA18100@jurassic.lan.banu.com> From: Warren Kumari Date: Thu, 14 Dec 2017 13:09:30 -0500 Message-ID: To: Mukund Sivaraman Cc: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] CLIENT-SUBNET bis appetite? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 18:10:15 -0000 On Thu, Dec 14, 2017 at 12:39 PM, Mukund Sivaraman wrote: > Any appetite for it? Don't throw things at me.. I ask because the > current thing is slowly getting more widely deployed and there are > design issues that can do with a ECS2 that breaks from ECS1 protocol. I > ask because I'm once again having to deal with myriad implementation > cases and dislike it. > As I'm sure you know / remember, getting the first version though was quite a slog. I suspect that, seeing as there seems to be good support for the initial version, getting a new one done will be much simpler, but the obvious question is: How would ECS2 differ, and how would it interact with ECS1 / backward compatibility? W > Mukund > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Dec 14 13:40:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45045126FDC for ; Thu, 14 Dec 2017 13:40:58 -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, SPF_PASS=-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 AqNQFzUqFIFb for ; Thu, 14 Dec 2017 13:40:56 -0800 (PST) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C79271243F3 for ; Thu, 14 Dec 2017 13:40:56 -0800 (PST) Received: by chase.mycre.ws (Postfix, from userid 1000) id 1C61B12C1CFC; Thu, 14 Dec 2017 16:40:56 -0500 (EST) Date: Thu, 14 Dec 2017 16:40:56 -0500 From: Robert Edmonds To: bert hubert Cc: "zuopeng@cnnic.cn" , dnsop Message-ID: <20171214214056.r37cz5rbmpxwjw3q@mycre.ws> References: <2017121315404971736813@cnnic.cn> <20171213081823.GA8970@laperouse.bortzmeyer.org> <20171213084342.GA30523@server.ds9a.nl> <201712131736325755287@cnnic.cn> <20171213095015.GC30523@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171213095015.GC30523@server.ds9a.nl> Archived-At: Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 21:40:58 -0000 bert hubert wrote: > On Wed, Dec 13, 2017 at 05:36:32PM +0800, zuopeng@cnnic.cn wrote: > > so far as i know, many CDNs already use similar methods as you mentioned in PowerDNS 4.1.1 > > but i think only the Authoritative Server change is not enough, support on the recursive server is also very important . > > because the resolver determines the reponse to clients. > > This is true. A typical resolver will serve around 50,000 to 2,000,000 > users (although this is rare). This means that for 60 seconds, you shift > around 'a hundred thousand' potential users. > > In practice, this appears to be good enough from what I hear. > > Or let me put it another way, before we burden the DNS protocol with another > record type we have to add downgrade/workaround/DNSSEC support for, we > should have numbers that say it solves a problem. > > CDNs could maybe chime in. Hi, With my CDN hat on, I don't see any need to turn over scheduling decisions to resolvers. Extremely precise amounts of traffic can already be scheduled to individual CDN nodes because you have a large pool of owner names to work with, not a single owner name, and every (QNAME, QTYPE, resolver IP, client subnet [if present], anycast location that receives the query) tuple is an opportunity to make a unique scheduling choice. Generally, however, assignments to CDN nodes should be relatively sticky. You want to be shifting traffic for performance reasons, not capacity reasons. Or, put another way, we like existing resolver implementations just fine, we just wish there were a lot more resolver instances, and closer to clients :-) -- Robert Edmonds From nobody Thu Dec 14 13:42:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEC2128D3E for ; Thu, 14 Dec 2017 13:42:39 -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 qJMOn11nlYgy for ; Thu, 14 Dec 2017 13:42:38 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80E7127599 for ; Thu, 14 Dec 2017 13:42:38 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:1143:ea77:b6ef:69f3] (unknown [IPv6:2001:559:8000:c9:1143:ea77:b6ef:69f3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 8353961FA2; Thu, 14 Dec 2017 21:42:38 +0000 (UTC) Message-ID: <5A32F04D.7050307@redbarn.org> Date: Thu, 14 Dec 2017 13:42:37 -0800 From: Paul Vixie User-Agent: Postbox 5.0.22 (Windows/20171208) MIME-Version: 1.0 To: Robert Edmonds CC: bert hubert , dnsop , "zuopeng@cnnic.cn" References: <2017121315404971736813@cnnic.cn> <20171213081823.GA8970@laperouse.bortzmeyer.org> <20171213084342.GA30523@server.ds9a.nl> <201712131736325755287@cnnic.cn> <20171213095015.GC30523@server.ds9a.nl> <20171214214056.r37cz5rbmpxwjw3q@mycre.ws> In-Reply-To: <20171214214056.r37cz5rbmpxwjw3q@mycre.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 21:42:40 -0000 Robert Edmonds wrote: > Or, put another way, we like existing resolver implementations just > fine, we just wish there were a lot more resolver instances, and closer > to clients:-) on it. no smiley. -- P Vixie From nobody Thu Dec 14 17:51:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B002912711B for ; Thu, 14 Dec 2017 17:51:15 -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] 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 mr1BX29JRCZE for ; Thu, 14 Dec 2017 17:51:14 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 27855126E7A for ; Thu, 14 Dec 2017 17:51:14 -0800 (PST) Received: from [169.254.182.237] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id vBF1pATA084685 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 14 Dec 2017 18:51:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.182.237] From: "Paul Hoffman" To: "dnsop WG" Date: Thu, 14 Dec 2017 17:51:10 -0800 X-Mailer: MailMate (1.10r5443) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 01:51:16 -0000 Please see . This is a small set of changes that make the draft not treat the root zone as special. It allows the labels to be used for any zone, not just the root. --Paul Hoffman From nobody Thu Dec 14 18:30:14 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C07127867 for ; Thu, 14 Dec 2017 18:30: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 cmbNwg1f5cpE for ; Thu, 14 Dec 2017 18:30:09 -0800 (PST) Received: from off-send01.osa.jprs.co.jp (off-send01.osa.jprs.co.jp [IPv6:2001:218:3001:17::10]) (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 F202012704B for ; Thu, 14 Dec 2017 18:30:08 -0800 (PST) Received: from off-sendsmg01.osa.jprs.co.jp (off-sendsmg01.osa.jprs.co.jp [172.23.8.61]) by off-send01.osa.jprs.co.jp (8.14.4/8.14.4) with ESMTP id vBF2U32H002233; Fri, 15 Dec 2017 11:30:03 +0900 Received: from off-sendsmg01.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id AD890180064; Fri, 15 Dec 2017 11:30:01 +0900 (JST) Received: from localhost (off-cpu05.osa.jprs.co.jp [172.23.4.15]) by off-sendsmg01.osa.jprs.co.jp (Postfix) with ESMTP id BF6AC180062; Fri, 15 Dec 2017 11:30:00 +0900 (JST) Date: Fri, 15 Dec 2017 11:30:00 +0900 (JST) Message-Id: <20171215.113000.152427157235084555.fujiwara@jprs.co.jp> To: ggm@algebras.org Cc: marka@isc.org, dnsop@ietf.org, paul.hoffman@vpnc.org From: fujiwara@jprs.co.jp In-Reply-To: References: <56BEBCFA-D6BA-4BD1-8B95-190375A57C06@isc.org> <20171213.204234.76214525553211985.fujiwara@jprs.co.jp> X-Mailer: Mew version 6.5 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-7 Content-Transfer-Encoding: base64 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1690-8.1.0.1062-23530.004 X-TM-AS-Result: No--15.953-5.0-31-10 X-imss-scan-details: No--15.953-5.0-31-10 X-TMASE-MatchedRID: sbZa3S7lkwxCXIGdsOwlUu5i6weAmSDKZggZX8gYmrWo+b+yOP0oGHE9 8vK91Z4Whv8Adff05PpwouDsIRL+EI4CTcyNRTN3JrUxoq6hvw8Po0vi0aZfNQlbhF7ZTanLEW4 +DfKR/mE56WD6kuo88f8KtL8xX4mR+uobhwVz9gCRxP6bcyML8WGNLTRnb5Yt1jpotO/+/6IDh5 XrP5wcJ+LPNWnqmqF//BUfMjFyUxS6DbmOdQomtARH1Nr7oERd+KgiyLtJrSD9k2xa9Ahjg8+cw CLpvDnE5HVHMPpMs/zGsxJP3ZWJYPJTDg3ZC9Juqbg9uWhLYLdBldmDYjwlpudTjSOFC/vqo8WM kQWv6iXE6c2GmTspMEkEKHyz1RwNZz0AAGWYgqKg5oovEWFmKY6HM5rqDwqtoH3xd1DXwHzven7 oryAKFzg5YMkuG4nOczF70t23mPvRbeOlQyt7CQ== Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 02:30:12 -0000 VGhhbmtzLg0KDQpBZGRpbmcgYSBleGFtcGxlIGFzIGEgdGV4dCBpcyBhIGxpdHRsZSBjb21wbGlj YXRlZC4NCg0KQWRkaW5nIGV4YW1wbGVzIGFzIGEgdGFibGUgaXMgZ29vZCA/IG9yIHRvbyBsYXJn ZSA/DQoNCkRlbGVnYXRpb24gIHwgUGFyZW50IHwgTmFtZSBTZXJ2ZXIgTmFtZSAgIHwgVHlwZQ0K ICAgICAgICAgICAgfCBab25lICAgfCAgICAgICAgICAgICAgICAgICAgfA0KLS0tLS0tLS0tLS0t Ky0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KY29tICAgICAgICAgfCAuICAgICAgfCBhLmd0bGQtc2VydmVycy5uZXQgfCBpbi1iYWls aXdpY2sgLyBzaWJsaW5nIGRvbWFpbg0KbmV0ICAgICAgICAgfCAuICAgICAgfCBhLmd0bGQtc2Vy dmVycy5uZXQgfCBpbi1iYWlsaXdpY2sgLyBpbi1kb21haW4NCmV4YW1wbGUub3JnIHwgb3JnICAg IHwgbnMuZXhhbXBsZS5vcmcgICAgIHwgaW4tYmFpbGl3aWNrIC8gaW4tZG9tYWluDQpleGFtcGxl Lm9yZyB8IG9yZyAgICB8IG5zLmlldGYub3JnICAgICAgICB8IGluLWJhaWxpd2ljayAvIHNpYmxp bmcgZG9tYWluDQpleGFtcGxlLm9yZyB8IG9yZyAgICB8IG5zLmV4YW1wbGUuY29tICAgICB8IG91 dC1vZi1iYWlsaXdpY2sNCmV4YW1wbGUuanAgIHwganAgICAgIHwgbnMuZXhhbXBsZS5qcCAgICAg IHwgaW4tYmFpbGl3aWNrIC8gaW4tZG9tYWluDQpleGFtcGxlLmpwICB8IGpwICAgICB8IG5zLmV4 YW1wbGUubmUuanAgICB8IGluLWJhaWxpd2ljayAvIHNpYmxpbmcgZG9tYWluDQpleGFtcGxlLmpw ICB8IGpwICAgICB8IG5zLmV4YW1wbGUuY29tICAgICB8IG91dC1vZi1iYWlsaXdpY2sNCg0KLS0N CkthenVub3JpIEZ1aml3YXJhLCBKUFJTIDxmdWppd2FyYUBqcHJzLmNvLmpwPg0KDQo+IEZyb206 IEdlb3JnZSBNaWNoYWVsc29uIDxnZ21AYWxnZWJyYXMub3JnPg0KPiBmZWVscyBsaWtlIGEgY29u Y3JldGUgZXhhbXBsZSBpbiBhLmIuYy5leGFtcGxlLmNvbSB0ZXJtcyB3b3VsZCBoZWxwDQo+IGRl ZmluZSBib3RoIGluLWJhbGl3aWNrLCBhbmQgb3V0LW9mLWJhbGl3aWNrLCBmb3IgdGhlIGNhc2Vz Lg0KPiANCj4gT24gV2VkLCBEZWMgMTMsIDIwMTcgYXQgOTo0MiBQTSwgIDxmdWppd2FyYUBqcHJz LmNvLmpwPiB3cm90ZToNCj4+IFRoYW5rcy4NCj4+DQo+PiB0ZXJtaW5vbG9neS1iaXMtMDg6DQo+ PiB8IEluLWJhaWxpd2ljazogQW4gYWRqZWN0aXZlIHRvIGRlc2NyaWJlIGEgbmFtZSBzZXJ2ZXIg d2hvc2UgbmFtZSBpcw0KPj4gfCAgICBlaXRoZXIgc3Vib3JkaW5hdGUgdG8gb3IgKHJhcmVseSkg dGhlIHNhbWUgYXMgdGhlIHpvbmUgb3JpZ2luLg0KPj4NCj4+IE9rLCBJbi1iYWlsd2ljayBpbiB0 ZXJtaW5vbG9neS1iaXMtMDggbWF5IGJlIHJlc3RyaWN0aXZlIGJlY2F1c2UgInRoZQ0KPj4gem9u ZSBvcmlnaW4iIGlzIHVuY2xlYXIuIEkgaW50ZW5kZWQgdGhhdCAidGhlIHpvbmUgb3JpZ2luIiBp cyB0aGUgem9uZQ0KPj4gb3JpZ2luIG9mIHBhcmVudCB6b25lLiBUaGUgc2VudGVuY2UgbmVlZHMg bW9yZSB3b3Jkcy4NCj4+DQo+PiBORVcNCj4+DQo+PiAgIEluLWJhaWxpd2ljazogQW4gYWRqZWN0 aXZlIHRvIGRlc2NyaWJlIGEgbmFtZSBzZXJ2ZXIgd2hvc2UgbmFtZSBpcw0KPj4gICAgICAgIGVp dGhlciBzdWJvcmRpbmF0ZSB0byBvciAocmFyZWx5KSB0aGUgc2FtZSBhcyB0aGUgb3JpZ2luDQo+ PiAgICAgICAgb2YgdGhlIHpvbmUgdGhhdCBjb250YWlucyB0aGUgZGVsZWdhdGlvbiB0byB0aGUg bmFtZSBzZXJ2ZXIuDQo+Pg0KPj4gLi4uIGJhZCBlbmdsaXNoIHRleHQgLi4uIHBsZWFzZSBmaXgu DQo+Pg0KPj4gLS0NCj4+IEthenVub3JpIEZ1aml3YXJhLCBKUFJTIDxmdWppd2FyYUBqcHJzLmNv LmpwPg0KPj4NCj4+PiBGcm9tOiBNYXJrIEFuZHJld3MgPG1hcmthQGlzYy5vcmc+DQo+Pj4gVGhl IHRleHQgZm9yICJpbi1iYWlsd2ljayIgaXMgdG9vIHJlc3RyaWN0aXZlLCBpdCBkb2VzbqJ0IGp1 c3QgY292ZXIgTlMgcmVjb3JkcyBvcg0KPj4+IGdsdWUgcmVjb3Jkcy4NCj4+Pg0KPj4+IEluLWJh aWx3aWNrIHJlZmVycyB0byByZWNvcmRzIHRoYXQgaW4gdGhlIG5vcm1hbCBjb3Vyc2Ugb2YgRE5T IHJlc29sdXRpb24NCj4+PiB3b3VsZCBoYXZlIGJlZW4gcmVxdWVzdGVkIG9mIGJ5IHRoZSBzZXJ2 ZXIgdGhlIGN1cnJlbnQgcmVzcG9uc2UgaXMgZnJvbS4NCj4+PiBlLmcuIGlmIHlvdSBhcmUgcXVl cnlpbmcgYSAuY29tIHNlcnZlciB0aGVuIGFsbCByZWNvcmRzIGluIHRoZSByZXNwb25zZSB0aGF0 IGVuZA0KPj4+IHdpdGggLmNvbSBhcmUgaW4tYmFpbHdpY2suDQo+Pj4NCj4+PiBNYXJrDQo+Pj4N Cj4+Pj4gT24gNSBEZWMgMjAxNywgYXQgNToyNyBhbSwgUGF1bCBIb2ZmbWFuIDxwYXVsLmhvZmZt YW5AdnBuYy5vcmc+IHdyb3RlOg0KPj4+Pg0KPj4+PiBHcmVldGluZ3MgYWdhaW4uDQo+Pj4+DQo+ Pj4+IFNvbWUgb2YgdGhlIG5ldyB0ZXJtcyBhZGRlZCB0byB0aGUgdGVybWlub2xvZ3ktYmlzIGRy YWZ0IChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRuc29wLXRl cm1pbm9sb2d5LWJpcy8pc2luY2UgUkZDIDc3MTkgY2FuIGJlIGEgYml0IHRyaWNreS4gVGhpcyB3 ZWVrLCB3ZSBob3BlIHlvdSB3aWxsIGxvb2sgYXQgdGhlIGRlZmluaXRpb25zIGluIHRoZSBkcmFm dCBmb3I6DQo+Pj4+IC0gSW4tYmFpbGl3aWNrDQo+Pj4+IC0gT3V0LW9mLWJhaWxpd2ljaw0KPj4+ PiAtIEluLWRvbWFpbg0KPj4+PiAtIFNpYmxpbmcgZG9tYWluDQo+Pj4+IFBsZWFzZSByZXZpZXcg dGhlc2UgdGVybXMgYW5kIGNvbW1lbnQgb24gdGhlIGxpc3QgaWYgeW91IHRoaW5rIHRoZSBkZWZp bml0aW9ucyBzaG91bGQgY2hhbmdlLg0KPj4+Pg0KPj4+PiAtLVBhdWwgSG9mZm1hbg0KPj4+Pg0K Pj4+PiBbWyBBcyBhIHJlbWluZGVyLCB3ZSBhc2tlZCB0aGUgZm9sbG93aW5nIGxhc3Qgd2Vlaywg YnV0IGdvdCBubyByZXBseTogRm9yIHRoZSBwYXN0IG1hbnkgdmVyc2lvbnMgb2YgdGhlIHRlcm1p bm9sb2d5LWJpcyBkcmFmdCAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1kbnNvcC10ZXJtaW5vbG9neS1iaXMvKSwgU2VjdGlvbiAyIGhhcyBkZWZpbml0aW9ucyBv ZiAiR2xvYmFsIEROUyIgYW5kICJQcml2YXRlIEROUyIsIGJhc2VkIG9uIHRoZSBmYWNldHMgbGlz dGVkIGluICJOYW1pbmcgc3lzdGVtIi4gVGhpcyB3YXMgZGlzY3Vzc2VkIGhlYXZpbHkgb24gdGhl IGxpc3QgZWFybGllciwgYnV0IGl0IGlzIGFsc28gYSBwcmV0dHkgYmlnIGNoYW5nZSwgc28gd2Ug d2FudCB0byBiZSBzdXJlIHRoYXQgaXQgaXMgd2hhdCB0aGUgV0cgd2FudHMuIFBsZWFzZSByZXZp ZXcgdGhlc2UgdGVybXMgYW5kIGNvbW1lbnQgb24gdGhlIGxpc3QgaWYgeW91IHRoaW5rIHRoZSBk ZWZpbml0aW9ucyBzaG91bGQgY2hhbmdlLiBdXQ0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBETlNPUCBtYWlsaW5nIGxpc3QN Cj4+Pj4gRE5TT1BAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kbnNvcA0KPj4+DQo+Pj4gLS0NCj4+PiBNYXJrIEFuZHJld3MsIElTQw0KPj4+IDEg U2V5bW91ciBTdC4sIER1bmRhcyBWYWxsZXksIE5TVyAyMTE3LCBBdXN0cmFsaWENCj4+PiBQSE9O RTogKzYxIDIgOTg3MSA0NzQyICAgICAgICAgICAgICBJTlRFUk5FVDogbWFya2FAaXNjLm9yZw0K Pj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+PiBETlNPUCBtYWlsaW5nIGxpc3QNCj4+PiBETlNPUEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zb3ANCj4+Pg0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IEROU09QIG1haWxpbmcgbGlz dA0KPj4gRE5TT1BAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZG5zb3ANCj4gDQo= From nobody Thu Dec 14 19:26:20 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102471279EB for ; Thu, 14 Dec 2017 19:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 0XbEWxXY7eMa for ; Thu, 14 Dec 2017 19:26:17 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 B657D1200F1 for ; Thu, 14 Dec 2017 19:26:17 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id r184so1175961qke.8 for ; Thu, 14 Dec 2017 19:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Ow42v/UNQatumV1aMbnl03xUgxCF1pfBC1qNqrDkw9U=; b=ZTaaGErtEELhEg5H4rDLCUFLeqWQQGk75XUBsimfOu3nXL0lgufGYf80al2eNeFZQN uIYzOVp1m8wRCrbSlurgbk3YBUTUlLjYIG9AI6sp2mu896FyTSsomigNcNujVoir8am4 k8qjqtE5YL87E3E2jd7kQehdt61hGmeFz2o0BotwQOCF82kbptQ8tPmi5QaCKSoq4Qm4 8EaDfhmqqKHXRBrLHu/g6fTtjnT0NGboSdUVPmSS8SRsPlad2xlqZaJ0+x/p9jrpC3Pw vh2wMQkjKYMX4Ipi2iTOFEWXHx+qgVFHqesRJpm8L9ng4up2hd+kcZ9lCbOZAGhgB+Z4 f3Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Ow42v/UNQatumV1aMbnl03xUgxCF1pfBC1qNqrDkw9U=; b=k5SuXu8Z62Y3yOjBAfKZ1W4ef3PQlDheKhowTZY6idvonSQFFHFUNqYmjvPw4cskeQ bWD3sjBT0q2miPRQcZc3ttLZsT1VR3YM+rhrT59PzxZ5WuWOcmF9pTzMT7UkENTtTYx7 trdmqG5JG3ZjI9m1/fU95j9sQqcsRjZTQF05Ui0vMLyMdS0Nq9Gxu6se1IN9yMzkrwso wfTuqaZ96mAGzeOxzgFgjIVCRtZikxFBLtwsE2EKBzA6b+SQo3YUStUw4JXNVnCR37/E 8xpR/h0j5mVMyMfvikOKcMsE+mwHevjkfPE8VSGCsH+kgnLqrX5EG1vkcqUJrZrwMLtA 5Jdw== X-Gm-Message-State: AKGB3mI8/n3/fTm6JHm48dIbByjcC6s7Qr3g82zb5RJ6yIS2CEWyJLFN kcsLl6tbC7nz815UMsV7czt+uYks X-Google-Smtp-Source: ACJfBov3fDAPMfTbMGP4uas9Gg3fqrWnJCEyDeE15w/EDwphFtzHS+qd33TxPzSwnMKx04UGGTW2fA== X-Received: by 10.55.164.132 with SMTP id n126mr18498941qke.85.1513308375891; Thu, 14 Dec 2017 19:26:15 -0800 (PST) Received: from ?IPv6:2601:152:4400:720f::101f? ([2601:152:4400:720f::101f]) by smtp.gmail.com with ESMTPSA id z126sm3597259qka.70.2017.12.14.19.26.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 19:26:14 -0800 (PST) From: Michael StJohns To: Wes Hardaker Cc: dnsop@ietf.org References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> <142cad85-1e0e-b4c9-1561-ad590984739a@nthpermutation.com> <1ca3daed-d521-0fcd-d1e7-eef2b781707b@nthpermutation.com> <26d61092-942a-16bc-e939-ed9400a17a29@nthpermutation.com> Message-ID: <19e3ce86-c797-0e88-e192-e82b936be579@nthpermutation.com> Date: Thu, 14 Dec 2017 22:26:13 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <26d61092-942a-16bc-e939-ed9400a17a29@nthpermutation.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 03:26:20 -0000 Below is a java program I wrote to model this stuff.  In the table, SF2 represents the number of clients that blew past twice the safety factor (for aR+aHD+aR), SF1 represents the number of clients that blew past the single safety factor.  OF is the number of clients using the activeRefreshOffset calculation that finished after the calculated interval (e.g. aR+aHD+aRO).  OF+s is the number of clients that finished after the activeRefreshOffset + safetyFactor (in the first table these are the same because of perfect responses).   In the second table, compare SF1 to OF+s - SF1 < OF+s suggesting that activeRefresh is a better choice that activeRefreshQuery for the third term of the equation.  You can try a lot of different combinations, but I haven't found any case where OF+s performs better that SF1. The difference between lastStart and lAddHoldBegin represents the retransmits after the first query.  The differences between lAddHoldEnd and lFinalQuery represent retransmits after the last normal query before the end of the add hold down time until a valid answer was received after the addHoldDown time expired. Feel free to twiddle with this. In this table, almost 1/5th of each of the clients exceeds the activeRefreshOffset based calculation. Note that the safety factor doesn't come into play as this specifies a "0" query failure rate. > java Test5011 > Original TTL? (enter dd:hh:mm:ss) 1:4:0:0 > New TTL? (enter dd:hh:mm:ss) 1:4:0:0 > RRSig expiration interval? (enter dd:hh:mm:ss) 7:0:0:0 > > Orig TTL: 100800 seconds > New TTL: 100800 seconds > RRSig interval: 604800 seconds > QueryInterval: 50400 seconds > FastQuery: 8640 seconds > AddHoldDown: 2592000 seconds > ActiveRefreshOffset: 21600 seconds > activeRefresh + addHoldDown + activeRefresh: 2692800 > > Number of trials(-1 to exit) 10 > Number of clients(-1 to exit) 25000 > Failure rate [0 to .99999](-1 to exit) 0 > Calculated safety factor: 0 (0.000000) > aR + aHD + aR + sF: 2692800 > > Offset calc - aR + aHD + aRO: 2664000 > Offset plus safety: 2664000 > > Trial  LastStart  lAddHoldBegin lAddHoldEnd  sOffset lFinalQuery SF2 > SF1  OF  OF+s > ----------------------------------------------------------------------------------- > 0      50394      50394         2671194       28800 2671194    0    > 0    3459  3459 > 1      50399      50399         2671199       28800 2671199    0    > 0    3576  3576 > 2      50399      50399         2671199       28800 2671199    0    > 0    3540  3540 > 3      50399      50399         2671199       28800 2671199    0    > 0    3508  3508 > 4      50399      50399         2671199       28800 2671199    0    > 0    3610  3610 > 5      50399      50399         2671199       28800 2671199    0    > 0    3544  3544 > 6      50398      50398         2671198       28800 2671198    0    > 0    3546  3546 > 7      50399      50399         2671199       28800 2671199    0    > 0    3611  3611 > 8      50398      50398         2671198       28800 2671198    0    > 0    3579  3579 > 9      50398      50398         2671198       28800 2671198    0    > 0    3517  3517 > $ !-2 > java Test5011 > Original TTL? (enter dd:hh:mm:ss) 1:0:0:0 > New TTL? (enter dd:hh:mm:ss) 1:0:0:0 > RRSig expiration interval? (enter dd:hh:mm:ss) 7:0:0:0 > > Orig TTL: 86400 seconds > New TTL: 86400 seconds > RRSig interval: 604800 seconds > QueryInterval: 43200 seconds > FastQuery: 8640 seconds > AddHoldDown: 2592000 seconds > ActiveRefreshOffset: 0 seconds > activeRefresh + addHoldDown + activeRefresh: 2678400 > > Number of trials(-1 to exit) 10 > Number of clients(-1 to exit) 100000 > Failure rate [0 to .99999](-1 to exit) .25 > Calculated safety factor: 77760 (9.000000) > aR + aHD + aR + sF: 2756160 > > Offset calc - aR + aHD + aRO: 2635200 > Offset plus safety: 2712960 > > Trial  LastStart  lAddHoldBegin lAddHoldEnd  sOffset lFinalQuery SF2 > SF1  OF  OF+s > ----------------------------------------------------------------------------------- > 0      43199      108405        2769525       0 2769525    0    1    > 54772 31 > 1      43198      95039         2729831       0 2753326    0    0    > 55168 26 > 2      43199      111816        2725266       0 2740462    0    0    > 54697 44 > 3      43199      90159         2736412       0 2745052    0    0    > 54882 31 > 4      43199      100917        2727795       0 2729947    0    0    > 54869 33 > 5      43199      94115         2726425       0 2740485    0    0    > 54978 23 > 6      43199      117523        2735443       0 2743990    0    0    > 55306 27 > 7      43198      101417        2734743       0 2743383    0    0    > 55006 29 > 8      43199      94634         2728554       0 2747760    0    0    > 54943 36 > 9      43199      85218         2727853       0 2737153    0    0    > 55070 33 import java.io.*; import java.security.SecureRandom; public class Test5011 {   static  BufferedReader in = new BufferedReader(new InputStreamReader (System.in));   public static void main (String[] args)     throws Exception {     int ttl = getResponse("Original TTL");     int newTTL = getResponse ("New TTL");     int rrsigExpire = getResponse ("RRSig expiration interval");     System.out.println();     boolean useSafetyFactor = true;     System.out.printf ("Orig TTL: %d seconds%nNew TTL: %d seconds%nRRSig interval: %d seconds%n", ttl, newTTL, rrsigExpire);     int thirtyDays = convertToSeconds ("30:0:0:0");     int oneDay = convertToSeconds ("1:0:0:0");     int oneHour = convertToSeconds ("0:1:0:0");     int queryInterval = Math.max (oneHour, Math.min (thirtyDays/2, Math.min (ttl/2, rrsigExpire/2)));     int fastQuery = Math.max (oneHour, Math.min (oneDay/10, Math.min (ttl/10, rrsigExpire/10)));     int addHoldDown = Math.max (thirtyDays, newTTL);     System.out.printf ("QueryInterval: %d seconds%nFastQuery: %d seconds%nAddHoldDown: %d seconds%n",                queryInterval, fastQuery, addHoldDown);     int activeRefreshOffset = addHoldDown % queryInterval;     System.out.printf ("ActiveRefreshOffset: %d seconds%n", activeRefreshOffset);     System.out.printf ("activeRefresh + addHoldDown + activeRefresh: %d%n%n",                2*queryInterval + addHoldDown);     int numberOfTrials = getInt ("Number of trials");     int numberOfClients = getInt ("Number of clients");     double queryFailureRate = getDouble ("Failure rate [0 to .99999]");     double safetyFactorMultiple = Math.ceil((Math.log (numberOfClients)/Math.log(1.0/(queryFailureRate))));     int origSafetyFactor = fastQuery * (int)safetyFactorMultiple;     int safetyFactor = 2* fastQuery * (int)safetyFactorMultiple;     int totalSafeInterval = safetyFactor + 2* queryInterval + addHoldDown;     int totalOrigSafeInterval = origSafetyFactor + 2*queryInterval + addHoldDown;     int offsetInterval = queryInterval + addHoldDown + activeRefreshOffset;     int offsetSafeInterval = offsetInterval + origSafetyFactor;     System.out.printf ("Calculated safety factor: %d (%.6f)%n", origSafetyFactor, safetyFactorMultiple);     System.out.printf ("aR + aHD + aR + sF: %d%n%n", totalOrigSafeInterval);     System.out.printf ("Offset calc - aR + aHD + aRO: %d%n", offsetInterval);     System.out.printf ("Offset plus safety: %d%n%n", offsetSafeInterval);     SecureRandom rnd = new SecureRandom();     System.out.printf ("Trial  LastStart  lAddHoldBegin lAddHoldEnd  sOffset  lFinalQuery SF2 SF1  OF  OF+s%n"+ "-----------------------------------------------------------------------------------%n");     for (int j = 0; j < numberOfTrials; j++) {     int latestStartOffset = 0;     int latestAddHoldBegin = 0;     int latestAddHoldEnd = 0;     int latestFinalQuery = 0;     int smallestOffsetAtEndOfAddHold = queryInterval;     int numExceededSafety = 0;     int numExceedOrigSafety = 0;     int numExceedOffset = 0;     int numExceedOffsetSafe = 0;     for (int i = 0; i < numberOfClients; i++) {     // each trial       int startOffset = rnd.nextInt(queryInterval);       latestStartOffset = (startOffset > latestStartOffset) ? startOffset : latestStartOffset;       /* Roll the dice after each query and if we roll a number < the query failure rate, queue up a fast query and retry */       while (rnd.nextDouble () < queryFailureRate) {     startOffset += fastQuery;       }       latestAddHoldBegin = (startOffset > latestAddHoldBegin) ? startOffset : latestAddHoldBegin;       // At beginning of add hold down period       int trialAddHoldDown = 0;       do {     startOffset += queryInterval;     trialAddHoldDown += queryInterval;     // and retransmits     while  (rnd.nextDouble () < queryFailureRate) {       startOffset += fastQuery;       trialAddHoldDown += fastQuery;     }       } while (trialAddHoldDown  < addHoldDown);       latestAddHoldEnd = (startOffset > latestAddHoldEnd) ? startOffset : latestAddHoldEnd;       int holddiff = trialAddHoldDown - addHoldDown;       smallestOffsetAtEndOfAddHold = (holddiff < smallestOffsetAtEndOfAddHold) ?     holddiff : smallestOffsetAtEndOfAddHold;       // past the end of the addHoldDown, the previous last query above       while (rnd.nextDouble () < queryFailureRate) {     startOffset += fastQuery;       }       latestFinalQuery = (startOffset > latestFinalQuery) ? startOffset : latestFinalQuery;       if (startOffset > totalSafeInterval)     numExceededSafety++;       if (startOffset >totalOrigSafeInterval)     numExceedOrigSafety++;       if (startOffset > offsetInterval)     numExceedOffset++;       if (startOffset > offsetSafeInterval)     numExceedOffsetSafe++;     }     //System.out.printf ("Clients: %d%nLatestStartOffset %d%nLatestAddHoldBegin: %d%nLatestAddHoldEnd: %d%nSmallest Offset: %d%nLatestFinalQuery %d%n%n",     System.out.printf ("%-7d%-11d%-14d%-14d%-9d%-11d%-5d%-5d%-5d %-5d%n",                j,latestStartOffset, latestAddHoldBegin,                 latestAddHoldEnd, smallestOffsetAtEndOfAddHold,                latestFinalQuery, numExceededSafety,numExceedOrigSafety,numExceedOffset, numExceedOffsetSafe);     }   }    public static double getDouble (String prompt)     throws Exception {     do {       System.out.printf ("%s(-1 to exit) ", prompt);       String resp = in.readLine();       try {     double val = Double.valueOf(resp);     if (val < 0.0 || val >= 1.0)       throw new NumberFormatException ("Number out of range");     return val;       } catch (NumberFormatException ex) {     System.out.println (ex.getMessage());       }     } while (true);   }   public static int getInt (String prompt)     throws Exception {     do {       System.out.printf ("%s(-1 to exit) ", prompt);       String resp = in.readLine();       try {     int val = Integer.valueOf(resp);     if (val < 0)       System.exit(1);     return val;       } catch (NumberFormatException ex) {     System.out.println (ex.getMessage());       }     } while (true);   }   // return interval in seconds   public static int getResponse(String prompt)     throws Exception{     do {       System.out.printf ("%s? (enter dd:hh:mm:ss) ", prompt);       String resp = in.readLine();       try {     return convertToSeconds(resp);       } catch (NumberFormatException ex) {     System.out.println (ex.getMessage());       }     } while (true);   }   public static int convertToSeconds (String val)     throws NumberFormatException {     String[] comps = val.split(":");     if (comps.length != 4) {       throw new NumberFormatException ("Wrong number of components");     }     int[] conv = new int[4];     for (int i = 0; i < 4; i++) {       conv[i]  = Integer.valueOf(comps[i]);       if (conv[i] < 0)     throw new NumberFormatException("Less than zero");     }     if (conv[1] > 23 || conv[2] > 60 || conv[3] > 60) {     throw new NumberFormatException ("Bad format - out of range for one or more elements");     }     return conv[3] + conv[2] * 60 + conv[1] * 3600 + conv[0] * 86400;   } } From nobody Thu Dec 14 19:27:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E44B127B73 for ; Thu, 14 Dec 2017 19:27:39 -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 (2048-bit key) header.d=algebras-org.20150623.gappssmtp.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 poVvBDddhFIt for ; Thu, 14 Dec 2017 19:27:35 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 91B1D127867 for ; Thu, 14 Dec 2017 19:27:35 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id i20so5350701uak.6 for ; Thu, 14 Dec 2017 19:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=t1mQ61AnXQm4TQ0NQp0cDp3CibdGUSOBuJIkzsiWVu8=; b=JCoKWCpXG6xr/QV4eNg0SMDffWBvcw+mjIw56bwXPm8icfvx0QROnLkBpHFl7vD7Hd XsfMjP/SYtfc7bFgpXdWXnfWtKO/UnjDdbK8mUkqBlZqveomKZn3VAqxo7LytxU5pK1X zTGApo6EykrTYVYcZcw8iyE6Xqws7z+PcxOLcXjFKetbjdk1gvBYWu3qzintyMaryviy yW7E4KLLqmyZT7phZZjOCCORspDWMFZriwl1KW2X7s4kWs3WVBAia51VV1z6AfA3ydF/ ckMy5fNe1e5VeJqXMNSAQ7RhGt1COZW7NAd5Qsqmz/Jx7SrdrTlhgGIAb7M/4CwqFGgm hW3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=t1mQ61AnXQm4TQ0NQp0cDp3CibdGUSOBuJIkzsiWVu8=; b=TW0TR5ftzZ2QJWil/edJdUcF5UZPQL7c3tAoDOqzZU4vQP/H+A8XgpUnGZwK1HiBKH 83GL3KcymOT1YMKjXPYBV8IVP/WsddiIs5wunEIjhRx0nTpOk49PXRL/mq0w7Uecj2Z/ PD1WPRW61fcVMcb9PFn6KJ1wEa8646BOMjFYvmxB5po55mhXw5KwZH9N4AjD0NfEfl9s eonoXpkX2qQTsh98UqvNBcOjK2mXXinq0sZPUFv99ayEsFXcHU00RNHpb3s4s9woBkOw hVEr18DtVO1WMZgUz9cOD0m6HFSI4tBrZJ7p4dFU3FSgzoxq+ZqrDWDQ5MefM6gCTZrE 32Fw== X-Gm-Message-State: AKGB3mJbgbQ/XGJeVNpkCAMuULiuQy0VrHyzn1F350woNbjjyVsxqY5J 6aw7GwRJ9hrXy+6/6/DBSnyg5PtR5tTcttxU07asnh/m X-Google-Smtp-Source: ACJfBosae8lxQxc68kV4BMDdYdxjHavbMcdLck76lXJEupsOjRA3QbFFVdnasDS97305GmY0ajavOhIo+RaSKXTWkRk= X-Received: by 10.159.32.99 with SMTP id 90mr13558229uam.186.1513308454375; Thu, 14 Dec 2017 19:27:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.91.2 with HTTP; Thu, 14 Dec 2017 19:27:33 -0800 (PST) X-Originating-IP: [2001:dc0:2001:210:a533:3c22:2821:b26a] In-Reply-To: <20171215.113000.152427157235084555.fujiwara@jprs.co.jp> References: <56BEBCFA-D6BA-4BD1-8B95-190375A57C06@isc.org> <20171213.204234.76214525553211985.fujiwara@jprs.co.jp> <20171215.113000.152427157235084555.fujiwara@jprs.co.jp> From: George Michaelson Date: Fri, 15 Dec 2017 13:27:33 +1000 Message-ID: To: fujiwara@jprs.co.jp Cc: "marka@isc.org" , dnsop WG , Paul Hoffman Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 03:27:39 -0000 yes. this is good. -G On Fri, Dec 15, 2017 at 12:30 PM, wrote: > Thanks. > > Adding a example as a text is a little complicated. > > Adding examples as a table is good ? or too large ? > > Delegation | Parent | Name Server Name | Type > | Zone | | > ------------+--------+--------------------+------------------------------ > com | . | a.gtld-servers.net | in-bailiwick / sibling domain > net | . | a.gtld-servers.net | in-bailiwick / in-domain > example.org | org | ns.example.org | in-bailiwick / in-domain > example.org | org | ns.ietf.org | in-bailiwick / sibling domain > example.org | org | ns.example.com | out-of-bailiwick > example.jp | jp | ns.example.jp | in-bailiwick / in-domain > example.jp | jp | ns.example.ne.jp | in-bailiwick / sibling domain > example.jp | jp | ns.example.com | out-of-bailiwick > > -- > Kazunori Fujiwara, JPRS > >> From: George Michaelson >> feels like a concrete example in a.b.c.example.com terms would help >> define both in-baliwick, and out-of-baliwick, for the cases. >> >> On Wed, Dec 13, 2017 at 9:42 PM, wrote: >>> Thanks. >>> >>> terminology-bis-08: >>> | In-bailiwick: An adjective to describe a name server whose name is >>> | either subordinate to or (rarely) the same as the zone origin. >>> >>> Ok, In-bailwick in terminology-bis-08 may be restrictive because "the >>> zone origin" is unclear. I intended that "the zone origin" is the zone >>> origin of parent zone. The sentence needs more words. >>> >>> NEW >>> >>> In-bailiwick: An adjective to describe a name server whose name is >>> either subordinate to or (rarely) the same as the origin >>> of the zone that contains the delegation to the name server. >>> >>> ... bad english text ... please fix. >>> >>> -- >>> Kazunori Fujiwara, JPRS >>> >>>> From: Mark Andrews >>>> The text for "in-bailwick" is too restrictive, it doesn=E2=80=99t just= cover NS records or >>>> glue records. >>>> >>>> In-bailwick refers to records that in the normal course of DNS resolut= ion >>>> would have been requested of by the server the current response is fro= m. >>>> e.g. if you are querying a .com server then all records in the respons= e that end >>>> with .com are in-bailwick. >>>> >>>> Mark >>>> >>>>> On 5 Dec 2017, at 5:27 am, Paul Hoffman wrote= : >>>>> >>>>> Greetings again. >>>>> >>>>> Some of the new terms added to the terminology-bis draft (https://dat= atracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since RFC 7719 can = be a bit tricky. This week, we hope you will look at the definitions in the= draft for: >>>>> - In-bailiwick >>>>> - Out-of-bailiwick >>>>> - In-domain >>>>> - Sibling domain >>>>> Please review these terms and comment on the list if you think the de= finitions should change. >>>>> >>>>> --Paul Hoffman >>>>> >>>>> [[ As a reminder, we asked the following last week, but got no reply:= For the past many versions of the terminology-bis draft (https://datatrack= er.ietf.org/doc/draft-ietf-dnsop-terminology-bis/), Section 2 has definitio= ns of "Global DNS" and "Private DNS", based on the facets listed in "Naming= system". This was discussed heavily on the list earlier, but it is also a = pretty big change, so we want to be sure that it is what the WG wants. Plea= se review these terms and comment on the list if you think the definitions = should change. ]] >>>>> >>>>> _______________________________________________ >>>>> DNSOP mailing list >>>>> DNSOP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnsop >>>> >>>> -- >>>> Mark Andrews, ISC >>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>>> >>>> _______________________________________________ >>>> DNSOP mailing list >>>> DNSOP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnsop >>>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> From nobody Thu Dec 14 21:46:33 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B429C126B7E for ; Thu, 14 Dec 2017 21:46:31 -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 p7kBwLsjdudi for ; Thu, 14 Dec 2017 21:46:27 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0088.outbound.protection.outlook.com [104.47.93.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8194D1241F5 for ; Thu, 14 Dec 2017 21:46:25 -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=zJ669to8zZfe/M6A3+DDt08vSen3NA9S77n5Al4wfaI=; b=FTkGLPLUG04UXl1IbfShdsa5V7AY9aXF/8vcXqP00K/RTtO6Nbv1jTqpJipx3JyH1hNKL3wIUBL9N+zgZyySxKGj2gquc9yonWciRbVJln3PBx1YK9rNDboFK0o4TnKxo7xmfaHpwqlGqUQPG1Bqbal3orilOxzmizyZ3Z002T8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from [IPv6:2602:306:b894:2bb0:a9e4:3647:f46f:c2f9] (2602:306:b894:2bb0:a9e4:3647:f46f:c2f9) by TY1PR04MB0703.apcprd04.prod.outlook.com (10.163.246.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Fri, 15 Dec 2017 05:46:20 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Geoff Huston In-Reply-To: Date: Fri, 15 Dec 2017 16:45:46 +1100 Cc: dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: <5E1FF941-C80D-442C-ABB5-6C81F3B1A149@apnic.net> References: To: Paul Hoffman X-Mailer: Apple Mail (2.3445.4.7) X-Originating-IP: [2602:306:b894:2bb0:a9e4:3647:f46f:c2f9] X-ClientProxiedBy: DM5PR13CA0070.namprd13.prod.outlook.com (10.175.103.160) To TY1PR04MB0703.apcprd04.prod.outlook.com (10.163.246.25) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 89ed77e6-d4f3-4049-7521-08d5437f2b99 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:TY1PR04MB0703; X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0703; 3:DIZDyAUnOaC/cVh1JIW7HeT4A4mxO98NpKp5XYZ76IXCUqiCvOcpxvyN94Yc/jO7xi/OEcQ7q2+yE76V8E6cHFJ0tXyw0i4ObgO/qXqUfIgCCfrO34X1oDzbEGo/CcgIqR0tDnhbOhmTg1vKTzo01BnKB1KRv2jYmkBgFHzBtZt+30tFRjHalA25TsqBwy4WTNAfF1tqqyf9u7EeU7JfmYa11CJ2LQrIN+5oKYtH+XyNTWzdjEXaHjoHsW3MTjiG; 25:LVVesP1rqZ1M0KGNr3EueX2eSmmiWvGNmoXZKlnqmN9pG3doakdeYjXieOKtY3IBNB0V+BvVk8XMXLKhqSnftICIGoktAhQ+eGUDJkNHKommeDOybYZQ08hRGy/H6AIooYQcCk9IpbVq/nZQ1iK+0mDoXtK0sZq4DXJu8JsVhbuhvt0fC/IhDoxa3gsyRgWY+rZMqluy6jG/d9BVsaVuDYGblTjFF4zNeh8YYy51WSgyy8X1DLS5GDa4Q86ZG/DwhUZ90RGFfr8jmPw657x92/8QqrgVcnhaSTekT2S/J3DrSrHn8VJ+rBv5bBoy7OWacTNaPUcWfaCLlt73Jol7cg==; 31:WWkE/u1DUl5EFGetjEckn4ehduaK5h4sYUsZLJ5qUlFMoGnH7r3cbFExJ85SeI9mWwgyPdPDpNeAL5c+GL8zRAFtPuRwH8iqwaC2shvw+Va0ELPjy29W985OXL/RF5IkWyIDZxq3hCYH+rT5x5Kjdh9NDlpdNXNu+83le94x7282kyNZFwqp+uLiHACMW0/M8C4YPt5dE44J/u3zMOMHRdYqJ+2GCCh7Okzwo/A7V7A= X-MS-TrafficTypeDiagnostic: TY1PR04MB0703: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(166708455590820); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231023)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011); SRVR:TY1PR04MB0703; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:TY1PR04MB0703; X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0703; 4:ifjmgHiJqaAvc+bCLd4GPVoym2Y5u4eNvCIXkLFYJXNn7h7D6VwZUjTH4DG1l/8qptbhn5emedc0GpJNqiM+KJnEjD8wvTTM7dmD7xntrVdOZz6naDeLKqdV/Gd4GwzCd9uGmbcHJ9N+/nIwcqwZZEcYF9sRPjVaGBlTLKRVyeb8u+RLIE8AzlLRg/3TQrOsRax+6v2shvDzf+TM84EiTd9/SITn3Ovm/cjl2kJXWHpCYLh+zBY3wl58EAuJshjVZyxllXR9nzkha4bPeGuNzxHgA5dDUrLc8Vyo+f/cRiMytP5+yDgnsVaFyeZk8+dG X-Forefront-PRVS: 05220145DE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39840400004)(346002)(396003)(24454002)(189003)(199004)(8746002)(25786009)(6116002)(2906002)(53936002)(1706002)(6666003)(316002)(57306001)(47776003)(4326008)(6246003)(6916009)(2950100002)(36756003)(97736004)(478600001)(81166006)(81156014)(8676002)(6306002)(33656002)(5660300001)(230783001)(305945005)(7736002)(105586002)(50466002)(83716003)(106356001)(86362001)(82746002)(68736007)(52116002)(229853002)(6486002)(386003)(8936002)(76176011)(53546011)(2486003)(52146003)(50226002)(23676004)(52396003)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:TY1PR04MB0703; H:[IPv6:2602:306:b894:2bb0:a9e4:3647:f46f:c2f9]; 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?MTtUWTFQUjA0TUIwNzAzOzIzOm5FaG95TTRNdWVPQ055QUkrV25vNkFldFNv?= =?utf-8?B?ME1Vb0NQQkppeDI0cFl5REFsaGZONnNKcmlOaUExOXNkQVVQU0tobEFlYjFF?= =?utf-8?B?bzFrMWw1Y1BQYkFVenFucmNrYlNGSTlnRkVhcDJRUUJUcXNlaXpPZE5qUjhR?= =?utf-8?B?SmRlT2NpNlA2bEptenRoSjRQd2tWVWVjUHRZWVhkR3g0SldHZk1veXpNell5?= =?utf-8?B?M2ZlNUxrNG8zQVRJamlZOFZTR0l0K2tLUUhZS2wyd2lDRExLL05TdXJ0QmVG?= =?utf-8?B?Z3FwRXd3ekFsN2ErNXZQMEVEaSsvemhYb2RwNFV5aWdlaDFTUDFrWEdSd0tz?= =?utf-8?B?OWlZQ20yQ1diNUp5L1FwK3hBS3ZEdExyZ0dVZkNJTmdvZHlhSU5iM2t5M2Q1?= =?utf-8?B?cG5tSER4LzNVS0wvM1RybWZYQXpaczc5MTlxbXVRa2JiWXo2KzFIM3BsUDQ5?= =?utf-8?B?WGhtVkIydkE5ak1sZmZOckVxZ0ZXTHM5aEVqVXR3ME1pSEpwd3RUOW16bEVJ?= =?utf-8?B?MmhydmphU2xRaHdRL1Z0OThtcSsva0szOGN3SkI1SDRoYlptclRtN2EwWFly?= =?utf-8?B?TXo1L0NmM1dhczk2N3czUUF4cUVOV0Vub3VGTE1VRHNIcEtBNEs1c1czQW5L?= =?utf-8?B?cWN3c0RRN1BCUEtaemRsR0hzUEE0c3JFakF6Q2ZNbkk3ZmNRY1dEb09BdVlQ?= =?utf-8?B?SEVqZjRCQ05Dc25zMVhGcUFucmZWZ0xGNjg0Vi9JUU9CbFAwUUhSZGg5by9W?= =?utf-8?B?ZDczQ2V0S2c0T1JSdXkxN2luQmgva0VNb3FWV2o1OFJicXA2TUJDWlQxOEt0?= =?utf-8?B?WEFNSHJhWDl3S0wweFJWT3RpK25zaUc4aitEVzlIRzJyR3R2K0hWM2tiQmVT?= =?utf-8?B?MDNGNEFIeXZnKzltN0hsanhLNUErOVovRzZlbG1wd0NzSlhTTGNNdWwzaG9i?= =?utf-8?B?UHROYnNPcXhjRUpuaXRwYXJuNUFaV1R4MTl3Uk13b1JMZmFDanpiTGJqRHhj?= =?utf-8?B?TzhDSjNEZlcxTkJxWGd4U2ZwWUFRaDlPZFF4SUVBdnJBQndvQU15R2FXQ3VC?= =?utf-8?B?SElWU1BrWHJWbEN5eHhsY3M2cDNFeXE4NGJCSHdoQUY0WktSbEgzQWtheDFG?= =?utf-8?B?bG9zY0tpYWVhQ0RTZy9zeGpaaHpQekhjSDRHbkxKRitoT25hVlF2dWM2WlBk?= =?utf-8?B?QWV2SnVraGNTcXAxRCtIYzdpalo1SnpnN082SWhsVkJHRzI4SjJRdzUrQVh1?= =?utf-8?B?WmZZUEpyalZCaEVmaWJRUnRIM3lPM2xBbm1FR0RoYnpOQkFDSzNtN0NDYlMy?= =?utf-8?B?UTdtVllSUmszS0NUaVdObEk4eXJheDBac3dSQVoyei9wVllaSE1ma1FmZ3ZM?= =?utf-8?B?NHNFMHVacjJGcHJXQ2ZOVmlYQjRVMjVNNTB1R1JqaXErRlQ1SytVdjJVK3pv?= =?utf-8?B?UHNhV0pOc2lrV2RQNnk0TWM3T3diZmZyN2prTDU3OHdQU2w3VVZIaWxUTmhG?= =?utf-8?B?TEVpM3liWHo4cEd6N3VsKzJDUmN5V3hFUVA5WjJLckVwTUVVaFJOZlRrdjBG?= =?utf-8?B?di9qYXBTZDlmRjU0ZGFvYnFjdFViNi9RNTdtemlpdW1KQm9XMlk5NjZpTzJ0?= =?utf-8?B?UzgrYjFYbXhuVEoyYnlqWXhqWUcvcGdhMTIzemN2NVZNbGNNbS91NmRBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR04MB0703; 6:Znpq+Y6jjowAaNRt+uak3HfbPyYMhPV/uIbmSHpGALcbRX4pQjC9iRHP1T+Bas6t5+GMupCFfHoEYQ3Ihcz66o7pOSM+3cA2ckBZ6MzdO2SOSh6TTIhzCfb0hw6++Qq9tHqPYuqMXGecmzF0UGN8LTje2I2Sg1PF1apFE7AUDMrjdU5aoagabVq7fRYiurDXIUAbXi0H/HYMzv4qXErER9HpSpYeiH9F2hfTpjSHpmJcHnvd0A1wZ2Qdg0SG+P8b0OABG4U3NifLJv+YI1FPCiP5g2RX9r6IKpZjq2xIkXigh7qYgMb0WW05G5wv5t2lKotMeoOJh+tOy2D9khnR//7VOnJ2Ozd/jRtQKyW+gIA=; 5:th/Ip5wk0rzzWmT5UTt+0HyHamdsxOToMPIs9GIjukQU3QqZoWmj5WPgzjEbTs0LWFR7+tyX9bgLzl2nCGYKkI1JAaYeNeArIyWV7AcnfSZM4Nq9pOc5Nw9FzJ+KUfmToEDgxknAYlUCePwUSyF/bOO1LqLwYFUOqMay27X6H0U=; 24:sEoauTWGydYMph12faTgf0SPVeDn2bJ4BZHzaLfidZWNtk8q6yHqGKdERFZEKmRyaJt816QDIsEbFf/VcWOSTYEqxWuQU/ZVTfjxjmXToPw=; 7:zUl/7m5ZhMH6iF3ia1tfwGtUlDx1khyAGNL/RnPUJBK88WJmEe5YcJNBJ5FZdT/l0Xk+VcV2LceU6X87P1JR9xvVvbfBojfnqHtKu60MpFoBXECP15RwWbVI3rtR8bwVdmZ4Zoo+UuT5OiZF2HfwvP6/qftw8MZsTkX0waZHDCxggPUTdqbHwrnVO4+93PrUcXalj5SWpNzkaoHAmdIb0IdLUrPH4yD9sN4o3gqGWMOSRam6z7Qnw/h2Ez3H4M56 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Dec 2017 05:46:20.4177 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 89ed77e6-d4f3-4049-7521-08d5437f2b99 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR04MB0703 Archived-At: Subject: Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 05:46:31 -0000 Hi Paul, > On 15 Dec 2017, at 12:51 pm, Paul Hoffman = wrote: >=20 > Please see = . This is a = small set of changes that make the draft not treat the root zone as = special. It allows the labels to be used for any zone, not just the = root. >=20 Could you please elaborate on the motivation here? I am unsure whether = this is needed, or, perhaps more critically, I=E2=80=99m unsure if this = represents a harmless general form of information disclosure (that the = resolver is using local trust keys for some unspecified non-root zone). I agree the mechanics of the change in the text, and even in the code = for support this are pretty minor, but I am slightly worried about the = intended generality of the proposed change being a small step too far, = so I am curious to understand why you are advocating this change. regards, Geoff From nobody Fri Dec 15 00:19:49 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B854127419 for ; Fri, 15 Dec 2017 00:19:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 90DCpqd38G-3 for ; Fri, 15 Dec 2017 00:19:46 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 122E0124D37 for ; Fri, 15 Dec 2017 00:19:45 -0800 (PST) Received: by ajax-webmail-ocmail02.zx.nicx.cn (Coremail) ; Fri, 15 Dec 2017 16:19:44 +0800 (GMT+08:00) X-CM-HeaderCharset: UTF-8 X-Originating-IP: [218.241.103.18] Date: Fri, 15 Dec 2017 16:19:44 +0800 (GMT+08:00) From: =?UTF-8?B?5bem6bmP?= To: "Robert Edmonds" Cc: "bert hubert" , dnsop X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT3.0.5b dev build 20150108(58896.7041) Copyright (c) 2002-2017 www.mailtech.cn cnnic In-Reply-To: <20171214214056.r37cz5rbmpxwjw3q@mycre.ws> References: <2017121315404971736813@cnnic.cn> <20171213081823.GA8970@laperouse.bortzmeyer.org> <20171213084342.GA30523@server.ds9a.nl> <201712131736325755287@cnnic.cn> <20171213095015.GC30523@server.ds9a.nl> <20171214214056.r37cz5rbmpxwjw3q@mycre.ws> X-SendMailWithSms: false Content-Transfer-Encoding: base64 Content-Type: text/plain; charset=UTF-8 MIME-Version: 1.0 Message-ID: <3519c0a3.328f.1605941fa4b.Coremail.zuopeng@cnnic.cn> X-CM-TRANSID: AQAAf0BJUNyghTNaWNU9AA--.4784W X-CM-SenderInfo: x2xr1vlqj6u0xqlfhubq/1tbiAQAPCSVCN20LiAAAs5 X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VW3Jw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Archived-At: Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 08:19:48 -0000 DQp0aGFua3MgZm9yIHlvdXIgY29tbWVudCENCg0KPiAtLS0tLeWOn+Wni+mCruS7ti0tLS0tDQo+ IOWPkeS7tuS6ujogIlJvYmVydCBFZG1vbmRzIiA8ZWRtb25kc0BteWNyZS53cz4NCj4g5Y+R6YCB 5pe26Ze0OiAyMDE3LTEyLTE1IDA1OjQwOjU2ICjmmJ/mnJ/kupQpDQo+IOaUtuS7tuS6ujogImJl cnQgaHViZXJ0IiA8YmVydC5odWJlcnRAcG93ZXJkbnMuY29tPg0KPiDmioTpgIE6ICJ6dW9wZW5n QGNubmljLmNuIiA8enVvcGVuZ0Bjbm5pYy5jbj4sIGRuc29wIDxkbnNvcEBpZXRmLm9yZz4NCj4g 5Li76aKYOiBSZTogW0ROU09QXSBBc2sgZm9yIGFkdmljZSBvZiAzIG5ldyBSUnMgZm9yIHByZWNp c2UgdHJhZmZpYyBzY2hlZHVsaW5nDQo+IA0KPiBiZXJ0IGh1YmVydCB3cm90ZToNCj4gPiBPbiBX ZWQsIERlYyAxMywgMjAxNyBhdCAwNTozNjozMlBNICswODAwLCB6dW9wZW5nQGNubmljLmNuIHdy b3RlOg0KPiA+ID4gIHNvIGZhciBhcyBpIGtub3csIG1hbnkgQ0ROcyBhbHJlYWR5IHVzZSBzaW1p bGFyIG1ldGhvZHMgYXMgeW91IG1lbnRpb25lZCBpbiBQb3dlckROUyA0LjEuMSANCj4gPiA+ICBi dXQgIGkgdGhpbmsgb25seSB0aGUgIEF1dGhvcml0YXRpdmUgU2VydmVyIGNoYW5nZSBpcyBub3Qg ZW5vdWdoLCAgc3VwcG9ydCBvbiB0aGUgcmVjdXJzaXZlIHNlcnZlciBpcyBhbHNvIHZlcnkgaW1w b3J0YW50IC4NCj4gPiA+ICAgYmVjYXVzZSB0aGUgcmVzb2x2ZXIgZGV0ZXJtaW5lcyB0aGUgcmVw b25zZSB0byBjbGllbnRzLg0KPiA+IA0KPiA+IFRoaXMgaXMgdHJ1ZS4gIEEgdHlwaWNhbCByZXNv bHZlciB3aWxsIHNlcnZlIGFyb3VuZCA1MCwwMDAgdG8gMiwwMDAsMDAwDQo+ID4gdXNlcnMgKGFs dGhvdWdoIHRoaXMgaXMgcmFyZSkuIFRoaXMgbWVhbnMgdGhhdCBmb3IgNjAgc2Vjb25kcywgeW91 IHNoaWZ0DQo+ID4gYXJvdW5kICdhIGh1bmRyZWQgdGhvdXNhbmQnIHBvdGVudGlhbCB1c2Vycy4g DQo+ID4gDQo+ID4gSW4gcHJhY3RpY2UsIHRoaXMgYXBwZWFycyB0byBiZSBnb29kIGVub3VnaCBm cm9tIHdoYXQgSSBoZWFyLg0KPiA+IA0KPiA+IE9yIGxldCBtZSBwdXQgaXQgYW5vdGhlciB3YXks IGJlZm9yZSB3ZSBidXJkZW4gdGhlIEROUyBwcm90b2NvbCB3aXRoIGFub3RoZXINCj4gPiByZWNv cmQgdHlwZSB3ZSBoYXZlIHRvIGFkZCBkb3duZ3JhZGUvd29ya2Fyb3VuZC9ETlNTRUMgc3VwcG9y dCBmb3IsIHdlDQo+ID4gc2hvdWxkIGhhdmUgbnVtYmVycyB0aGF0IHNheSBpdCBzb2x2ZXMgYSBw cm9ibGVtLg0KPiA+IA0KPiA+IENETnMgY291bGQgbWF5YmUgY2hpbWUgaW4uDQo+IA0KPiBIaSwN Cj4gDQo+IFdpdGggbXkgQ0ROIGhhdCBvbiwgSSBkb24ndCBzZWUgYW55IG5lZWQgdG8gdHVybiBv dmVyIHNjaGVkdWxpbmcNCj4gZGVjaXNpb25zIHRvIHJlc29sdmVycy4gRXh0cmVtZWx5IHByZWNp c2UgYW1vdW50cyBvZiB0cmFmZmljIGNhbiBhbHJlYWR5DQo+IGJlIHNjaGVkdWxlZCB0byBpbmRp dmlkdWFsIENETiBub2RlcyBiZWNhdXNlIHlvdSBoYXZlIGEgbGFyZ2UgcG9vbCBvZg0KPiBvd25l ciBuYW1lcyB0byB3b3JrIHdpdGgsIG5vdCBhIHNpbmdsZSBvd25lciBuYW1lLCBhbmQgZXZlcnkg KFFOQU1FLA0KPiBRVFlQRSwgcmVzb2x2ZXIgSVAsIGNsaWVudCBzdWJuZXQgW2lmIHByZXNlbnRd LCBhbnljYXN0IGxvY2F0aW9uIHRoYXQNCj4gcmVjZWl2ZXMgdGhlIHF1ZXJ5KSB0dXBsZSBpcyBh biBvcHBvcnR1bml0eSB0byBtYWtlIGEgdW5pcXVlIHNjaGVkdWxpbmcNCj4gY2hvaWNlLiBHZW5l cmFsbHksIGhvd2V2ZXIsIGFzc2lnbm1lbnRzIHRvIENETiBub2RlcyBzaG91bGQgYmUNCj4gcmVs YXRpdmVseSBzdGlja3kuIFlvdSB3YW50IHRvIGJlIHNoaWZ0aW5nIHRyYWZmaWMgZm9yIHBlcmZv cm1hbmNlDQo+IHJlYXNvbnMsIG5vdCBjYXBhY2l0eSByZWFzb25zLg0KPiANCg0KVGhlICJwcmVj aXNlIHRyYWZmaWNlIHNjaGVkdWxpbmciIGkgbWVudGlvbmVkIGlzIG5vdCBvbmx5IGZvciBwZXJm b3JtYW5jZSByZWFzb24sIGJ1dCBhbHNvIGZvciBjYXBhY2l0eSByZWFzb24uDQpGb3IgcGVyZm9y bWFuY2UsIGkgdGhpbmsgdGhlIGV4aXN0aW5nIHN5c3RlbSBhbHJlYWR5IHdvcmtzIGZpbmUuIEFz IGxvbmcgYXMgYSBDRE4gRE5TIGhhcyAidmlldyIgZnVuY3Rpb24sIHRoZSBsb2NhbCBETlMgY2Fu IA0KYnJpbmcgdGhlIGNsaWVudCB0byB0aGUgY2xvc2VzdCBDRE4gbm9kZXMgZWFzaWx5LiAgDQpG b3IgY2FwYWNpdHksIGhlcmUgaXMgYSB1c2VyIGNhc2UuIEkgbGVhcm5lZCB0aGlzIGNhc2UgZnJv bSBwZW9wbGUgd29ya2luZyBpbiBhIENETiBjb21wYW55LHRob3VnaCBpIGFtIG5vdCBzdXJlIGlm IGl0IGlzIGEgDQpjb21tb24gcHJvYmxlbSB3b3JsZHdpZGUuIEZvciBleGFtcGxlLCBhIENETiBw cm92aWRlciBoYXMgMTBHIGNhcGFjaXR5IGluIHByb3ZpbmNlIEEgYW5kIDhHIGluIHByb3ZpbmNl IEIuIChCIGlzIGNsb3NlIHRvIEEgDQpnZW9ncmFwaGljYWxseSkuICBGb3Igc29tZSByZWFzb24o ZWcuIGxhcmdlIHBvcHVsYXRpb24gaW4gQSksIDEwRyBpcyBub3QgZW5vdWdoIGluIHRoZSBydXNo IGhvdXIuIEFzc3VtZSB0aGVyZSBpcyAxMkcgdHJhZmZmaWMgZHVyaW5nIHJ1c2ggaG91ciwgdGhl IENETiBuZWVkcyB0byBzY2hlZHVsZSAyRyB0byBwcm92aW5jZSBCIHdoaWxlIGtlZXAgMTBHIGlu IEEuICANCg0KDQo+IE9yLCBwdXQgYW5vdGhlciB3YXksIHdlIGxpa2UgZXhpc3RpbmcgcmVzb2x2 ZXIgaW1wbGVtZW50YXRpb25zIGp1c3QNCj4gZmluZSwgd2UganVzdCB3aXNoIHRoZXJlIHdlcmUg YSBsb3QgbW9yZSByZXNvbHZlciBpbnN0YW5jZXMsIGFuZCBjbG9zZXINCj4gdG8gY2xpZW50cyA6 LSkNCj4gDQoNCnllcywgbW9yZSByZXNvbHZlcnMgYXJlIGdvb2QgdG8gaW1wcm92ZSB1c2VyIGV4 cGVyaWVuY2UuDQpidXQgYWxzbyBtYXliZSB3ZSBzaG91bGQgbm90aWNlIGVhY2ggQ0ROIG5vZGUg aGFzIGRpZmZlcmVudCBjYXBhY2l0eS4oaXQgaXMgdGhlIHJlYWwgaW4gcHJhY3RpY2UpLg0KYSAi d2VpZ2h0LWF3YXJlIiByb3NvbHZlciBjYW4gc2NoZWR1bGUgY2xpZW50cyB0byBkaWZmZW50IG5v ZGVzIGFjY29yZGluZyB0byB3ZWlnaHQgcHJpY2lzZWx5Lg0Kb3Igc2hhbGwgd2UgZG8gc29tZXRo aW5nIG9ubHkgZm9yIGF1dGhvcml0YXRpdmUgc2VydmVyIGxpa2UgZGVmaW5pbmcgdGhlIHdlaWdo dGVkIEEvQUFBQXg/IA0KDQpidHcsIGFueSBjb21tZW50cyBvbiB0aGUgd2VpZ2h0ZCBDTkFNRVhz IGZvciBtdWx0aS1DRE4/IDopDQo+IC0tIA0KPiBSb2JlcnQgRWRtb25kcw0K From nobody Fri Dec 15 07:32:00 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C8B126B6E for ; Fri, 15 Dec 2017 07:31:59 -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] 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 EKLNX3hshbYS for ; Fri, 15 Dec 2017 07:31:56 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 5F623124205 for ; Fri, 15 Dec 2017 07:31:56 -0800 (PST) Received: from [10.32.60.141] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id vBFFVjTw085867 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Dec 2017 08:31:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.141] From: "Paul Hoffman" To: "Geoff Huston" Cc: "dnsop WG" Date: Fri, 15 Dec 2017 07:31:45 -0800 X-Mailer: MailMate (1.10r5443) Message-ID: In-Reply-To: <5E1FF941-C80D-442C-ABB5-6C81F3B1A149@apnic.net> References: <5E1FF941-C80D-442C-ABB5-6C81F3B1A149@apnic.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 15:31:59 -0000 On 14 Dec 2017, at 21:45, Geoff Huston wrote: >> Please see >> . This >> is a small set of changes that make the draft not treat the root zone >> as special. It allows the labels to be used for any zone, not just >> the root. >> > > Could you please elaborate on the motivation here? The last sentence is the motivation. Some operators add trust anchors for things other than the root to their validating resolver, and a user might want to know if such a trust anchor exists and, if it does, what the key tag is. > I am unsure whether this is needed, or, perhaps more critically, I’m > unsure if this represents a harmless general form of information > disclosure (that the resolver is using local trust keys for some > unspecified non-root zone). Serious question: in your mind, why is the answer for non-root zone any more "information disclosure" than for the root zone? > I agree the mechanics of the change in the text, and even in the code > for support this are pretty minor, but I am slightly worried about the > intended generality of the proposed change being a small step too far, > so I am curious to understand why you are advocating this change. Because the root zone is not special for DNSSEC. --Paul Hoffman From nobody Fri Dec 15 07:37:27 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565651270A7 for ; Fri, 15 Dec 2017 07:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 2MTKxqzUZ5a7 for ; Fri, 15 Dec 2017 07:37:25 -0800 (PST) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (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 CDCE3126B6E for ; Fri, 15 Dec 2017 07:37:24 -0800 (PST) Received: by mail-it0-x242.google.com with SMTP id f190so19798255ita.5 for ; Fri, 15 Dec 2017 07:37:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3N1L6O2sM0AMXgZBC+LlNRHJ6bjEmOlNSziATw+I0LM=; b=LF8FaVvnnqT2jXfWRh4Tp+rSRfcFy3Y+n5O19T5Psm7YTpFvzDJNkwM5pITjnmQd3h BH3l3npqwD/TY4LxfTtpyr+JkZoRDh0CAyPzI7zGXepC3WW0gMF/gs1GTCMvvIpBSYR0 D4GhY2wDUQ0nQ1AD8mbPcqtYLuFQk7fbWy0vc= 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=3N1L6O2sM0AMXgZBC+LlNRHJ6bjEmOlNSziATw+I0LM=; b=HgAlLoS4X9qdPhgldw2z4tFTmNqFYHIvwfGQyqoLqX0l+vbXdku2dDkggfiovJ4hoI 0hcu3Kw5WJpYU/hCMw29Qt0GY1kQx9oGPRdLigpGoTwEDA1sB0CxP95LOBPgbDLzDy/O HgiYAhWpHVuY4U8+8okMTwRkYMGAx2daBW6upu7o6LPha4R8/GKta2yfvu77I9HPYG1k UsjDui5A6d7d112+I/ATVeomCcU/WjINj0Z3FVDzER/G4IXSvQFG9V3wvq8Y4THblBhi VF5RIfcAf0yP2CDP0ffXkeskL/d0lNMQQsCYEHF4KdjSYYyye/83xIstxIth/AOThcbn W6MA== X-Gm-Message-State: AKGB3mJpHO01MQtuCPicVGZpum2CC0Gg1WRHYquKmJ0hoxTQJgMHO7Of lljVqnxT3mf7cG7ypy1EdifkAROIz3s= X-Google-Smtp-Source: ACJfBot1zJ+54F7Qofx3944tMQViKgTtJxD+LROa5UkjhaoyWSqL0XSXTEQSw8228W3rMo+hG+Q0dA== X-Received: by 10.36.107.69 with SMTP id v66mr9370277itc.10.1513352244045; Fri, 15 Dec 2017 07:37:24 -0800 (PST) Received: from [199.212.92.9] (135-23-173-35.cpe.pppoe.ca. [135.23.173.35]) by smtp.gmail.com with ESMTPSA id d3sm3856495itf.1.2017.12.15.07.37.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 07:37:22 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Abley In-Reply-To: Date: Fri, 15 Dec 2017 10:37:17 -0500 Cc: Geoff Huston , dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E1FF941-C80D-442C-ABB5-6C81F3B1A149@apnic.net> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 15:37:26 -0000 On 15 Dec 2017, at 10:31, Paul Hoffman wrote: > On 14 Dec 2017, at 21:45, Geoff Huston wrote: >=20 >> I agree the mechanics of the change in the text, and even in the code = for support this are pretty minor, but I am slightly worried about the = intended generality of the proposed change being a small step too far, = so I am curious to understand why you are advocating this change. >=20 > Because the root zone is not special for DNSSEC. I agree with that philosophically, but not practically. In practical terms anybody who has a non-root trust anchor installed has = a bidirectional operational relationship with the people who publish it. = Synchronising that trust anchor, with the glorious benefit of a full = list of relying parties and knowledge of how to interact with them, is a = far cry from the situation we find ourselves in with the root zone. While it's conceptually elegant to have this mechanism easily available = to the operator of nameservers for any zone, it's not clear to me that = this is supported by a tangible use case. If changes motivated by this desire for elegance weaken support for the = one use case we have, they seem like a bad idea. (Not saying they do; I = haven't thought about them that hard and in any case I am not an = implementor.) Joe= From nobody Fri Dec 15 07:48:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281241270A7 for ; Fri, 15 Dec 2017 07:48:15 -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] 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 9Fy0F9A2lHVQ for ; Fri, 15 Dec 2017 07:48:13 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 A4BAD126C89 for ; Fri, 15 Dec 2017 07:48:13 -0800 (PST) Received: from [10.32.60.141] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id vBFFm91k090572 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Dec 2017 08:48:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.141] From: "Paul Hoffman" To: "Joe Abley" Cc: "dnsop WG" Date: Fri, 15 Dec 2017 07:48:10 -0800 X-Mailer: MailMate (1.10r5443) Message-ID: <630B95A9-2F0A-45C3-9C50-4901291DD67D@vpnc.org> In-Reply-To: References: <5E1FF941-C80D-442C-ABB5-6C81F3B1A149@apnic.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 15:48:15 -0000 On 15 Dec 2017, at 7:37, Joe Abley wrote: > On 15 Dec 2017, at 10:31, Paul Hoffman wrote: > >> On 14 Dec 2017, at 21:45, Geoff Huston wrote: >> >>> I agree the mechanics of the change in the text, and even in the >>> code for support this are pretty minor, but I am slightly worried >>> about the intended generality of the proposed change being a small >>> step too far, so I am curious to understand why you are advocating >>> this change. >> >> Because the root zone is not special for DNSSEC. > > I agree with that philosophically, but not practically. > > In practical terms anybody who has a non-root trust anchor installed > has a bidirectional operational relationship with the people who > publish it. Synchronising that trust anchor, with the glorious benefit > of a full list of relying parties and knowledge of how to interact > with them, is a far cry from the situation we find ourselves in with > the root zone. Fully agree. But you don't say why that should prevent a resolver's user from testing that. > While it's conceptually elegant to have this mechanism easily > available to the operator of nameservers for any zone, it's not clear > to me that this is supported by a tangible use case. A TLD operator who doesn't really like the fact that ICANN and Verisign control the contents of the root zone declares that their KSK has tag 12321 and will have that tag until further notice. They suggest that everyone who wants to trust them should install their current KSK as a trust anchor because who knows what evil or incompetent thing ICANN and Verisign will do in the future. A user wants to see if their resolver operator has done so. (I wish this was far-fetched. Since starting to work for ICANN, I have been told **by people on this list** that this could happen for their TLDs.) > If changes motivated by this desire for elegance weaken support for > the one use case we have, they seem like a bad idea. (Not saying they > do; I haven't thought about them that hard and in any case I am not an > implementor.) Thinking hard about the above use case is very unpleasant, I admit. It indicates that some TLD operators might make validation for their own zones more fragile. And yet it is discussed more regularly than you would hope. --Paul Hoffman From nobody Fri Dec 15 08:11:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6481292F4 for ; Fri, 15 Dec 2017 08:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.921 X-Spam-Level: X-Spam-Status: No, score=-3.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_NEUTRAL=0.779] 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 728P2uBCSxLK for ; Fri, 15 Dec 2017 08:11:48 -0800 (PST) Received: from smtp85.iad3a.emailsrvr.com (smtp85.iad3a.emailsrvr.com [173.203.187.85]) (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 72F41127868 for ; Fri, 15 Dec 2017 08:11:48 -0800 (PST) Received: from smtp27.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp27.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9B32024F5B; Fri, 15 Dec 2017 11:11:42 -0500 (EST) X-Auth-ID: matt@kahlerlarson.org Received: by smtp27.relay.iad3a.emailsrvr.com (Authenticated sender: matt-AT-kahlerlarson.org) with ESMTPSA id 7ACD524E15; Fri, 15 Dec 2017 11:11:42 -0500 (EST) X-Sender-Id: matt@kahlerlarson.org Received: from [192.168.1.48] (pool-96-255-43-12.washdc.fios.verizon.net [96.255.43.12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:465 (trex/5.7.12); Fri, 15 Dec 2017 11:11:42 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Matt Larson In-Reply-To: <630B95A9-2F0A-45C3-9C50-4901291DD67D@vpnc.org> Date: Fri, 15 Dec 2017 11:11:41 -0500 X-Mao-Original-Outgoing-Id: 535047101.932811-512e9283da3f25a3206d8326a44ec4d9 Content-Transfer-Encoding: quoted-printable Message-Id: <1F03D499-5754-47CC-85B3-FFA0D9B536CC@kahlerlarson.org> References: <5E1FF941-C80D-442C-ABB5-6C81F3B1A149@apnic.net> <630B95A9-2F0A-45C3-9C50-4901291DD67D@vpnc.org> To: Paul Hoffman , Joe Abley , dnsop WG X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:11:50 -0000 > On Dec 15, 2017, at 10:48 AM, Paul Hoffman = wrote: >=20 >> While it's conceptually elegant to have this mechanism easily = available to the operator of nameservers for any zone, it's not clear to = me that this is supported by a tangible use case. >=20 > A TLD operator who doesn't really like the fact that ICANN and = Verisign control the contents of the root zone declares that their KSK = has tag 12321 and will have that tag until further notice. They suggest = that everyone who wants to trust them should install their current KSK = as a trust anchor because who knows what evil or incompetent thing ICANN = and Verisign will do in the future. A user wants to see if their = resolver operator has done so. >=20 > (I wish this was far-fetched. Since starting to work for ICANN, I have = been told **by people on this list** that this could happen for their = TLDs.) Even if someone says "this could happen for their TLD", I think the = sentiment is really "they fear that this could happen for their TLD". = And people are afraid of a lot of things that have an extremely low = probability of occurring, which is the territory we're in when it comes = to fearing that ICANN would do something "evil or incompetent" with the = root zone. Since I've been at ICANN, I've been impressed with the extent = to which the community's wishes drive what the organization does, and = since the IANA transition, there are no actors besides the ICANN = community to influence root zone management. As for Verisign, they are ICANN's contractor for root zone management, = so they are prohibited by contract from doing anything evil, and = Verisign's competence when it comes to root zone management is not a = thing I worry about. So having been on the inside of both ICANN and Verisign, I can state = without hesitation that concern about evil or incompetence regarding = root zone policy and management should be low on everyone's list. Matt P.S. Though this message is in reply to Paul, he knows all of this and = I'm stating it for the record. From nobody Fri Dec 15 08:24:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD8E12932A for ; Fri, 15 Dec 2017 08:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.921 X-Spam-Level: X-Spam-Status: No, score=-3.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_NEUTRAL=0.779] 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 BjHQlNofXG4r for ; Fri, 15 Dec 2017 08:24:04 -0800 (PST) Received: from smtp109.iad3a.emailsrvr.com (smtp109.iad3a.emailsrvr.com [173.203.187.109]) (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 2B36B120227 for ; Fri, 15 Dec 2017 08:24:04 -0800 (PST) Received: from smtp14.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6585225232; Fri, 15 Dec 2017 11:24:03 -0500 (EST) X-Auth-ID: matt@kahlerlarson.org Received: by smtp14.relay.iad3a.emailsrvr.com (Authenticated sender: matt-AT-kahlerlarson.org) with ESMTPSA id 43F7C2513D; Fri, 15 Dec 2017 11:24:03 -0500 (EST) X-Sender-Id: matt@kahlerlarson.org Received: from [192.168.1.48] (pool-96-255-43-12.washdc.fios.verizon.net [96.255.43.12]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:465 (trex/5.7.12); Fri, 15 Dec 2017 11:24:03 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Matt Larson In-Reply-To: Date: Fri, 15 Dec 2017 11:24:02 -0500 Cc: Paul Hoffman , dnsop WG X-Mao-Original-Outgoing-Id: 535047842.624204-3dc45a3fda7f9b7ccff0ec666a315327 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E1FF941-C80D-442C-ABB5-6C81F3B1A149@apnic.net> To: Joe Abley X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:24:05 -0000 > On Dec 15, 2017, at 10:37 AM, Joe Abley wrote: >=20 > In practical terms anybody who has a non-root trust anchor installed = has a bidirectional operational relationship with the people who publish = it. Synchronising that trust anchor, with the glorious benefit of a full = list of relying parties and knowledge of how to interact with them, is a = far cry from the situation we find ourselves in with the root zone. I'm not convinced that even in the scenario you describe the trust = anchor publisher could really count on knowing all the relying parties. = And even if they did, a mechanism to give visibility would still be = desirable, even in that controlled situation. I think there should be a very high bar for making any zone special in = the protocol. In this case, I don't see the harm in making the sentinel = mechanism more general, especially if implementations offer controls to = disable it on a per-zone basis. With my root zone KSK roll = responsibility hat on, I'd sure like for this mechanism to be enabled by = default. In that case, an operator could have the ability to shut off = sentinel on secret.example but easily leave it enabled for the root. Matt From nobody Fri Dec 15 08:34:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5922126B6E for ; Fri, 15 Dec 2017 08:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 tTRo6jkq9IR2 for ; Fri, 15 Dec 2017 08:34:37 -0800 (PST) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::243]) (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 761F2120227 for ; Fri, 15 Dec 2017 08:34:37 -0800 (PST) Received: by mail-it0-x243.google.com with SMTP id t1so20772309ite.5 for ; Fri, 15 Dec 2017 08:34:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tzOhJrC/3jb+z2kTbUgtp+LIUPAEXxwQ258nkAfMvZA=; b=EGMhimDN6Y7AWi0OeNcbn9lGq+CX7lUc3Dj1R4MoBfxqPsu5Lb/mgvXROiMsWBC+/C OgKozT33LL7XfqjycdT69gcdWB/IuEz90fCu3Nn73BOwtoqa0xZqDF2kSkrYsd5LOf3e HK2tm0awAUxo7vlm+/cZPhJpTWVTDWgtpduvk= 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=tzOhJrC/3jb+z2kTbUgtp+LIUPAEXxwQ258nkAfMvZA=; b=FGXJD4SNtlH2XAl+aCqQBcsv3vbb8lC/hah8X5nJRC9q6gMxFaydbaRJ1Ze5LdXZrk zJro1ICMbrjKK6S3mkovOuAOYCnRmTk5HCSL4Rms50VZZJFzN2Yzgop/KI93LQkxL4nD kTfGKJ960pguJykEbayBM5k3WEAd7d5vubh1OC5MB1iqEi7aiIa7/A2Dqcu7FBYa8Fva Cx1fq0a+j7aK30Pg66b8DVGSx71/utkaQJE1rlrLI9x9C5BSKGm7WSRl8/9++9N5jYQC y6lGsSK5fbqouTO/C1UFDouBkn6y5UpfaHYeoW52YfCj1ahR0LYwocol3mcvCioTE39a lHcw== X-Gm-Message-State: AKGB3mKsMAMYrR2M7F+msaT0njK+fEehifZK4bR/8db9Ar39dgY1bVYt I9a4HIGy+rA0ODaXaSpyk2zWPg== X-Google-Smtp-Source: ACJfBos8dWrQNC8zjhjV0HNTYn1Fohwz3mTieclcA51uROYyPjKD11C6TKmbH4OvqCXE3HGUIQ2p0w== X-Received: by 10.36.16.206 with SMTP id 197mr9002672ity.1.1513355676806; Fri, 15 Dec 2017 08:34:36 -0800 (PST) Received: from [199.212.92.9] (135-23-173-35.cpe.pppoe.ca. [135.23.173.35]) by smtp.gmail.com with ESMTPSA id v11sm4019324itf.6.2017.12.15.08.34.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 08:34:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Abley In-Reply-To: Date: Fri, 15 Dec 2017 11:34:28 -0500 Cc: Paul Hoffman , dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: <0790F3D6-5257-4C17-A724-7B8EB27748BB@hopcount.ca> References: <5E1FF941-C80D-442C-ABB5-6C81F3B1A149@apnic.net> To: Larson Matt X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:34:40 -0000 On 15 Dec 2017, at 11:24, Matt Larson wrote: >> On Dec 15, 2017, at 10:37 AM, Joe Abley wrote: >>=20 >> In practical terms anybody who has a non-root trust anchor installed = has a bidirectional operational relationship with the people who publish = it. Synchronising that trust anchor, with the glorious benefit of a full = list of relying parties and knowledge of how to interact with them, is a = far cry from the situation we find ourselves in with the root zone. >=20 > I'm not convinced that even in the scenario you describe the trust = anchor publisher could really count on knowing all the relying parties. = And even if they did, a mechanism to give visibility would still be = desirable, even in that controlled situation. That seems fair. I was definitely speaking from a set of personal = assumptions without any data; it's certainly possible that non-root = trust anchors are widely deployed, however much I haven't seen it. Joe From nobody Fri Dec 15 08:50:17 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733B112711D for ; Fri, 15 Dec 2017 08:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 NKIWhdI17kgK for ; Fri, 15 Dec 2017 08:50:14 -0800 (PST) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEB7120227 for ; Fri, 15 Dec 2017 08:50:14 -0800 (PST) Received: from jurassic.lan.banu.com (unknown [182.156.108.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 352FE56A085A; Fri, 15 Dec 2017 16:50:11 +0000 (GMT) Date: Fri, 15 Dec 2017 22:20:08 +0530 From: Mukund Sivaraman To: bert hubert Cc: dnsop@ietf.org Message-ID: <20171215165008.GA11449@jurassic.lan.banu.com> References: <20171214173913.GA18100@jurassic.lan.banu.com> <20171214180058.GC4176@server.ds9a.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171214180058.GC4176@server.ds9a.nl> User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: Re: [DNSOP] CLIENT-SUBNET bis appetite? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 16:50:16 -0000 On Thu, Dec 14, 2017 at 07:00:58PM +0100, bert hubert wrote: > On Thu, Dec 14, 2017 at 11:09:13PM +0530, Mukund Sivaraman wrote: > > Any appetite for it? Don't throw things at me.. I ask because the > > current thing is slowly getting more widely deployed and there are > > design issues that can do with a ECS2 that breaks from ECS1 protocol. I > > ask because I'm once again having to deal with myriad implementation > > cases and dislike it. > > Could you elaborate what you dislike most? It is too complicated to implement ECS correctly. There are a large number of corner cases. The things that resolvers and authoritative sides have to take care of are quite different. It is more complex than anything else in DNS. I think this should be built again from scratch. > The biggest thing we are noticing is that while it does great things > to getting to a server the content provider likes, it unavoidably > drives doen cache hitrates a lot, introducing a latency penalty. > > The operators we see deploying ECS have tens of thousands of subnets > which all need to be mapped to only a few servers. But you still end up > with tens of thousands of cache entries and therefore tiny cache hitrates. > > Such things could be addressed by answering with lists of subnet masks to > which this answer would also apply, but this makes little sense > operationally I think. Firstly, correct deaggregation is an important requirement of reducing cache usage. With the current design of ECS protocol, it's very important that correct disjoining of prefixes be done optimally to avoid cache pollution, yet the draft does not specify a suitable algorithm for it (we know how to do it, I think the draft should have stated it). A /n address prefix as specified by ECS option is a perfect binary tree of 1< source) * 10.0.1.0/23 answer * 10.0.0.0/22 exact match answer (scope > source) * 10.0.3.0/22 answer and so on.. there are about 2n+1 answers necessary so that a 0.0.0.0/0 answer does not override a /n client from receiving its specific answer. x x x x x x x x x x x x x y y If ECS option had more fields, we could have put the above pattern as a difference of trees (with direction bit and height, e.g., "x"s in the diagram above) and it would have reduced cache usage considerably. This can be generalized with more differences but anyway I think that using QUERY for ECS is a badly done idea (not even mentioning privacy loss). As an example, RPZ does not rely on queries.. it transfers all prefixes for matching in a zone so that the longest prefix match algorithm will not suffer from a previously cached shorter prefix matching and preventing future fetches. Another related problem is this: We often want to match against a GeoIP database (containing what may be changing but maintained prefixes) in associating zone data with geographic/network-topo clients. We want to say "serve this answer for country X or city Y or ASNNNN" and we don't care about managing the actual prefixes. GeoIP is a custom database format, where I can match against GeoIP, but I can't easily deaggregate all its prefixes for an ECS zone to be cached properly. I feel it would have been better to say to a downstream resolver "This answer is for country X", or "A is the answer for country X, B is the answer for country Y, the rest use answer C". The design of ECS needs to be reconsidered. I'd prefer something like a zone format for it, than using QUERY. QUERY cannot give complete information about all prefixes and there is a possibility of incorrect caching, and a very high probability of redundant cache pollution. >From a resolver's point of view, a non-ECS answer (no client-subnet option) is different from an ECS answer with scope=0 which is different from an ECS answer with source=0, whereas all these may be the same from an authority's point of view. They all need to be cached differently (from an intermediate resolver's view). This thing of scope > source meaning for-exact-match-only is weird as hell when implementing longest prefix matching. It is not convenient to use an off-the-shelf radix tree. ECS relies on the option always being returned for any kind of answers, as some resolvers use that as an indicator of ECS support (and stop using ECS if it ever stops). But ECS does not apply to several kinds of answers (e.g., anything but NOERROR, esp. NXDOMAIN and NODATA have to be consistent across all prefixes.) It doesn't apply to SOA, DNSKEY, NS in answer section, referrals, etc. Yet, many of these need to answer with SCOPE=0. An ACL config option about whether the NS supports ECS or not (to return the option or not) is different from a config option whether the NS passes through ECS or not: the latter would always pass through SOURCE=0 but return REFUSED for any ECS queries that didn't match the ACL; where as the former would return non-ECS reply for any ECS queries that didn't match the ACL). Transitivity of the option has corner cases. I don't have to point out how easy it is for a erroneous /16 to prevent queries to /24 answers shadowed by the /16. Some cache cases: Obviously an ECS cache is different from a zone.. it's not from a single zone, it is not an atomic collection of a single version of zone and ever changing. If there's a /24 answer in cache, and a newer query brings in a /16 answer that shadows it, should the resolver assume that the /16 has precedence because it's newer (hence the /24 should no longer exist) or do a longest-prefix-match against the older /24? What if the /16 then expires and the /24 hasn't expired? An NXDOMAIN answer should expire any previously cached prefix-specific cache entries for that name. A NODATA answer should expire any previously cached prefix-specific cache entries for that type. Non-ECS data is different from SCOPE=0 data. There are questions about trust ranking with usage of ECS data. These are just some topics that I can quickly think of. There are many other issues we faced and discussed during resolver ECS development. The draft leaves many things unspecified, such as more clarity in DNSSEC and handling of negative answers. Many issues were fixed during the draft phase, but I feel it was insufficient. > Can you share your ideas for ECS2? There are many quirks in ECS. I don't want to propose specific ideas now, except that we should gather requirements and start from scratch. We have to reduce complexity of the protocol on both auth and caching resolver sides. I think it should be designed again from requirements without being a tweak of ECS1. The current protocol complicates DNS implementation significantly. Mukund From nobody Fri Dec 15 09:16:49 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8531293DF for ; Fri, 15 Dec 2017 09:16:47 -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, HTML_MESSAGE=0.001, 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 HZGv9bCA7rEt for ; Fri, 15 Dec 2017 09:16:45 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84F61200CF for ; Fri, 15 Dec 2017 09:16:45 -0800 (PST) Received: from localhost.localdomain (dhcp-153.access.lah1.vix.su [24.104.150.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 9E98D61FA2; Fri, 15 Dec 2017 17:16:45 +0000 (UTC) From: Paul Vixie To: dnsop@ietf.org Cc: =?utf-8?B?5bem6bmP?= , Robert Edmonds , bert hubert Date: Fri, 15 Dec 2017 09:16:45 -0800 Message-ID: <2963886.DngpFJ6m7L@localhost.localdomain> Organization: none User-Agent: KMail/4.13.0.30 (Linux/4.13.16-202.fc26.x86_64; KDE/4.14.32; x86_64; ; ) In-Reply-To: <3519c0a3.328f.1605941fa4b.Coremail.zuopeng@cnnic.cn> References: <2017121315404971736813@cnnic.cn> <20171214214056.r37cz5rbmpxwjw3q@mycre.ws> <3519c0a3.328f.1605941fa4b.Coremail.zuopeng@cnnic.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart1718149.DTi4WEc3rW" Content-Transfer-Encoding: 7Bit Archived-At: Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 17:16:47 -0000 This is a multi-part message in MIME format. --nextPart1718149.DTi4WEc3rW Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday, December 15, 2017 04:19:44 PM =E5=B7=A6=E9=B9=8F wrote: > thanks for your comment! >=20 >=20 > > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: "Robert Edmonds" > > Or, put another way, we like existing resolver implementations just= > > fine, we just wish there were a lot more resolver instances, and cl= oser > > to clients :-) > >=20 >=20 >=20 > yes, more resolvers are good to improve user experience. > but also maybe we should notice each CDN node has different capacity.= (it is > the real in practice). a "weight-aware" rosolver can schedule clients= to > diffent nodes according to weight pricisely. load vs. capacity information varies too often to publish guidance abou= t it in DNS. if a=20 CDN can topolocate an HTTP initator, it can vary its answer according t= o load, far=20 better than it can predict or estimate both load, capacity, and topoloc= ation in a way=20 expressible in the DNS. > or shall we do something only > for authoritative server like defining the weighted A/AAAAx?=20 > btw, any comments on the weightd CNAMEXs for multi-CDN? :) we should do neither. the path you are recommending increases complexit= y by a=20 greater order of magnitude than any possible or prospective resulting b= enefit. --=20 P. Vixie --nextPart1718149.DTi4WEc3rW Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

On = Friday, December 15, 2017 04:19:44 PM =E5=B7=A6=E9=B9=8F wrote:

>= ; thanks for your comment!

>= ;

>= ;

>= ; > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-----

>= ; > =E5=8F=91=E4=BB=B6=E4=BA=BA: "Robert Edmonds" <edmo= nds@mycre.ws>

>= ; > Or, put another way, we like existing resolver implementations j= ust

>= ; > fine, we just wish there were a lot more resolver instances, and= closer

>= ; > to clients :-)

>= ; >

>= ;

>= ;

>= ; yes, more resolvers are good to improve user experience.

>= ; but also maybe we should notice each CDN node has different capacity.= (it is

>= ; the real in practice). a "weight-aware" rosolver can schedu= le clients to

>= ; diffent nodes according to weight pricisely.

 

loa= d vs. capacity information varies too often to publish guidance about i= t in DNS. if a CDN can topolocate an HTTP initator, it can vary its ans= wer according to load, far better than it can predict or estimate both = load, capacity, and topolocation in a way expressible in the DNS.

 

>= ; or shall we do something only

>= ; for authoritative server like defining the weighted A/AAAAx?

>= ; btw, any comments on the weightd CNAMEXs for multi-CDN? :)

 

we = should do neither. the path you are recommending increases complexity b= y a greater order of magnitude than any possible or prospective resulti= ng benefit.

 

-- =

P. = Vixie

--nextPart1718149.DTi4WEc3rW-- From nobody Fri Dec 15 09:31:56 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A526129411 for ; Fri, 15 Dec 2017 09:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.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 dZ-X5tbKwlvr for ; Fri, 15 Dec 2017 09:31:38 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (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 0DD1C12940F for ; Fri, 15 Dec 2017 09:31:38 -0800 (PST) Received: from [IPv6:2a04:b900:0:1:746f:fbee:87b9:7a43] (unknown [IPv6:2a04:b900:0:1:746f:fbee:87b9:7a43]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 2005385B4 for ; Fri, 15 Dec 2017 18:31:36 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1513359096; bh=6w2Dp2OjXxQfe0RoTMqTCJtJOC0g0EhS37RMDy820UE=; h=Subject:To:References:From:Date:In-Reply-To; b=tGbzCRpUCBzCpnV0eNdbeYXUxB723+7K9yyYBV8D3bimGCU8e4oNYE9YZjEoWeAbK Kl18QlErxrXeSwDCVNBfvoDB9w2UK+uEpVKCva4BuJczRLRRGGnQzfXljkeqMnOnrk JWMwNAt1yAuqCazDosc7llEViI3PmPRXuDngt9dQ= To: dnsop@ietf.org References: From: Ralph Dolmans Message-ID: Date: Fri, 15 Dec 2017 18:31:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 17:31:40 -0000 Hi, On 15-12-17 02:51, Paul Hoffman wrote: > Please see > . This is a > small set of changes that make the draft not treat the root zone as > special. It allows the labels to be used for any zone, not just the root. I agree that a mechanism that works for all trust anchors (like RFC8145 does) is preferable. I am, however, not sure that this suggestion works. If I understand this proposal the idea is to use the keytag to find the correct TA. This might work for most cases but it is possible to have a non-root TA with the same keytag as the root. Or someone can, for some weird reason, configure the root key as one of the entries for a local TA. For this mechanism to work, the validator need to know the TA's zone. This can be done by always using the root or by signaling the TA name, for example in the query. The latter can be as simple as using the TA for the qname without the special label. So: - _is-ta-.example.com. -> applies for example.com TA - _is-ta-. -> applies for root TA In this case only the root zone manager can control the test addresses for the root TA, which some might see as a downside. Also, Geoff's remark about information disclosure still stands. If the consensus is that this mechanism only has to work for the root TA then this should be made more clear in the document. The document now talks a lot about "a key in a trust store" instead of the root key. It only becomes clear somewhere halfway the 2nd section that it only works for the root TA. Some other remarks regarding the draft-ietf-dnsop-kskroll-sentinel document: The three times SERVFAIL case in section 4 can be distinguished from a SERVFAIL for another reason by using a 4th query for a signed domain without special labels. If only that one succeeds you know for sure that a key roll will give issues, unlike in the indeterminate (Vleg) state. Is there a reason why this mechanism should only be applied for A and AAAA queries? "if the left-most label of the original query name matches the template "_is-ta-."" The trailing dot should not be part of the label. If this mechanism should only work for the root TA, what should a validator do when the queried for name is covered by a non-root TA? Not applying this mechanism, or applying it for the unused root TA? Some editorial nits: - trust anchor vs Trust Anchor, both used in document - section 2: aplied -> applied - section 3, Vleg: "RRSET" -> "RRset" - section 3, Vleg: "an A record" -> "an A or AAAA RRset" Regards, -- Ralph Dolmans From nobody Fri Dec 15 11:32:14 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128A3126E3A for ; Fri, 15 Dec 2017 11:32: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 cLPd6DUL20pM for ; Fri, 15 Dec 2017 11:32:10 -0800 (PST) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9770126DCA for ; Fri, 15 Dec 2017 11:32:10 -0800 (PST) Received: by chase.mycre.ws (Postfix, from userid 1000) id 953D712C1CFE; Fri, 15 Dec 2017 14:32:09 -0500 (EST) Date: Fri, 15 Dec 2017 14:32:09 -0500 From: Robert Edmonds To: =?utf-8?B?5bem6bmP?= Cc: dnsop , bert hubert Message-ID: <20171215193209.jmt55sltyodjricx@mycre.ws> References: <2017121315404971736813@cnnic.cn> <20171213081823.GA8970@laperouse.bortzmeyer.org> <20171213084342.GA30523@server.ds9a.nl> <201712131736325755287@cnnic.cn> <20171213095015.GC30523@server.ds9a.nl> <20171214214056.r37cz5rbmpxwjw3q@mycre.ws> <3519c0a3.328f.1605941fa4b.Coremail.zuopeng@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3519c0a3.328f.1605941fa4b.Coremail.zuopeng@cnnic.cn> Archived-At: Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 19:32:12 -0000 左鹏 wrote: > The "precise traffice scheduling" i mentioned is not only for performance reason, but also for capacity reason. CDNs already have the ability to do precise traffic scheduling for both performance and capacity reasons, using the existing capabilities built into the DNS. > yes, more resolvers are good to improve user experience. > but also maybe we should notice each CDN node has different capacity.(it is the real in practice). > a "weight-aware" rosolver can schedule clients to diffent nodes according to weight pricisely. > or shall we do something only for authoritative server like defining the weighted A/AAAAx? No, the DNS's existing capabilities provide more than enough power for CDNs for these use cases. > btw, any comments on the weightd CNAMEXs for multi-CDN? :) I don't have any direct experience of the multi-CDN use case. I would think the intra-CDN case for CDN node selection can be generalized to the multi-CDN case for CDN provider selection, though you probably have fewer owner names to work with. -- Robert Edmonds From nobody Fri Dec 15 11:34:25 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7E1128616 for ; Fri, 15 Dec 2017 11:34:22 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 ShT7c4Sw1gma for ; Fri, 15 Dec 2017 11:34:11 -0800 (PST) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 3DEF3129406 for ; Fri, 15 Dec 2017 11:34:10 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id x49so8915023wrb.13 for ; Fri, 15 Dec 2017 11:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=sXSbES3OXu/zo+Llan5vycjsUqhSY9OTEJTNRoyiJTo=; b=TcLIAdAjRDfH2RCfZJ/Xfeo1X1z47hWU95Kk/vqQPL6vs4Rf9Wr4amyD7+6X+ufoWz AgBGq2tvubJGFfZ4B6T5SnPjT0FqHMMfWpkIxg1TMoCGZd4s6RUcr88a3XYLtO+H6cej 2yKKknGO2/ZB39DNaDkgElIjhvbxvfnxpov+VAqxvrrvOVtdBrtDMDdwUs2b0VaWoo2I k38+XC/B41jyZwwSp7sswftfmL41txphVpFMWACDXdkbiD2pKAtuxWcH1wkugA1oPjF1 RRjzG1xMGyXdSvC5xOg6cscPnw02JPoesd3V72Nwf3Lq4hDG+NklEHHFhbNKdKQSBtN5 6n7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=sXSbES3OXu/zo+Llan5vycjsUqhSY9OTEJTNRoyiJTo=; b=mmJTFQxhdY4SmH8DhjCeMv8e2lE5T7lmLjyL/npf9cO9yWjGreRyWitSYead4W+/0t OWYQ0aLlSXlaulb+ugRSa3T4Z71pbmMuXDQHNgiOS7VFUuKcpLxP8Ss+8ahr77to5kTA Rbkt84yEfrNqjmm/mGwwW+sYzJ5JkWjdXz819Hdi3m9TuISzv+u9UNJjILAgO0l4TMyj IzCgGbAMOS6ybFTRDRXrtX/vcOprJ6dwd6JIgI+VXq7VfJFLSr63vRv0RR6NSmDO9MHK ND80RMDxXeIZxX7BOr54EjZNGDIND5rclCBnijorSuAbzWTCS9UMb+TGzK2pvOGsEavx PSkQ== X-Gm-Message-State: AKGB3mIK5aLPQBLRrBlW1j5tiIngVMWgTPbWszTZYMsYOy53oj58lYQR EJQnFAh3+qCLvBJfvotwxwQdh9oFoUOg6MWy5VldsQ== X-Google-Smtp-Source: ACJfBovMZAfZmFbvX0tJFul9arvlyn5sB8Tw2qocwYCEf8WZDNyCO8Gvu0456YDlT5hvQDCpAhw2dsgb2GNDnogMsNk= X-Received: by 10.223.201.139 with SMTP id f11mr8761940wrh.283.1513366448322; Fri, 15 Dec 2017 11:34:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.149 with HTTP; Fri, 15 Dec 2017 11:33:27 -0800 (PST) In-Reply-To: <20171215165008.GA11449@jurassic.lan.banu.com> References: <20171214173913.GA18100@jurassic.lan.banu.com> <20171214180058.GC4176@server.ds9a.nl> <20171215165008.GA11449@jurassic.lan.banu.com> From: Warren Kumari Date: Fri, 15 Dec 2017 14:33:27 -0500 Message-ID: To: Mukund Sivaraman Cc: bert hubert , dnsop Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] CLIENT-SUBNET bis appetite? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 19:34:22 -0000 On Fri, Dec 15, 2017 at 11:50 AM, Mukund Sivaraman wrote: > On Thu, Dec 14, 2017 at 07:00:58PM +0100, bert hubert wrote: >> On Thu, Dec 14, 2017 at 11:09:13PM +0530, Mukund Sivaraman wrote: >> > Any appetite for it? Don't throw things at me.. I ask because the >> > current thing is slowly getting more widely deployed and there are >> > design issues that can do with a ECS2 that breaks from ECS1 protocol. = I >> > ask because I'm once again having to deal with myriad implementation >> > cases and dislike it. >> >> Could you elaborate what you dislike most? > > It is too complicated to implement ECS correctly. There are a large > number of corner cases. The things that resolvers and authoritative > sides have to take care of are quite different. It is more complex > than anything else in DNS. > > I think this should be built again from scratch. > >> The biggest thing we are noticing is that while it does great things >> to getting to a server the content provider likes, it unavoidably >> drives doen cache hitrates a lot, introducing a latency penalty. >> >> The operators we see deploying ECS have tens of thousands of subnets >> which all need to be mapped to only a few servers. But you still end up >> with tens of thousands of cache entries and therefore tiny cache hitrate= s. >> >> Such things could be addressed by answering with lists of subnet masks t= o >> which this answer would also apply, but this makes little sense >> operationally I think. > > Firstly, correct deaggregation is an important requirement of reducing > cache usage. With the current design of ECS protocol, it's very > important that correct disjoining of prefixes be done optimally to avoid > cache pollution, yet the draft does not specify a suitable algorithm for > it (we know how to do it, I think the draft should have stated it). > > A /n address prefix as specified by ECS option is a perfect binary > tree of 1< data from a longer prefix such as 10.0.0.0/24, this will result in all > these answers to be generated: > > * 10.0.0.0/24 answer > * 10.0.0.0/23 exact match answer (scope > source) > * 10.0.1.0/23 answer > * 10.0.0.0/22 exact match answer (scope > source) > * 10.0.3.0/22 answer > > and so on.. there are about 2n+1 answers necessary so that a 0.0.0.0/0 > answer does not override a /n client from receiving its specific answer. > > x > x x > x x x x > x x x x x x y y > > If ECS option had more fields, we could have put the above pattern as > a difference of trees (with direction bit and height, e.g., "x"s in > the diagram above) and it would have reduced cache usage > considerably. > > This can be generalized with more differences but anyway I think that > using QUERY for ECS is a badly done idea (not even mentioning privacy > loss). > > As an example, RPZ does not rely on queries.. it transfers all prefixes > for matching in a zone so that the longest prefix match algorithm will > not suffer from a previously cached shorter prefix matching and > preventing future fetches. > > Another related problem is this: We often want to match against a GeoIP > database (containing what may be changing but maintained prefixes) in > associating zone data with geographic/network-topo clients. We want to > say "serve this answer for country X or city Y or ASNNNN" and we don't > care about managing the actual prefixes. > > GeoIP is a custom database format, where I can match against GeoIP, but > I can't easily deaggregate all its prefixes for an ECS zone to be cached > properly. > > I feel it would have been better to say to a downstream resolver "This > answer is for country X", or "A is the answer for country X, B is the > answer for country Y, the rest use answer C". Please see the thread https://www.ietf.org/mail-archive/web/dnsop/current/msg19614.html There is no *best* answer for a country, nor a city or even a postal addres= s. There is instead a best answer for a specific IP address / subnet, which depends upon the ISP, the peering connections with that ISP, the utilization of the peering links with that ISP, the utilization of the datacenter, and then much lower down, where in the physical topology that subnet resides. I'm within spitting distance of Ashburn Equinix (well, I cannot quite spit there, but I could easily walk there, it's < 5 miles), but my ISP is Comcast. This means that, instead of hitting anything in IAD (Ashburn), I (currently) instead get sent to MRN (Lenoir, North Carolina), which is 400 miles away. My packets also happen to go through 111 8th Ave, NY - even though there is stuff in NY, the MRN location is better / faster. If I happened to have chosen a different ISP, Verizon for instance, my optimal answers would be very different. And no, the "obvious" answer of "just use the AS number then" fails equally badly - my latency to 8.8.8.8 (to chose something at random) is ~12ms. If I ware a Comcast customer in California and the same location were handed out, the latency would be ~80ms. Note that I'm in a place which is well connected - in many places, the "less optimal" answer is much much less optimal... > > The design of ECS needs to be reconsidered. I'd prefer something like a > zone format for it, than using QUERY. QUERY cannot give complete > information about all prefixes and there is a possibility of incorrect > caching, and a very high probability of redundant cache pollution. Sure, happy to reconsider the design, but it is important to know more about what the constraints are, and how specific and dynamic the answers are. For exmaple, Akamai says they are in 1,600 networks (https://www.akamai.com/uk/en/about/facts-figures.jsp), "The Cloudflare Global Anycast Network" (https://www.cloudflare.com/network/) is is powered by 118 data centers around the world. " Google Cloud Platform has added new regions in S=C3=A3o Paulo and Mumbai. GCP has 13 regions, 39 zones, over 100 points of presence, and a well-provisioned global network with 100,000s of miles of fiber optic cable." (embarrassingly I couldn't easily find a public page with more detail) Dyn has a map here: https://dyn.com/dns/network-map/ > > >From a resolver's point of view, a non-ECS answer (no client-subnet > option) is different from an ECS answer with scope=3D0 which is different > from an ECS answer with source=3D0, whereas all these may be the same fro= m > an authority's point of view. They all need to be cached differently > (from an intermediate resolver's view). > > This thing of scope > source meaning for-exact-match-only is weird as > hell when implementing longest prefix matching. It is not convenient > to use an off-the-shelf radix tree. > > ECS relies on the option always being returned for any kind of > answers, as some resolvers use that as an indicator of ECS support > (and stop using ECS if it ever stops). But ECS does not apply to > several kinds of answers (e.g., anything but NOERROR, esp. NXDOMAIN > and NODATA have to be consistent across all prefixes.) It doesn't > apply to SOA, DNSKEY, NS in answer section, referrals, etc. Yet, > many of these need to answer with SCOPE=3D0. > > An ACL config option about whether the NS supports ECS or not (to > return the option or not) is different from a config option whether > the NS passes through ECS or not: the latter would always pass through > SOURCE=3D0 but return REFUSED for any ECS queries that didn't match the > ACL; where as the former would return non-ECS reply for any ECS > queries that didn't match the ACL). > > Transitivity of the option has corner cases. > > I don't have to point out how easy it is for a erroneous /16 to > prevent queries to /24 answers shadowed by the /16. > > Some cache cases: Obviously an ECS cache is different from a > zone.. it's not from a single zone, it is not an atomic collection of > a single version of zone and ever changing. If there's a /24 answer in > cache, and a newer query brings in a /16 answer that shadows it, > should the resolver assume that the /16 has precedence because it's > newer (hence the /24 should no longer exist) or do a > longest-prefix-match against the older /24? What if the /16 then > expires and the /24 hasn't expired? An NXDOMAIN answer should expire > any previously cached prefix-specific cache entries for that name. A > NODATA answer should expire any previously cached prefix-specific > cache entries for that type. Non-ECS data is different from SCOPE=3D0 > data. There are questions about trust ranking with usage of ECS data. > > These are just some topics that I can quickly think of. There are many > other issues we faced and discussed during resolver ECS development. > > The draft leaves many things unspecified, such as more clarity in DNSSEC > and handling of negative answers. Many issues were fixed during the > draft phase, but I feel it was insufficient. > >> Can you share your ideas for ECS2? > > There are many quirks in ECS. I don't want to propose specific ideas > now, except that we should gather requirements and start from > scratch. Yes, much of my soapbox rant was about just this -- understanding the requirements is important - the reason that CDNs provide different answers based upon the IP address it is a proxy for latency / performance. I'm sure we got many things wrong in ECS, but a redesign needs to be informed by the use case and requirements. (This mail not meant to sound as grumpy as it turned out :-) ) W > We have to reduce complexity of the protocol on both auth and > caching resolver sides. I think it should be designed again from > requirements without being a tweak of ECS1. The current protocol > complicates DNS implementation significantly. > > Mukund > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Dec 15 15:56:00 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B8F1241FC for ; Fri, 15 Dec 2017 15:55:58 -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 Wngqux4FzGKD for ; Fri, 15 Dec 2017 15:55:56 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B66CF1201FA for ; Fri, 15 Dec 2017 15:55:56 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 5602F2233F; Fri, 15 Dec 2017 15:55:56 -0800 (PST) From: Wes Hardaker To: Michael StJohns Cc: Wes Hardaker , dnsop@ietf.org References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> <142cad85-1e0e-b4c9-1561-ad590984739a@nthpermutation.com> <1ca3daed-d521-0fcd-d1e7-eef2b781707b@nthpermutation.com> <26d61092-942a-16bc-e939-ed9400a17a29@nthpermutation.com> <19e3ce86-c797-0e88-e192-e82b936be579@nthpermutation.com> Date: Fri, 15 Dec 2017 15:55:56 -0800 In-Reply-To: <19e3ce86-c797-0e88-e192-e82b936be579@nthpermutation.com> (Michael StJohns's message of "Thu, 14 Dec 2017 22:26:13 -0500") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Dec 2017 23:55:58 -0000 Michael StJohns writes: > Below is a java program I wrote to model this stuff.=C2=A0 In the table, > SF2 represents the number of clients that blew past twice the safety > factor (for aR+aHD+aR), SF1 represents the number of clients that blew > past the single safety factor.=C2=A0 OF is the number of clients using the > activeRefreshOffset calculation that finished after the calculated > interval (e.g. aR+aHD+aRO).=C2=A0 OF+s is the number of clients that > finished after the activeRefreshOffset + safetyFactor (in the first > table these are the same because of perfect responses).=C2=A0=C2=A0 In the > second table, compare SF1 to OF+s - SF1 < OF+s suggesting that > activeRefresh is a better choice that activeRefreshQuery for the third > term of the equation.=C2=A0 You can try a lot of different combinations, > but I haven't found any case where OF+s performs better that SF1. > > The difference between lastStart and lAddHoldBegin represents the > retransmits after the first query.=C2=A0 The differences between > lAddHoldEnd and lFinalQuery represent retransmits after the last > normal query before the end of the add hold down time until a valid > answer was received after the addHoldDown time expired. > > Feel free to twiddle with this. Work bogged me down to able to write anything back so far. Thanks for the java code; I'll respond with the java*script* code I've been hacking up at the same time: https://www.isi.edu/~hardaker/projects/5011/ I didn't add the re-transmit time issue that your code takes into account, but I did add a query drift that nicely shows one of your concerns. In particular, with various values of query drift (including -1) you can reproduce the real world situation that you're worried about, which is (as I've mentioned) an important one to call out. --=20 Wes Hardaker USC/ISI From nobody Fri Dec 15 16:37:49 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF3B124D85 for ; Fri, 15 Dec 2017 16:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 qavT__WPsy83 for ; Fri, 15 Dec 2017 16:37:46 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3014A120725 for ; Fri, 15 Dec 2017 16:37:46 -0800 (PST) Received: from [46.227.151.81] (port=59736 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1eQ0U0-0002zR-2y (Exim 4.72) for dnsop@ietf.org (return-path ); Sat, 16 Dec 2017 00:37:40 +0000 To: dnsop From: Ray Bellis Message-ID: <97c3f729-721e-61ab-b5d7-d5208288acec@bellis.me.uk> Date: Sat, 16 Dec 2017 00:37:44 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] Call For Presentations - DNS-OARC Workshop 28, San Juan, Puerto Rico, 8th/9th March 2018 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 00:37:48 -0000 [with apologies to those who see this on multiple lists] Call For Presentations The 28th DNS-OARC Workshop will be hosted by ICANN in San Juan, Puerto Rico, and will take place on March 8th and 9th immediately before ICANN61 (March 10th - 15th) [*] The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. The first day of the workshop will start with a Members-only session which will include reports on DNS-OARC's activities. If you are an OARC member and have a sensitive topic that you wish to present during that session those can be accommodated. A timeslot will also be available for lightning talks (5-10 minutes) on day two of the workshop for which submissions will be accepted on the first day of the workshop, until 4pm. Workshop Milestones: 19 Jan 2018 - Deadline for submission 23 Jan 2018 - Initial contribution list published 16 Feb 2018 - Full agenda published 02 Mar 2018 - Deadline for slideset submission Details for presentation submission are published here: The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via Ray Bellis, for the OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) [*] From nobody Sat Dec 16 03:12:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E04124B18 for ; Sat, 16 Dec 2017 03:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 H9R5z3LXus2h for ; Sat, 16 Dec 2017 03:12:09 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 0374D1200FC for ; Sat, 16 Dec 2017 03:12:09 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id f206so21677304wmf.5 for ; Sat, 16 Dec 2017 03:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RbmkJC9CMKKjlkp8jfvVeqO4viDCdmq7ohfk/jAgsF0=; b=tPnCnN/MNEeDlabBFyk2EnY3UaIXAC0kB5tHZYJakjmsnyXFwwh/sj75pgUHMtmuFu 4eF5gVx1BkoPikIaTRGBPYgR9jJoAW7iQNUnRwFBN2aAwr3eu/EPCRfKjfHp+fv65A/C Np9ZvedSzq4RMNsT2l3fgAvsHbLkBEl9vzWiSLhKFZjhebBVrL0PmaC6gskB/oT3Pj1T l8SDJY7apv7TNCldGl8mRCTWDHFai1jiPn5BdUbbAR6VgxaApMi44D33xtOoaoVzKXbZ HnY+DACY/dUTcf810fYznOlzfysn0cFOAVt5OViphaP3E7H1CZZ0RNz1sw/YkvNEp2nw Iz1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RbmkJC9CMKKjlkp8jfvVeqO4viDCdmq7ohfk/jAgsF0=; b=PtuQy9AyxbptFlumUu4f69CKogKhX/boKmwiXkgDbE9OvzuPRnFo2xNkDfn92FK9Dj rIQ5q/Rump+mIvtYOjY0rDAt8LPaIcVagfz76IxGXshTCet9CRkuwUy+XoBtVqOZlzsZ QuBmP7Ibm3ApGFmLP9JOJAc0s54RFzOmH0hJmO/1SK90tbPcOw3t8ELk8LNwFRg2HP3X N7nLeqzTYaRIbgz6H/EIkzPJC108ABF5ey++OgOT1OQVsF6AFUUolRButnMp6G9L8yXx pr7VgW18TLqqRZZiDJJN8dm3G7fhMpS0Je1T0a5TPvnn8+aq7CIYe+boUDlmvu9n6kMb oo8A== X-Gm-Message-State: AKGB3mKxLkIQLaThMF1lMyv+9xK3gWeK4tjCGwF1CysP3NOcbx/aOoKZ 2gL7baCwrpVMsuCXt2d1jiv2r38VXAXru8U/Fk4= X-Google-Smtp-Source: ACJfBouEYC1rSbDEjbTkGzzwEsYMCDkR2rby1yK6gjaZ0BuVQ0StxjcKmvjo+q5hKJcLDnNA+nrKjusRkuQpz63SPrY= X-Received: by 10.80.148.124 with SMTP id q57mr21611636eda.300.1513422727460; Sat, 16 Dec 2017 03:12:07 -0800 (PST) MIME-Version: 1.0 References: <20171214173913.GA18100@jurassic.lan.banu.com> <20171214180058.GC4176@server.ds9a.nl> <20171215165008.GA11449@jurassic.lan.banu.com> In-Reply-To: From: Lanlan Pan Date: Sat, 16 Dec 2017 11:11:56 +0000 Message-ID: To: Warren Kumari Cc: Mukund Sivaraman , dnsop , bert hubert Content-Type: multipart/alternative; boundary="f403045c202410bf6605607330da" Archived-At: Subject: Re: [DNSOP] CLIENT-SUBNET bis appetite? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 11:12:13 -0000 --f403045c202410bf6605607330da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Warren, Thank you for the mention, :-) We all know that, because of network topology, client subnet is the *best* indicator for CDN traffic management, expecially for Akamai, Google, ... Totally agree with you: There is no *best* answer for a country, nor a city or even a postal address. My thought is : For GeoIP-enabled Authoritative Servers, they offen map Client Subnet into EIL , then return tailored response only based on . There is *sufficient* answer for , on a GeoIP-enabled Authoritative Server=E2=80=98s *own view*. EIL can be a trade-off choice for GeoIP-enabled Authoritative Server, and optimize Recursive Resolver's cache cost. Latest EIL document is at: https://github.com/abbypan/dns_test_eil/blob/master/ietf_draft/draft.txt There are many compatibility, cost vs benefit, operational concerns on EIL from WG experts now, I am *still revising* it, welcome discussions and issues. Example: xxx.com's Authoritative Server deploy GeoDNS proactively. =3D> xxx.com's Authoritative Server itself choose accept ** level traffic management. =3D> for some operation problem/privacy concerns (maybe like Mukund mention= ed above), we can use EIL to mitigrate. ECS: I am network topology close to <111.201.133.0/24>, which is the best answer on network topology now ? GeoIP-enabled Authoritative Servers map <111.201.133.0/24> into , then find the tailored answer. Recursive Resolver cache the response with <111.201.133.0/24>, or some shorter prefix. EIL: I am network topology close to , which is the best answer on network topology now ? Recursive Resolver cache the response with , which can cover many *network topology closed* client subnets. Warren Kumari =E4=BA=8E2017=E5=B9=B412=E6=9C=8816=E6=97= =A5=E5=91=A8=E5=85=AD =E4=B8=8A=E5=8D=883:34=E5=86=99=E9=81=93=EF=BC=9A > On Fri, Dec 15, 2017 at 11:50 AM, Mukund Sivaraman wrote: > > On Thu, Dec 14, 2017 at 07:00:58PM +0100, bert hubert wrote: > >> On Thu, Dec 14, 2017 at 11:09:13PM +0530, Mukund Sivaraman wrote: > >> > Any appetite for it? Don't throw things at me.. I ask because the > >> > current thing is slowly getting more widely deployed and there are > >> > design issues that can do with a ECS2 that breaks from ECS1 protocol= . > I > >> > ask because I'm once again having to deal with myriad implementation > >> > cases and dislike it. > >> > >> Could you elaborate what you dislike most? > > > > It is too complicated to implement ECS correctly. There are a large > > number of corner cases. The things that resolvers and authoritative > > sides have to take care of are quite different. It is more complex > > than anything else in DNS. > > > > I think this should be built again from scratch. > > > >> The biggest thing we are noticing is that while it does great things > >> to getting to a server the content provider likes, it unavoidably > >> drives doen cache hitrates a lot, introducing a latency penalty. > >> > >> The operators we see deploying ECS have tens of thousands of subnets > >> which all need to be mapped to only a few servers. But you still end u= p > >> with tens of thousands of cache entries and therefore tiny cache > hitrates. > >> > >> Such things could be addressed by answering with lists of subnet masks > to > >> which this answer would also apply, but this makes little sense > >> operationally I think. > > > > Firstly, correct deaggregation is an important requirement of reducing > > cache usage. With the current design of ECS protocol, it's very > > important that correct disjoining of prefixes be done optimally to avoi= d > > cache pollution, yet the draft does not specify a suitable algorithm fo= r > > it (we know how to do it, I think the draft should have stated it). > > > > A /n address prefix as specified by ECS option is a perfect binary > > tree of 1< > data from a longer prefix such as 10.0.0.0/24, this will result in all > > these answers to be generated: > > > > * 10.0.0.0/24 answer > > * 10.0.0.0/23 exact match answer (scope > source) > > * 10.0.1.0/23 answer > > * 10.0.0.0/22 exact match answer (scope > source) > > * 10.0.3.0/22 answer > > > > and so on.. there are about 2n+1 answers necessary so that a 0.0.0.0/0 > > answer does not override a /n client from receiving its specific answer= . > > > > x > > x x > > x x x x > > x x x x x x y y > > > > If ECS option had more fields, we could have put the above pattern as > > a difference of trees (with direction bit and height, e.g., "x"s in > > the diagram above) and it would have reduced cache usage > > considerably. > > > > This can be generalized with more differences but anyway I think that > > using QUERY for ECS is a badly done idea (not even mentioning privacy > > loss). > > > > As an example, RPZ does not rely on queries.. it transfers all prefixes > > for matching in a zone so that the longest prefix match algorithm will > > not suffer from a previously cached shorter prefix matching and > > preventing future fetches. > > > > Another related problem is this: We often want to match against a GeoIP > > database (containing what may be changing but maintained prefixes) in > > associating zone data with geographic/network-topo clients. We want to > > say "serve this answer for country X or city Y or ASNNNN" and we don't > > care about managing the actual prefixes. > > > > GeoIP is a custom database format, where I can match against GeoIP, but > > I can't easily deaggregate all its prefixes for an ECS zone to be cache= d > > properly. > > > > I feel it would have been better to say to a downstream resolver "This > > answer is for country X", or "A is the answer for country X, B is the > > answer for country Y, the rest use answer C". > > optimized answers> > Please see the thread > https://www.ietf.org/mail-archive/web/dnsop/current/msg19614.html > > There is no *best* answer for a country, nor a city or even a postal > address. > > There is instead a best answer for a specific IP address / subnet, > which depends upon the ISP, the peering connections with that ISP, the > utilization of the peering links with that ISP, the utilization of the > datacenter, and then much lower down, where in the physical topology > that subnet resides. > > I'm within spitting distance of Ashburn Equinix (well, I cannot quite > spit there, but I could easily walk there, it's < 5 miles), but my ISP > is Comcast. This > m= eans > that, instead of hitting anything in IAD > (Ashburn), I (currently) instead get sent to MRN (Lenoir, North > Carolina), which is 400 miles away. My packets also happen to go > through 111 8th Ave, NY - even though there is stuff in NY, the MRN > location is better / faster. > > If I happened to have chosen a different ISP, Verizon for instance, my > optimal answers would be very different. > And no, the "obvious" answer of "just use the AS number then" fails > equally badly - my latency to 8.8.8.8 (to chose something at random) > is ~12ms. If I ware a Comcast customer in California and the same > location were handed out, the latency would be ~80ms. > > Note that I'm in a place which is well connected - in many places, the > "less optimal" answer is much much less optimal... > > > > > > The design of ECS needs to be reconsidered. I'd prefer something like a > > zone format for it, than using QUERY. QUERY cannot give complete > > information about all prefixes and there is a possibility of incorrect > > caching, and a very high probability of redundant cache pollution. > > Sure, happy to reconsider the design, but it is important to know more > about what the constraints are, and how specific and dynamic the > answers are. > > For exmaple, Akamai says they are in 1,600 networks > (https://www.akamai.com/uk/en/about/facts-figures.jsp), "The > Cloudflare Global Anycast Network" > (https://www.cloudflare.com/network/) is is powered by 118 data > centers around the world. " > > Google Cloud Platform has added new regions in S=C3=A3o Paulo and Mumbai. > GCP has 13 regions, 39 zones, over 100 points of presence, and a > well-provisioned global network with 100,000s of miles of fiber optic > cable." (embarrassingly I couldn't easily find a public page with more > detail) > > Dyn has a map here: https://dyn.com/dns/network-map/ > > > > > > > >From a resolver's point of view, a non-ECS answer (no client-subnet > > option) is different from an ECS answer with scope=3D0 which is differe= nt > > from an ECS answer with source=3D0, whereas all these may be the same f= rom > > an authority's point of view. They all need to be cached differently > > (from an intermediate resolver's view). > > > > This thing of scope > source meaning for-exact-match-only is weird as > > hell when implementing longest prefix matching. It is not convenient > > to use an off-the-shelf radix tree. > > > > ECS relies on the option always being returned for any kind of > > answers, as some resolvers use that as an indicator of ECS support > > (and stop using ECS if it ever stops). But ECS does not apply to > > several kinds of answers (e.g., anything but NOERROR, esp. NXDOMAIN > > and NODATA have to be consistent across all prefixes.) It doesn't > > apply to SOA, DNSKEY, NS in answer section, referrals, etc. Yet, > > many of these need to answer with SCOPE=3D0. > > > > An ACL config option about whether the NS supports ECS or not (to > > return the option or not) is different from a config option whether > > the NS passes through ECS or not: the latter would always pass through > > SOURCE=3D0 but return REFUSED for any ECS queries that didn't match the > > ACL; where as the former would return non-ECS reply for any ECS > > queries that didn't match the ACL). > > > > Transitivity of the option has corner cases. > > > > I don't have to point out how easy it is for a erroneous /16 to > > prevent queries to /24 answers shadowed by the /16. > > > > Some cache cases: Obviously an ECS cache is different from a > > zone.. it's not from a single zone, it is not an atomic collection of > > a single version of zone and ever changing. If there's a /24 answer in > > cache, and a newer query brings in a /16 answer that shadows it, > > should the resolver assume that the /16 has precedence because it's > > newer (hence the /24 should no longer exist) or do a > > longest-prefix-match against the older /24? What if the /16 then > > expires and the /24 hasn't expired? An NXDOMAIN answer should expire > > any previously cached prefix-specific cache entries for that name. A > > NODATA answer should expire any previously cached prefix-specific > > cache entries for that type. Non-ECS data is different from SCOPE=3D0 > > data. There are questions about trust ranking with usage of ECS data. > > > > These are just some topics that I can quickly think of. There are many > > other issues we faced and discussed during resolver ECS development. > > > > The draft leaves many things unspecified, such as more clarity in DNSSE= C > > and handling of negative answers. Many issues were fixed during the > > draft phase, but I feel it was insufficient. > > > >> Can you share your ideas for ECS2? > > > > There are many quirks in ECS. I don't want to propose specific ideas > > now, except that we should gather requirements and start from > > scratch. > > Yes, much of my soapbox rant was about just this -- understanding the > requirements is important - the reason that CDNs provide different > answers based upon the IP address it is a proxy for latency / > performance. > I'm sure we got many things wrong in ECS, but a redesign needs to be > informed by the use case and requirements. > > (This mail not meant to sound as grumpy as it turned out :-) ) > > W > > > We have to reduce complexity of the protocol on both auth and > > caching resolver sides. I think it should be designed again from > > requirements without being a tweak of ECS1. The current protocol > > complicates DNS implementation significantly. > > > > Mukund > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045c202410bf6605607330da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Warren,

Thank you fo= r the mention, :-)

We all know that, because of network t= opology, client subnet is the *best* indicator for CDN traffic management, = expecially for Akamai, Google, ...
Totally agree with = you:=C2=A0 There is no *best* answer for a country, nor a city or even a po= stal address.

My thought is :=C2=A0
For GeoIP-enabled Authoritative Servers, they offen map Client Subnet into= EIL <COUNTRY, AREA, ISP>, then return tailored response only based o= n <COUNTRY, AREA, ISP>.
There is *sufficient* answer for &l= t;COUNTRY, AREA, ISP>, on a GeoIP-enabled Authoritative Server=E2=80=98s= *own view*.
EIL can be a trade-off choice for GeoIP-enabled= Authoritative Server, and optimize Recursive Resolver's cache cost.

There are many compatibility, cost vs benefit, = operational concerns on EIL from WG experts now, I am *still revising* it, = welcome discussions and issues.

<= div>
Example:
xxx.com'= s Authoritative Server deploy GeoDNS proactively.
=3D> xxx.com's = Authoritative Server itself choose accept *<COUNTRY, AREA, ISP>* leve= l traffic management.
=3D> for some operation probl= em/privacy concerns (maybe like Mukund mentioned above),=C2=A0 we can use E= IL to mitigrate.

ECS: I am networ= k topology close to <111.201.133.0/2= 4>, which is the best answer on network topology now ?
Geo= IP-enabled Authoritative Servers map <111.201.133.0/24> into <China, Beijing, Unicom ISP>, then fi= nd the tailored answer.
Recursive Resolver cache the response wit= h <111.201.133.0/24>, or some= shorter prefix.

EIL: I am network topology close= to <China, Beijing, Unicom ISP>, which is the best answer on network= topology now ?
Recursive Resolver cache the response with &l= t;China, Beijing, Unicom ISP>, which can cover many *network topology cl= osed* client subnets.

Warren Kumari <warren@kumari.net>=E4=BA=8E2= 017=E5=B9=B412=E6=9C=8816=E6=97=A5=E5=91=A8=E5=85=AD =E4=B8=8A=E5=8D=883:34= =E5=86=99=E9=81=93=EF=BC=9A
On Fri, Dec 15,= 2017 at 11:50 AM, Mukund Sivaraman <muks@isc.org> wrote:
> On Thu, Dec 14, 2017 at 07:00:58PM +0100, bert hubert wrote:
>> On Thu, Dec 14, 2017 at 11:09:13PM +0530, Mukund Sivaraman wrote:<= br> >> > Any appetite for it? Don't throw things at me.. I ask bec= ause the
>> > current thing is slowly getting more widely deployed and ther= e are
>> > design issues that can do with a ECS2 that breaks from ECS1 p= rotocol. I
>> > ask because I'm once again having to deal with myriad imp= lementation
>> > cases and dislike it.
>>
>> Could you elaborate what you dislike most?
>
> It is too complicated to implement ECS correctly. There are a large > number of corner cases. The things that resolvers and authoritative > sides have to take care of are quite different. It is more complex
> than anything else in DNS.
>
> I think this should be built again from scratch.
>
>> The biggest thing we are noticing is that while it does great thin= gs
>> to getting to a server the content provider likes, it unavoidably<= br> >> drives doen cache hitrates a lot, introducing a latency penalty. >>
>> The operators we see deploying ECS have tens of thousands of subne= ts
>> which all need to be mapped to only a few servers. But you still e= nd up
>> with tens of thousands of cache entries and therefore tiny cache h= itrates.
>>
>> Such things could be addressed by answering with lists of subnet m= asks to
>> which this answer would also apply, but this makes little sense >> operationally I think.
>
> Firstly, correct deaggregation is an important requirement of reducing=
> cache usage. With the current design of ECS protocol, it's very > important that correct disjoining of prefixes be done optimally to avo= id
> cache pollution, yet the draft does not specify a suitable algorithm f= or
> it (we know how to do it, I think the draft should have stated it). >
> A /n address prefix as specified by ECS option is a perfect binary
> tree of 1<<n addresses. To correctly deaggregate 0.0.0.0/0 (scope=3D0= )
> data from a longer prefix such as 10.0.0.0/24, this will result in all<= br> > these answers to be generated:
>
> * = 10.0.0.0/24 answer
> * = 10.0.0.0/23 exact match answer (scope > source)
> * = 10.0.1.0/23 answer
> * = 10.0.0.0/22 exact match answer (scope > source)
> * = 10.0.3.0/22 answer
>
> and so on.. there are about 2n+1 answers necessary so that a 0.0.0.0/0 > answer does not override a /n client from receiving its specific answe= r.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0x<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 x=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 x
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 x=C2=A0 =C2=A0x=C2=A0 =C2=A0 =C2=A0 = =C2=A0 x=C2=A0 =C2=A0x
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0x x x x=C2=A0 =C2=A0 =C2=A0 x x y y >
> If ECS option had more fields, we could have put the above pattern as<= br> > a difference of trees (with direction bit and height, e.g., "x&qu= ot;s in
> the diagram above) and it would have reduced cache usage
> considerably.
>
> This can be generalized with more differences but anyway I think that<= br> > using QUERY for ECS is a badly done idea (not even mentioning privacy<= br> > loss).
>
> As an example, RPZ does not rely on queries.. it transfers all prefixe= s
> for matching in a zone so that the longest prefix match algorithm will=
> not suffer from a previously cached shorter prefix matching and
> preventing future fetches.
>
> Another related problem is this: We often want to match against a GeoI= P
> database (containing what may be changing but maintained prefixes) in<= br> > associating zone data with geographic/network-topo clients. We want to=
> say "serve this answer for country X or city Y or ASNNNN" an= d we don't
> care about managing the actual prefixes.
>
> GeoIP is a custom database format, where I can match against GeoIP, bu= t
> I can't easily deaggregate all its prefixes for an ECS zone to be = cached
> properly.
>
> I feel it would have been better to say to a downstream resolver "= ;This
> answer is for country X", or "A is the answer for country X,= B is the
> answer for country Y, the rest use answer C".

<No hats. other than working at a place that uses ECS to provide
optimized answers>
Please see the thread
https://www.ietf.org/mail-archive/w= eb/dnsop/current/msg19614.html

There is no *best* answer for a country, nor a city or even a postal addres= s.

There is instead a best answer for a specific IP address / subnet,
which depends upon the ISP, the peering connections with that ISP, the
utilization of the peering links with that ISP, the utilization of the
datacenter, and then much lower down, where in the physical topology
that subnet resides.

I'm within spitting distance of Ashburn Equinix (well, I cannot quite spit there, but I could easily walk there, it's < 5 miles), but my I= SP
is Comcast. This means that, instead o= f hitting anything in IAD
(Ashburn), I (currently) instead get sent to MRN (Lenoir, North
Carolina), which is 400 miles away. My packets also happen to go
through 111 8th Ave, NY - even though there is stuff in NY, the MRN
location is better / faster.

If I happened to have chosen a different ISP, Verizon for instance, my
optimal answers would be very different.
And no, the "obvious" answer of "just use the AS number then= " fails
equally badly - my latency to 8.8.8.8 (to chose something at random)
is ~12ms. If I ware a Comcast customer in California and the same
location were handed out, the latency would be ~80ms.

Note that I'm in a place which is well connected - in many places, the<= br> "less optimal" answer is much much less optimal...


>
> The design of ECS needs to be reconsidered. I'd prefer something l= ike a
> zone format for it, than using QUERY. QUERY cannot give complete
> information about all prefixes and there is a possibility of incorrect=
> caching, and a very high probability of redundant cache pollution.

Sure, happy to reconsider the design, but it is important to know more
about what the constraints are, and how specific and dynamic the
answers are.

For exmaple, Akamai says they are in 1,600 networks
(https://www.akamai.com/uk/en/about/facts-figure= s.jsp),=C2=A0 "The
Cloudflare Global Anycast Network"
(https://www.cloudflare.com/network/) is is powered by 118 d= ata
centers around the world. "

Google Cloud Platform has added new regions in S=C3=A3o Paulo and Mumbai. GCP has 13 regions, 39 zones, over 100 points of presence, and a
well-provisioned global network with 100,000s of miles of fiber optic
cable." (embarrassingly I couldn't easily find a public page with = more
detail)

Dyn has a map here: https://dyn.com/dns/network-map/



>
> >From a resolver's point of view, a non-ECS answer (no client-s= ubnet
> option) is different from an ECS answer with scope=3D0 which is differ= ent
> from an ECS answer with source=3D0, whereas all these may be the same = from
> an authority's point of view. They all need to be cached different= ly
> (from an intermediate resolver's view).
>
> This thing of scope > source meaning for-exact-match-only is weird = as
> hell when implementing longest prefix matching. It is not convenient > to use an off-the-shelf radix tree.
>
> ECS relies on the option always being returned for any kind of
> answers, as some resolvers use that as an indicator of ECS support
> (and stop using ECS if it ever stops). But ECS does not apply to
> several kinds of answers (e.g., anything but NOERROR, esp. NXDOMAIN > and NODATA have to be consistent across all prefixes.) It doesn't<= br> > apply to SOA, DNSKEY, NS in answer section, referrals, etc. Yet,
> many of these need to answer with SCOPE=3D0.
>
> An ACL config option about whether the NS supports ECS or not (to
> return the option or not) is different from a config option whether > the NS passes through ECS or not: the latter would always pass through=
> SOURCE=3D0 but return REFUSED for any ECS queries that didn't matc= h the
> ACL; where as the former would return non-ECS reply for any ECS
> queries that didn't match the ACL).
>
> Transitivity of the option has corner cases.
>
> I don't have to point out how easy it is for a erroneous /16 to > prevent queries to /24 answers shadowed by the /16.
>
> Some cache cases: Obviously an ECS cache is different from a
> zone.. it's not from a single zone, it is not an atomic collection= of
> a single version of zone and ever changing. If there's a /24 answe= r in
> cache, and a newer query brings in a /16 answer that shadows it,
> should the resolver assume that the /16 has precedence because it'= s
> newer (hence the /24 should no longer exist) or do a
> longest-prefix-match against the older /24? What if the /16 then
> expires and the /24 hasn't expired? An NXDOMAIN answer should expi= re
> any previously cached prefix-specific cache entries for that name. A > NODATA answer should expire any previously cached prefix-specific
> cache entries for that type.=C2=A0 Non-ECS data is different from SCOP= E=3D0
> data. There are questions about trust ranking with usage of ECS data.<= br> >
> These are just some topics that I can quickly think of. There are many=
> other issues we faced and discussed during resolver ECS development. >
> The draft leaves many things unspecified, such as more clarity in DNSS= EC
> and handling of negative answers. Many issues were fixed during the > draft phase, but I feel it was insufficient.
>
>> Can you share your ideas for ECS2?
>
> There are many quirks in ECS. I don't want to propose specific ide= as
> now, except that we should gather requirements and start from
> scratch.

Yes, much of my soapbox rant was about just this -- understanding the
requirements is important - the reason that CDNs provide different
answers based upon the IP address it is a proxy for latency /
performance.
I'm sure we got many things wrong in ECS, but a redesign needs to be informed by the use case and requirements.

(This mail not meant to sound as grumpy as it turned out :-) )

W

> We have to reduce complexity of the protocol on both auth and
> caching resolver sides. I think it should be designed again from
> requirements without being a tweak of ECS1. The current protocol
> complicates DNS implementation significantly.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mukund >
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org=
> https://www.ietf.org/mailman/listinfo/dnsop



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=C2=A0 =C2=A0---maf

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
=E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85= =B0=C2=A0 Pan Lanlan
--f403045c202410bf6605607330da-- From nobody Sat Dec 16 10:41:55 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E02126D46 for ; Sat, 16 Dec 2017 10:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 p4qetcsWPP8F for ; Sat, 16 Dec 2017 10:41:51 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 35A5D126D0C for ; Sat, 16 Dec 2017 10:41:51 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id b184so14097097qkc.13 for ; Sat, 16 Dec 2017 10:41:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=gzhsRzFpHQ4c4uP0wO2PH3x5ITUO2XC5E9BhZf4lSf8=; b=ig40saQAWYaTplnN+6Fvdh3mqoOR2JgYhts8Oh/UZm6dvc2rOsbBG5TqXG9CvS19jl JHsVnPGBzgNjOoLSO7Qr8T7SRgjLFWTmnU8L+4r5qMScX6awQapL9LJzVTYEa4y+wFzY 48xQhuo+c9Lz3JESh4x2nKNTHrxhAOYzoMy5T4GK6KQMrZNfblMLXQ5UeBkWM2RulUjq c/+IggNzRdUCMIP/PNEWqpSXwWvWGnoNtBQluk5Ryf8Vw39TwGFd/XV85NdUteSyL4gK y/6YZDBq+N69bj+dxSdbahHeF/9u9y1N+Y5GfAy1dCxVd1gLIyJCGCJlWAkJUgHjFUXF W/vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=gzhsRzFpHQ4c4uP0wO2PH3x5ITUO2XC5E9BhZf4lSf8=; b=syZ5fCBetznoSdjhMTbGKBlJlxzH7DFWQQHxfWStuzRYcy/jOBx/N1t2x3WvsaMOiz CpBWFQxUuLFYnGiJYG5bH4nVVaH2fQ06fuLs5GOjxEeMjZjY9lQKxr2gt542ytJp50gx D5bgLmy80RPiRQHpWhR6itMaOexrcGEGgfrJI5gY0cuWLLjC9EmL8pp3vwhOBOR6sRYX XryZkmi0IdAuDCEUFc/PseVfhN/RJN2vn8CrVsTxBzPqs6OdBygPVx7vNIY6dxXtmQLi tlR77DG2EDBMNug2/9Jb9g8XQPaQPZSixw3gnVrMpvZ0EHajA0FZXDs+URdyfN79r0sw B0TQ== X-Gm-Message-State: AKGB3mKU1FFMxuD/GcFqwGRb2HAyHHEF329cgsRx59kWeMbqKmwnb0VV 4DJJ6zk+5KLLYT2CpYYrJk5o+O3X X-Google-Smtp-Source: ACJfBou+ZkExvDkTWD7eMjUdM6DIjFSTIZzofc2fiI6Y2SVoCDkV68Ip+7yvv1xi+TH1LpyFGBHupA== X-Received: by 10.55.165.129 with SMTP id o123mr26085508qke.8.1513449709811; Sat, 16 Dec 2017 10:41:49 -0800 (PST) Received: from [192.168.1.107] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id b202sm5728481qkg.18.2017.12.16.10.41.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Dec 2017 10:41:48 -0800 (PST) To: Wes Hardaker Cc: dnsop@ietf.org References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> <142cad85-1e0e-b4c9-1561-ad590984739a@nthpermutation.com> <1ca3daed-d521-0fcd-d1e7-eef2b781707b@nthpermutation.com> <26d61092-942a-16bc-e939-ed9400a17a29@nthpermutation.com> <19e3ce86-c797-0e88-e192-e82b936be579@nthpermutation.com> From: Michael StJohns Message-ID: Date: Sat, 16 Dec 2017 13:41:46 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DE113191A79B7974F81911A0" Content-Language: en-US Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Dec 2017 18:41:54 -0000 This is a multi-part message in MIME format. --------------DE113191A79B7974F81911A0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Wes - Interesting approach, but characterizing a single resolver isn't useful.  You need to characterize the entire set of resolvers doing the query. Also, you're still missing the fact that a given resolver can start its addHoldDown timer anywhere in the range of [0..activeRefresh] AFTER the signature expiration depending on when it was starting its clock.  All of your calculations are starting from the wrong point. You're also continuing to miss the point that a given resolver makes its last query (assuming no retransmits) anywhere in the range of [0..activeRefresh] after the addHoldDown timer expires. Your calculations represent the best case [e.g. triggers at 0 for both ends of the problem] when what you want is worst case. Below you've calculated activeRefresh as 43200 > Timestamp > > Human Time Note > 0 0d 0h 0m 0s Resolver Queries > *New DNSKEY Publication* > 604800 7d 0h 0m 0s Resolver Queries > *sigExpirationTime = Original DNSKEY RRSIG Expires* > 604800 7d 0h 0m 0s DNSKEY First seen > 648000 7d 12h 0m 0s Latest time DNSKEY first seen. (sigExpirationTime + activeRefresh) > 3196800 37d 0h 0m 0s Resolver Queries > *sigExpirationTime + addHoldDownTimer* > ** > 3196800 37d 0h 0m 0s DNSKEY Accepted > *3240000 37d 12h - Add Hold down expired for last client sigExpirationTime + activeRefresh + addHoldDownTimer (without retransmits) * > 3240000 37d 12h 0m 0s Resolver Queries > *sigExpirationTime + addHoldDownTimer + activeRefresh* > 3240000 37d 12h 0m 0s *sigExpirationTime + addHoldDownTimer + > activeRefresh + activeRefreshOffset* > *3283200  38d 0m 0s  DNSKey accepted by last client sigExpirationTime + activeRefresh + addHoldDownTimer  (without retransmits)* > 3326400 38d 12h 0m 0s Resolver Queries > *sigExpirationTime + addHoldDownTimer + activeRefresh + driftSafety* > 3326400 38d 12h 0m 0s *sigExpirationTime + addHoldDownTimer + > activeRefresh + activeRefreshOffset + driftSafety* > 3412800 39d 12h 0m 0s Resolver Queries > *sigExpirationTime + addHoldDownTimer + activeRefresh + driftSafety + > retrySafety* > For the rest - drift safety is probably no more 10seconds per query - call it for this formula about 620 seconds for the worst case (not assuming retransmit) and could mostly be ignored - the worst case is going to be less than a fastQueryInterval in all but pathological cases.    Basically 10s * (2 * activeRefresh + addHoldDown)/activeRefresh. RetrySafety needs to be calculated on the set of clients as we're looking for the worst case of all of the clients (rightmost point of the normal distribution curve). I'd suggest redoing this as a simulation.  I used the two sets of params (30 days and 24 hours vs 30 days and  28 hours) (sig expire and ttl) plus .05 failure plus 25000 clients and ran multiple trials for each.  The values in my table represent - for each trial - the latest time a client got to that point.  For the last four columns, those values represent the number of times a client exceeded the calculated safe interval (and divide by the total number of clients to get a percentage...). Later, Mike On 12/15/2017 6:55 PM, Wes Hardaker wrote: > Michael StJohns writes: > >> Below is a java program I wrote to model this stuff.  In the table, >> SF2 represents the number of clients that blew past twice the safety >> factor (for aR+aHD+aR), SF1 represents the number of clients that blew >> past the single safety factor.  OF is the number of clients using the >> activeRefreshOffset calculation that finished after the calculated >> interval (e.g. aR+aHD+aRO).  OF+s is the number of clients that >> finished after the activeRefreshOffset + safetyFactor (in the first >> table these are the same because of perfect responses).   In the >> second table, compare SF1 to OF+s - SF1 < OF+s suggesting that >> activeRefresh is a better choice that activeRefreshQuery for the third >> term of the equation.  You can try a lot of different combinations, >> but I haven't found any case where OF+s performs better that SF1. >> >> The difference between lastStart and lAddHoldBegin represents the >> retransmits after the first query.  The differences between >> lAddHoldEnd and lFinalQuery represent retransmits after the last >> normal query before the end of the add hold down time until a valid >> answer was received after the addHoldDown time expired. >> >> Feel free to twiddle with this. > Work bogged me down to able to write anything back so far. Thanks for > the java code; I'll respond with the java*script* code I've been hacking > up at the same time: > > https://www.isi.edu/~hardaker/projects/5011/ > > > I didn't add the re-transmit time issue that your code takes into > account, but I did add a query drift that nicely shows one of your > concerns. In particular, with various values of query drift (including > -1) you can reproduce the real world situation that you're worried > about, which is (as I've mentioned) an important one to call out. > --------------DE113191A79B7974F81911A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Wes -

Interesting approach, but characterizing a single resolver isn't useful.  You need to characterize the entire set of resolvers doing the query. 

Also, you're still missing the fact that a given resolver can start its addHoldDown timer anywhere in the range of [0..activeRefresh] AFTER the signature expiration depending on when it was starting its clock.  All of your calculations are starting from the wrong point.

You're also continuing to miss the point that a given resolver makes its last query (assuming no retransmits) anywhere in the range of [0..activeRefresh] after the addHoldDown timer expires.

Your calculations represent the best case [e.g. triggers at 0 for both ends of the problem] when what you want is worst case.

Below you've calculated activeRefresh as 43200


Timestamp

Human Time Note
0 0d 0h 0m 0s Resolver Queries
New DNSKEY Publication
604800 7d 0h 0m 0s Resolver Queries
sigExpirationTime = Original DNSKEY RRSIG Expires
604800 7d 0h 0m 0s DNSKEY First seen
648000 7d 12h 0m 0s Latest time DNSKEY first seen. (sigExpirationTime + activeRefresh)
3196800 37d 0h 0m 0s Resolver Queries
sigExpirationTime + addHoldDownTimer

3196800 37d 0h 0m 0s DNSKEY Accepted
3240000 37d 12h - Add Hold down expired for last client sigExpirationTime + activeRefresh + addHoldDownTimer (without retransmits)
3240000 37d 12h 0m 0s Resolver Queries
sigExpirationTime + addHoldDownTimer + activeRefresh
3240000 37d 12h 0m 0s sigExpirationTime + addHoldDownTimer + activeRefresh + activeRefreshOffset
3283200  38d 0m 0s  DNSKey accepted by last client sigExpirationTime + activeRefresh + addHoldDownTimer  (without retransmits)
3326400 38d 12h 0m 0s Resolver Queries
sigExpirationTime + addHoldDownTimer + activeRefresh + driftSafety
3326400 38d 12h 0m 0s sigExpirationTime + addHoldDownTimer + activeRefresh + activeRefreshOffset + driftSafety
3412800 39d 12h 0m 0s Resolver Queries
sigExpirationTime + addHoldDownTimer + activeRefresh + driftSafety + retrySafety


For the rest - drift safety is probably no more 10seconds per query - call it for this formula about 620 seconds for the worst case (not assuming retransmit) and could mostly be ignored - the worst case is going to be less than a fastQueryInterval in all but pathological cases.    Basically 10s * (2 * activeRefresh + addHoldDown)/activeRefresh.

RetrySafety needs to be calculated on the set of clients as we're looking for the worst case of all of the clients (rightmost point of the normal distribution curve).

I'd suggest redoing this as a simulation.  I used the two sets of params (30 days and 24 hours vs 30 days and  28 hours) (sig expire and ttl) plus .05 failure plus 25000 clients and ran multiple trials for each.  The values in my table represent - for each trial - the latest time a client got to that point.  For the last four columns, those values represent the number of times a client exceeded the calculated safe interval (and divide by the total number of clients to get a percentage...). 

Later, Mike


On 12/15/2017 6:55 PM, Wes Hardaker wrote:
Michael StJohns <msj@nthpermutation.com> writes:


Below is a java program I wrote to model this stuff.  In the table,
SF2 represents the number of clients that blew past twice the safety
factor (for aR+aHD+aR), SF1 represents the number of clients that blew
past the single safety factor.  OF is the number of clients using the
activeRefreshOffset calculation that finished after the calculated
interval (e.g. aR+aHD+aRO).  OF+s is the number of clients that
finished after the activeRefreshOffset + safetyFactor (in the first
table these are the same because of perfect responses).   In the
second table, compare SF1 to OF+s - SF1 < OF+s suggesting that
activeRefresh is a better choice that activeRefreshQuery for the third
term of the equation.  You can try a lot of different combinations,
but I haven't found any case where OF+s performs better that SF1.

The difference between lastStart and lAddHoldBegin represents the
retransmits after the first query.  The differences between
lAddHoldEnd and lFinalQuery represent retransmits after the last
normal query before the end of the add hold down time until a valid
answer was received after the addHoldDown time expired.

Feel free to twiddle with this.

Work bogged me down to able to write anything back so far.  Thanks for
the java code; I'll respond with the java*script* code I've been hacking
up at the same time:

https://www.isi.edu/~hardaker/projects/5011/


I didn't add the re-transmit time issue that your code takes into
account, but I did add a query drift that nicely shows one of your
concerns.  In particular, with various values of query drift (including
-1) you can reproduce the real world situation that you're worried
about, which is (as I've mentioned) an important one to call out.


--------------DE113191A79B7974F81911A0-- From nobody Sun Dec 17 09:20:13 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003AD1272E1 for ; Sun, 17 Dec 2017 09:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 TOaDHF86oEVq for ; Sun, 17 Dec 2017 09:20:10 -0800 (PST) Received: from mail.hardakers.net (unknown [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3780127137 for ; Sun, 17 Dec 2017 09:20:10 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 0B6DB22275; Sun, 17 Dec 2017 09:20:10 -0800 (PST) From: Wes Hardaker To: Michael StJohns Cc: Wes Hardaker , dnsop@ietf.org References: <151199364931.4845.3034001091375154653@ietfa.amsl.com> <9c71768d-4807-3d0a-b4b1-0ac8d066fe9f@nthpermutation.com> <6d239b9a-fd1e-46a3-c705-6851dd8ffe0a@nthpermutation.com> <142cad85-1e0e-b4c9-1561-ad590984739a@nthpermutation.com> <1ca3daed-d521-0fcd-d1e7-eef2b781707b@nthpermutation.com> <26d61092-942a-16bc-e939-ed9400a17a29@nthpermutation.com> <19e3ce86-c797-0e88-e192-e82b936be579@nthpermutation.com> Date: Sun, 17 Dec 2017 09:20:09 -0800 In-Reply-To: (Michael StJohns's message of "Sat, 16 Dec 2017 13:41:46 -0500") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Dec 2017 17:20:12 -0000 Michael StJohns writes: > Also, you're still missing the fact that a given resolver can start > its addHoldDown timer anywhere in the range of [0..activeRefresh] > AFTER the signature expiration depending on when it was starting its > clock.=C2=A0 All of your calculations are starting from the wrong point. No I'm not. Set the resolver query offset amount to something large and it does exactly what you're talking about. I didn't forget it. In fact, the most interesting case is when you set it large (set it to 300d, and the code will clip it to activeRefresh-1 anyway) and then you set the resolver query drift amount to -1. You'll note, in this case, that that the dnskey is accepted *after* my current activeRefreshOffset line, *proving* your case. You keep saying I don't understand and don't agree with you, but if this doesn't prove that I both do understand and agree with the problem I don't know what will. Go change *only* those two lines in the simulator and it *shows* that you have very legitimately found a source of real-world error that must be accounted for. > > Your calculations represent the best case [e.g. triggers at 0 for both en= ds of the problem] when what > you want is worst case. Try 300d in resolver query offset. --=20 Wes Hardaker USC/ISI From nobody Mon Dec 18 01:05:48 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98767120725; Mon, 18 Dec 2017 01:05:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151358794259.28874.17776900000110465516@ietfa.amsl.com> Date: Mon, 18 Dec 2017 01:05:42 -0800 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-let-localhost-be-localhost-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 09:05:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Let 'localhost' be localhost. Author : Mike West Filename : draft-ietf-dnsop-let-localhost-be-localhost-02.txt Pages : 10 Date : 2017-12-18 Abstract: This document updates the treatment of the special-use domain name "localhost" as specified in RFC6761, Section 6.3, with the goal of ensuring that it can be safely relied upon as a name for the local host's loopback interface. To that end, stub resolvers are required to resolve localhost names to loopback addresses. Recursive DNS servers are required to return "NXDOMAIN" when queried for localhost names, making non-conformant stub resolvers more likely to fail and produce problem reports that result in updates. Together, these requirements would allow applications and specifications to join regular users in drawing the common-sense conclusions that "localhost" means "localhost", and doesn't resolve to somewhere else on the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-let-localhost-be-localhost/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-let-localhost-be-localhost-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-let-localhost-be-localhost-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 18 01:25:09 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8402F12741D for ; Mon, 18 Dec 2017 01:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ixFaCBYun83i for ; Mon, 18 Dec 2017 01:25:06 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 17BDC127419 for ; Mon, 18 Dec 2017 01:25:06 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id e2so19218152qti.0 for ; Mon, 18 Dec 2017 01:25:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=bovNPz5vWCWYIhuVwMFlLHJeoFVEc+3FFaMqJ4mZoEI=; b=IdqU3M29pWynejA1EO5dzHPBoyZ8vRGNdH5aqFoocUxDCPYpwKFPpjGc/KbWhp6dcf TE/BjwigicQoQLT29dl4kOJYXI2nWTesGFfDhYTdGsF4Pw4adbUc55TjeDKOkTKUI+Wx TTnMk4x2UW+2Fjf4c2z1oiw2wqy3U2xjcbMjCzyEheI/VjQpe3WdGHZE56JCcQtE7/a5 Bii/BkfQNexoBv6jO9G3sSO/AjtQMUBJLQxtQybMVN6nm5c1Oy+vHMYluv6Jec4EeEWx OGF9I+qMngWSxFK/+7BSE4MOa41LOiPmUvm8CoOI4geB/EmGQesgJaVzvxWfYMOBk3/I YNYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=bovNPz5vWCWYIhuVwMFlLHJeoFVEc+3FFaMqJ4mZoEI=; b=Q7RmzVQY1r0sgnl4BWHuhHApn6s/CzkIgvA0UGum5RizVK81rZBvpRGcGXR5vhh7fJ PGZ0kwRY3qjI0kSNLaur71SlOdUYjkWxmKjU06nWnbLmkwmjavHEQoej371bsejXUuVX fuaQggr3XqZklvpzLu6NQWh2BdCmZtCXPeOQ7tun0Pv825vEoLvnxQe5eqFrKF9bv4gS +xbpyGtnctes4Vm+nLCqupkBMjPA5r/sbJKhVrZ7st+GMHGuWI92BHx/Fxz5vYvSN91J tRAdIstJHWwEV1euYPn3bofJGZW3SxUbGRjhg5qoKpWQpdL1qHX8yctZ6E22JCw1GR8d dXlw== X-Gm-Message-State: AKGB3mJnOdC9jogbpcnP/7OgsLmtlbsEPCAsMZ36XrxUTTJIwuORxrne 330tAA4jJW6ab4mBN+dmgTeCyXZyAsuNy9VEfuC+leajHos= X-Google-Smtp-Source: ACJfBouVpIfxyBWAP1LGdlLhw2beyLhpEiu5om/xN1r3GnCfqkFbuhti58vAeoRRGUk14s7p+gs35JY/iurL/SMbyss= X-Received: by 10.200.25.134 with SMTP id u6mr32484164qtj.221.1513589104475; Mon, 18 Dec 2017 01:25:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.6.146 with HTTP; Mon, 18 Dec 2017 01:24:43 -0800 (PST) In-Reply-To: <151358794259.28874.17776900000110465516@ietfa.amsl.com> References: <151358794259.28874.17776900000110465516@ietfa.amsl.com> From: Mike West Date: Mon, 18 Dec 2017 10:24:43 +0100 Message-ID: To: dnsop WG Content-Type: multipart/alternative; boundary="94eb2c04435ee9223f056099ecae" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-let-localhost-be-localhost-02.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 09:25:08 -0000 --94eb2c04435ee9223f056099ecae Content-Type: text/plain; charset="UTF-8" This draft addresses a few nits that were raised in conversation on the -01. Changelog at https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02#appendix-B.1 . -mike On Mon, Dec 18, 2017 at 10:05 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : Let 'localhost' be localhost. > Author : Mike West > Filename : draft-ietf-dnsop-let- > localhost-be-localhost-02.txt > Pages : 10 > Date : 2017-12-18 > > Abstract: > This document updates the treatment of the special-use domain name > "localhost" as specified in RFC6761, Section 6.3, with the goal of > ensuring that it can be safely relied upon as a name for the local > host's loopback interface. To that end, stub resolvers are required > to resolve localhost names to loopback addresses. Recursive DNS > servers are required to return "NXDOMAIN" when queried for localhost > names, making non-conformant stub resolvers more likely to fail and > produce problem reports that result in updates. > > Together, these requirements would allow applications and > specifications to join regular users in drawing the common-sense > conclusions that "localhost" means "localhost", and doesn't resolve > to somewhere else on the network. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-let- > localhost-be-localhost/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-let- > localhost-be-localhost-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-let- > localhost-be-localhost-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --94eb2c04435ee9223f056099ecae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This draft addresses a few nits that were raised in conver= sation on the -01. Changelog at=C2=A0https://tools= .ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02#appendix-B.1<= /a>.

-mike

On Mon, Dec 18, 2017 at 10:05 AM, <= internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Let 'localhost' be localhost.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Mike= West
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dnsop-let-localhost-be-localhost-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-12-18

Abstract:
=C2=A0 =C2=A0This document updates the treatment of the special-use domain = name
=C2=A0 =C2=A0"localhost" as specified in RFC6761, Section 6.3, wi= th the goal of
=C2=A0 =C2=A0ensuring that it can be safely relied upon as a name for the l= ocal
=C2=A0 =C2=A0host's loopback interface.=C2=A0 To that end, stub resolve= rs are required
=C2=A0 =C2=A0to resolve localhost names to loopback addresses.=C2=A0 Recurs= ive DNS
=C2=A0 =C2=A0servers are required to return "NXDOMAIN" when queri= ed for localhost
=C2=A0 =C2=A0names, making non-conformant stub resolvers more likely to fai= l and
=C2=A0 =C2=A0produce problem reports that result in updates.

=C2=A0 =C2=A0Together, these requirements would allow applications and
=C2=A0 =C2=A0specifications to join regular users in drawing the common-sen= se
=C2=A0 =C2=A0conclusions that "localhost" means "localhost&q= uot;, and doesn't resolve
=C2=A0 =C2=A0to somewhere else on the network.


The IETF datatracker status page for this draft is:
https://datatracker.iet= f.org/doc/draft-ietf-dnsop-let-localhost-be-localhost/

There are also htmlized versions available at:
https://tools.ietf.org/htm= l/draft-ietf-dnsop-let-localhost-be-localhost-02
https://datatrac= ker.ietf.org/doc/html/draft-ietf-dnsop-let-localhost-be-localhost= -02

A diff from the previous version is available at:
https://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-dnsop-let-localhost-be-localhost-02<= /a>


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--94eb2c04435ee9223f056099ecae-- From nobody Mon Dec 18 05:06:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEBE128959 for ; Mon, 18 Dec 2017 05:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 QnDLMDpixb23 for ; Mon, 18 Dec 2017 05:06:49 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 A9947128954 for ; Mon, 18 Dec 2017 05:06:49 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 91E432821D0; Mon, 18 Dec 2017 14:06:47 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 8C4E7282267; Mon, 18 Dec 2017 14:06:47 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 8580A2821D0; Mon, 18 Dec 2017 14:06:47 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 82B0D642A7A1; Mon, 18 Dec 2017 14:06:47 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 74AE7401D4; Mon, 18 Dec 2017 14:06:47 +0100 (CET) Date: Mon, 18 Dec 2017 14:06:47 +0100 From: Stephane Bortzmeyer To: Paul Hoffman Cc: dnsop@ietf.org Message-ID: <20171218130647.el2thqrvqzpi6apu@nic.fr> References: <151180495773.30942.2986792598977230034@ietfa.amsl.com> <7262E5E9-D844-4CBA-B406-C38B57440321@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7262E5E9-D844-4CBA-B406-C38B57440321@vpnc.org> X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.18.125416 Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 13:06:51 -0000 On Mon, Nov 27, 2017 at 09:53:32AM -0800, Paul Hoffman wrote a message of 59 lines which said: > We will be opening new issues in the coming weeks with the intention to be > ready for WG Last Call by mid-January. I've read the document and it seems basically OK to me (ready for WGLC). I will comment on contentious terms in the other threads. From nobody Mon Dec 18 05:12:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53641289B0 for ; Mon, 18 Dec 2017 05:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 ksshjFiSg9BD for ; Mon, 18 Dec 2017 05:12:24 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 983CD12785F for ; Mon, 18 Dec 2017 05:12:24 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 2C98C28243F; Mon, 18 Dec 2017 14:12:23 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 26B71282482; Mon, 18 Dec 2017 14:12:23 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 1FF6F28243F; Mon, 18 Dec 2017 14:12:23 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 1CD396423549; Mon, 18 Dec 2017 14:12:23 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 14036401D4; Mon, 18 Dec 2017 14:12:23 +0100 (CET) Date: Mon, 18 Dec 2017 14:12:23 +0100 From: Stephane Bortzmeyer To: Paul Hoffman Cc: dnsop WG Message-ID: <20171218131223.yfu5ntzdyjivlnzi@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000016, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.18.130316 Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: QNAME X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 13:12:25 -0000 On Mon, Dec 11, 2017 at 07:30:27AM -0800, Paul Hoffman wrote a message of 16 lines which said: > Some of the new terms added to the terminology-bis draft > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since > RFC 7719 can expose what some (but not all) people perceive as lack > of clarity in RFC 1034/1035. This week, we hope you will look at the > definition in the draft for "QNAME". As I mentioned in this errata , I think RFC 2308 was wrong in redefining QNAME. My personal preference would be to change the second paragraph to "RFC 2308 proposed another definition, different from the original one. Since it is actually a different concept, it would be better to find another name for it. Here, QNAME retains the original definition of RFC 1034." Otherwise, if the WG prefers, I can live with the current text :-( From nobody Mon Dec 18 05:24:50 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685ED129C5D for ; Mon, 18 Dec 2017 05:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 TnntqvgLQhNz for ; Mon, 18 Dec 2017 05:24:48 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 6CE3A1205F1 for ; Mon, 18 Dec 2017 05:24:48 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 01166282531; Mon, 18 Dec 2017 14:24:47 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id EF27228254A; Mon, 18 Dec 2017 14:24:46 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id E8741282531; Mon, 18 Dec 2017 14:24:46 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id E5B116427BE0; Mon, 18 Dec 2017 14:24:46 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id DE839401D4; Mon, 18 Dec 2017 14:24:46 +0100 (CET) Date: Mon, 18 Dec 2017 14:24:46 +0100 From: Stephane Bortzmeyer To: Paul Hoffman Cc: dnsop WG Message-ID: <20171218132446.w7o5x4mrz2ttprlb@nic.fr> References: <707A270D-94DA-4651-84DC-409FAA6793F7@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <707A270D-94DA-4651-84DC-409FAA6793F7@vpnc.org> X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.18.131216 Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 13:24:49 -0000 On Mon, Dec 04, 2017 at 10:27:32AM -0800, Paul Hoffman wrote a message of 28 lines which said: > - In-bailiwick > - Out-of-bailiwick The current definition is restrictive: it mentions only name servers. IMHO, "in-bailiwick" could be said for any domain name, even if it has less practical consequences than for name servers. For instance, www.toto.fr is in-bailiwick for .fr. > In-bailiwick name servers may have glue records in their parent zone Wrong use of "parent" here, since the definition of "parent" says "The domain in which the Child is registered". Should be "ancestor", as in "d.nic.fr's parent zone is fr but it requires glue in the root, which is an ancestor" > - In-domain > - Sibling domain I tend to think it would be better to drop these two terms. I find them rarely used and they don't seem to bring much value. From nobody Mon Dec 18 05:44:31 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77259120726 for ; Mon, 18 Dec 2017 05:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 X4tf5yoUiV8F for ; Mon, 18 Dec 2017 05:44:29 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 871321205D3 for ; Mon, 18 Dec 2017 05:44:29 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id CCE18282593; Mon, 18 Dec 2017 14:44:27 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id C625D2825AC; Mon, 18 Dec 2017 14:44:27 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id BF9CA282593; Mon, 18 Dec 2017 14:44:27 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id BCE98642354A; Mon, 18 Dec 2017 14:44:27 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id B0F7A401D4; Mon, 18 Dec 2017 14:44:27 +0100 (CET) Date: Mon, 18 Dec 2017 14:44:27 +0100 From: Stephane Bortzmeyer To: fujiwara@jprs.co.jp Cc: ggm@algebras.org, dnsop@ietf.org, paul.hoffman@vpnc.org Message-ID: <20171218134427.4przwtuy3o2jsrm7@nic.fr> References: <56BEBCFA-D6BA-4BD1-8B95-190375A57C06@isc.org> <20171213.204234.76214525553211985.fujiwara@jprs.co.jp> <20171215.113000.152427157235084555.fujiwara@jprs.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171215.113000.152427157235084555.fujiwara@jprs.co.jp> X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.007977, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.18.133316 Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 13:44:30 -0000 On Fri, Dec 15, 2017 at 11:30:00AM +0900, fujiwara@jprs.co.jp wrote a message of 74 lines which said: > Adding examples as a table is good ? or too large ? No, not too large. It is a very good idea and this table is useful. From nobody Mon Dec 18 05:52:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4991242F7 for ; Mon, 18 Dec 2017 05:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 qBp2ZarTjNOK for ; Mon, 18 Dec 2017 05:52:13 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 51FE1124217 for ; Mon, 18 Dec 2017 05:52:13 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id DB2412825D3; Mon, 18 Dec 2017 14:52:11 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id D54332825EC; Mon, 18 Dec 2017 14:52:11 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id CE7EE2825D3; Mon, 18 Dec 2017 14:52:11 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id CB3CD6427BE0; Mon, 18 Dec 2017 14:52:11 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id C68AA401D4; Mon, 18 Dec 2017 14:52:11 +0100 (CET) Date: Mon, 18 Dec 2017 14:52:11 +0100 From: Stephane Bortzmeyer To: Paul Hoffman Cc: dnsop WG Message-ID: <20171218135211.nul66bgdxczmg4lp@nic.fr> References: <8CB86DAB-B80E-469A-9BDA-7F1361634933@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8CB86DAB-B80E-469A-9BDA-7F1361634933@vpnc.org> X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.18.134216 Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: Global DNS and Private DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 13:52:14 -0000 On Mon, Nov 27, 2017 at 10:28:04AM -0800, Paul Hoffman wrote a message of 14 lines which said: > Section 2 has definitions of "Global DNS" and "Private DNS", based > on the facets listed in "Naming system". This was discussed heavily > on the list earlier, but it is also a pretty big change, so we want > to be sure that it is what the WG wants. Please review these terms > and comment on the list if you think the definitions should change. I think that it would be better to remove "global DNS". It is not a technical definition and it assumes things like the mythical "names operational community". This draft is about DNS terminology. From the point of view of the DNS, ICANN and OpenNIC are the same (same protocols, same concepts, same names) even if their registration (i.e. non-DNS) policies are different. From nobody Mon Dec 18 06:11:17 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3BF12895E for ; Mon, 18 Dec 2017 06:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 CoQfg19Asy9Q for ; Mon, 18 Dec 2017 06:11:14 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 5C02E12708C for ; Mon, 18 Dec 2017 06:11:14 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id E499D28211A; Mon, 18 Dec 2017 15:11:12 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id DE8DA282260; Mon, 18 Dec 2017 15:11:12 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id D73F228211A; Mon, 18 Dec 2017 15:11:12 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id D3D5B642A7A1; Mon, 18 Dec 2017 15:11:12 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id C8168401D4; Mon, 18 Dec 2017 15:11:12 +0100 (CET) Date: Mon, 18 Dec 2017 15:11:12 +0100 From: Stephane Bortzmeyer To: Martin Hoffmann Cc: dnsop@ietf.org Message-ID: <20171218141112.56cxoc5nvt3wlsdf@nic.fr> References: <20171130133600.447a2904@grisu.home.partim.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171130133600.447a2904@grisu.home.partim.org> X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.098608, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.18.140316 Archived-At: Subject: Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 14:11:16 -0000 On Thu, Nov 30, 2017 at 01:36:00PM +0100, Martin Hoffmann wrote a message of 297 lines which said: > GLOBAL DNS -- FORMAT OF NAMES > > | Names in the common display format are normally written such that the > | directionality of the writing system presents labels by decreasing > | distance from the root (so, in both English and C the first label in > the | ordered list is right-most; but in Arabic it may be left-most, > depending | on local conventions). > > The first sentence makes it sound as if right-to-left languages would > normally write ‘com.example’ which is not the case. BiDI is complicated enough so I suggest we keep only examples where the script of the domain name is the same as the parent script. This way, sentences like "The TLD is at the end" are always true. Writing a latin domain name in arabic is left as an exercice for the reader :-) > under these circumstances the name will always be in the ‘usual’ > order. I challenge this assumption. After all, numbers in arabic are sometimes big-endian and sometimes little-endian (depending on wether you are in the Middle-East or in North Africa). > PRIMING > > This comes a bit suddenly. Maybe it should start with a short > introduction a la ‘In order to operate in recursive mode, a resolver > needs to know the address of at least one root server.’ IMHO, the reference to the excellent RFC 8109 is sufficient. > PASSIVE DNS > > | A mechanism to collect DNS data by storing DNS transactions from name > | servers. Some of these systems also collect the DNS queries > associated | with the responses. > > I don’t think it has been defined yet, but the term ‘transaction’ > commonly refers to a pair of a query and its response (plus possibly > any re-sent queries or responses due to packet loss). With this in > mind, the second sentence doesn’t quite make sense. I agree and I suggest this text: Passive DNS: A mechanism to collect DNS data by storing DNS responses from name servers. Some of these systems also collect the DNS queries associated with the responses, although it raises some privacy concerns. Passive DNS databases can be used to answer historical questions about DNS zones such as which values were present at a given time in the past, or when a name was spotted first. Passive DNS databases allow searching of the stored records on keys other than just the name and type, such as "find all names which have A records of a particular value". > IN-BAILIWICK ... > Also, on behalf on non-native speakers, a short explanation of the > origin of the term would perhaps be nice. I like the Wiktionary (and it can be copied freely into a RFC): Etymology >From bailie (“bailiff”) and wick (“dwelling”), from Old English wīc. bailiwick (plural bailiwicks) The district within which a bailie or bailiff has jurisdiction. The Bailiwick of Jersey. A person's concern or sphere of operations, their area of skill or authority. Synonyms (area or subject of authority or involvement): domain, department, jurisdiction, sphere, territory, turf. From nobody Mon Dec 18 06:17:03 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9167512711E for ; Mon, 18 Dec 2017 06:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 7kWTJcLlMube for ; Mon, 18 Dec 2017 06:16:49 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 8A1B512708C for ; Mon, 18 Dec 2017 06:16:49 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id CBE2328211A; Mon, 18 Dec 2017 15:16:47 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id C4EE0282260; Mon, 18 Dec 2017 15:16:47 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id BDFEC28211A; Mon, 18 Dec 2017 15:16:47 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id BA80F642A7A1; Mon, 18 Dec 2017 15:16:47 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id B395B401D4; Mon, 18 Dec 2017 15:16:47 +0100 (CET) Date: Mon, 18 Dec 2017 15:16:47 +0100 From: Stephane Bortzmeyer To: Mark Andrews Cc: Joe Abley , Paul Vixie , dnsop@ietf.org, Ted Lemon Message-ID: <20171218141647.3t7in2trpa5sv76r@nic.fr> References: <20171211090051.qjoruin7nkdjsnvd@nic.fr> <5A2E4B7C.50509@redbarn.org> <20171211091800.wonjnvhl3xrx6r4s@nic.fr> <118C37A8-0DEF-460B-8A79-AAE470D3CED8@hopcount.ca> <1B37BBA1-D141-441A-855E-1ACFF2DC15BD@fugue.com> <23CF8A88-F530-426D-A6A9-4B80AF28D603@fugue.com> <09515131-DD1B-4FC9-90F6-C088173857BA@hopcount.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.18.140316 Archived-At: Subject: Re: [DNSOP] DNS privacy and AS 112: the case of home.arpa X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 14:16:52 -0000 On Thu, Dec 14, 2017 at 12:53:30PM +1100, Mark Andrews wrote a message of 41 lines which said: > Also IANA was NOT instructed to delegate to the AS112 servers. IANA > was instructed to delegate to back hole servers and a example of > which, the AS112 servers, was presented. I understand it is precisely one of the problems Joe Abley mentioned: AS 112 servers are not really black hole servers (they reply). From nobody Mon Dec 18 06:30:05 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551221270AC for ; Mon, 18 Dec 2017 06:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 BJfmsY8SS_TT for ; Mon, 18 Dec 2017 06:30:01 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 9942212D0C3 for ; Mon, 18 Dec 2017 06:30:01 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id x7so1101586qkb.0 for ; Mon, 18 Dec 2017 06:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=z7DVTye6D/AhFGzXAB4I3XLARFAmF5Xcfh3aCUhDw+I=; b=wPwjeMU5ndvttFGwVWeVdlZ0xEd2SB4uC1XIYo9VVeJemq94qvkzxcmKIOvZoNj6vZ cNGra43xc9PvafdbWAphXPZZywpJhwtpONA9nlidfWdNLxEaZt4SSisrFN/GXOqghw1u crBzxvqmy9/ELGq1ORyyGRTo+uczuP4Anf70OywyfQQo5duBWdr0EbEBxB31o96xiZAJ MhJLA83VFZmkk1peHKXr6Xmiw7QYL72uNf5sxejE9bw7OL7kICXdsjTivRiUatxl0rgM jboauj0uGToy4eEJxfJxFhXE9/y873sgjt6XnVzhgLyzcU1zcRu978f3LZKd67ZfvHhc Cz2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=z7DVTye6D/AhFGzXAB4I3XLARFAmF5Xcfh3aCUhDw+I=; b=BxEHcr9T6FJ2vZKlHMCI/GtG79hWeMBh22JKp2vZshQwC0xr7l4ZEthfbpznDzVZU5 iHeMLDwHWAelDnAU8yZFaw1uv5lqXxANATO07wgMO2evW1fiRS6I7m5EDssv5Aqo1WBv lcWET5SwDOY89NjD5OXWpCxP+/ZL/iaW/QPSJOJkvR1wwvUU1I772vaD8QrfxIlvFGVB b7p6oron2rHCuTRqJPEOpVxRgeaXALzVdcFO9WZ0FvQ6IqMOXVfQBWMlbV/fMZI4YgpR JR+3hx/biJu3d2XpD7Kc+YXi/28XxRVeM1Uziz2H9Ng/hm5W6ee0OmZ/i+Uyr+aVUJML P02g== X-Gm-Message-State: AKGB3mIOkR0LhPG0Tvgws659o8uInp5RhGCtB4kwga3aiSvyhHaBCyOq Gi96r3nZecm8AB2wIoqzmoUaAeOyZN4= X-Google-Smtp-Source: ACJfBosUMO3Yyb4R4L/yhrUcW+YpI7okxStrqn9qm/kUpB+YHWuNVLqlAa9gtRUtTeMoZtKOH/z/Ag== X-Received: by 10.55.167.73 with SMTP id q70mr63334qke.47.1513607400447; Mon, 18 Dec 2017 06:30:00 -0800 (PST) Received: from cavall.lan (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id k1sm8244119qtf.11.2017.12.18.06.29.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Dec 2017 06:29:59 -0800 (PST) From: Ted Lemon Message-Id: <160A1E3B-0ABA-4A22-9128-0ED5B8577F87@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_59FDA47E-A05C-480F-AA10-1D2722F8AABC" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 18 Dec 2017 09:29:58 -0500 In-Reply-To: <20171218135211.nul66bgdxczmg4lp@nic.fr> Cc: Paul Hoffman , dnsop WG To: Stephane Bortzmeyer References: <8CB86DAB-B80E-469A-9BDA-7F1361634933@vpnc.org> <20171218135211.nul66bgdxczmg4lp@nic.fr> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: Global DNS and Private DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 14:30:04 -0000 --Apple-Mail=_59FDA47E-A05C-480F-AA10-1D2722F8AABC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 18, 2017, at 8:52 AM, Stephane Bortzmeyer = wrote: > I think that it would be better to remove "global DNS". It is not a > technical definition and it assumes things like the mythical "names > operational community". This draft is about DNS terminology. =46rom = the > point of view of the DNS, ICANN and OpenNIC are the same (same > protocols, same concepts, same names) even if their registration > (i.e. non-DNS) policies are different. In homenet-dot, IIRC we ran into this problem, and started using terms = like "globally-unique name" and "non-globally-unique name" to finesse = it, but we still used "global DNS" once. We use "globally scoped" and = "locally scoped" a lot. If you were to define the global DNS, I think it would simply be the set = of names that are published and are unique subdomains of names that have = delegations from the root. This is slightly looser than "the set of = all names that can be reached by delegations from the root" because some = parts of the "global DNS" are not reachable outside of their local = scope. I'm not claiming that what I just said is what should be in the = document, just that that's sort of the general idea of it. What the = document actually says is much more than this, much better than this, = and I think includes this, although perhaps not as explicitly as might = be desired. Anyway, my point is that if you were to remove "global DNS" from the = document, that would be really unfortunate. What's there is good, and = useful. I think the point you've raised about "names operational community" is = also pretty obviously wrong, because the text uses the term = "administrative operational community" and says what it means: "which = convenes itself in the ICANN." So the term you say is mythical is not = only well-defined, but has a meaning that is well known to pretty much = everybody who participates in DNSOP! :) Now that I've attempted to compose this reply, it seems to me, and = perhaps was obvious to other readers more quickly because they're at = 20kft and not 1ft on this, that your real point is that the document = should not privilege ICANN over OpenNIC. If so, you should say that = directly and we should reason about that, not start from your = conclusion. This is difficult, in the sense that while I tend to not like the idea = of reifying ICANN in this way, the document is reporting the status quo, = and is not saying anything about it that's not true, and the confusion = you propose will in fact come up for the reader if the document doesn't = say this. If the status quo is wrong, this is not really the document = in which that argument should be made; if that argument is successfully = made at some later date, the document will not be wrong, but merely out = of date in terms of reporting the status quo. Taking out the whole section on global and private names seems like = cutting off one's nose to spite one's face. --Apple-Mail=_59FDA47E-A05C-480F-AA10-1D2722F8AABC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Dec 18, 2017, at 8:52 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> = wrote:
I think that it = would be better to remove "global DNS". It is not a
technical definition and it assumes things like = the mythical "names
operational = community". This draft is about DNS terminology. =46rom the
point of view of the DNS, ICANN and OpenNIC are = the same (same
protocols, same concepts, same names) = even if their registration
(i.e. non-DNS) = policies are different.

In homenet-dot, IIRC we ran into this problem, and started = using terms like "globally-unique name" and "non-globally-unique name" = to finesse it, but we still used "global DNS" once.   We use = "globally scoped" and "locally scoped" a lot.

If you were to define the global DNS, I = think it would simply be the set of names that are published and are = unique subdomains of names that have delegations from the root.   = This is slightly looser than "the set of all names that can be reached = by delegations from the root" because some parts of the "global DNS" are = not reachable outside of their local scope.   I'm not claiming that = what I just said is what should be in the document, just that that's = sort of the general idea of it.   What the document actually says = is much more than this, much better than this, and I think includes = this, although perhaps not as explicitly as might be desired.

Anyway, my point is that = if you were to remove "global DNS" from the document, that would be = really unfortunate.   What's there is good, and useful.

I think the point you've = raised about "names operational community" is also pretty obviously = wrong, because the text uses the term "administrative operational = community" and says what it means: "which convenes itself in the ICANN." =   So the term you say is mythical is not only well-defined, but has = a meaning that is well known to pretty much everybody who participates = in DNSOP!   :)

Now that I've attempted to compose this reply, it seems to = me, and perhaps was obvious to other readers more quickly because = they're at 20kft and not 1ft on this, that your real point is that the = document should not privilege ICANN over OpenNIC.   If so, you = should say that directly and we should reason about that, not start from = your conclusion.

This is difficult, in the sense that while I tend to not like = the idea of reifying ICANN in this way, the document is reporting the = status quo, and is not saying anything about it that's not true, and the = confusion you propose will in fact come up for the reader if the = document doesn't say this.   If the status quo is wrong, this is = not really the document in which that argument should be made; if that = argument is successfully made at some later date, the document will not = be wrong, but merely out of date in terms of reporting the status = quo.

Taking = out the whole section on global and private names seems like cutting off = one's nose to spite one's face.

= --Apple-Mail=_59FDA47E-A05C-480F-AA10-1D2722F8AABC-- From nobody Mon Dec 18 11:05:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7B612D832 for ; Mon, 18 Dec 2017 11:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 5D6sCXC7nhsT for ; Mon, 18 Dec 2017 11:05:50 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B06F120454 for ; Mon, 18 Dec 2017 11:05:50 -0800 (PST) Received: from [10.1.10.225] (50-255-33-26-static.hfc.comcastbusiness.net [50.255.33.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 44F6161FA2; Mon, 18 Dec 2017 19:05:49 +0000 (UTC) Message-ID: <5A381173.5000906@redbarn.org> Date: Mon, 18 Dec 2017 11:05:23 -0800 From: Paul Vixie User-Agent: Postbox 5.0.22 (Windows/20171208) MIME-Version: 1.0 To: Stephane Bortzmeyer CC: Paul Hoffman , dnsop WG References: <20171218131223.yfu5ntzdyjivlnzi@nic.fr> In-Reply-To: <20171218131223.yfu5ntzdyjivlnzi@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: QNAME X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 19:05:51 -0000 Stephane Bortzmeyer wrote: > As I mentioned in this errata > , I think RFC 2308 was > wrong in redefining QNAME. My personal preference would be to change > the second paragraph to "RFC 2308 proposed another definition, > different from the original one. Since it is actually a different > concept, it would be better to find another name for it. Here, QNAME > retains the original definition of RFC 1034." +1. -- P Vixie From nobody Mon Dec 18 11:12:54 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB19712D838 for ; Mon, 18 Dec 2017 11:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 VtVUbpVUd8yv for ; Mon, 18 Dec 2017 11:12:51 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 E8D4812D80F for ; Mon, 18 Dec 2017 11:12:50 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id q67so298458pga.9 for ; Mon, 18 Dec 2017 11:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q6sXv5IjSMehRtF30XGxGt9vIOnJJGKfnHgLREk8HKg=; b=hJapmEph5CIJZkPy93B0zhF2SGcqm/BIVPl+Wy42hOaRtWfjSrsO1vWMAnVOIvMwrJ Y7CvApXV7LxOIS0jJf52b0U2SrtMpT05LUOjwjGzPfqYe5Yy3JDOw8ZscaktFGp2EcCi DyWBtYnbhtGcC8VlGjG1ANiAPso537V05KHCKJUzCICC5opVuZihrxAMJowpnbLgh/yl 2qRQjbvswRG5SdficcLpS1fb4vA5v/eyJpumyzLUFNOUQeACradFYkcTA2f7oJSUPKR+ bMcPxhrFBoOzU4YoVE8Dtydwzs2AUN09HgZorHKKL5ySiaJBlSZtefvPr5wyyPGAPBgl k68Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q6sXv5IjSMehRtF30XGxGt9vIOnJJGKfnHgLREk8HKg=; b=son/wERwI8Tus3nOKOMFrAZWfwdoW+5+yhpKG8qioyRudtsIGis/yhSF5XKYZpJx0h ujRYZefVKiOAGmaftldFbmdFCCgKTO4KsD3ugrgbMM12p7SQyIkGM2ZCZWDtMpxpgCo7 VRZjPXeo6Z82dIVVzR/UsrUN4mKqfTr1/i/fjOdUTG1yZMMqsDnkPeDu4IX28HA9vIwm e43QpWCHSy1nWw6Z8LaaXNdWlMPrFlv0zC7wrstlCqaQYxUrsnocvfFfapVqJMB6GMz5 n0W8K77Cv5A9fCB1bIn7wWP5lLaPrrhFhxjw08lQgr6x3D01XFCWI7HzBRAf+VQJF73z KnNQ== X-Gm-Message-State: AKGB3mL/Er1rxCrMikfP0lFOt7OO05FCXrW05s7Kfju4cjYF241Imv1q /IPxIPlgi3QfRjDY/hvS0ljw2E/p/jLnvwzZqFB6jKcc X-Google-Smtp-Source: ACJfBovXtZysRrbG8q7E8qDsBkr1PYky9jjiKdiODGkHBWvvKiuE6Ht5RyG1SKvWWgLuNGfHbqunBrnlFf+B3arfRFQ= X-Received: by 10.98.19.202 with SMTP id 71mr663587pft.181.1513624370342; Mon, 18 Dec 2017 11:12:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.139.5 with HTTP; Mon, 18 Dec 2017 11:12:49 -0800 (PST) In-Reply-To: <5A381173.5000906@redbarn.org> References: <20171218131223.yfu5ntzdyjivlnzi@nic.fr> <5A381173.5000906@redbarn.org> From: Bob Harold Date: Mon, 18 Dec 2017 14:12:49 -0500 Message-ID: To: Paul Vixie Cc: Stephane Bortzmeyer , dnsop WG , Paul Hoffman Content-Type: multipart/alternative; boundary="001a11459990eafd760560a22256" Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: QNAME X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 19:12:53 -0000 --001a11459990eafd760560a22256 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 18, 2017 at 2:05 PM, Paul Vixie wrote: > > > Stephane Bortzmeyer wrote: > >> As I mentioned in this errata >> , I think RFC 2308 was >> wrong in redefining QNAME. My personal preference would be to change >> the second paragraph to "RFC 2308 proposed another definition, >> different from the original one. Since it is actually a different >> concept, it would be better to find another name for it. Here, QNAME >> retains the original definition of RFC 1034." >> > > +1. > > -- > P Vixie > +1 -- Bob Harold --001a11459990eafd760560a22256 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Mon, Dec 18, 2017 at 2:05 PM, Paul Vixie <paul@redbarn.org> wrote:


Stephane Bortzmeyer wrote:
As I mentioned in this errata
<https://www.rfc-editor.org/errata/eid4983>,= I think RFC 2308 was
wrong in redefining QNAME. My personal preference would be to change
the second paragraph to "RFC 2308 proposed another definition,
different from the original one. Since it is actually a different
concept, it would be better to find another name for it. Here, QNAME
retains the original definition of RFC 1034."

 +1.

--
P Vixie


+1

-= -=C2=A0
Bob Harold

--001a11459990eafd760560a22256-- From nobody Mon Dec 18 11:16:58 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5CF12D80F for ; Mon, 18 Dec 2017 11:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 mVrMsRhjtipd for ; Mon, 18 Dec 2017 11:16:55 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 6029D1277BB for ; Mon, 18 Dec 2017 11:16:52 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 9585F28260F for ; Mon, 18 Dec 2017 20:16:50 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 8E23528267F; Mon, 18 Dec 2017 20:16:50 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 86DFF28260F for ; Mon, 18 Dec 2017 20:16:50 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 83F4A642C581 for ; Mon, 18 Dec 2017 20:16:50 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 7FF39401D5; Mon, 18 Dec 2017 20:16:50 +0100 (CET) Date: Mon, 18 Dec 2017 20:16:50 +0100 From: Stephane Bortzmeyer To: dnsop@ietf.Org Message-ID: <20171218191650.j5nq2gbfjuv335e2@nic.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="rvqn53dkjltvvjun" Content-Disposition: inline X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.18.190316 Archived-At: Subject: [DNSOP] [iesg-secretary@ietf.org: Results of IETF-conflict review for draft-klensin-dns-function-considerations-04] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 19:16:57 -0000 --rvqn53dkjltvvjun Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Probably relevant for this group. --rvqn53dkjltvvjun Content-Type: message/rfc822 Content-Disposition: inline Return-Path: ietf-announce-bounces@ietf.org Received: from hebe.prod-int.prive.th3.nic.fr [10.1.81.80] by b12.tech.prive.nic.fr with IMAP (fetchmail-6.3.26) for (single-drop); Mon, 18 Dec 2017 18:30:07 +0100 (CET) Received: from hebe.prod-int.prive.th3.nic.fr (LHLO zimbra.afnic.fr) (10.1.81.80) by zimbra.afnic.fr with LMTP; Mon, 18 Dec 2017 18:28:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra.afnic.fr (Postfix) with ESMTP id 1458F10C4013 for ; Mon, 18 Dec 2017 18:28:29 +0100 (CET) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at zimbra.afnic.fr X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-10 required=6.6 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_FAIL=0.001, TO_EQ_FM_DOM_SPF_FAIL=0.001] autolearn=no autolearn_force=no Authentication-Results: zimbra.afnic.fr (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org Received: from zimbra.afnic.fr ([127.0.0.1]) by localhost (zimbra.afnic.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5Rn2Pnq1JYQ for ; Mon, 18 Dec 2017 18:28:28 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [10.1.50.11]) by zimbra.afnic.fr (Postfix) with ESMTP id 29C4A10C4010 for ; Mon, 18 Dec 2017 18:28:27 +0100 (CET) Received: by relay01.prive.nic.fr (Postfix) id 79A56642354F; Mon, 18 Dec 2017 18:28:27 +0100 (CET) Delivered-To: bortzmeyer@nic.fr Received: from mx5.nic.fr (mx5.nic.fr [IPv6:2001:67c:2218:2::4:13]) by relay01.prive.nic.fr (Postfix) with ESMTP id 6BD6F642354A; Mon, 18 Dec 2017 18:28:27 +0100 (CET) Received: from mx5.nic.fr (localhost [127.0.0.1]) by mx5.nic.fr (Postfix) with SMTP id 5E1393001CD; Mon, 18 Dec 2017 18:28:27 +0100 (CET) Received: by mx5.nic.fr (Postfix, from userid 1137) id 307B93002D6; Mon, 18 Dec 2017 18:28:27 +0100 (CET) Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1900:3001:11::2c]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx5.nic.fr (Postfix) with ESMTPS id 03CA83001CD; Mon, 18 Dec 2017 18:28:27 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 062B812D84A; Mon, 18 Dec 2017 09:27:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1513618074; bh=N0RRVgawjl2Bj9IkhBX60HCr6QJPzS/QfBEdd+wWC+w=; h=From:To:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To:Cc; b=LRi5rRDNIsTLc6+bpR10eO7CatWLssTE/Wu9GzPBwrwvKGYntzzCZdLW7q2uGFZhS G8i4O5TBQU6OjojBUyQuh9QgRWGWF20klC/I9NB4/OPQ9Sz+kB30NSxBuQKqR4VT1d 3x7uggFaJPjOYl7HCwbGOvV9idQ+GUjrZEcxgnnU= X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58E9E12D82D; Mon, 18 Dec 2017 09:27:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Old-From: The IESG To: "Nevil Brownlee" , "Nevil Brownlee" , , , Old-Subject: Results of IETF-conflict review for draft-klensin-dns-function-considerations-04 X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151361806831.3487.9815864861213948518.idtracker@ietfa.amsl.com> Date: Mon, 18 Dec 2017 09:27:48 -0800 Archived-At: X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: ietf@ietf.org Cc: iana@iana.org, The IESG , IETF-Announce Errors-To: ietf-announce-bounces@ietf.org Sender: "IETF-Announce" X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.18.171816 X-PerlMx-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' MULTIPLE_RCPTS 0.1, REPLYTO_FROM_DIFF_ADDY 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1100_1199 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, CTYPE_X2 0, DATE_TZ_NA 0, DKIM_SIGNATURE 0, LEGITIMATE_SIGNS 0, MULTIPLE_REAL_RCPTS 0, URI_ENDS_IN_HTML 0, URI_WITH_PATH_ONLY 0, __ANY_URI 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FROM_DOMAIN_IN_ANY_CC1 0, __FROM_DOMAIN_IN_ANY_TO1 0, __FROM_DOMAIN_IN_RCPT 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_LIST_HEADER 0, __HAS_LIST_HELP 0, __HAS_LIST_ID 0, __HAS_LIST_SUBSCRIBE 0, __HAS_LIST_UNSUBSCRIBE 0, __HAS_MSGID 0, __HAS_REPLYTO 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __MULTIPLE_URI_TEXT 0, __NO_HTML_TAG_RAW 0, __REPLYTO_SAMEAS_FROM_DOMAIN 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NOT_IMG 0, __URI_NO_MAILTO 0, __URI_NS , __URI_WITH_PATH 0' X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Subject: Results of IETF-conflict review for draft-klensin-dns-function-considerations-04 From: The IESG The IESG has completed a review of draft-klensin-dns-function-considerations-04 consistent with RFC5742. The IESG has no problem with the publication of 'DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?' as an Informational RFC. The IESG has concluded that this work is related to IETF work done in many working groups, but this relationship does not prevent publishing. The IESG would also like the Independent Submissions Editor to review the comments in the datatracker related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. The IESG review is documented at: https://datatracker.ietf.org/doc/conflict-review-klensin-dns-function-considerations/ A URL of the reviewed Internet Draft is: https://datatracker.ietf.org/doc/draft-klensin-dns-function-considerations/ The process for such documents is described at https://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary --rvqn53dkjltvvjun-- From nobody Mon Dec 18 11:19:26 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD2F1277BB for ; Mon, 18 Dec 2017 11:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 gbfBlqSJCQTz for ; Mon, 18 Dec 2017 11:19:23 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9838512D84F for ; Mon, 18 Dec 2017 11:19:23 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 18 Dec 2017 11:19:21 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 18 Dec 2017 11:19:21 -0800 From: Edward Lewis To: Joe Abley , Larson Matt CC: dnsop WG , Paul Hoffman Thread-Topic: is the root special? (musings of an old timer) - was Re: [Ext] Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones Thread-Index: AQHTeDUbQ5CyLN7SgEuXfgIgGgxRCg== Date: Mon, 18 Dec 2017 19:19:21 +0000 Message-ID: <247B55A3-9708-4174-9FD6-6A59544DBD05@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.28.0.171108 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3596451560_819388510" MIME-Version: 1.0 Archived-At: Subject: [DNSOP] is the root special? (musings of an old timer) - was Re: [Ext] Re: Making draft-ietf-dnsop-kskroll-sentinel apply to all zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 19:19:25 -0000 --B_3596451560_819388510 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 12/15/17, 11:34, "DNSOP on behalf of Joe Abley" wrote: >That seems fair. I was definitely speaking from a set of personal assumptions without any data; it's certainly possible that non-root trust anchors are widely deployed, however much I haven't seen it. I have one confirmed TLD use of STD 69 (I asked them) and I suspect another does as well (I haven't asked but they do regularly revoke SEP's), this coming from years of steady observation of TLD zones. Of the SLD data I have, which is far less comprehensive and thus inconclusive, I don't see many revoked keys. (With revoked keys being an ingredient of STD 69's process.) But I'll offer that paucity, by its nature, is hard to measure. Nonetheless, no matter what is done for the DNS protocol, it's best if the protocol works the same for all nodes in the tree. Whether the secure entry point is the root or "example.com." or "something.deep.example.com.", we should define the protocol to function in the same manner. (To clear this up, because "my history" vs. "my current" caused confusion before - I'm seeing this a protocol engineer dating back to the time when DNSSEC was assembled [including the earliest opt-out "wars" where the temptation was so "special case" the TLD "com."], not as much as someone working for ICANN today.) And as much as there is one unique root on the global public Internet, there are multiple inter-networks in existence. Such networks also use DNS and also make use of general purpose DNS software. So, I'd really resist setting special rules for the root zone that are tied to how "we" operate. (We can be IANA as the operator of the root zone or we as those whose job is to collectively maintain the global public Internet.) So, I'd make no assumptions about familiarity between the secure entry point and the trust anchor databases. There's not even a way, in-band (to DNS), for a trust anchor operator to know if the secure entry point is honoring STD 69.) In fact, I'd surmise that one of the ingredients in the DNS's wild success and growth is that there's no feedback loop, with the protocol featuring anonymous, context-free sessions. Each time we try to fight that bit of nature, we find "it's hard." Doesn't mean it can't be done, but you're fighting "parental-guardian" nature. --B_3596451560_819388510 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR5gYJKoZIhvcNAQcCoIIR1zCCEdMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D68wggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjCCBk4wggU2oAMCAQIC EASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAwMFoXDTI4MTEwNTEy MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENB MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/AJ3kbLQWHohBDMd8O 1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+yTU7VvEffEJ+ JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo8Ymvzf9e /1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYhrTg8 E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAO BgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwIC MIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBp AGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBl ACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBk ACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5 ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8lAvZP3Q5STI8inkw HwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQADggEBAE7U iSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZpgeafBMn2+UC ooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxIEM4zaHvN k6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaBVUCO Zu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3MIICn6ADAgECAhAM 5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQK EwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAw MDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3 dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq 9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii 72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PW w25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqi uhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn 8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0 ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy 5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU 5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58B BZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJG YIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD +cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMG A1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQD ExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEATrh/G0WNLYN1Xwl+i6gVIwCQYFKw4D AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRE+WlnlC5gGpujt9wuk9IiwKqQAjAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEyMTgxOTE5MjBaMA0GCSqGSIb3 DQEBAQUABIIBABuyfRvicm7esa/ajO9LktHq4Abfth5YCNkGxhDAZPl30If+FMjoYVrApoFo LgRP5GOm0fbgvuhuFZTAA2JmW4QCUNLzw4rrXxL0ycPr0q5gI4HDD6+iFJ+G1PiaMc6UfV+y Nf/65P1d0t9WDLYjLjmuwvTf+O65a1KQcHlv8bn7m01IImaArU3oVq95nBqZ4K5bKPmU2vL3 3T9hTtTaNB4Eew+kEiAgkFha32KvaDrVdZiqlsz5uFo2YSXxYSJN+jPMPmd61mQ0g2+ShK05 YvMWBIKUOrw92mIBFBgOjM9He+F2TT9Zv16lgIdjraTdXzRw2PB7kdbtoH9JTsKgtr8= --B_3596451560_819388510-- From nobody Mon Dec 18 11:31:20 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2917E1277BB for ; Mon, 18 Dec 2017 11:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rorAO3e000DC for ; Mon, 18 Dec 2017 11:31:16 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 9DD01126CF6 for ; Mon, 18 Dec 2017 11:31:16 -0800 (PST) Received: from [10.32.60.159] (96-82-124-54-static.hfc.comcastbusiness.net [96.82.124.54]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id vBIJVAiR088753 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Dec 2017 12:31:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 96-82-124-54-static.hfc.comcastbusiness.net [96.82.124.54] claimed to be [10.32.60.159] From: "Paul Hoffman" To: "Stephane Bortzmeyer" Cc: dnsop@ietf.Org Date: Mon, 18 Dec 2017 11:31:11 -0800 X-Mailer: MailMate (1.10r5443) Message-ID: <902EAAA3-81C5-4FAB-A00C-1A810C9B5951@vpnc.org> In-Reply-To: <20171218191650.j5nq2gbfjuv335e2@nic.fr> References: <20171218191650.j5nq2gbfjuv335e2@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [DNSOP] [iesg-secretary@ietf.org: Results of IETF-conflict review for draft-klensin-dns-function-considerations-04] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 19:31:18 -0000 On 18 Dec 2017, at 11:16, Stephane Bortzmeyer wrote: > Probably relevant for this group. Surprisingly not. An IETF-conflict review is just the IESG's way of giving input on a document that the Independent Submissions Editor (ISE) might publish in the future. Having said that, if anyone has comments on the document that you feel that the ISE should consider before publishing it, the ISE generally likes to hear them. You can send them to rfc-ise@rfc-editor.org. FWIW, all the documents that the ISE is considering can be found at . More about the ISE's role can be found at . --Paul Hoffman From nobody Mon Dec 18 12:22:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BF112D853 for ; Mon, 18 Dec 2017 12:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4poq2Px_S-jK for ; Mon, 18 Dec 2017 12:22:18 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C6E124239 for ; Mon, 18 Dec 2017 12:22:13 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 18 Dec 2017 12:22:11 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 18 Dec 2017 12:22:11 -0800 From: Richard Lamb To: Paul Hoffman , Stephane Bortzmeyer CC: "dnsop@ietf.Org" Thread-Topic: [DNSOP] [iesg-secretary@ietf.org: Results of IETF-conflict review for draft-klensin-dns-function-considerations-04] Thread-Index: AQHTeDTIePLElzA4cUewBjcno+HkOaNKAzeA//+HlNA= Date: Mon, 18 Dec 2017 20:22:11 +0000 Message-ID: References: <20171218191650.j5nq2gbfjuv335e2@nic.fr> <902EAAA3-81C5-4FAB-A00C-1A810C9B5951@vpnc.org> In-Reply-To: <902EAAA3-81C5-4FAB-A00C-1A810C9B5951@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [iesg-secretary@ietf.org: Results of IETF-conflict review for draft-klensin-dns-function-considerations-04] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 20:22:20 -0000 Thanks for calming fears. With "..document asks the question of whether it= is time to either redesign and replace the DNS.." in the abstract of a doc= by Klensin, I was a bit worried. -Rick > -----Original Message----- > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Paul Hoffman > Sent: Monday, December 18, 2017 11:31 AM > To: Stephane Bortzmeyer > Cc: dnsop@ietf.Org > Subject: Re: [DNSOP] [iesg-secretary@ietf.org: Results of IETF-conflict r= eview > for draft-klensin-dns-function-considerations-04] >=20 > On 18 Dec 2017, at 11:16, Stephane Bortzmeyer wrote: >=20 > > Probably relevant for this group. >=20 > Surprisingly not. An IETF-conflict review is just the IESG's way of givin= g input > on a document that the Independent Submissions Editor (ISE) might publish > in the future. >=20 > Having said that, if anyone has comments on the document that you feel > that the ISE should consider before publishing it, the ISE generally like= s to > hear them. You can send them to rfc-ise@rfc-editor.org. >=20 > FWIW, all the documents that the ISE is considering can be found at > . More about the ISE's role can= be > found at . >=20 > --Paul Hoffman >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Mon Dec 18 12:28:11 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE0112D876 for ; Mon, 18 Dec 2017 12:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlV3pgEionbY for ; Mon, 18 Dec 2017 12:28:09 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (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 3227312D86B for ; Mon, 18 Dec 2017 12:28:09 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 7C86831CBA; Mon, 18 Dec 2017 21:28:06 +0100 (CET) Received: by mail.sources.org (Postfix, from userid 1000) id EBF40190888; Mon, 18 Dec 2017 21:23:11 +0100 (CET) Date: Mon, 18 Dec 2017 21:23:11 +0100 From: Stephane Bortzmeyer To: Paul Hoffman Cc: Stephane Bortzmeyer , dnsop@ietf.Org Message-ID: <20171218202311.expokhek6vpytdpo@sources.org> References: <20171218191650.j5nq2gbfjuv335e2@nic.fr> <902EAAA3-81C5-4FAB-A00C-1A810C9B5951@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <902EAAA3-81C5-4FAB-A00C-1A810C9B5951@vpnc.org> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 9.1 X-Charlie: Je suis Charlie User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [DNSOP] [iesg-secretary@ietf.org: Results of IETF-conflict review for draft-klensin-dns-function-considerations-04] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 20:28:10 -0000 On Mon, Dec 18, 2017 at 11:31:11AM -0800, Paul Hoffman wrote a message of 17 lines which said: > > Probably relevant for this group. > > Surprisingly not. An IETF-conflict review is just the IESG's way of > giving input on a document that the Independent Submissions Editor > (ISE) might publish in the future. When I said "relevant", I was not speaking of the IETF-conflict review but of the document itself, which will probably be of interest for people here. From nobody Mon Dec 18 13:23:16 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C796F12D946 for ; Mon, 18 Dec 2017 13:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 ALvnuKAAMnky for ; Mon, 18 Dec 2017 13:23:12 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 B180E12D950 for ; Mon, 18 Dec 2017 13:23:11 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id n138so390726wmg.2 for ; Mon, 18 Dec 2017 13:23:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yfewT0GBaCPzN2KetNStOvzrx0bf/VFz1Uxz3LWrMjs=; b=cghAHTXZ8vOcJbMEabM9FxepCKYSbdnDNB9E75H6YIvv9vCHP+YN8AyBL5W012tYw8 7eD6j+nhSEXC2BTIgdxo/fE34fP/93wLZmgHxdpt+PvOTisdUfPnnTnEBOXBOTPMsrGh 7fnwjSEj+jxQmmvNU4vGsJH85sm6vWN/oIgdHpVQf4Qhsbzb03S3H+aaeyA9f+MPCW97 sWXQcSTTJ1/p8ggCcZnqSWdA5eS+JJcR4dYhfVUa6jlFeKMRD7grMznLpF6Suiyxb+Bu ylIIlm1DlAV3KJefqRJEkgeOEwmxH8SqIZM0a78qxiIMR+7Vd3YSF8iWU4kb8O1wVohx e49A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yfewT0GBaCPzN2KetNStOvzrx0bf/VFz1Uxz3LWrMjs=; b=gdnnDmMrvODwQpg5XzMwsoGo0xXpTY5USnT1KFJ/VPrFIiOLfwkBCzXvnMuY9yV3Ua Uyfe9a0ooE4mxRXj6nOtpn2Ny8cT0MTzUlhp3VvO0iainmDgMDiqNO54c19fn5fcfB+n eDqr5zNRsZ230cS+Y4EGuwns21plEJNnf4kDu8iQtJL+60NHtRLmbDqu7X/OVtjKazfE mOV0dYrtijTpPb47bFvoNv3hq7wCr4ZKEd70lhcshLKOXLsFv0KKPI6byXlIEpa77pM9 +5ivfEpD9YAcMHU4t2z2/6N9BKiB7D0fxqbQQYbwFPvUn/m5AJ4ARkH4EtQA0o2wJSc5 XVdg== X-Gm-Message-State: AKGB3mIEiWd0AcbxxBL5gdHazHvNwo2iSa8Q5jpBHdfeXCGgNf81q33Y zfJLf+WlTWJiy5292OwHUWZELCb7XO1WSNXsCvTixQ== X-Google-Smtp-Source: ACJfBoviyGNGWFtGkYpVIKLMd7NGx73oMZUG6rHGAjEicHDU1wvQi/mVkJCsYMq8dyy0yK4QO3eDl/Ai/cRiFE3kJyI= X-Received: by 10.28.207.130 with SMTP id f124mr593665wmg.132.1513632189836; Mon, 18 Dec 2017 13:23:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.149 with HTTP; Mon, 18 Dec 2017 13:22:29 -0800 (PST) In-Reply-To: <20171218202311.expokhek6vpytdpo@sources.org> References: <20171218191650.j5nq2gbfjuv335e2@nic.fr> <902EAAA3-81C5-4FAB-A00C-1A810C9B5951@vpnc.org> <20171218202311.expokhek6vpytdpo@sources.org> From: Warren Kumari Date: Mon, 18 Dec 2017 16:22:29 -0500 Message-ID: To: Stephane Bortzmeyer Cc: Paul Hoffman , dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] [iesg-secretary@ietf.org: Results of IETF-conflict review for draft-klensin-dns-function-considerations-04] X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2017 21:23:15 -0000 On Mon, Dec 18, 2017 at 3:23 PM, Stephane Bortzmeyer wrote: > On Mon, Dec 18, 2017 at 11:31:11AM -0800, > Paul Hoffman wrote > a message of 17 lines which said: > >> > Probably relevant for this group. >> >> Surprisingly not. An IETF-conflict review is just the IESG's way of >> giving input on a document that the Independent Submissions Editor >> (ISE) might publish in the future. > > When I said "relevant", I was not speaking of the IETF-conflict review > but of the document itself, which will probably be of interest for > people here. > Yup -- I personally thought that this was a good read, and contained a bunch of useful background. For those readers who think if feels strangely familiar (from early June 2017): https://mailarchive.ietf.org/arch/search/?email_list=dnsop&q=What+can+be+done+with+the+DNS+and+what+should+be+done+elsewhere+%5Bdraft-klensin-dns-function-considerations%5D W > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Dec 18 17:55:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5F3127863 for ; Mon, 18 Dec 2017 17:55:20 -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] 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 k9blq-40z4ZX for ; Mon, 18 Dec 2017 17:55:20 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 005151201FA for ; Mon, 18 Dec 2017 17:55:19 -0800 (PST) Received: from [10.32.60.159] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id vBJ1tFNi094962 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 18 Dec 2017 18:55:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.159] From: "Paul Hoffman" To: dnsop@ietf.org Date: Mon, 18 Dec 2017 17:55:17 -0800 X-Mailer: MailMate (1.10r5443) Message-ID: In-Reply-To: <20171218134427.4przwtuy3o2jsrm7@nic.fr> References: <56BEBCFA-D6BA-4BD1-8B95-190375A57C06@isc.org> <20171213.204234.76214525553211985.fujiwara@jprs.co.jp> <20171215.113000.152427157235084555.fujiwara@jprs.co.jp> <20171218134427.4przwtuy3o2jsrm7@nic.fr> MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 01:55:21 -0000 Thanks for the input. This is now slated for the next version of the draft. --Paul Hoffman From nobody Mon Dec 18 18:56:28 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7151270AB for ; Mon, 18 Dec 2017 18:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 zlULGQ-OlwWS for ; Mon, 18 Dec 2017 18:56:25 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 C4336127137 for ; Mon, 18 Dec 2017 18:56:25 -0800 (PST) Received: from grisu.home.partim.org (unknown [84.245.51.209]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 49C6A8322 for ; Tue, 19 Dec 2017 03:56:23 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=opennetlabs.com Date: Tue, 19 Dec 2017 03:56:22 +0100 From: Martin Hoffmann To: dnsop WG Message-ID: <20171219035622.414457a1@grisu.home.partim.org> In-Reply-To: <20171218132446.w7o5x4mrz2ttprlb@nic.fr> References: <707A270D-94DA-4651-84DC-409FAA6793F7@vpnc.org> <20171218132446.w7o5x4mrz2ttprlb@nic.fr> Organization: Open Netlabs X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 02:56:27 -0000 Stephane Bortzmeyer wrote: > On Mon, Dec 04, 2017 at 10:27:32AM -0800, > Paul Hoffman wrote > a message of 28 lines which said: > > > - In-bailiwick > > - Out-of-bailiwick > > The current definition is restrictive: it mentions only name servers. > > IMHO, "in-bailiwick" could be said for any domain name, even if it has > less practical consequences than for name servers. For instance, > www.toto.fr is in-bailiwick for .fr. So a domain name would be in-bailiwick with regards to a given zone if it is part of that zone or any of its child zones? > > - In-domain > > - Sibling domain > > I tend to think it would be better to drop these two terms. I find > them rarely used and they don't seem to bring much value. They do make it clear whether glue records are necessary, which is useful. "Sibling domain" seems to also include the case where the name server is part of the parent zone which is un-intuitive but also probably rare enough to not warrant a separate term. One option would be to only define "in-domain" as a special case of "in-bailiwick" that needs special treatment? Kind regards, Martin From nobody Mon Dec 18 19:20:21 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CB01273E2 for ; Mon, 18 Dec 2017 19:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.878 X-Spam-Level: X-Spam-Status: No, score=-5.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, 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 SX6bwDyDSyW5 for ; Mon, 18 Dec 2017 19:20:18 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 DDB33127342 for ; Mon, 18 Dec 2017 19:20:17 -0800 (PST) Received: from grisu.home.partim.org (unknown [84.245.51.209]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 96C088379 for ; Tue, 19 Dec 2017 04:20:15 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=opennetlabs.com Date: Tue, 19 Dec 2017 04:20:14 +0100 From: Martin Hoffmann Cc: dnsop@ietf.org Message-ID: <20171219042014.390cbfd7@grisu.home.partim.org> In-Reply-To: <20171218141112.56cxoc5nvt3wlsdf@nic.fr> References: <20171130133600.447a2904@grisu.home.partim.org> <20171218141112.56cxoc5nvt3wlsdf@nic.fr> Organization: Open Netlabs X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 03:20:19 -0000 Stephane Bortzmeyer wrote: > On Thu, Nov 30, 2017 at 01:36:00PM +0100, > Martin Hoffmann wrote=20 > a message of 297 lines which said: >=20 > > GLOBAL DNS -- FORMAT OF NAMES > >=20 > > | Names in the common display format are normally written such that > > the | directionality of the writing system presents labels by > > decreasing | distance from the root (so, in both English and C the > > first label in the | ordered list is right-most; but in Arabic it > > may be left-most, depending | on local conventions). > >=20 > > The first sentence makes it sound as if right-to-left languages > > would normally write =E2=80=98com.example=E2=80=99 which is not the cas= e. =20 >=20 > BiDI is complicated enough so I suggest we keep only examples where > the script of the domain name is the same as the parent script. This > way, sentences like "The TLD is at the end" are always true. Writing a > latin domain name in arabic is left as an exercice for the reader :-) RFC 5893 cleverly declares a "network order" and for it only speaks in terms such as "previous" and "next" with regards to the order of octets on the wire. This avoids the need for using left and right entirely even though it is clear to a reader that "example" is previous to "com" when written as "example.com". That said, there seems to be a mistake in the text for the common display format: | so, in both English and C the first label in the ordered list is | right-most Previously this list was defined as being "ordered ordered by decreasing distance from the root" which would make the first labal in this list to be the left-most label in English. > > under these circumstances the name will always be in the =E2=80=98usual= =E2=80=99 > > order. =20 >=20 > I challenge this assumption. After all, numbers in arabic are > sometimes big-endian and sometimes little-endian (depending on wether > you are in the Middle-East or in North Africa). I wouldn=E2=80=99t dare claim to understand the Unicode Bidi Algorithm, but= it seems to me that with the somewhat academic exception of names not containing any ASCII letters and ignoring any shenanigans with explicit overrides, domain names in common display format (that is, before any possible IDNA processing) would always end up as a single left-to-right run.=20 Kind regards, Martin From nobody Mon Dec 18 23:14:36 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252EA126C19 for ; Mon, 18 Dec 2017 23:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 LR71WvA9KJ_V for ; Mon, 18 Dec 2017 23:14:32 -0800 (PST) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 80416124D68 for ; Mon, 18 Dec 2017 23:14:32 -0800 (PST) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.21/8.16.0.21) with SMTP id vBJ7Bi9S002235; Tue, 19 Dec 2017 07:14:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=corp-2017-10-26; bh=sRSig0DWixC6hj74gRx85otCwgQ4RWlQ0kxSXIzreu4=; b=fgBpTZ/DTENzPEW775+MOajtEsEY8QODET493l3jwYGIXEwAdAaSeNmHoES1cuRTDPcP pJb7mqUrUNH4gcq0BdaGD1TLlgzcCjQcrhfQC2+YDdZlGG/R/QgfO3NW2Ldpq7TDiN1b Ls9jyojtWGFeLLMXMdWEYTmP7VkSqER7vcbWAr2azz3sSQhOVahtuYGkPKjZuI7ANFQd ZbxiyvRmCJePtM0P0EfPlvWJ8xnPSGCiQYI5cTOTLLeT/bZk+/Ggjzb2uxfX9tmkzLiW lmhECQPJjAfPXeJsKZHUoFu/3KNIvluN0nkKIjh3s7M6t4+1YKJdedRbQaHcagJfCmJT eQ== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2exx0381g8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 19 Dec 2017 07:14:31 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vBJ79TGO030091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 19 Dec 2017 07:09:30 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vBJ79TK4025167; Tue, 19 Dec 2017 07:09:29 GMT Received: from [172.19.129.26] (/216.146.45.33) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 18 Dec 2017 23:09:29 -0800 To: Martin Hoffmann Cc: dnsop@ietf.org References: <20171130133600.447a2904@grisu.home.partim.org> <20171218141112.56cxoc5nvt3wlsdf@nic.fr> <20171219042014.390cbfd7@grisu.home.partim.org> From: Richard Gibson Message-ID: <95695b68-9506-1ab3-ae1a-f2c1f780ed69@oracle.com> Date: Tue, 19 Dec 2017 02:09:28 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171219042014.390cbfd7@grisu.home.partim.org> Content-Type: multipart/alternative; boundary="------------E186BAE3C03B677A4A15317D" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8749 signatures=668649 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=593 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712190106 Archived-At: Subject: Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 07:14:34 -0000 This is a multi-part message in MIME format. --------------E186BAE3C03B677A4A15317D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/18/2017 10:20 PM, Martin Hoffmann wrote: > That said, there seems to be a mistake in the text for the common > display format: > > | so, in both English and C the first label in the ordered list is > | right-most > > Previously this list was defined as being "ordered ordered by > decreasing distance from the root" which would make the first labal in > this list to be the left-most label in English. Hmmm. 1. "Domain name" is defined as «an ordered list of one or more labels… identifying a portion along one edge of a directed acyclic graph» (presumably starting at the root). 2. In "Global DNS", "Composition of names" relies upon that same order: «in a fully-qualified domain name, the first label in the ordered list is 0 octets long… it is called the "root" or "root label"». 3. But then in "Format of names", the opposite order is specified: «The basic wire format for names in the global DNS is a list of labels /ordered by //*decreasing*//distance from the root/, with the root label last» and «The presentation format for names in the global DNS is a list of labels /ordered by *decreasing* distance from the root/» (emphasis mine) and «The common display format… is the same as the presentation format… in both English and C the first label in the ordered list is right-most». It makes sense if that last "ordered list" is the one from "Domain name" and "Composition of names", but not if it is the one from "presentation format", which I guess is the problem. The initial graph-theoretic definition is accurate, but suggests (although notably does not require) an order backwards with respect to all three name formats. Perhaps everything would be more clear if those issues were eliminated right up front: «given a directed acyclic graph in which no node has in-degree greater than one, a domain name is a list of labels identifying a path in reverse (i.e., against the direction of the edges)» (the restriction on in-degree precluding child-to-parent directionality). For global DNS, the labels would then /always/ be ordered by decreasing distance from the root, hopefully eliminating confusion about how they appear in text or on the wire. --------------E186BAE3C03B677A4A15317D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 12/18/2017 10:20 PM, Martin Hoffmann wrote:
That said, there seems to be a mistake in the text for the common
display format:

| so, in both English and C the first label in the ordered list is
| right-most

Previously this list was defined as being "ordered ordered by
decreasing distance from the root" which would make the first labal in
this list to be the left-most label in English.
Hmmm.
1. "Domain name" is defined as «an ordered list of one or more labels… identifying a portion along one edge of a directed acyclic graph» (presumably starting at the root).
2. In "Global DNS", "Composition of names" relies upon that same order: «in a fully-qualified domain name, the first label in the ordered list is 0 octets long… it is called the "root" or "root label"».
3. But then in "Format of names", the opposite order is specified: «The basic wire format for names in the global DNS is a list of labels ordered by decreasing distance from the root, with the root label last» and «The presentation format for names in the global DNS is a list of labels ordered by decreasing distance from the root» (emphasis mine) and «The common display format… is the same as the presentation format… in both English and C the first label in the ordered list is right-most». It makes sense if that last "ordered list" is the one from "Domain name" and "Composition of names", but not if it is the one from "presentation format", which I guess is the problem.

The initial graph-theoretic definition is accurate, but suggests (although notably does not require) an order backwards with respect to all three name formats. Perhaps everything would be more clear if those issues were eliminated right up front: «given a directed acyclic graph in which no node has in-degree greater than one, a domain name is a list of labels identifying a path in reverse (i.e., against the direction of the edges)» (the restriction on in-degree precluding child-to-parent directionality). For global DNS, the labels would then always be ordered by decreasing distance from the root, hopefully eliminating confusion about how they appear in text or on the wire.
--------------E186BAE3C03B677A4A15317D-- From nobody Tue Dec 19 01:13:24 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A891201F2 for ; Tue, 19 Dec 2017 01:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, 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 CxHIzUvitXFi for ; Tue, 19 Dec 2017 01:13:20 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 94B0212421A for ; Tue, 19 Dec 2017 01:13:20 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id CE77028288F; Tue, 19 Dec 2017 10:13:18 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id C89B0282A42; Tue, 19 Dec 2017 10:13:18 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id C219C28288F; Tue, 19 Dec 2017 10:13:18 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id BF2F0642C581; Tue, 19 Dec 2017 10:13:18 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id B8A7B401D4; Tue, 19 Dec 2017 10:13:18 +0100 (CET) Date: Tue, 19 Dec 2017 10:13:18 +0100 From: Stephane Bortzmeyer To: Martin Hoffmann Cc: dnsop WG Message-ID: <20171219091318.zugag6shf5vrairy@nic.fr> References: <707A270D-94DA-4651-84DC-409FAA6793F7@vpnc.org> <20171218132446.w7o5x4mrz2ttprlb@nic.fr> <20171219035622.414457a1@grisu.home.partim.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171219035622.414457a1@grisu.home.partim.org> X-Operating-System: Debian GNU/Linux 9.2 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000124, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.19.90316 Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 09:13:23 -0000 On Tue, Dec 19, 2017 at 03:56:22AM +0100, Martin Hoffmann wrote a message of 38 lines which said: > > The current definition is restrictive: it mentions only name servers. > > > > IMHO, "in-bailiwick" could be said for any domain name, even if it has > > less practical consequences than for name servers. For instance, > > www.toto.fr is in-bailiwick for .fr. > > So a domain name would be in-bailiwick with regards to a given zone if > it is part of that zone or any of its child zones? Yes. Practical consequences: an authoritative name server can reply NOERROR or NXDOMAIN if and only if the name is in-bailiwick. And REFUSED (or may be SERVFAIL) otherwise. From nobody Tue Dec 19 01:59:03 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B01212421A for ; Tue, 19 Dec 2017 01:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 FVbfX7t18efw for ; Tue, 19 Dec 2017 01:58:59 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 9454712D94D for ; Tue, 19 Dec 2017 01:58:59 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id d137so2130253itc.2 for ; Tue, 19 Dec 2017 01:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=fycPUzutpL5xAuORJkyp9mIH6jl+XiSxgx8rcGyZkpg=; b=DbOopzVem3DI4bE8m5pOMyqJl34fxLP4TIlO7pogqy2+dhYk3Qju0kDY9EK10bqezs gnaNkDu5QNeoZXwzod1mEqLVSFveWevJYqjqDBmTunX/+kxOelSM8221jcUe2/fT+guW CpbRZ0IBRGOCI7kuoiQN1DJRsOFNEAVmyymhl/R6MWqmPzCJJp8pTgeqPDTHc0Op2cZs iY0TxzgDNiVxFNyNKcAeqXu5vtb+/RWN4FYHJWo4bt5l2k/oWmGisFGVxvQrHZkdGkwB PWvYAiDix0wj5RrYOQugzwqFMdgD17LUTR3buJFIjSOttJPwqYBCwThjsU0hMwkHaWlg vdGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=fycPUzutpL5xAuORJkyp9mIH6jl+XiSxgx8rcGyZkpg=; b=l47PV+IT2vMfhoPjvb3+z4osz8ApcHxLSlC5N4I+7Cd3P26qiItu3RGnq+75tc833M kldUGB/odGbkcHxKVBbpHskfsmeGcDJk8KBQvdpuLjWslf+mXQFcKqK0fqquL80/NVcU jEWPb6ujCTiMBuFkv9AcR7THXo4WWllj+0sVws/dvL05NvKOFjnSsOy1IWy6h2ZFHs+a VRLoescii1j3zhXUBc4YP/CZpfX+mEuFcU1EZTXTMCFOi6jfXqQudvRttN200gHfDjLT wSxNtzjFNzxj5q+zH5SlqDQA0T767izAvp76pLd4XAz4R1qjeSSaD47xBXXM3kQisnkA ZcIQ== X-Gm-Message-State: AKGB3mKk3BRBIIfhwNY9uu7rksJ0WW8HS7SDKMhJE/I4IOeqchSzrjVI fBZAoiZ+JQGH2ccbAGbLuS5Ddg72UI6X/h6+jAJWMFah X-Google-Smtp-Source: ACJfBosJKArZmW80OfSLyeuRDUvHhai1zfMGHaY7yBGkmzeNkru06E5nRdH/EBrp01xYVUVkwQdbaDSKRXh4lpgwDfM= X-Received: by 10.36.189.205 with SMTP id x196mr2493226ite.152.1513677538482; Tue, 19 Dec 2017 01:58:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.15.71 with HTTP; Tue, 19 Dec 2017 01:58:57 -0800 (PST) In-Reply-To: References: From: Tariq Saraj Date: Tue, 19 Dec 2017 14:58:57 +0500 Message-ID: To: dnsop@ietf.org, Stephane Bortzmeyer Content-Type: multipart/alternative; boundary="94eb2c19dd02fc5f680560ae8351" Archived-At: Subject: Re: [DNSOP] DNSOP Digest, Vol 132, Issue 53 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 09:59:03 -0000 --94eb2c19dd02fc5f680560ae8351 Content-Type: text/plain; charset="UTF-8" >The only use case you describe (firewall configuration) is >questionable. This is just a single use case, there can be a number of implementations for IPv4 to IPv6 and vice versa resolution. As I have faced the problem during development of writing automation service, thus i discuss this use case to support the requiremnet of the proposed resource record. >Most firewall configuration interfaces allow you to use >domain names instead of IP addresses. So, if I want to allow port 443 >to www.example.com (which has IPv4 and IP v6 addresses), I can. Note >that many firewall administrators don't use this because, rightly or >wrongly, they don't trust the DNS. They'll have the same issue with >your proposal. using a firewall based on domain names can be simply bypassed by accessing websites through IP address. We have experienced this scenario here in Pakistan when the Government restrict access to youtube, but people were still able to access it through the IP address. Second, there are some firewalls such as Cisco and Kaspersky that handle this situation when someone configure a firewall rule based on domain name, it automatically resolves the IPv4 and IPv6 addresses for that domain and update the firewall rules so that it cannot be bypassed through accessing a server through IP based. But, these are highly expensive firewalls and normally not affordable for every organization. >By the way, that's why you _need_ to write something in the Security >Considerations, probably mentioning DNSSEC. Yes agreed, I will discuss it in that perspective. On Mon, Nov 27, 2017 at 10:58 PM, wrote: > Send DNSOP mailing list submissions to > dnsop@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/dnsop > or, via email, send a message with subject or body 'help' to > dnsop-request@ietf.org > > You can reach the person managing the list at > dnsop-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DNSOP digest..." > > > Today's Topics: > > 1. Re: IVIPTR: New RR for DNS (Stephane Bortzmeyer) > 2. Re: IVIPTR: New RR for DNS (Stephane Bortzmeyer) > 3. Re: Terminology: "primary master" (Joe Abley) > 4. Re: Terminology: "primary master" (Tony Finch) > 5. I-D Action: draft-ietf-dnsop-terminology-bis-08.txt > (internet-drafts@ietf.org) > 6. Re: I-D Action: draft-ietf-dnsop-terminology-bis-08.txt > (Paul Hoffman) > 7. Re: [v6ops] New Version Notification for > draft-palet-sunset4-ipv6-ready-dns-00.txt (Gert Doering) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 27 Nov 2017 15:27:39 +0100 > From: Stephane Bortzmeyer > To: Tony Finch > Cc: bert hubert , Tariq Saraj > , dnsop@ietf.org > Subject: Re: [DNSOP] IVIPTR: New RR for DNS > Message-ID: <20171127142739.3a3w6yv5wsje5m4y@nic.fr> > Content-Type: text/plain; charset=us-ascii > > On Mon, Nov 27, 2017 at 01:38:08PM +0000, > Tony Finch wrote > a message of 24 lines which said: > > > Why not > > Section 1 of the draft explains "why not" but I disagree with their > assessment. I think the PTR way is indeed the right one. > > > > ------------------------------ > > Message: 2 > Date: Mon, 27 Nov 2017 15:45:15 +0100 > From: Stephane Bortzmeyer > To: Tariq Saraj > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] IVIPTR: New RR for DNS > Message-ID: <20171127144515.4ol63kkaptnwmemn@nic.fr> > Content-Type: text/plain; charset=us-ascii > > On Sat, Nov 25, 2017 at 10:41:13PM +0500, > Tariq Saraj wrote > a message of 60 lines which said: > > > Please provide your valuable feedback on the newly uploaded draft. > > draft-tariq-dnsop-iviptr-00 > > > > *IVIPTR: Resource Record for DNS* > > The only use case you describe (firewall configuration) is > questionable. Most firewall configuration interfaces allow you to use > domain names instead of IP addresses. So, if I want to allow port 443 > to www.example.com (which has IPv4 and IP v6 addresses), I can. Note > that many firewall administrators don't use this because, rightly or > wrongly, they don't trust the DNS. They'll have the same issue with > your proposal. > > By the way, that's why you _need_ to write something in the Security > Considerations, probably mentioning DNSSEC. > > Otherwise, I'm not convinced by your argument against using PTR. If > people don't configure PTRs to get the effect you want, it may be because: > > * they don't want to (so they don't need your proposal) > * they're lazy or incompetent (so they'll ignore your proposal) > > > > ------------------------------ > > Message: 3 > Date: Mon, 27 Nov 2017 11:34:11 -0500 > From: Joe Abley > To: Tony Finch > Cc: "dnsop@ietf.org" , Havard Eidnes > Subject: Re: [DNSOP] Terminology: "primary master" > Message-ID: <180576EC-BC7C-47E1-B3F1-87062260C018@hopcount.ca> > Content-Type: text/plain; charset=us-ascii > > Hi Tony, > > On Nov 27, 2017, at 08:22, Tony Finch wrote: > > > Joe Abley wrote: > >>> On Nov 23, 2017, at 12:44, Tony Finch wrote: > >>> > >>> It's quite difficult to have multiple masters and DNSSEC and coherent > >>> copies of the zone from all masters - i.e. more effort than just > spinning > >>> up parallel instances of BIND or Knot in automatic signing mode. > >> > >> Note that I wasn't talking about multiple signers; I was talking about > >> (from the perspective of one particular slave) having multiple masters > >> available to serve precisely the same zone. > > > > A primary master is wrt a zone not a server - a zone's primary master is > > a server that's authoritative for a zone and which does not get the zone > > contents via axfr/ixfr, but instead from a master file and/or UPDATE (or > > a non-standard mechanism such as directly from a database). > > That's an alluringly clear definition, but I'm not sure it matches common > understanding of the term, which I think has more to do with "single source > of truth" than with the specifics of what transport is used to provision > zone data in a server. > > For example, > > W <------- A -------> X > > Suppose A is a source of truth for a particular zone, and that W and X > obtain zone data from A. Are you saying that if the mechanism represented > by the arrows is [AI]XFR then A is a primary master and W and X are not, > whereas if that mechanism is something else (perhaps it's rsync, with W, A > and X all configured to be masters from local zone files) then W, A and X > are all primary masters? > > If A is not a nameserver but instead is a database, and the arrows > represent database replication, then W and X are primary masters but A is > not? > > > Joe > > > ------------------------------ > > Message: 4 > Date: Mon, 27 Nov 2017 17:15:17 +0000 > From: Tony Finch > To: Joe Abley > Cc: "dnsop@ietf.org" , Havard Eidnes > Subject: Re: [DNSOP] Terminology: "primary master" > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Joe Abley wrote: > > > > A primary master is wrt a zone not a server - a zone's primary master > is > > > a server that's authoritative for a zone and which does not get the > zone > > > contents via axfr/ixfr, but instead from a master file and/or UPDATE > (or > > > a non-standard mechanism such as directly from a database). > > > > That's an alluringly clear definition, but I'm not sure it matches > > common understanding of the term, which I think has more to do with > > "single source of truth" than with the specifics of what transport is > > used to provision zone data in a server. > > Hmm, I think I sort-of agree, but with caveats... > > I prefer to make a clear distinction between the standard DNS as specified > in the RFCs versus any funky non-standard stuff that people might do with > the DNS. > > The standard DNS protocols are closely fitted to a particular distributed > architecture, in which a zone has a single source of truth that we call > the primary master. You can, of course, implement a similar architecture > using non-standard protocols, but if you do you should take care to make > it clear how you are diverging from the standard - and be careful about > how you use standard DNS terminology when talking about your non-standard > system. > > > For example, > > > > W <------- A -------> X > > > > Suppose A is a source of truth for a particular zone, and that W and X > > obtain zone data from A. Are you saying that if the mechanism > > represented by the arrows is [AI]XFR then A is a primary master and W > > and X are not, whereas if that mechanism is something else (perhaps it's > > rsync, with W, A and X all configured to be masters from local zone > > files) then W, A and X are all primary masters? > > In this case I would say A is a primary master and W and X are secondaries > that use rsync instead of standard zone transfers. > > The part of the standard architecture that you have replaced is the zone > transfer mechanism, so the primary master is architecturally unaffected, > so it's OK to use the same name. > > (But you can't call rsync "ixfr" even though it is incrementally > transferring zones, because that would be unreasonably confusing.) > > > If A is not a nameserver but instead is a database, and the arrows > > represent database replication, then W and X are primary masters but A > > is not? > > In this case I would be very proud of my high-availability multi-master > system. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ - I xn--zr8h > punycode > Shannon, Rockall, Malin, Hebrides, Bailey: North or northwest 5 to 7, > occasionally gale 8 except in Shannon. Rough or very rough, occasionally > moderate. Squally showers. Good. > > > > ------------------------------ > > Message: 5 > Date: Mon, 27 Nov 2017 09:49:17 -0800 > From: internet-drafts@ietf.org > To: > Cc: dnsop@ietf.org > Subject: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-08.txt > Message-ID: <151180495773.30942.2986792598977230034@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : DNS Terminology > Authors : Paul Hoffman > Andrew Sullivan > Kazunori Fujiwara > Filename : draft-ietf-dnsop-terminology-bis-08.txt > Pages : 44 > Date : 2017-11-27 > > Abstract: > The DNS is defined in literally dozens of different RFCs. The > terminology used by implementers and developers of DNS protocols, and > by operators of DNS systems, has sometimes changed in the decades > since the DNS was first defined. This document gives current > definitions for many of the terms used in the DNS in a single > document. > > This document will be the successor to RFC 7719, and thus will > obsolete RFC 7719. It will also update RFC 2308. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-08 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-terminology-bis-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-08 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > ------------------------------ > > Message: 6 > Date: Mon, 27 Nov 2017 09:53:32 -0800 > From: "Paul Hoffman" > To: dnsop@ietf.org > Subject: Re: [DNSOP] I-D Action: > draft-ietf-dnsop-terminology-bis-08.txt > Message-ID: <7262E5E9-D844-4CBA-B406-C38B57440321@vpnc.org> > Content-Type: text/plain; format=flowed > > This draft closes out a bunch of issues. (As a reminder, we're tracking > issues both here on the list and on the GitHub repo: > https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis). > > We will be opening new issues in the coming weeks with the intention to > be ready for WG Last Call by mid-January. > > --Paul Hoffman > > On 27 Nov 2017, at 9:49, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Domain Name System Operations WG of > > the IETF. > > > > Title : DNS Terminology > > Authors : Paul Hoffman > > Andrew Sullivan > > Kazunori Fujiwara > > Filename : draft-ietf-dnsop-terminology-bis-08.txt > > Pages : 44 > > Date : 2017-11-27 > > > > Abstract: > > The DNS is defined in literally dozens of different RFCs. The > > terminology used by implementers and developers of DNS protocols, > > and > > by operators of DNS systems, has sometimes changed in the decades > > since the DNS was first defined. This document gives current > > definitions for many of the terms used in the DNS in a single > > document. > > > > This document will be the successor to RFC 7719, and thus will > > obsolete RFC 7719. It will also update RFC 2308. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-08 > > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop- > terminology-bis-08 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-bis-08 > > > > > > Please note that it may take a couple of minutes from the time of > > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > ------------------------------ > > Message: 7 > Date: Mon, 27 Nov 2017 18:58:46 +0100 > From: Gert Doering > To: Tony Finch > Cc: Joe Abley , "v6ops@ietf.org WG" > , 6man@ietf.org, Daniel Karrenberg > , dnsop@ietf.org, sunset4@ietf.org > Subject: Re: [DNSOP] [v6ops] New Version Notification for > draft-palet-sunset4-ipv6-ready-dns-00.txt > Message-ID: <20171127175846.GH45648@Space.Net> > Content-Type: text/plain; charset=us-ascii > > Hi, > > On Mon, Nov 27, 2017 at 12:28:16PM +0000, Tony Finch wrote: > > The 31 TLDs with no v6 nameservers: > [..] > > > mil. > > Yay. Like, IPv6 mandate, and all that. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > ------------------------------ > > End of DNSOP Digest, Vol 132, Issue 53 > ************************************** > -- Regards Tariq Saraj Riphah Institute of Systems Engineering, Islamabad --94eb2c19dd02fc5f680560ae8351 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>The only use case you descr= ibe (firewall configuration) is
>questionable.
This is just a single use case, there can be a number of implementati= ons for IPv4 to IPv6 and vice versa resolution. As I have faced the problem= during development of writing automation service, thus i discuss this use = case to support the requiremnet of the proposed resource record.

&g= t;Most firewall configuration interfaces allow you to use
>domain names instead= of IP addresses. So, if I want to allow port 443
>to www.example.com (which has IPv4 and IP v6 addresses), I can. Note>that many fire= wall administrators don't use this because, rightly or
>wrongly, they don= 9;t trust the DNS. They'll have the same issue with
>your proposal.

using a firewall based on domain names can be simply= bypassed by accessing websites through IP address. We have experienced thi= s scenario here in Pakistan when the Government restrict access to youtube,= but people were still able to access it through the IP address.
= Second, there are some firewalls such as Cisco and=C2=A0Kaspersky that hand= le this situation when someone configure a firewall rule based on domain na= me, it automatically resolves the IPv4 and IPv6 addresses for that domain a= nd update the firewall rules so that it cannot be bypassed through accessin= g a server through IP based. But, these are highly expensive firewalls and = normally not affordable for every organization.

>By t= he way, that's why you _need_ to write something in the Security=
>Considerati= ons, probably mentioning DNSSEC.
Yes agreed, I will discuss it in t= hat perspective.


On Mon, Nov 27= , 2017 at 10:58 PM, <dnsop-request@ietf.org> wrote:
Send DNSOP mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dnsop@ietf.or= g

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/dnsop
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dnsop= -request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 dnsop-o= wner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of DNSOP digest..."


Today's Topics:

=C2=A0 =C2=A01. Re:=C2=A0 IVIPTR: New RR for DNS (Stephane Bortzmeyer)
=C2=A0 =C2=A02. Re:=C2=A0 IVIPTR: New RR for DNS (Stephane Bortzmeyer)
=C2=A0 =C2=A03. Re:=C2=A0 Terminology: "primary master" (Joe Able= y)
=C2=A0 =C2=A04. Re:=C2=A0 Terminology: "primary master" (Tony Fin= ch)
=C2=A0 =C2=A05.=C2=A0 I-D Action: draft-ietf-dnsop-terminology-bis-08.= txt
=C2=A0 =C2=A0 =C2=A0 (internet-= drafts@ietf.org)
=C2=A0 =C2=A06. Re:=C2=A0 I-D Action: draft-ietf-dnsop-terminology-bis= -08.txt
=C2=A0 =C2=A0 =C2=A0 (Paul Hoffman)
=C2=A0 =C2=A07. Re:=C2=A0 [v6ops] New Version Notification for
=C2=A0 =C2=A0 =C2=A0 draft-palet-sunset4-ipv6-ready-dns-00.txt (Gert D= oering)


-----------------------------------------------------------------= -----

Message: 1
Date: Mon, 27 Nov 2017 15:27:39 +0100
From: Stephane Bortzmeyer <bortzmey= er@nic.fr>
To: Tony Finch <dot@dotat.at>
Cc: bert hubert <bert.hubert= @powerdns.com>, Tariq Saraj
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <tar= iqsaraj@gmail.com>, dnsop@ietf.org=
Subject: Re: [DNSOP] IVIPTR: New RR for DNS
Message-ID: <2= 0171127142739.3a3w6yv5wsje5m4y@nic.fr>
Content-Type: text/plain; charset=3Dus-ascii

On Mon, Nov 27, 2017 at 01:38:08PM +0000,
=C2=A0Tony Finch <dot@dotat.at> w= rote
=C2=A0a message of 24 lines which said:

> Why not

Section 1 of the draft explains "why not" but I disagree with the= ir
assessment. I think the PTR way is indeed the right one.



------------------------------

Message: 2
Date: Mon, 27 Nov 2017 15:45:15 +0100
From: Stephane Bortzmeyer <bortzmey= er@nic.fr>
To: Tariq Saraj <tariqsaraj@gmai= l.com>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] IVIPTR: New RR for DNS
Message-ID: <2= 0171127144515.4ol63kkaptnwmemn@nic.fr>
Content-Type: text/plain; charset=3Dus-ascii

On Sat, Nov 25, 2017 at 10:41:13PM +0500,
=C2=A0Tariq Saraj <tariqsaraj@gm= ail.com> wrote
=C2=A0a message of 60 lines which said:

> Please provide your valuable feedback on the newly uploaded draft.
> draft-tariq-dnsop-iviptr-00
> <https://datatracker.ietf.org/doc/draft-tariq-dnsop-iviptr/>
> *IVIPTR: Resource Record for DNS*

The only use case you describe (firewall configuration) is
questionable. Most firewall configuration interfaces allow you to use
domain names instead of IP addresses. So, if I want to allow port 443
to = www.example.com (which has IPv4 and IP v6 addresses), I can. Note
that many firewall administrators don't use this because, rightly or wrongly, they don't trust the DNS. They'll have the same issue with=
your proposal.

By the way, that's why you _need_ to write something in the Security Considerations, probably mentioning DNSSEC.

Otherwise, I'm not convinced by your argument against using PTR. If
people don't configure PTRs to get the effect you want, it may be becau= se:

* they don't want to (so they don't need your proposal)
* they're lazy or incompetent (so they'll ignore your proposal)



------------------------------

Message: 3
Date: Mon, 27 Nov 2017 11:34:11 -0500
From: Joe Abley <jabley@hopcount.c= a>
To: Tony Finch <dot@dotat.at>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Havard Eidnes <<= a href=3D"mailto:he@uninett.no">he@uninett.no>
Subject: Re: [DNSOP] Terminology: "primary master"
Message-ID: <180576EC-BC7C-47E1-B3F1-87062260C018@hopcount.ca>
Content-Type: text/plain;=C2=A0 =C2=A0 =C2=A0 =C2=A0charset=3Dus-ascii

Hi Tony,

On Nov 27, 2017, at 08:22, Tony Finch <d= ot@dotat.at> wrote:

> Joe Abley <jabley@hopcount.ca= > wrote:
>>> On Nov 23, 2017, at 12:44, Tony Finch <dot@dotat.at> wrote:
>>>
>>> It's quite difficult to have multiple masters and DNSSEC a= nd coherent
>>> copies of the zone from all masters - i.e. more effort than ju= st spinning
>>> up parallel instances of BIND or Knot in automatic signing mod= e.
>>
>> Note that I wasn't talking about multiple signers; I was talki= ng about
>> (from the perspective of one particular slave) having multiple mas= ters
>> available to serve precisely the same zone.
>
> A primary master is wrt a zone not a server - a zone's primary mas= ter is
> a server that's authoritative for a zone and which does not get th= e zone
> contents via axfr/ixfr, but instead from a master file and/or UPDATE (= or
> a non-standard mechanism such as directly from a database).

That's an alluringly clear definition, but I'm not sure it matches = common understanding of the term, which I think has more to do with "s= ingle source of truth" than with the specifics of what transport is us= ed to provision zone data in a server.

For example,

=C2=A0 =C2=A0 W <------- A -------> X

Suppose A is a source of truth for a particular zone, and that W and X obta= in zone data from A. Are you saying that if the mechanism represented by th= e arrows is [AI]XFR then A is a primary master and W and X are not, whereas= if that mechanism is something else (perhaps it's rsync, with W, A and= X all configured to be masters from local zone files) then W, A and X are = all primary masters?

If A is not a nameserver but instead is a database, and the arrows represen= t database replication, then W and X are primary masters but A is not?


Joe


------------------------------

Message: 4
Date: Mon, 27 Nov 2017 17:15:17 +0000
From: Tony Finch <dot@dotat.at> To: Joe Abley <jabley@hopcount.ca<= /a>>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Havard Eidnes <<= a href=3D"mailto:he@uninett.no">he@uninett.no>
Subject: Re: [DNSOP] Terminology: "primary master"
Message-ID: <alpine.DEB.2.11.1711271640260.4416@grey.csi.cam.ac.= uk>
Content-Type: TEXT/PLAIN; charset=3DUS-ASCII

Joe Abley <jabley@hopcount.ca&= gt; wrote:

> > A primary master is wrt a zone not a server - a zone's primar= y master is
> > a server that's authoritative for a zone and which does not g= et the zone
> > contents via axfr/ixfr, but instead from a master file and/or UPD= ATE (or
> > a non-standard mechanism such as directly from a database).
>
> That's an alluringly clear definition, but I'm not sure it mat= ches
> common understanding of the term, which I think has more to do with > "single source of truth" than with the specifics of what tra= nsport is
> used to provision zone data in a server.

Hmm, I think I sort-of agree, but with caveats...

I prefer to make a clear distinction between the standard DNS as specified<= br> in the RFCs versus any funky non-standard stuff that people might do with the DNS.

The standard DNS protocols are closely fitted to a particular distributed architecture, in which a zone has a single source of truth that we call
the primary master. You can, of course, implement a similar architecture using non-standard protocols, but if you do you should take care to make it clear how you are diverging from the standard - and be careful about
how you use standard DNS terminology when talking about your non-standard system.

> For example,
>
>=C2=A0 =C2=A0 =C2=A0W <------- A -------> X
>
> Suppose A is a source of truth for a particular zone, and that W and X=
> obtain zone data from A. Are you saying that if the mechanism
> represented by the arrows is [AI]XFR then A is a primary master and W<= br> > and X are not, whereas if that mechanism is something else (perhaps it= 's
> rsync, with W, A and X all configured to be masters from local zone > files) then W, A and X are all primary masters?

In this case I would say A is a primary master and W and X are secondaries<= br> that use rsync instead of standard zone transfers.

The part of the standard architecture that you have replaced is the zone transfer mechanism, so the primary master is architecturally unaffected, so it's OK to use the same name.

(But you can't call rsync "ixfr" even though it is incrementa= lly
transferring zones, because that would be unreasonably confusing.)

> If A is not a nameserver but instead is a database, and the arrows
> represent database replication, then W and X are primary masters but A=
> is not?

In this case I would be very proud of my high-availability multi-master
system.

Tony.
--
f.anthony.n.finch=C2=A0 <dot@dotat.at>=C2=A0 http://dotat.at/=C2=A0 -=C2=A0 I xn--zr8h punycode
Shannon, Rockall, Malin, Hebrides, Bailey: North or northwest 5 to 7,
occasionally gale 8 except in Shannon. Rough or very rough, occasionally moderate. Squally showers. Good.



------------------------------

Message: 5
Date: Mon, 27 Nov 2017 09:49:17 -0800
From: internet-drafts@ietf.org<= /a>
To: <i-d-announce@ietf.org&= gt;
Cc: dnsop@ietf.org
Subject: [DNSOP] I-D Action: draft-ietf-dnsop-terminology-bis-08.txt Message-ID: <151180495773.30942.2986792598977230034@ietfa.amsl.c= om>
Content-Type: text/plain; charset=3D"utf-8"


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= DNS Terminology
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Paul= Hoffman
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Andrew Sullivan
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kazunori Fujiwara
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dnsop-terminology-bis-08.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 44
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-11-27

Abstract:
=C2=A0 =C2=A0The DNS is defined in literally dozens of different RFCs.=C2= =A0 The
=C2=A0 =C2=A0terminology used by implementers and developers of DNS protoco= ls, and
=C2=A0 =C2=A0by operators of DNS systems, has sometimes changed in the deca= des
=C2=A0 =C2=A0since the DNS was first defined.=C2=A0 This document gives cur= rent
=C2=A0 =C2=A0definitions for many of the terms used in the DNS in a single<= br> =C2=A0 =C2=A0document.

=C2=A0 =C2=A0This document will be the successor to RFC 7719, and thus will=
=C2=A0 =C2=A0obsolete RFC 7719.=C2=A0 It will also update RFC 2308.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/= doc/draft-ietf-dnsop-terminology-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draf= t-ietf-dnsop-terminology-bis-08
https://datatracker.ietf.or= g/doc/html/draft-ietf-dnsop-terminology-bis-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-dnsop-terminology-bis-08


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/



------------------------------

Message: 6
Date: Mon, 27 Nov 2017 09:53:32 -0800
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: dnsop@ietf.org
Subject: Re: [DNSOP] I-D Action:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-dnsop-terminology-bis-08.txt Message-ID: <7262E5E9-D844-4CBA-B406-C38B57440321@vpnc.org>
Content-Type: text/plain; format=3Dflowed

This draft closes out a bunch of issues. (As a reminder, we're tracking=
issues both here on the list and on the GitHub repo:
https://github.com/DNSOP/draft-ietf-dn= sop-terminology-bis).

We will be opening new issues in the coming weeks with the intention to
be ready for WG Last Call by mid-January.

--Paul Hoffman

On 27 Nov 2017, at 9:49, intern= et-drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Domain Name System Operations WG of > the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: DNS Terminology
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Paul Hoffman
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Andrew Sullivan
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Kazunori Fujiwara
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-dnsop-terminology-bis-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 44
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-11-27
>
> Abstract:
>=C2=A0 =C2=A0 The DNS is defined in literally dozens of different RFCs.= =C2=A0 The
>=C2=A0 =C2=A0 terminology used by implementers and developers of DNS pr= otocols,
> and
>=C2=A0 =C2=A0 by operators of DNS systems, has sometimes changed in the= decades
>=C2=A0 =C2=A0 since the DNS was first defined.=C2=A0 This document give= s current
>=C2=A0 =C2=A0 definitions for many of the terms used in the DNS in a si= ngle
>=C2=A0 =C2=A0 document.
>
>=C2=A0 =C2=A0 This document will be the successor to RFC 7719, and thus= will
>=C2=A0 =C2=A0 obsolete RFC 7719.=C2=A0 It will also update RFC 2308. >
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/= doc/draft-ietf-dnsop-terminology-bis/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-terminology-bis-08
> https://datatracker.ie= tf.org/doc/html/draft-ietf-dnsop-terminology-bis-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfc= diff?url2=3Ddraft-ietf-dnsop-terminology-bis-08
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org. >
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/



------------------------------

Message: 7
Date: Mon, 27 Nov 2017 18:58:46 +0100
From: Gert Doering <gert@space.net= >
To: Tony Finch <dot@dotat.at>
Cc: Joe Abley <jabley@hopcount.ca<= /a>>, "v6ops@ietf.org WG"= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <v6ops@iet= f.org>, 6man@ietf.org, Daniel K= arrenberg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <da= niel@karrenberg.net>, dnsop@ietf.o= rg, sunset4@ietf.org
Subject: Re: [DNSOP] [v6ops] New Version Notification for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-palet-sunset4-ipv6-ready-dns-00.txt<= br> Message-ID: <20171127175846.GH45648@Space.Net>
Content-Type: text/plain; charset=3Dus-ascii

Hi,

On Mon, Nov 27, 2017 at 12:28:16PM +0000, Tony Finch wrote:
> The 31 TLDs with no v6 nameservers:
[..]

> mil.

Yay.=C2=A0 Like, IPv6 mandate, and all that.

Gert Doering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.:= DE813185279



------------------------------

Subject: Digest Footer

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


------------------------------

End of DNSOP Digest, Vol 132, Issue 53
**************************************



--
<= div>Regards
Tariq Sar= aj
Riphah Institute of Systems Engineering, Islamabad

--94eb2c19dd02fc5f680560ae8351-- From nobody Tue Dec 19 02:08:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E366312DA49 for ; Tue, 19 Dec 2017 02:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.878 X-Spam-Level: X-Spam-Status: No, score=-5.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, 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 PHCiUDFUcg5L for ; Tue, 19 Dec 2017 02:08:15 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 8318D12DA42 for ; Tue, 19 Dec 2017 02:08:15 -0800 (PST) Received: from grisu.home.partim.org (unknown [IPv6:2a04:b900:0:1:de53:60ff:fe07:b3e0]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 45C05851C for ; Tue, 19 Dec 2017 11:08:13 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=opennetlabs.com Date: Tue, 19 Dec 2017 11:08:13 +0100 From: Martin Hoffmann Cc: dnsop WG Message-ID: <20171219110813.497fcd29@grisu.home.partim.org> In-Reply-To: <20171219091318.zugag6shf5vrairy@nic.fr> References: <707A270D-94DA-4651-84DC-409FAA6793F7@vpnc.org> <20171218132446.w7o5x4mrz2ttprlb@nic.fr> <20171219035622.414457a1@grisu.home.partim.org> <20171219091318.zugag6shf5vrairy@nic.fr> Organization: Open Netlabs X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 10:08:19 -0000 Stephane Bortzmeyer wrote: > On Tue, Dec 19, 2017 at 03:56:22AM +0100, > Martin Hoffmann wrote > a message of 38 lines which said: > > > > The current definition is restrictive: it mentions only name > > > servers. > > > > > > IMHO, "in-bailiwick" could be said for any domain name, even if > > > it has less practical consequences than for name servers. For > > > instance, www.toto.fr is in-bailiwick for .fr. > > > > So a domain name would be in-bailiwick with regards to a given zone > > if it is part of that zone or any of its child zones? > > Yes. In that case, perhaps we can use a definition along these lines? At least to me it seems intuitively clear whereas with the current definition I had to think for a bit to make sense of it. Except that "child zone" should probably be "subordinate zones" or something similar to also include (great)*grandchildren. Kind regards, Martin From nobody Tue Dec 19 10:50:04 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 406E81272E1; Tue, 19 Dec 2017 10:49:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151370939722.7367.18068254315788230511@ietfa.amsl.com> Date: Tue, 19 Dec 2017 10:49:57 -0800 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 18:49:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : Security Considerations for RFC5011 Publishers Authors : Wes Hardaker Warren Kumari Filename : draft-ietf-dnsop-rfc5011-security-considerations-10.txt Pages : 19 Date : 2017-12-19 Abstract: This document extends the RFC5011 rollover strategy with timing advice that must be followed by the publisher in order to maintain security. Specifically, this document describes the math behind the minimum time-length that a DNS zone publisher must wait before signing exclusively with recently added DNSKEYs. This document also describes the minimum time-length that a DNS zone publisher must wait after publishing a revoked DNSKEY before assuming that all active RFC5011 resolvers should have seen the revocation-marked key and removed it from their list of trust anchors. This document contains much math and complicated equations, but the summary is that the key rollover / revocation time is much longer than intuition would suggest. If you are not both publishing a DNSSEC DNSKEY, and using RFC5011 to advertise this DNSKEY as a new Secure Entry Point key for use as a trust anchor, you probably don't need to read this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-10 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 19 12:24:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5B4126BF6 for ; Tue, 19 Dec 2017 12:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 YKV6I1fw6rzT for ; Tue, 19 Dec 2017 12:24:19 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 ECEBF1201F2 for ; Tue, 19 Dec 2017 12:24:18 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id f12so11002087pgo.5 for ; Tue, 19 Dec 2017 12:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nH40sY5SRugK+XuD5b7lPzi8N1sZXB5tJAv3PLXvmLE=; b=NOomRcpHqCnW2WlSdAOebfDbhxagWMDIOy6iAjWUx1qDCwT+/LJ/YxcD/hA58AQORQ eGp1tomQ7B+kfUuEUUod/sG0REtCKsl41j3zxkxLbAAOHeHPO3q23rZ5ozp55LVNgraS /2ofV+9ZNxR7sxcYgf3IxzGGR3zTolL3SsmJGurwubHMeCg6MzIFbnmTE9qc1i7qohko +mI1mt4jsJjywl4n91bfIvdrmKB38ZQvP0fBo/HnJSOjomNIJpjGZbnMyhtletWIHMUf 48zi5NlgoFGugbhvfQv3AOpqaVovNOAIDm5+rCvMaDMEHus37Ll8ncqObxn9RqiuQtSN VVYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nH40sY5SRugK+XuD5b7lPzi8N1sZXB5tJAv3PLXvmLE=; b=m556wPvyn7ZdK/KnCI5+sYDyqYJtByD00m1aEX7dUBXFax9zFp1rAtJ/37E+Z7GnT7 F6OudEXTXa8A10IvtT4gJ29d/r3TTrAm0LFT94a5JTpelzA6cEbt3R6SLUJtP5ZKfL5O ziISV5+q958n5s6o/+UvV5PbGHuXHgw3LTCLXTXs0DVZx114jP92aTcP2Pu/Kb70URKD AwTbiqFQmX1FRV+anmJvh5H6hh/xuLyV3wbvRhwRpk7R8V4UVcJizp1+DmB+774Ri850 dNa6iqwgHzXb7Wyk13SlBZW/6xKuIToHPa29jqcF/olO8rynzPoektHesjiXxXGwe2V5 AMvg== X-Gm-Message-State: AKGB3mLWmy2ub/qMk9jCU6MQk/QrdMv4q4hq78gpT9HNyYKmBiZZurjd StXKCygO3vkulwj3h936QsgjFcxRMtAUVZRF77d3aQ== X-Google-Smtp-Source: ACJfBou+7jEnhx9dMUo66oUBjbUGsxnlFcQfUqkLifZmw32QzAfmbOVdkA9iaD0wTLQYhtxlXWDIAstJtOn3yr1L4Qo= X-Received: by 10.99.160.96 with SMTP id u32mr4020601pgn.140.1513715058223; Tue, 19 Dec 2017 12:24:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.139.5 with HTTP; Tue, 19 Dec 2017 12:24:17 -0800 (PST) In-Reply-To: <151370939722.7367.18068254315788230511@ietfa.amsl.com> References: <151370939722.7367.18068254315788230511@ietfa.amsl.com> From: Bob Harold Date: Tue, 19 Dec 2017 15:24:17 -0500 Message-ID: To: internet-drafts@ietf.org Cc: IETF DNSOP WG Content-Type: multipart/alternative; boundary="f403043636ea56485f0560b7402c" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 20:24:21 -0000 --f403043636ea56485f0560b7402c Content-Type: text/plain; charset="UTF-8" On Tue, Dec 19, 2017 at 1:49 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the > IETF. > > Title : Security Considerations for RFC5011 Publishers > Authors : Wes Hardaker > Warren Kumari > Filename : draft-ietf-dnsop-rfc5011- > security-considerations-10.txt > Pages : 19 > Date : 2017-12-19 > > Abstract: > This document extends the RFC5011 rollover strategy with timing > advice that must be followed by the publisher in order to maintain > security. Specifically, this document describes the math behind the > minimum time-length that a DNS zone publisher must wait before > signing exclusively with recently added DNSKEYs. This document also > describes the minimum time-length that a DNS zone publisher must wait > after publishing a revoked DNSKEY before assuming that all active > RFC5011 resolvers should have seen the revocation-marked key and > removed it from their list of trust anchors. > > This document contains much math and complicated equations, but the > summary is that the key rollover / revocation time is much longer > than intuition would suggest. If you are not both publishing a > DNSSEC DNSKEY, and using RFC5011 to advertise this DNSKEY as a new > Secure Entry Point key for use as a trust anchor, you probably don't > need to read this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011- > security-considerations/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011- > security-considerations-10 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security- > considerations-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011- > security-considerations-10 > > 6.1.7. driftSafetyMargin "Moving past the theoretical model parameters above, we not that clock drift" "not" -> "note" -- Bob Harold --f403043636ea56485f0560b7402c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Tue, Dec 19, 2017 at 1:49 PM, <internet-drafts@ietf.org>= wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Domain Name System Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Security Considerations for RFC5011 Publishers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Wes = Hardaker
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Warren Kumari
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-dnsop-rfc5011-security-considerations-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 19
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-12-19

Abstract:
=C2=A0 =C2=A0This document extends the RFC5011 rollover strategy with timin= g
=C2=A0 =C2=A0advice that must be followed by the publisher in order to main= tain
=C2=A0 =C2=A0security.=C2=A0 Specifically, this document describes the math= behind the
=C2=A0 =C2=A0minimum time-length that a DNS zone publisher must wait before=
=C2=A0 =C2=A0signing exclusively with recently added DNSKEYs.=C2=A0 This do= cument also
=C2=A0 =C2=A0describes the minimum time-length that a DNS zone publisher mu= st wait
=C2=A0 =C2=A0after publishing a revoked DNSKEY before assuming that all act= ive
=C2=A0 =C2=A0RFC5011 resolvers should have seen the revocation-marked key a= nd
=C2=A0 =C2=A0removed it from their list of trust anchors.

=C2=A0 =C2=A0This document contains much math and complicated equations, bu= t the
=C2=A0 =C2=A0summary is that the key rollover / revocation time is much lon= ger
=C2=A0 =C2=A0than intuition would suggest.=C2=A0 If you are not both publis= hing a
=C2=A0 =C2=A0DNSSEC DNSKEY, and using RFC5011 to advertise this DNSKEY as a= new
=C2=A0 =C2=A0Secure Entry Point key for use as a trust anchor, you probably= don't
=C2=A0 =C2=A0need to read this document.


The IETF datatracker status page for this draft is:
https://datatracke= r.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/<= /a>

There are also htmlized versions available at:
https://tools.ietf.or= g/html/draft-ietf-dnsop-rfc5011-security-considerations-10 https://dat= atracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-10

A diff from the previous version is available at:
https://www.i= etf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-rfc5011-security-consider= ations-10


6.1.7.=C2=A0 driftSafetyMargin

"Moving past the theoretical model parameters ab= ove, we not that clock drift"

"not"= -> "note"

--=C2=A0
Bob Har= old


--f403043636ea56485f0560b7402c-- From nobody Tue Dec 19 12:38:00 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690311205F0; Tue, 19 Dec 2017 12:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 N0W-9-wCf7m6; Tue, 19 Dec 2017 12:37:57 -0800 (PST) Received: from mail.hardakers.net (unknown [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669451201F2; Tue, 19 Dec 2017 12:37:57 -0800 (PST) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id A709B21AB7; Tue, 19 Dec 2017 12:37:56 -0800 (PST) From: Wes Hardaker To: internet-drafts@ietf.org Cc: , dnsop@ietf.org References: <151370939722.7367.18068254315788230511@ietfa.amsl.com> Date: Tue, 19 Dec 2017 12:37:55 -0800 In-Reply-To: <151370939722.7367.18068254315788230511@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Tue, 19 Dec 2017 10:49:57 -0800") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 20:37:58 -0000 FYI, there are multiple data analysis engines you can play with when trying to figure out the math and how it works. MSJ posted a java program that simulates a lot of clients under randomized conditions with failure rates here: https://www.ietf.org/mail-archive/web/dnsop/current/msg21602.html Additionally, I wrote a javascript based calculator for a single resolver so you can try to put in "worst case" numbers into form fields and have it calculate what happens here: https://www.isi.edu/~hardaker/projects/5011/ -- Wes Hardaker USC/ISI From nobody Tue Dec 19 15:05:18 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A614E1243FE for ; Tue, 19 Dec 2017 15:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 MhoXGIETVm_a for ; Tue, 19 Dec 2017 15:05:16 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 C7C1512D889 for ; Tue, 19 Dec 2017 15:05:15 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id g9so26244106qth.9 for ; Tue, 19 Dec 2017 15:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=CjBtdTo2cL2fKzLagwpLqTci72VHYtvzRq7H8pfBBz0=; b=ZkHShfOaWBHZKIzQBnO+w380b8F7yifeZrszcZhgVW5l+lE81LWIgNwfNKFFE/U+70 5mjnVLPkl6yKAy2BKXR2CUNUPFznZdCa/tTxFlmyY9Rye5QNwnzLWtyHpAPh2WOt/55G dIVqvDcusgKlGttemvXqQx9WtFnsubZVshtvEvnaK7t6/N14b3uFchOZTPp7kKfICUhi FnNKz9wh7kG2pUF9qq24wnhrgvYsZR/aTvY7EJhUht405io3wncflv0EgARfA+PrZZfZ W9zF/8GgMVOuM9wlFlAhpMAURu9gcSp5cSqZ+qyBcahhFQYc/qla1rdwUCz433rwefm1 uoVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=CjBtdTo2cL2fKzLagwpLqTci72VHYtvzRq7H8pfBBz0=; b=lbysMjGMFFgZjLjn6Yc/jMB8ouE5RTh4cWNsDG4HK8D4Ibpv0HZWmcZYISnHPjY+eU Ya5Ff+WQREJmxj+f/ZdJ0+p+OfXezw2q/YiZHhzVQTJKrn19m3YKLOuynRa5lK4mE6Vq ya0REcFoJ3Y6GxzaJcvsHCE7DoGwczDbVX8IQHV4MEC/sviGS8FY2hfzL5njBNj3cGs9 dK+wHindK+wwH3tLyuptGi4MPcBti6c1JC0jwnydyOoaZ8AdqjJmQtUv+v68M5HqMNEc ADzgsIz9vBjY9VByYfDDtIote3p4ULh5pnpoF6dWlqW4xh31Xjhy7J8kh2LTRiz1yPsk tnNQ== X-Gm-Message-State: AKGB3mJZuWAhauM8ZAwetHdZ0QO4YxORqfmOZCYstjaNe6eqB8CsLGdI gKIApDz3PDXCGsjsIqowlZ5GH89s X-Google-Smtp-Source: ACJfBovUUgsvWNBwwVmVH1eluEZIYK3NR3kQbD07fpqPej/zJkzSdWqGRZtGnGHefYU2l5yXLpznBw== X-Received: by 10.237.47.228 with SMTP id m91mr7560191qtd.205.1513724714366; Tue, 19 Dec 2017 15:05:14 -0800 (PST) Received: from [192.168.1.107] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id t63sm479557qke.94.2017.12.19.15.05.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Dec 2017 15:05:13 -0800 (PST) To: dnsop@ietf.org References: <151370939722.7367.18068254315788230511@ietfa.amsl.com> From: Michael StJohns Message-ID: Date: Tue, 19 Dec 2017 18:05:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <151370939722.7367.18068254315788230511@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 23:05:17 -0000 I didn't think this could get worse.  I was wrong. I can't support any version of this document for publication.   In the same way that activeRefreshOffset is a nonsensical value so to are  driftSafetyMargin and timingSafetyMargin. 1) Drift happens per query. 2) Any drift that happens related to the multiple queries in the addHoldDown interval can safely be ignored with respect to its impact on the overall wait time for the publisher.  (e.g. all the drift is going to do is change the phase of the last query in the interval with respect to the end of the addHoldDown time) 3) The only other drift that may be of interest is the drift at the beginning and end of the queryInterval where the end of the interval is the beginning of the addHoldDown interval. Given that a typical drift is something like 1-60 seconds it can safely be ignored related to all the other stuff. Timing safety margin is based on the nonsensical driftSafetyMargin and activeRefreshOffset and is then by definition also nonsensical. (And yes, I realize that Wes has set driftSafetyMargin to activeRefresh meaning that calculated results are identical to what I want, but there's no analysis that supports the use of a driftSafetyMargin and this just seems to be sleight of hand to replace activeRefreshOffset with a term that has a value activeRefresh... *pounds head against wall*) Please delete 6.1.6, 6.,1.7 and 6.1.8 and fix the formulas accordingly. Again: addWaitClockTime = lastSigExpirationTime + activeRefresh + addHoldDownTime + activeRefresh + safetyMargin (which now seems to be labeled retrySafetyMargin). Mike On 12/19/2017 1:49 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : Security Considerations for RFC5011 Publishers > Authors : Wes Hardaker > Warren Kumari > Filename : draft-ietf-dnsop-rfc5011-security-considerations-10.txt > Pages : 19 > Date : 2017-12-19 > > Abstract: > This document extends the RFC5011 rollover strategy with timing > advice that must be followed by the publisher in order to maintain > security. Specifically, this document describes the math behind the > minimum time-length that a DNS zone publisher must wait before > signing exclusively with recently added DNSKEYs. This document also > describes the minimum time-length that a DNS zone publisher must wait > after publishing a revoked DNSKEY before assuming that all active > RFC5011 resolvers should have seen the revocation-marked key and > removed it from their list of trust anchors. > > This document contains much math and complicated equations, but the > summary is that the key rollover / revocation time is much longer > than intuition would suggest. If you are not both publishing a > DNSSEC DNSKEY, and using RFC5011 to advertise this DNSKEY as a new > Secure Entry Point key for use as a trust anchor, you probably don't > need to read this document. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-10 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue Dec 19 20:25:15 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBB21201FA; Tue, 19 Dec 2017 20:25:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: tjw.ietf@gmail.com, warren@kumari.net, dnsop@ietf.org, dnsop-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151374391379.2497.6458236051438809827.idtracker@ietfa.amsl.com> Date: Tue, 19 Dec 2017 20:25:13 -0800 Archived-At: Subject: [DNSOP] dnsop - New Meeting Session Request for IETF 101 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 04:25:14 -0000 A new meeting session request has just been submitted by Tim Wicinski, a Chair of the dnsop working group. --------------------------------------------------------- Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Tim Wicinski Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 160 Conflicts to Avoid: First Priority: dhc homenet dnssd dprive doh Second Priority: v6ops intarea trans acme Third Priority: 6man grow opsarea opsawg saag sidr People who must be present: Suzanne Woolf Warren Kumari Tim Wicinski Resources Requested: Special Requests: If either session is slotted for Friday, please make it the second 1 hour session. thanks --------------------------------------------------------- From nobody Wed Dec 20 10:15:41 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3799D129511 for ; Wed, 20 Dec 2017 10:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CFNPioavKXoc for ; Wed, 20 Dec 2017 10:15:38 -0800 (PST) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D16A126BF7 for ; Wed, 20 Dec 2017 10:15:38 -0800 (PST) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 05C71228AE; Wed, 20 Dec 2017 10:15:37 -0800 (PST) From: Wes Hardaker To: Michael StJohns Cc: dnsop@ietf.org References: <151370939722.7367.18068254315788230511@ietfa.amsl.com> Date: Wed, 20 Dec 2017 10:15:36 -0800 In-Reply-To: (Michael StJohns's message of "Tue, 19 Dec 2017 18:05:12 -0500") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 18:15:40 -0000 Michael StJohns writes: > 1) Drift happens per query. Agreed. I'll go double check that I didn't imply that, or better: make sure I state that in the document. > 2) Any drift that happens related to the multiple queries in the > addHoldDown interval can safely be ignored with respect to its impact > on the overall wait time for the publisher.=C2=A0 (e.g. all the drift is > going to do is change the phase of the last query in the interval with > respect to the end of the addHoldDown time) Most likely, but I could see bad code calculating total waited time by adding time between queries together, rather than doing a wall clock subtraction from new - start_hold_down like they should. Anyway, I agree only the last one should be shifted in the correct case. > 3) The only other drift that may be of interest is the drift at the > beginning and end of the queryInterval where the end of the interval > is the beginning of the addHoldDown interval. Given that a typical > drift is something like 1-60 seconds it can safely be ignored related > to all the other stuff. I think I agree with that too. Only a small percentage of clients will end up needing the extra queryInterval. > (And yes, I realize that Wes has set driftSafetyMargin to > activeRefresh meaning that calculated results are identical to what I > want, but there's no analysis that supports the use of a > driftSafetyMargin and this just seems to be sleight of hand to replace > activeRefreshOffset with a term that has a value > activeRefresh... *pounds head against wall*) Hmm... I'll try to clean up the wording some more to make the analysis more clear. But in the end, yes: when real world conditions occur you're right and the extra activeRefresh is needed. Again, you're right there is *another* new issue with 5011 that had to be spelled out, and I'm glad you caught yet another needed length extension during last call. But no, it wasn't slight of hand and have no idea why you think I'd be trying to trick you. Again, Mike, I can't state this more clearly: I admit you were right and found a more important timing constraint than activeRefreshOffset. That being said, I left (and want to leave) activeRefreshOffset in the document so that others performing similar analysis of the whole 5011 process understand all the ramifications of both the theoretical and practical applications of the 5011 algorithm and usage. Thus, we actually agree. You just want to limit what goes into it. > Again: > > addWaitClockTime =3D lastSigExpirationTime + activeRefresh + > addHoldDownTime + activeRefresh + safetyMargin (which now seems to be > labeled retrySafetyMargin). Which is exactly what's in ... *crap* ... I missed a term in an equation. But 6.2.1.1 *will* state: addWaitTime =3D addHoldDownTime + sigExpirationTimeRemaining + MAX(1 hour, MIN(sigExpirationTime / 2, MAX(TTL of K_old DNSKEY RRSet) / 2, 15 days) ) + 2 * activeRefresh + retrySafetyMargin So your desired equation is there. (the current published document doesn't have the 2*, even though the previous non-expanded version should have lead to it). I'll do a final check of equations again today, as well as look to make sure I didn't state drift can only happen for one query (though I'm sure I didn't say that). --=20 Wes Hardaker USC/ISI From nobody Wed Dec 20 10:21:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82131241FC for ; Wed, 20 Dec 2017 10:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 g1iQYWqupwLE for ; Wed, 20 Dec 2017 10:21:50 -0800 (PST) Received: from mail.hardakers.net (unknown [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE279126BF7 for ; Wed, 20 Dec 2017 10:21:50 -0800 (PST) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id D0BBE228AE; Wed, 20 Dec 2017 10:21:49 -0800 (PST) From: Wes Hardaker To: Wes Hardaker Cc: Michael StJohns , dnsop@ietf.org References: <151370939722.7367.18068254315788230511@ietfa.amsl.com> Date: Wed, 20 Dec 2017 10:21:49 -0800 In-Reply-To: (Wes Hardaker's message of "Wed, 20 Dec 2017 10:15:36 -0800") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 18:21:52 -0000 Wes Hardaker writes: >> Again: >> >> addWaitClockTime = lastSigExpirationTime + activeRefresh + >> addHoldDownTime + activeRefresh + safetyMargin (which now seems to be >> labeled retrySafetyMargin). > > Which is exactly what's in ... *crap* ... I missed a term in an > equation. > > But 6.2.1.1 *will* state: Whoops, I got the section number wrong for the equation you wanted. It's 6.2.2 and it *will* state: addWallClockTime = lastSigExpirationTime + addHoldDownTime + 2 * MAX(1 hour, MIN(sigExpirationTime / 2, MAX(TTL of K_old DNSKEY RRSet) / 2, 15 days) ) + retrySafetyMargin Which is exactly what you wanted. -- Wes Hardaker USC/ISI From nobody Wed Dec 20 10:30:58 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F63B1267BB for ; Wed, 20 Dec 2017 10:30:56 -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 dZ98KzQSqlvi for ; Wed, 20 Dec 2017 10:30:52 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0046.outbound.protection.outlook.com [104.47.124.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C22A1241FC for ; Wed, 20 Dec 2017 10:30:49 -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=20RAzL7Aq8I9HqOSalFtK48emwgjEBZpl0/ZB+a1DJ0=; b=k74rt8onTxVgdAYlkgUlioOJ9aRjx/1eQXrqL5ruXybIQK9LlJSlO4N+rMn3Ae2A78DVzi1jZSC4hI+BYkQyrfcfC3fx7io4ZkZ3CrSRmOpAp1194KDiL57fMw/TWsqes2ph5+kD76rbGbGRoKY202u7UcpszAe8C/yZr7zc744= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from 2001-44b8-1121-1a00-dcc1-842d-fce2-c598.static.ipv6.internode.on.net (2001:44b8:1121:1a00:dcc1:842d:fce2:c598) by SIXPR04MB0699.apcprd04.prod.outlook.com (2a01:111:e400:51ed::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Wed, 20 Dec 2017 18:30:42 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Geoff Huston In-Reply-To: Date: Thu, 21 Dec 2017 05:30:28 +1100 Cc: dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E1FF941-C80D-442C-ABB5-6C81F3B1A149@apnic.net> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.5.20) X-Originating-IP: [2001:44b8:1121:1a00:dcc1:842d:fce2:c598] X-ClientProxiedBy: SG2PR0302CA0002.apcprd03.prod.outlook.com (2603:1096:3:2::12) To SIXPR04MB0699.apcprd04.prod.outlook.com (2a01:111:e400:51ed::15) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 372e09f4-2844-4b26-cbc4-08d547d7c86a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:SIXPR04MB0699; X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0699; 3:o1Nkwc5vdfX3y/A9SbcM/P5WAF8+jbI+SK82qErOUtS4pUa/yBXkgrUpmRX2c52H3PvG33/t42QGdgA7p9/p/9SX5om9rF5ys+vXK9bomXd+L28+B3JxnbQwlii+NXmvJbpXlhPKI0v7+aCU0kNmZe5mP/CeNu5LL3465jUjBAaYdqDYoAo49nIBJQSzbR8vcvhOOatzgVUHL143v5peMbSFBxm24AT0CVseJ4DfdRV6B3BfTUwL72YBVXO6I3tb; 25:ofTLMQvTlf1HQG0WocSD10pcl3kOnE/R5bb/frPaLoMnXR9FKxcsmLDvUmSKpk1bQMEQTtJsOBL2tCyoi3+DTeuFnJOkB3fBihnvOmDruIgNEL+blADe2+UhXagj/LqoVopsKnQfd2fVsgwhOu7VkOjIWRi/8Z7rIvPbtZ2ZNEXdo/5cWC7G7laWyVP29LGQLpuac5HRN3TsM6+Tkvr7g27ZUNVQhBLv35s6IOnIX3lrnSL7XTjzGKA7VaA2/pxebnMTAcx/djsEz5N8u2Y7xMjWlh7tl+sP21jfnXcGrQsQYY8ztZO6xbdJnu5VK+VYw5hRwgNexR37juriS+WsTCQmoFvL0ZcJRHEJNBoyZxA=; 31:qGFnllEsp2X+yN/6ZYHdExs1xWqgQ4dZ3dklnM9TKd576IgUECaDsHBqTtDsXaJjmn7dkt9pbeto8iVba3zYb46Ix3RAx/actjo+8PHpZ+jKiD12GL5pCjCRGdHuZ9BFCHJbD/Ej1Sq2OLs0nHNnMAdjoAH5Gdy9JfgQGzYDOKrDy5e4HKJilYodFlAUoLxbKA0d2J1zmmZWCy4SYAfN6mQw07dfIMIB1bGi5pbCmNA= X-MS-TrafficTypeDiagnostic: SIXPR04MB0699: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(20558992708506)(35073007944872); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231023)(6041268)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:SIXPR04MB0699; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SIXPR04MB0699; X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0699; 4:HhgImlLtw8yiR5vdHPzWgy+1UB8qGizXzMhQP/50S6o4QSW0BqRQrHduae4MNYiV+XiAzRd1AVAd4Jz2nSN4tlDqLJ0r7Hmi0vAapi39BDi2+99QlRfMfSg4SUPhlIFKmW+wHae4EGXR2eXDHri4SaC+t25uK3hm5EWLcy/XmsCz18tffMHtFIkDB0JcEn7A7umbAGtghUTF8xireyJ6DSiPLNEB0cVVkk1yuMIoxZ4EX1vS8uJ2x6qW2ftwoNL5dLaOtnHr5Np1dFqJcXm/OYiANRyPdkDF/um695ly6FuuV2pB6DTPng7Jbul/ux8fhHbypdqbu3dD6PQLTBpwhr0vE8Gld2QAATRmtKeBVzE= X-Forefront-PRVS: 0527DFA348 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(396003)(39840400004)(39380400002)(199004)(189003)(24454002)(25786009)(2906002)(68736007)(50226002)(6666003)(7736002)(4326008)(6486002)(230783001)(8936002)(386003)(8746002)(23676004)(305945005)(53936002)(47776003)(83716003)(229853002)(52396003)(52146003)(53546011)(8676002)(6506007)(52116002)(76176011)(6246003)(6512007)(81156014)(82746002)(478600001)(81166006)(2486003)(50466002)(93886005)(36756003)(97736004)(106356001)(105586002)(57306001)(6116002)(316002)(2950100002)(6916009)(5660300001)(33656002)(86362001)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:SIXPR04MB0699; H:2001-44b8-1121-1a00-dcc1-842d-fce2-c598.static.ipv6.internode.on.net; 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?MTtTSVhQUjA0TUIwNjk5OzIzOk9TTWhrSVBzTkcxQ1BRT0RZcUdLeTgzNEUw?= =?utf-8?B?YXdGME5MaEJJelgzakhJNW00alkxMVk1NjRCeDJzaW5oV0NxckdwZGRCS1Rs?= =?utf-8?B?Nk84UUxYaUZpOVdwUm14SjQ2anBuZ1M0RnA0ell6Q0RBRXRIZDltNHRXYmJT?= =?utf-8?B?RUYwTEh5RmRyRDN1M3M0aFpBUjZhdHU2M3lQYWg1NVpENmU2ZE40ZlRLRm5w?= =?utf-8?B?OEZEcVhmRW1pWnhnbFlaNDVBUTJhTkNOeitXYjRxWmVUcGNpbjd4ak5YQjhx?= =?utf-8?B?T1hLRm9XZllJaElRelpISi91SWZmZW5pVzQxaHVZZ01RWElpU3c5RThNMnZJ?= =?utf-8?B?ZzhHRXU4MXVYRHpFYXp3a2MvWG55cmU0RUJZMS9WdGN3UkZQMkQxZGttcWNQ?= =?utf-8?B?WE51NDBZMXBNQVpHSWJVZXVSdTgzRFNFRVNRQTFvRDVjb1pPVnNxNXcyTWEx?= =?utf-8?B?L0lnc1YvTzU3SkNCVmQ5MjZaa0dubTg1QnA5L3JrVzJQUVBDL3BneG52Wm9E?= =?utf-8?B?ZjZtVnRRa05WZEJZa3QyajlXRTZwT2F1Ymc4ZWZYQlliaVFWaWNRTFNXYU1H?= =?utf-8?B?K2tydzBQU0dFaERQcVAwZWEwZHlCb2FMN01BMCswSldKYmM5YVAzYUFVVTRU?= =?utf-8?B?NEZWT0Q4bUFSNDNzVUxEdzJxODFqUzlsWHQ2Y1hYQkMxQldFcWZPUWVNaG9j?= =?utf-8?B?bENMOHF1VFBRamViMWduMGpUUXY0cjU3Sk1yQ2x2Zk5mci9JUjVCVmxHU1VX?= =?utf-8?B?ZDdzZGFSZEVKSlNmSnR1QWxzQjFRaVpSZllkQzVrbVJrYUJid3MrOU9rdzls?= =?utf-8?B?ck5CRlNVZkRiY2xMaHl0cXRzR2tSN1RZTE0xSkUrdzFSTEZQMEV5TTN0NVlE?= =?utf-8?B?UGdFVGdLWVhVMVAwYTAwU1BrU3FMQnpVVEJ1MkFZRXQzQzRUR3hobUZ4bEl2?= =?utf-8?B?R2piQnRUSXZud3hWbTZ5NGdpaVpBR2hFU3JlUDJ4MEpVQno1U045SThCcDNn?= =?utf-8?B?WkNqR2loNFRKRVY3dEFyWHNUd1NlQnUzWW5xa2VhRmRwcDZNSkUwbGdnWXll?= =?utf-8?B?R3pHdWg2UGZLSURxdjgwSWpmMnQvTThyUVVuRElMaVBGSzRJR3RxNk1kVk50?= =?utf-8?B?LzdMOElYcGQ2clFBYzdOWXp0OXQ2RlZZeUpIMnVOZllmejJaUlVkUnlrRURB?= =?utf-8?B?anY3RUdxdno0NHl0VUljTmhKaE1wUjh2VFdzTEZOa1Q0ZUhTWEpWUUREZzk3?= =?utf-8?B?MUFveXdsUzhWemVPSXpEdEp5TWVUWG5obmdCUUt2TWdXQ2VxamxCV1EwUjEw?= =?utf-8?B?c01jMlFvQXpZM2ZNcVo2Z2FaTWFORU9yTXJiZTIxbkhrcVQvcG9lcFBSc05j?= =?utf-8?B?Z0NXWEkwT24zV240OVV6UkYwTUF3YXRCVGRIdWRZbTFFMHc3U0I3N2t4MXIr?= =?utf-8?B?NTVlTWRGS0xRMHhScm03V1ptMzV6czZ1aHRPTjVGakdDK3FrN2lGY1VYeW13?= =?utf-8?B?elFKRWwrdldHUzhFblFpeGp5b0s1ais2ZXl4cmVkeHVyR0lpZEFMYmc3VjRV?= =?utf-8?B?SjZGNUJLd3l3TEFrTm1wUFp2UzRUdi9ZeFdmNG5pSGQ1L2l2anQ0Z2ZBUmVl?= =?utf-8?B?NmdUSHh5NEJxR25OS0N3UVhlZDFLU3UvWFBDclNHSU5kdmJYbGoxSjlWUmlV?= =?utf-8?B?ZVdBekRPWkpCeTducDFvbFVFMTk1em5MMExqaElSbnpKS29semFqUXpGdzM1?= =?utf-8?B?TnhZNzh2RFRGYnNrTXl2Zz09?= X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0699; 6:zY90VaVaxd0QZCDvbZ338hThhWsCnlACjFjj4uy/JwGTqP9v8kbCcNTcOzK98nZ2A2Cee08lJAItDl2J9D6cDH6x1FWNd9iGDVLzKYt8MX7laGgbQRmj5lGs1QUMs8fnGXF3MWu1mbgWzNthKpZKwh5oyD+yvqntI2foEQ8CI2zq7gUgY+1rAaURXzRw7L2JrW3xl2X5CSVNLoMX5bVxpzAuv+NJY+B1XV8YdNSIJTVjmgCfl1e24m1j7FWLaPoK+Zmc5geN4fo0ey2LpyoYedZ1iRYYkBt/s2gG/95zECXxGmCO7D/9c3zp8sgaowUx9PcBC9bgQGsAKWqSYx5urn4Q2T//bmCifCRGD0bX8K4=; 5:1AeM/JuZTG+HCWrIxZs0AQ8ciATYHhZwRcoCgAk5qZf8jW5Uow2E0qAHhVQZhr11S4lK2+pQ7az2rIKZqThI+cdnxdkpyKME27+/HVw0vOzOxoV6UqYOg0eIUQzXihE/2z6YAN1DKzY8bbpiqasJM6vJvoUYdSfEpL0yLoMUKEQ=; 24:U4HvvmVeUGBXlWDjibkaI5ZMENaq1Tc0V+JNMRHltvHljsET5rjKDcIHf9XNJsGMavfHMH8OVb5gPcEY+/qnGduoa30rfhiE18wIWXW00Hg=; 7:uuZtsC7GUx8YZ/HwK+gvp9b5RYmLWHYLqMddF/GozkglJny0mXR+tEoX3ICwBF5GQ2BmLaQQ96ndjkkei2EPm/hqxBPw8h+tM/qoeoUMMag6MzYN0vs7UrpIp6SkKiZE9HB81WtJTKWyR6KeiSYzu3EhCbib3IW3U3PqNnboPLOT1/30+tU5Rh9/diDlrQVLCoUxz+lXNub7OBqzmJTs2R/e6SyU5O6d3glb2H4yV3QY+/Kv9s8UXnXMdOHRbwr+ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2017 18:30:42.4712 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 372e09f4-2844-4b26-cbc4-08d547d7c86a X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: SIXPR04MB0699 Archived-At: Subject: Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 18:30:56 -0000 > On 16 Dec 2017, at 2:37 am, Joe Abley wrote: >=20 > On 15 Dec 2017, at 10:31, Paul Hoffman wrote: >=20 >> On 14 Dec 2017, at 21:45, Geoff Huston wrote: >>=20 >>> I agree the mechanics of the change in the text, and even in the = code for support this are pretty minor, but I am slightly worried about = the intended generality of the proposed change being a small step too = far, so I am curious to understand why you are advocating this change. >>=20 >> Because the root zone is not special for DNSSEC. >=20 > I agree with that philosophically, but not practically. >=20 > In practical terms anybody who has a non-root trust anchor installed = has a bidirectional operational relationship with the people who publish = it. Synchronising that trust anchor, with the glorious benefit of a full = list of relying parties and knowledge of how to interact with them, is a = far cry from the situation we find ourselves in with the root zone. >=20 > While it's conceptually elegant to have this mechanism easily = available to the operator of nameservers for any zone, it's not clear to = me that this is supported by a tangible use case. >=20 > If changes motivated by this desire for elegance weaken support for = the one use case we have, they seem like a bad idea. (Not saying they = do; I haven't thought about them that hard and in any case I am not an = implementor.) >=20 I share Joe=E2=80=99s concern here - I prefer the option of a simple, = focussed mechanism that reports on a resolver=E2=80=99s root Zone KSK = trust state.=20 I=E2=80=99ll leave this open, but will not incorporate Paul=E2=80=99s = proposed changes into the WG draft unless I see some further WG comments = in favour of making this proposed change. regards, Geoff From nobody Wed Dec 20 10:34:32 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE8D12D0C3 for ; Wed, 20 Dec 2017 10:34:30 -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 4LjxhCSjNkYR for ; Wed, 20 Dec 2017 10:34:28 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0084.outbound.protection.outlook.com [104.47.124.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F43B1267BB for ; Wed, 20 Dec 2017 10:34:27 -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=2jhUXmF3zRhc9V825HqYiLCvqbqvPWO9BxtmJQTEzcs=; b=pPPw74nx43c8mmX18s/Ymrw2vEHu129cLVpGvpg6tivQt0fFr4lJpid3b2NpcsviogU87NLtlKExePRJw04iIfZMEKhgDnC1yIZZvI7CC5Ji4K8eRsbIOQQgK/6MLrEvI/mugU0lVoldKU+j8/y9AIsPRvEmZ6Xi5R6sX9S9K6w= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from 2001-44b8-1121-1a00-dcc1-842d-fce2-c598.static.ipv6.internode.on.net (2001:44b8:1121:1a00:dcc1:842d:fce2:c598) by SIXPR04MB0700.apcprd04.prod.outlook.com (2a01:111:e400:51ee::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.9; Wed, 20 Dec 2017 18:34:20 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Geoff Huston In-Reply-To: Date: Thu, 21 Dec 2017 05:34:08 +1100 Cc: dnsop WG Content-Transfer-Encoding: quoted-printable Message-Id: <332B908E-77C5-4E9C-B49D-19AFC1A3E76B@apnic.net> References: <5E1FF941-C80D-442C-ABB5-6C81F3B1A149@apnic.net> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.5.20) X-Originating-IP: [2001:44b8:1121:1a00:dcc1:842d:fce2:c598] X-ClientProxiedBy: HK2PR02CA0209.apcprd02.prod.outlook.com (2603:1096:201:20::21) To SIXPR04MB0700.apcprd04.prod.outlook.com (2a01:111:e400:51ee::22) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 637fa793-eb2e-46b7-b3d5-08d547d84a4b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:SIXPR04MB0700; X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0700; 3:VENb3EacQdxpZJ/sw/ao97/dw0wyoYUg6UHJjwipSj+8mWmNW4IPrS8erPv2C1e+C8C1iYHhnig1OFQp3IeMpdLzPUgT8oydplVqzCLF1xNgHBz4+NsYHFkrcIU7OXsVVUJ85s4nph0XQVs3ZKABtctzlFvIfNj3LGL3gxEkuLX3PmpzUEzhkv/6ZuOa5uvlIYg5uKDPVw92qYwn9WiHqEqiakvqs0AqCnu0/PKO134AsXTGgCf8klr+Kk9lHZd7; 25:x5bJGJrk2XNtvjcf9OGqMSElYT0f7Oke3FwPJ4R5ZkrJMSD/Vctdyy1AnJkR2TyXjeQV9B8EKzxtrpqiKMdLQZ6EgDvjqkO6LVOuUud/NBv/JSH6wG3GHTNjetAo5oNsk4qACAST9gy3x+oi6qfmFThgxnmNvQkGj/q9mE6lh2Sj14puz0WvGjLZAunDVbHOQGMHa1OBfPsQ6f8dQdqxv2TLeBei6zKA1/armEA0kc/Yl0dkFca10k24L+xGGV17GdjFAy5UpamQfzvY5hfN7EWKsT8Voi2sYvf3Z73UoJ8viD6CpTWTFkL1ULpkYqvJljGwsozXnRKF2LzrjIz7ID2jMNKT92j1VqHIz97Ec+0=; 31:iGOVBQR8CHcyDA6qFcldueCIETJzqFO96slBH8IJVd25isF9i7Glyl5rEsh95GvvOMv3h83WlnTx/jFgjS45scZsGCiWqRLlr2DKMYV5wJiqOuJT6eEHx4xAboxQcoCLLAh0bUMTrCgVYM1+A9pQ/LaCKjbsQ1NnAiJCReMwEcw+3fesZVxUxkbSZMBiBhv34KheX5zfqzoV/krFDdOua6i5fmhuOWsopZ46yEc+eZA= X-MS-TrafficTypeDiagnostic: SIXPR04MB0700: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(166708455590820); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231023)(10201501046)(6041268)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:SIXPR04MB0700; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SIXPR04MB0700; X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0700; 4:dyPtiKAL30nu7awDTnjkxfaQ834BKGPIHWLqHNxhZwefjQfzR4CuHO46IUWJAjn/8J3LhNxzWwcIfca4K16Fc8poD20UnaW4DFbr1pkbbj2Hgd0olnrDbUHxsQpaImazwChWmwYlgX83iGCGVkUuOCMvLnLFasaOO868Nd3PLRMclR6/pZsV+qrA6G52vLSLo1sFmENVNi0lRaY2+LiECQDLDuOV4HgN/hbkTzSjxewyGsNuqg6NeGXJi3daO4r1AezyrKawVzGP+LDQVOjOA4Cpqnwm4NKO0bHihr5ni9eCZqjBs3UgYVny7HLsSayP X-Forefront-PRVS: 0527DFA348 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39840400004)(346002)(376002)(39380400002)(199004)(24454002)(189003)(50226002)(2906002)(316002)(6116002)(6306002)(5660300001)(81156014)(6666003)(6916009)(81166006)(6486002)(6506007)(386003)(2950100002)(86362001)(83716003)(33656002)(82746002)(8746002)(6512007)(53546011)(305945005)(8936002)(68736007)(8676002)(7736002)(76176011)(478600001)(106356001)(25786009)(52146003)(53936002)(57306001)(6246003)(4326008)(36756003)(229853002)(97736004)(2486003)(230783001)(105586002)(47776003)(52396003)(50466002)(23676004)(52116002)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:SIXPR04MB0700; H:2001-44b8-1121-1a00-dcc1-842d-fce2-c598.static.ipv6.internode.on.net; 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?MTtTSVhQUjA0TUIwNzAwOzIzOjJ5bXg5YWZyd1VPSHJSS3loajVSSS9XQ3lV?= =?utf-8?B?aEhISlgvMUZQQnVGS3BkL2pKeHU3Uy80MkwwSWJLdnRyS3ZteFgzVWZCV3Qv?= =?utf-8?B?dnVERTgvcjhLYitPY1hqcWFTaUplb05qd2p6SXl3WU9mNi9WclcrWm9hQjJW?= =?utf-8?B?cEdTS01QWDdDNnFGM1VRUmhncVNjWERPazg5RTZpSGRkVVI3b0JuaCtERXZt?= =?utf-8?B?blI0ZklZcFdNZXBabDVFdGNVQUt5MFYySENvcUd4cEJuRkdQUGlmcy8vS2Vz?= =?utf-8?B?QVJ6YUNBK0EvTTJyS2hEd0hCKzVGQlpmdzBuNWtQajRLWVV2QVFaaE9vQ1Iy?= =?utf-8?B?SGMxZFRleWtyc0VPb0lFaXBaUUNQa3o1MlNoUWF0eFNyWGhYZFhPMnJ4SzdM?= =?utf-8?B?TG9zSFJOdzhaODArbEZnNjBpamNEejNwcXNiRUF2QmFTRlJkTi9qZUR2YVgv?= =?utf-8?B?WUFMQjdGWVV6aEZQM0FudGh3Y2xVK1RuUW9oUi8zU1h6N3dBbUQxcitDTzM5?= =?utf-8?B?MTEwTTY4RU9mTVpjaGRhbGJqV0Z3RFA4RzdIelovMllHRWVQU3lXZTNkMmhV?= =?utf-8?B?eWN5L2RVYXZuSTN2MTkzS1dlcS8zdytCYnB6YlNLSy9wTzF5NVlESTBDbXBl?= =?utf-8?B?Y0JTVy81dlFwRllpcS9iT20wQlFqRGVJeHdjUjhlbiszKzV3OTgzUE9ndmxI?= =?utf-8?B?Q0NndDNab0ZETHh3bWpqcnowN1l4SFk3UnV6K3QrYkRlOTI2RGlqc1c4cUJh?= =?utf-8?B?dUZJTTF3a25qTXExM2RjdjhWNDJZWjRhelBvcTBBYWxyeDdpQWlqR2p5cjVj?= =?utf-8?B?Q3BzWVdwUDltWFpodGV1V2hTbkZ2RU9FNHRKbXlXZ1FkNSsvZUxJTCtmNUdV?= =?utf-8?B?dUJPcjlyQklmRENFMFBUbDBzWkRyOHVMZWZpajV3TzRDQXJUazQ3N25ubUho?= =?utf-8?B?M2FtN203VkR5UWZ6NEFHd0I3anluKzNXYkJzcTVReWJwYmM2VDNaVDhuZFpU?= =?utf-8?B?di9JaUxKRXdkSWh2cXQxbm5Ic2s3cTBCbEpOc0lwMGVjSmc0UFZXNGxGMFBE?= =?utf-8?B?TkQ0S0tkZ1k3NUwxblNtRWZSOHlKajVwMXc4b00wd3lXWTF6bUt5WHdtdXdz?= =?utf-8?B?eGwveEVtaGxiL3owZ2pWV0ltd3pCb3lBTTdoa0RPWVZ1QVNTUFNaOVo1U2Fx?= =?utf-8?B?bXlmWDlEcmxlV2NtL3c1anU1U1U4RGdXd1NtZWd1QzNGcUpwUUk4T2ZiQ0Fx?= =?utf-8?B?Wm8vMWZZK3JIUXVFR2FsM290NG5nRnlwWSs4ZCtJWHFQc2ZrRmI4cEExVWpa?= =?utf-8?B?Mkl0QmNyK2dNV0luY2Z6V0V3L0sxcm51TUVPN0dkdllZNXhIWUxuT2lsbU1Z?= =?utf-8?B?c2JCM092ZkJvR3d1c1Uyb250UUFwYUpySzlQbVhnZUdyZVB5SFpYZG1OamVW?= =?utf-8?B?WEF2dWx0ZUxaZTd6TWtLa21keHBZeGpQM2tJYzVYcU9RZUhkYkQrVnNvN0dU?= =?utf-8?B?aDFpdHI2aStVcDV5MmNMVUpiRXM3QnNQRWVOdjN3K3hIcmtpUzI0Y05yK2U3?= =?utf-8?B?QTlaZ1k4aXlDNWoxSzVhdEtTTzJyeHZ5bXRDc05IY0R0MmVEY1M1VmZjWSty?= =?utf-8?B?eVdTRDIyTEtmQ3hRMHpDNi9WR1hzemh3b2ltNDBIbXJWUUUvWE5RR2RBRzBN?= =?utf-8?B?L244SFdzNEZ2RFo1OVZCbVJpZkpGY0s2VzZBN0p2aXBTd1JBL1FYNmRSWTRD?= =?utf-8?B?VWFkZWFZMkIwRW1OTm5JZz09?= X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0700; 6:uFMUvLtE4+TNeOtDpe1JdZUHcWkBPRQbbx0Cqzel2XrZY4vqWf+COspktMUrNt6RiZHaYAkGrAbaPCHsP8IZJdjlSOqf9NjFL/fmjnO7EATFsW6Dur0l+WOD4M/Tpmno4GFHD5AiEgBP6tHTZFxJA79obmzobXpwnbTk0+YbNxzTJ36AslpUeAXsXx+MCyFoewPOdJgHmhwu3eT3Siv2VVoxy81yP4XFg+UEQWlEhsU13uszi74HN90+BgcRdHMqnFN2abeOcvZyXF38tYlsMRuLFxd3GTTWnSGJipxX3LEIpC4PzSQAWzBT+285Ad5589CXK8WyUqXhe88R5+VKDXBkqrPQe/2foMZWUWMDi+M=; 5:4nGDvFp/5vzDo83SuyGugnBEf0AF6O4C+VvISN6yztJ+RbmcKElj5MgpxSKHMRENt4xTb3+APkOFm8S9PyyKvc1r721x2kRHUZhOxTLJ4NqXFM+xXyhqlgBD+15Y82n/V40nJ0z3JOFGP6/fOV0VEhBzWBPd/a4sfurml/tjgNY=; 24:978UlSXdDUqirk7y1pI81yi0cIdGWk5yIH0I3h4Q/mUwI4d+eFxgAXExD5LxkFk8FJ67vcm/ElQoce6TK4+NSJPuK4tNeunaQwU502jv9/A=; 7:YtQ+GzFDOBnPh/6+0PVh3D2Ws0f6GkVILUwbCRqdfhD8XDv1C9JsI/AYfZ+VrhBm3aQ5nFzlNRXk/GsMtGF7iajd+WxJ1ULHzdrSIAo/SuKGP+0uytAsrBsKRwOVjTwvgYBruXn88j45+o/nBSCJzLzdj3An7qEe8EUoW/UI2oMhg+K+7Itcsr8jTDsgjNOIMqKMRedgrdUi68SscQxKRKs7Im2oAbp2bbSLijpGULh7fEnWyM4tRD+VoY88gIFV SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Dec 2017 18:34:20.3712 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 637fa793-eb2e-46b7-b3d5-08d547d84a4b X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded X-MS-Exchange-Transport-CrossTenantHeadersStamped: SIXPR04MB0700 Archived-At: Subject: Re: [DNSOP] Making draft-ietf-dnsop-kskroll-sentinel apply to all zones X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2017 18:34:31 -0000 > On 16 Dec 2017, at 2:31 am, Paul Hoffman = wrote: >=20 > On 14 Dec 2017, at 21:45, Geoff Huston wrote: >=20 >>> Please see = . This is a = small set of changes that make the draft not treat the root zone as = special. It allows the labels to be used for any zone, not just the = root. >>>=20 >>=20 >> Could you please elaborate on the motivation here? >=20 > The last sentence is the motivation. Some operators add trust anchors = for things other than the root to their validating resolver, and a user = might want to know if such a trust anchor exists and, if it does, what = the key tag is. >=20 >> I am unsure whether this is needed, or, perhaps more critically, = I=E2=80=99m unsure if this represents a harmless general form of = information disclosure (that the resolver is using local trust keys for = some unspecified non-root zone). >=20 > Serious question: in your mind, why is the answer for non-root zone = any more "information disclosure" than for the root zone? I suppose that I am concerned that a resolver is disclosing that it has = some other trust point in the name space.=20 I would normally have thought that such choices of trust are choice a = resolver makes, but does not necessarily need to reveal to third = parties. Geoff From nobody Thu Dec 21 00:19:12 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE47127419 for ; Thu, 21 Dec 2017 00:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 dPmuA1SluY0g for ; Thu, 21 Dec 2017 00:19:09 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97A81200FC for ; Thu, 21 Dec 2017 00:19:08 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 568567A3309 for ; Thu, 21 Dec 2017 08:19:07 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) From: Viktor Dukhovni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: dnsop@ietf.org Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <588463BC-7B9E-4BFC-AD36-C5D408703F8D@dukhovni.org> Date: Thu, 21 Dec 2017 03:19:06 -0500 To: dnsop@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [DNSOP] NSEC3PARAM iteration count update X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 08:19:11 -0000 [ I'm also posting a separate copy to dns-operations@dns-oarc.net ] In light of the observations in: = https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-= 05#section-2.3.1 I thought it would be useful to take another look at current practice. To that end, I gathered responses to NSEC3PARAM queries from the 5.147 million DNSSEC-signed domains I'm tracking as part of the ongoing DANE SMTP survey. This covers all the DNSSEC-signed domains from zones where I have a full field (.com, .net, .org, .se, .nu and a bunch of the more recent gTLDs for which CZDS provides access). So the coverage is = primarily incomplete just for various ccTLDs (.de, .nl, .ru, .uk, ...) where I've managed to collect around around 60% of the domains from other sources. The overall sample characteristics are: 5126588 successful NSEC3PARAM lookups 20820 failed lookups (ServFail or timeout) 3598119 NSEC3PARAM RRsets with 1 record 6 NSEC3PARAM RRsets with 2 records (two salts) 1523390 NODATA (presumably domain uses NSEC rather than NSEC3) The below distribution of iteration counts (rounded up to the nearest multiple of 10 for values between 20 and 2500) is largely concentrated at 1, 5, 8, 10, 20, 40 and 100. Values <=3D 150 should work for all key sizes with a correctly configured resolver, so the vast majority of domains don't have any trouble with secure denial of existence: #domains iterations -------- ------ 115 0 1501953 1 3513 2 92 3 10 4 58907 5 21 6 322 7 941391 8 17 9 194324 10 5 11 229 12 49 13 2 14 599 15 8778 16 4 17 1 19 317662 20 167 30 37138 40 3834 50 3 60 13 70 28 80 4 90 528157 100 32 130 1 140 307 150 3 200 1 240 49 250 1 260 261 300 70 330 3 400 1 430 24 500 24 1600 12 2500 1 4096 1 16384 2 65535 Of the 453 domains with iteration counts above 150 only 4 have counts in excess of 2500, which are unsupported by many resolvers with the default RFC5155 iteration count limits. The remaining "interesting" domains are the 449 with iterations in the interval [151,2500]. Of these: * 258 have 512-bit P256 (algorithm 13) keys and 300 iterations. This exceeds the RFC5155 iteration limits and breaks secure DoE for many resolvers. All these domains are hosted at "ns1.desec.io". * 1 has both a 512-bit P256 key and a 1024-bit RSA key and 250 = iterations in excess of the limits for either size. * 1 has a 1024-bit RSA key and 300 iterations. * 7 have 768-bit P384 (algorithm 14) keys and 500 iterations. * 2 have P384 keys and 200 iterations. So, in all, 273 domains are misconfigured with counter-productively high iteration counts. So the problem described in the draft exists in the = wild, but is, for the moment at least, quite infrequent. The vast majority of domains use sensibly low counts (with 1 being the most popular value, = though frankly 0 would have done just as well, but is perhaps not as well = understood). With a bit of luck, better documentation and tools that warn users to not exceed 150 (regardless of key size) will keep the problem largely in check. I still think there's a lesson here for protocol design, quoting the = draft: A simple design would have constrained the iteration count only by the bit width of the iteration count field (perhaps 12 bits for up 4096 iterations), with all representable values supported by both signers and resolvers. At this time, I would say that just 7bits for the iteration count would have been plenty. Few users want to hide their content against off-line dictionary attacks so badly, that they are willing to pay the cost of more than 100 iterations, and most are happy with 1, 10 or 20. So an update to RFC5155 that sets a flat iteration limit of 127 and reserves the leading 9 bits of the iteration count would IMHO be a good idea. In any case, protocols with integral fields where only a subset of the values is supported, and the supported set depends on other parameters is a design feature that should be avoided. --=20 Viktor. From nobody Thu Dec 21 04:31:18 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA19312D85E for ; Thu, 21 Dec 2017 04:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ucd-ie.20150623.gappssmtp.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 4FQUlA0Oi2am for ; Thu, 21 Dec 2017 04:31:13 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 7C4D7127869 for ; Thu, 21 Dec 2017 04:31:13 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id r78so15713474wme.5 for ; Thu, 21 Dec 2017 04:31:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=KHNJsT3BDqUQd8Ak6gjDn43+5Mkuu4bB/ggjH5UYmWs=; b=TfEnyjRBINQ7uIXIyWHFjbDMDuE1TwhuX6vshu9aoQ3Sr6yo+KacwkyRMY5wJwAS1f hiNnUePWKaUnMyGF6TbbfMeqv1H+8QD6cc58DI4FQTWkGYHfvimptHslqXF4jLO8ZG5b FhMM+Vdk3j5ww2yqYLaUp2iO6gW7vYLtF7oWqjzwfRHGJWyIOYoh+ZphAjNek0D1EzYr YC7yZD8GX0MfwNWVBArYFyNf6H5M3AbVTY+f/zwMUC9gGiATKB7jAmJDN0v6UBnuP3lc FdxLkjHIC9ZtF1AYRQvX+FJPkZgFW/ubUiIk5HH2ROeYQl2InBc1K3p/HtEBDzVHTVVf toGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=KHNJsT3BDqUQd8Ak6gjDn43+5Mkuu4bB/ggjH5UYmWs=; b=q7nDzrma3Z932gwNv/I9QJUB+kfw+fIQnqUlSDQVc/TGjg3BikElFsnXqC6VlkHv6S MbtYcD+g/6EdzXaveaRe+rEDNrQzP9W+DwIvfSv5MymWP52EhZeIi4/hVfxgAzVIzMsT aFTvbVR7r1vT2OxGQhuzwXvQPwGP+Q3Z3R/jB3LxCgw0QGjNQN0Vmt3YORov2t21fo9e nzJDVmrOBt+AE/26/9+NnmTR0Je30ah0mupSp5eY65q5jXFR5YAKM1ox68sk154RuiHw OGSgQ8u+8UaHHMO6O7OI9+pb33jfALOCpEENE6bf+x86914ijPseVBm1RVMOqCVukyAl +3Lw== X-Gm-Message-State: AKGB3mImbKbvwJzOcxH/j5pUDFxW9MglO1u8Z7xzZrskVqQKX+qTRnr7 url3rZn6pIoaD1n2H6JPtEpzd57Z4iI= X-Google-Smtp-Source: ACJfBovfJaVxifJRheaT0t3uQuaBN0zXG2NrOJYernC09ms2owrSMAsLHVUqcljtxmhzEro9w17bJA== X-Received: by 10.80.184.23 with SMTP id j23mr10031447ede.115.1513859471803; Thu, 21 Dec 2017 04:31:11 -0800 (PST) Received: from [10.0.1.162] ([2001:bb6:506:8e01:e080:7848:e2cc:cb39]) by smtp.gmail.com with ESMTPSA id h56sm16401522ede.45.2017.12.21.04.31.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Dec 2017 04:31:10 -0800 (PST) From: "Niall O'Reilly" X-Google-Original-From: "Niall O'Reilly" To: dnsop@ietf.org Date: Thu, 21 Dec 2017 12:31:09 +0000 X-Mailer: MailMate (1.10r5443) Message-ID: In-Reply-To: <95695b68-9506-1ab3-ae1a-f2c1f780ed69@oracle.com> References: <20171130133600.447a2904@grisu.home.partim.org> <20171218141112.56cxoc5nvt3wlsdf@nic.fr> <20171219042014.390cbfd7@grisu.home.partim.org> <95695b68-9506-1ab3-ae1a-f2c1f780ed69@oracle.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_EF3105EB-5446-4263-A9BE-E178777C20CE_="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 12:31:16 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_EF3105EB-5446-4263-A9BE-E178777C20CE_= Content-Type: multipart/alternative; boundary="=_MailMate_B67FB8BA-201B-41DE-98DD-6D333A2D99A3_=" --=_MailMate_B67FB8BA-201B-41DE-98DD-6D333A2D99A3_= Content-Type: text/plain; charset=utf-8; markup=markdown Content-Transfer-Encoding: quoted-printable On 19 Dec 2017, at 7:09, Richard Gibson wrote: > 1\. "Domain name" is defined as =C2=ABan ordered list of one or more la= bels=E2=80=A6 identifying a portion along one edge of a directed acyclic = graph=C2=BB (presumably starting at the root). I'm not sure why one would presume to start there. As I read the followi= ng fragment of RFC 1034, the list of labels explicitly starts at the node of interest= and is read towards the root. The domain name of a node is the list of the labels on the path from = the node to the root of the tree. By convention, the labels that compose= a domain name are printed or read left to right, from the most specific= (lowest, farthest from the root) to the least specific (highest, clos= est to the root). Best regards, Niall O'Reilly --=_MailMate_B67FB8BA-201B-41DE-98DD-6D333A2D99A3_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 19 Dec 2017, at 7:09, Richard Gibson wrote:

1. "Domain name" is defined as =C2=ABan ordered list of o= ne or more labels=E2=80=A6 identifying a portion along one edge of a dire= cted acyclic graph=C2=BB (presumably starting at the root).

I'm not sure why one would presume to start there. As I = read the following fragment
of RFC 1034, the list of labels explicitly starts at the node of interest= and is read
towards the root.

The domain name o=
f a node is the list of the labels on the path from the
node to the root of the tree.  By convention, the labels that compose a
domain name are printed or read left to right, from the most specific
(lowest, farthest from the root) to the least specific (highest, closest
to the root).

Best regards,
Niall O'Reilly

--=_MailMate_B67FB8BA-201B-41DE-98DD-6D333A2D99A3_=-- --=_MailMate_EF3105EB-5446-4263-A9BE-E178777C20CE_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJJBAEBCgAzFiEE8gFTJFuOkmd9Gtxz5N4O614kXW8FAlo7qY0VHG5pYWxsLm9y ZWlsbHlAdWNkLmllAAoJEOTeDuteJF1vzmEQALD+RH+huAbMMC5agq85BoS3GTyb 89pHlraaK6jyjgLSmcmo4FkXZnKbJom4Z4GSD0SdCm05TbuCWhhEcW9w8nsb8Y3q uyniLmj55RZEKU+dKwDdUwsciYw1V39daMgt5RnwlFXHpN/Hh1e5ZJDUui6BMlUv ixvOMuJcx5YmLqSFf3Rz/V8QsGBjaMR/L8jhu1vyzV4WNwuOJE3QiUlIAXJuPJso QKFjR7771d8Gbg9ycrJ5RciMLR4D3VNx+swaa0eSvPbCz7I1pWtmA/8cPYUyJffH rBRw/oQQrEoZMiZtbLC3IkezPOhIABqy5cVdNbcI07gYBMA6Fjxw1ORW/FCkTW9b 8E4Bg/0GgnuUrEtgIx8iLJPtE2WT4OJVjjRGS72cUz8lp4a18XswrWhE+1mxK9TE SIQUkk3L+tRoE4melH51q3Q2en3nxsMX97z3Plm2599E9ZvvBsuHP2FecTQTiDPF FMJAqPhrpnwIn3tsGiJQNF61TSe9vHBn30yHrqObo4D+Z+tWpV0ka5lu35GzQYR5 SjTO2XHjRq2GBppB9hF386Xj1Yq20q0o/evkFXcGmRaCw54MTlc+SjC+yphyrarx y0qEy2VBJ8W7ra2DDztvXXFleDWTEo8rcwdJJbf8TuSeKyUypjwbg+engOpxy9HT K3WNCt9ltEvIkN6I =fn6v -----END PGP SIGNATURE----- --=_MailMate_EF3105EB-5446-4263-A9BE-E178777C20CE_=-- From nobody Thu Dec 21 04:34:23 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782AA12D861 for ; Thu, 21 Dec 2017 04:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ucd-ie.20150623.gappssmtp.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 HHyvD6gsXTyx for ; Thu, 21 Dec 2017 04:34:19 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 7617212D85E for ; Thu, 21 Dec 2017 04:34:19 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id b76so15614591wmg.1 for ; Thu, 21 Dec 2017 04:34:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=YaatDPR7uiLEh3QrkdvHNPhQvDYph9aj7aXeRQbdogw=; b=gkmTY6ifg/n+ss/0XLXBocpwpDhkAhyn89UxbKhnQ87kQUu1zvS2iUmCc/oqgcTyWv 1L+NWrgUeE7fLkoNEikfs6/vXB73cjbReBD+GR3/zHGGEEgoRj9hUKXqUIq4Si8BHi4t Xj0mZU+5WkP5dtnn6Bb1b+aRPGFrJ7OkqDP0r/DHVIRyGoqYl4Bfqz79Qx3XM4/0wMd4 +He6vtLBKbuhVSI8q2mtct635FqfLN1rvHrzhcO0ranM1ivzaOZsnfo4wp8f3CcVMMwZ Rmx2GSd5EL14HFRMCxht5+Mdr3nNTUks94OreF/44iQCNKmVavFdKdW57JcjYW9Vj/xL aj4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=YaatDPR7uiLEh3QrkdvHNPhQvDYph9aj7aXeRQbdogw=; b=O0DR5YK+J21lEkSH89LPnEqZl7T2y/ynmhn4eGxUfzz2uRHaV5CTqQSfeh645LkqtK 2a6py7nICoWKBMl+AElMNhwy20cS/2vEdIk369JjHg8TQxVDKDtwasShWkNYDx1umWpg JD5hsp5I8Y31spBdXS+hI2R8DlhIb2YkbBmuPnyLXue9ZMhRN/vnl2g8cB8XwbmUSZPo JLh6cvvWRch/p7LrV25VuAQYhPML3gGafYJB0cOWlvfK3rbUNaOhIHtfYkGWKDNqew7d RS3p6gexXwRA0cWhcyvxRJcFlc2P5BhhQV4MJzoQIYUlkKGk9DRzfKrsqFeKA8VZzn9I vdSQ== X-Gm-Message-State: AKGB3mIIQ4gzHXGdXcS+JA5JsPPrNBfyQanNtUI/4ckRDbrekuILf3fN zOIb4Kx1E/nagZZx4bm4TCDO/bC5cN4= X-Google-Smtp-Source: ACJfBovPQxvEC9WGAlKq3FwSMBMNNpb51fs6HcVmfGXKrbwpxDkirVT52Kuz88j2uvXGhS1QqLFIwQ== X-Received: by 10.80.181.70 with SMTP id z6mr10134134edd.201.1513859657681; Thu, 21 Dec 2017 04:34:17 -0800 (PST) Received: from [10.0.1.162] ([2001:bb6:506:8e01:e080:7848:e2cc:cb39]) by smtp.gmail.com with ESMTPSA id n3sm16789146edb.46.2017.12.21.04.34.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Dec 2017 04:34:16 -0800 (PST) From: "Niall O'Reilly" X-Google-Original-From: "Niall O'Reilly" To: "dnsop WG" Date: Thu, 21 Dec 2017 12:34:15 +0000 X-Mailer: MailMate (1.10r5443) Message-ID: In-Reply-To: <20171219110813.497fcd29@grisu.home.partim.org> References: <707A270D-94DA-4651-84DC-409FAA6793F7@vpnc.org> <20171218132446.w7o5x4mrz2ttprlb@nic.fr> <20171219035622.414457a1@grisu.home.partim.org> <20171219091318.zugag6shf5vrairy@nic.fr> <20171219110813.497fcd29@grisu.home.partim.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_E9879689-C838-459A-9D8C-1C08C29CDD72_="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 12:34:21 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_E9879689-C838-459A-9D8C-1C08C29CDD72_= Content-Type: text/plain; markup=markdown On 19 Dec 2017, at 10:08, Martin Hoffmann wrote: > Except that "child zone" should probably be "subordinate zones" or > something similar to also include (great)*grandchildren. If "ancestor" were acceptable, then the natural counterpart would be "descendant". 0,02 Niall O'Reilly --=_MailMate_E9879689-C838-459A-9D8C-1C08C29CDD72_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJJBAEBCgAzFiEE8gFTJFuOkmd9Gtxz5N4O614kXW8FAlo7qkcVHG5pYWxsLm9y ZWlsbHlAdWNkLmllAAoJEOTeDuteJF1vuDAQAJPP88SMz+7gVCVDfS1hbuM0dsdy fUZ1RkW5aD088z1DFILsvW2vIaZDXf7+VBXFMc8M2leW6KVK97FmJbuJMu1lhdTq fBzoP1mIGTKTRfVzjMyRzrutCs6qHTcgJdUy6Fj4KcWWm/PtXP8Q3OEvXNgeaEy9 YFMX/tzUbHQGLPyifG0t238dZHJKEMhd7Is8i0bfiSW074QU+p+s95h/86pRK6za PwUSpchq3BdDMvSP/gcN5E+8QzfX3dMtkrViWec8CDZLngHuGcu3gXnJlHdxe6ou r9QMOHcGhXyrn9jMtWYAWbJa349/6d4kGpSta6fY2VUi8zMlLwC1KyHgqwgNWagM NGp+Ax57YitqON2vN0Otk++vn32+v5lHedr4dVZXJxV64zQhhMbP9n/J6D8OQOhH vU+PA9yDEZHnW7qyM4UvcYCHvZq7ygeIioNeafDU2a/UX+zVdQ7DYBEI6LhsQDEW 4ptVLTV9itGsuv0CngnkDmTFsNwZkr8j2kI2/cRDNgEDdKxDuIrPEZr9hQ050iGJ f2BY8ZHIFlwApoiGUb/j859iiWPmUOmV8X5IXMbTl9IwsgAjlDnkdc3Y5AX1YZMj Ts/JlhUKKM4X3CtLMq8lUDQU89M2kniuRCpdfzrd8FSlgoM7EU2JqrNXlnBF7cMh FR0LaxSVN+Jxbook =nXZM -----END PGP SIGNATURE----- --=_MailMate_E9879689-C838-459A-9D8C-1C08C29CDD72_=-- From nobody Thu Dec 21 07:36:40 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42B412D886 for ; Thu, 21 Dec 2017 07:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=isi-edu.20150623.gappssmtp.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 CsdZamFsje2o for ; Thu, 21 Dec 2017 07:36:37 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 0A289124D85 for ; Thu, 21 Dec 2017 07:36:37 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id q26so3079471ywa.6 for ; Thu, 21 Dec 2017 07:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isi-edu.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:organization:mime-version; bh=Sqc0daiiJhGXo7yYBTxhYKTRMbojLfxYWxSHHb2UDKY=; b=yDBdWx9qRKpSsH/n2O03c2+OSo9padIvVfmi8J18HAa8Qr05/1P1yWNf76ASFgiTVS E7DqpfMQD5xcymUFZHskR9GhuEh2WhjUctkdXtuShqqFBJzsn/MywYm0d7v4UvnKHX94 cq4gAQbM3l563ZMu+WbwCEwUi6eC9RSrKG0t5QzmhYwDpVeMxMXAKA8p6xSjlYufZyn4 pwG21XOaKuPxI59hCXXgpYmlKX1CvynNHnbcEx45zplAPt3bI8XfMcwB65lyf6sTicpE MHyF9ZevflxWsXFccH1IrS5f78aLfcxoonFi7voX+Vrlxi4+4TIoKhxnJnE0vafL/kAw ddpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:organization :mime-version; bh=Sqc0daiiJhGXo7yYBTxhYKTRMbojLfxYWxSHHb2UDKY=; b=r9u1UU+7Eqs18DEL1DUBHBJz7PavoIG76euDq+o2q+KDaPrTaELPwZHqk5sNjCr3px di25PtP1YDZOOMwy3TfcxCCJGUhoPNg9hTBK6sJFPK6kFxd6NQAL0CVWZ6jrRr7R6v6w S6vF47p3x1n+U20YnnJLJWcktihlLa6VtnRyNzPmSWprUIgOX+G0I+tAxjsV1ehZft08 DW/ZxLqoZ3wccRnUt4BiYVR0NzGtF65UtUwvFmP/97Tsy85UJsED/S20oRa3Ca78Nz33 FaA3umx5RMD/gOZned9GJSNPA97O7f8iQ3CwZt0iAZy+W3vC/ej1PKlXzFEPkmRO6zMF Htug== X-Gm-Message-State: AKGB3mI3Nxyaj8y2ndlvQXUTHQPXDRpzHGfxUN3V1WD7ZCEppMzNJE6W zCQHJGxIjmOqxs3QuPTPOWsllx3l X-Google-Smtp-Source: ACJfBotRNQG/cdHwIACjVeFrmLyF8OzS0/Q2LFR4tYOcLGjSLZ0eES83QfmDj8JO4neWL6z/pRTDkQ== X-Received: by 10.129.88.215 with SMTP id m206mr7799004ywb.404.1513870595868; Thu, 21 Dec 2017 07:36:35 -0800 (PST) Received: from titan.int.futz.org (c-73-43-1-81.hsd1.ga.comcast.net. [73.43.1.81]) by smtp.gmail.com with ESMTPSA id e128sm8945987ywf.104.2017.12.21.07.36.34 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 21 Dec 2017 07:36:34 -0800 (PST) Date: Thu, 21 Dec 2017 10:36:23 -0500 From: Robert Story To: dnsop WG Message-ID: <20171221103623.045eed5e@titan.int.futz.org> Organization: USC Information Sciences Institute X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/5y9ysbK3ZovYKi2s4qpfBg3"; protocol="application/pgp-signature" Archived-At: Subject: [DNSOP] kskroll-sentinel responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 15:36:39 -0000 --Sig_/5y9ysbK3ZovYKi2s4qpfBg3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I reread the draft today, and noticed that two things aren't specified. The first is the contents of the A/AAAA RRSET returned, and the second is the TTL for the records. Maybe the A/AAAA record values could be used to return additional details? For example, whether or not the key is part of static configuration, or learned via 5011. --=20 Robert Story USC Information Sciences Institute --Sig_/5y9ysbK3ZovYKi2s4qpfBg3 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEawchBniOfXbYLEHAvyP5CRjTDmIFAlo71PcACgkQvyP5CRjT DmJXZg//T/Y+n9SnafFhPUYLhpS+H7yAT0Ve/obC604QMk7ESFc/ZV4V3LVALITH YD1WpXcX7dhnqXkOas8xH1VUC6UAQT0jX+aRKKUajtk+0lovGexs2oebnvTN4GLC gmMwIh66EZvVhHfLf9vVHSP0VLunlaf5dXKDNyN//ZHuihWAwAcNv5PsmTl0bIPS YrTTjGR+JRso9pZNhHC/PdDaH0Z4v1t3YDjjrQpeVGGjMa/czHGFDSmOJ36V0mfS oyU9r5WTJWVpV6hHLfNnxfE46L19vUGPKMGjb1ZAspC4sswkvMoaYNWdfGBUWOPA Ez9jEYq+lfHp3CEckvt+dEwXQueUTg0BpuFxKnLkJ/zkJ7IRbNJfgJtd/KABt323 vSa8In/16WY0xzesRlegYXaXpt09CaVIYF6tQ2dZcUwBiCbjnyv7QiRFy+83VOPc hQk6PixYi/G5lOmoZ6PdU8WCQM/iBQJiVYkBv8dCfkouY2a5g3gAUzmgvZuA6jy4 sQwzIlLRVNUcq9hrnjg6gvKVowoiZVCQ9l20mHFioaQSmaJLA2Ak2D+9ARTC6v9R Jv57h8ck774BpXoRVPfeASDxemFC6Qc1uuxIbrzGAFIj7H60/d3xxOekNcAAHLXR 2euweE87g7+IjVuiTdzZvyDLXGnxJ1cQ2HHAAZO944XBb3kCjRQ= =ZAbC -----END PGP SIGNATURE----- --Sig_/5y9ysbK3ZovYKi2s4qpfBg3-- From nobody Thu Dec 21 08:06:53 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBD1126D74 for ; Thu, 21 Dec 2017 08:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 OyFTjU-xPO0u for ; Thu, 21 Dec 2017 08:06:49 -0800 (PST) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 4DBD1126CD6 for ; Thu, 21 Dec 2017 08:06:48 -0800 (PST) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.21/8.16.0.21) with SMTP id vBLG6ToX123886; Thu, 21 Dec 2017 16:06:45 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=corp-2017-10-26; bh=Kqn6LJvmIZk1iHZh2LJWJY/mttddauNnpxxcjaprcaA=; b=e+KR3mngWEgP6NheTRJ85Pl2IL6b63mDzzcQj3GnkSzVXqRrwdokmh+H6kOJuwFvngqi dZr9xkqTYoECPv+9t0PEjID605nHmHv5mflXjRdy8dD/iMSP9Fuci50xhnhBPijmaPdW zfGEixtdEl1pdsA2LyobUT1mNnldVGs3BI8mmd57q9COf6EDyMcVfMaq8lgkTs1b32x+ yG4WRqzTSJVX38e02b/oo+A0GGKNWp5e9SpFdRp98ooRbAWEF2J6qezSBmBXqLClcQ3b vwntrUIwgWzoETLPdeqNwTA+3phtt/zK+wnEDn6gWVXIOglIGYAl6U+yCtZ/THFZNhUc sQ== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2f0fnn09vy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 21 Dec 2017 16:06:44 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vBLG6hUJ025489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 21 Dec 2017 16:06:44 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vBLG6dmE023345; Thu, 21 Dec 2017 16:06:40 GMT Received: from [172.16.4.245] (/216.146.45.243) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 21 Dec 2017 08:06:39 -0800 To: "Niall O'Reilly" , dnsop@ietf.org References: <20171130133600.447a2904@grisu.home.partim.org> <20171218141112.56cxoc5nvt3wlsdf@nic.fr> <20171219042014.390cbfd7@grisu.home.partim.org> <95695b68-9506-1ab3-ae1a-f2c1f780ed69@oracle.com> From: Richard Gibson Message-ID: <90cb3520-a714-d93d-f113-776d936de489@oracle.com> Date: Thu, 21 Dec 2017 11:06:38 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6E9D66E69512267037E8602B" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8752 signatures=668651 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=514 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712210220 Archived-At: Subject: Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 16:06:51 -0000 This is a multi-part message in MIME format. --------------6E9D66E69512267037E8602B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/21/2017 07:31 AM, Niall O'Reilly wrote: > > On 19 Dec 2017, at 7:09, Richard Gibson wrote: > > 1. "Domain name" is defined as «an ordered list of one or more > labels… identifying a portion along one edge of a directed acyclic > graph» (presumably starting at the root). > > I'm not sure why one would presume to start there. As I read the > following fragment > of RFC 1034, the list of labels explicitly starts at the node of > interest and is read > towards the root. > > |The domain name of a node is the list of the labels on the path from > the node to the root of the tree. By convention, the labels that > compose a domain name are printed or read left to right, from the most > specific (lowest, farthest from the root) to the least specific > (highest, closest to the root). | Two reasons why I presume edge direction to be away from the root: first, because it's consistent with the rest of the document in its current form (for example, the very next sentence after my quoted text describes how a fully qualified domain name "begins at the common root of the graph"), and second, because parent-to-child directionality is inherent to the DNS for delegations. RFC 1034 seems to contemplate an undirected graph, so can happily use towards-the-root for domain names and away-from-the-root for delegations. But I don't think 7719bis has that luxury, because "domain name" should remain valid even in a "naming system" without a single common root. --------------6E9D66E69512267037E8602B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 12/21/2017 07:31 AM, Niall O'Reilly wrote:

On 19 Dec 2017, at 7:09, Richard Gibson wrote:

1. "Domain name" is defined as «an ordered list of one or more labels… identifying a portion along one edge of a directed acyclic graph» (presumably starting at the root).

I'm not sure why one would presume to start there. As I read the following fragment
of RFC 1034, the list of labels explicitly starts at the node of interest and is read
towards the root.

The domain name of a node is the list of the labels on the path from the
node to the root of the tree.  By convention, the labels that compose a
domain name are printed or read left to right, from the most specific
(lowest, farthest from the root) to the least specific (highest, closest
to the root).
Two reasons why I presume edge direction to be away from the root: first, because it's consistent with the rest of the document in its current form (for example, the very next sentence after my quoted text describes how a fully qualified domain name "begins at the common root of the graph"), and second, because parent-to-child directionality is inherent to the DNS for delegations.

RFC 1034 seems to contemplate an undirected graph, so can happily use towards-the-root for domain names and away-from-the-root for delegations. But I don't think 7719bis has that luxury, because "domain name" should remain valid even in a "naming system" without a single common root.
--------------6E9D66E69512267037E8602B-- From nobody Thu Dec 21 08:20:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E78126CD6 for ; Thu, 21 Dec 2017 08:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, 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 36b5dhzMXRUk for ; Thu, 21 Dec 2017 08:20:12 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 29F0E120727 for ; Thu, 21 Dec 2017 08:20:12 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 58221281803; Thu, 21 Dec 2017 17:20:10 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 51A7E281808; Thu, 21 Dec 2017 17:20:10 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 4AD45281803; Thu, 21 Dec 2017 17:20:10 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 45A6D6427580; Thu, 21 Dec 2017 17:20:10 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 38C1F3FD8A; Thu, 21 Dec 2017 17:20:10 +0100 (CET) Date: Thu, 21 Dec 2017 17:20:10 +0100 From: Stephane Bortzmeyer To: Ted Lemon Cc: Stephane Bortzmeyer , Paul Hoffman , dnsop WG Message-ID: <20171221162010.yzln6hd6ciz4ft3c@nic.fr> References: <8CB86DAB-B80E-469A-9BDA-7F1361634933@vpnc.org> <20171218135211.nul66bgdxczmg4lp@nic.fr> <160A1E3B-0ABA-4A22-9128-0ED5B8577F87@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <160A1E3B-0ABA-4A22-9128-0ED5B8577F87@fugue.com> X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-4-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000004, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.21.160616 Archived-At: Subject: Re: [DNSOP] Please review in terminology-bis: Global DNS and Private DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 16:20:14 -0000 On Mon, Dec 18, 2017 at 09:29:58AM -0500, Ted Lemon wrote a message of 176 lines which said: > Now that I've attempted to compose this reply, it seems to me, and > perhaps was obvious to other readers more quickly because they're at > 20kft and not 1ft on this, that your real point is that the document > should not privilege ICANN over OpenNIC. If so, you should say > that directly Please do not tell me what is my real point. I know my real point (even if it is not always expressed clearly). When it comes to non-technical issue, the draft says, when defining TLD, that "the division [between ccTLD and gTLD] is a matter of policy, and beyond the scope of this document." This is the right approach. The fact that the root is managed by ICANN or OpenNIC or whatever is beyond the scope of this document. From nobody Thu Dec 21 08:29:59 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C00A126CD6 for ; Thu, 21 Dec 2017 08:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 i_QWDEGFDlmc for ; Thu, 21 Dec 2017 08:29:57 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 4390C120727 for ; Thu, 21 Dec 2017 08:29:57 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C9D14281810; Thu, 21 Dec 2017 17:29:55 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id C3E9528181D; Thu, 21 Dec 2017 17:29:55 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id BCFEF281810; Thu, 21 Dec 2017 17:29:55 +0100 (CET) Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id BA3FA6427580; Thu, 21 Dec 2017 17:29:55 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id B2DED3FDCE; Thu, 21 Dec 2017 17:29:55 +0100 (CET) Date: Thu, 21 Dec 2017 17:29:55 +0100 From: Stephane Bortzmeyer To: Tariq Saraj Cc: dnsop@ietf.org Message-ID: <20171221162955.y4her5sdyggsnf5l@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-4-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000001, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.12.21.162416 Archived-At: Subject: Re: [DNSOP] DNSOP Digest, Vol 132, Issue 53 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 16:29:59 -0000 On Tue, Dec 19, 2017 at 02:58:57PM +0500, Tariq Saraj wrote a message of 1158 lines which said: > using a firewall based on domain names can be simply bypassed by > accessing websites through IP address. No, no, this is absolutely not what I was talking about. Instead, I referred to: > Second, there are some firewalls such as Cisco and Kaspersky that handle > this situation when someone configure a firewall rule based on domain name, > it automatically resolves the IPv4 and IPv6 addresses for that domain and > update the firewall rules so that it cannot be bypassed through accessing a > server through IP based. Exactly. > But, these are highly expensive firewalls and normally not > affordable for every organization. Any 50 US $ OpenWRT router can do it (iptables accepts domain names). % sudo iptables -A OUTPUT -d www.example.com -j DROP % sudo iptables -n -v -L OUTPUT Chain OUTPUT (policy ACCEPT 184 packets, 22306 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all -- * * 0.0.0.0/0 93.184.216.34 From nobody Thu Dec 21 09:13:43 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FEC126CD8 for ; Thu, 21 Dec 2017 09:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ucd-ie.20150623.gappssmtp.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 MJDTs1UXtCAh for ; Thu, 21 Dec 2017 09:13:39 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 95D1A1242F7 for ; Thu, 21 Dec 2017 09:13:39 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id f9so17217028wmh.0 for ; Thu, 21 Dec 2017 09:13:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=qAiowDT2y3lJn8ZYf6ekAcpyIEQfq4tuKDIJhNaFAiQ=; b=yVejKYjAFrpD9optqskdIG2P1+4WmIhc99cGFCdrW928Cc5RChi2lLRhUKmfVx0o7I m1Hn8hdTx2He/NX0BFcRmyC84fHtrOG12phbE/cFrapyeoGg6bXCbSQjrqAUPmzukSj3 7zd17+Um1Z+iH6I0mWXVc/Qx0pWlT6xIpA2zjmwwkCY1ZRKPbUFpcg76eyQp+OTQE3SJ XAo8MmUXn1v84DEt4crYPnK41mBgcR2f1kLH7laMRXz0Qh2Cyqgp3c1aYWoDtYGPLCm8 sxPQeK7OQMLqUKvwKo82vN4HQjLCijSnY7kw9/SswCboYik7iW1jqs04cY1ECKSRxpy9 SS0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=qAiowDT2y3lJn8ZYf6ekAcpyIEQfq4tuKDIJhNaFAiQ=; b=qqsBmRT+H58idyEGBTR72HZZTkpAWfUHwwUb1b5tjBuHhZW14Pj3q2kzOWhwF0d0pp nDzZeqXUs0/9UuSji8VRYu3fsXBbjwiLGCWkp1nrj69QbN06+NNwV6Kd6lyoLHowB002 mSJmyGOUZNThSWHwF6gRfPQjfm+3bSP5M3rtnrQVgZz1a6qf3wU4+dcfSo7ouUHhl2iq LiUEsS0DfTrDefGmtDWlLvNOz05zyybOQyvhIZ0bCBn2HdYUorPgfke1crFzAMtjqAn+ chX2w3+xnkz5OXbaTyCR0TJ5StYFqUsN3rFzBhWRlBWr6sRPRaIEDSLQRo6+x7E+Ne9B i1Gg== X-Gm-Message-State: AKGB3mIUujBWRAMi5Y3JT31hFDgvZSD+zCxKFDW9NbzlLUVpk7EmAkBD wU2Jkrss0DvioPv26FbSXF/JrwGHupY= X-Google-Smtp-Source: ACJfBosqT8YLlPUKwlETXkgxy2HN0dpNyXICRcBq0E8rCRWe28EAw8OoQOihwoVFjPgZRL+T4EEMoA== X-Received: by 10.80.217.6 with SMTP id t6mr11291537edj.217.1513876417643; Thu, 21 Dec 2017 09:13:37 -0800 (PST) Received: from [10.0.1.162] ([2001:bb6:506:8e01:837:412b:5b47:dab0]) by smtp.gmail.com with ESMTPSA id t23sm18176369edb.70.2017.12.21.09.13.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Dec 2017 09:13:36 -0800 (PST) From: "Niall O'Reilly" X-Google-Original-From: "Niall O'Reilly" To: dnsop@ietf.org Date: Thu, 21 Dec 2017 17:13:32 +0000 X-Mailer: MailMate (1.10r5443) Message-ID: <8121DBC3-365E-4F41-A313-AA81AD03B61B@ucd.ie> In-Reply-To: <20171218141112.56cxoc5nvt3wlsdf@nic.fr> References: <20171130133600.447a2904@grisu.home.partim.org> <20171218141112.56cxoc5nvt3wlsdf@nic.fr> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_84571C96-CB4D-47A2-ACAC-9257C8104B89_="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 17:13:42 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_84571C96-CB4D-47A2-ACAC-9257C8104B89_= Content-Type: text/plain On 18 Dec 2017, at 14:11, Stephane Bortzmeyer wrote: >> IN-BAILIWICK > > ... > >> Also, on behalf on non-native speakers, a short explanation of the >> origin of the term would perhaps be nice. > > I like the Wiktionary (and it can be copied freely into a RFC): I like this suggestion. As a native speaker of English (admittedly conditioned by the period in which I acquired the language, by those who gave me instruction, and by the literature to which I've been exposed), I'm wondering whether it wouldn't be better to have "Bailiwick" as the head-word in this repertoire of terminology, rather than having separate entries for "In-Bailiwick" and "Out-of-Bailiwick". In the English I learned, a hyphenated adjective such as "in-bailiwick" can be used only as an attributive adjective (before the noun), and not as a predicate or complement (after the verb). Just as a five-year-old child is five years old (and neither five-years old nor five years-old), so an in-bailiwick name is within the relevant bailiwick, or is inside this bailiwick, or belongs to the bailiwick. For me, all of these alternative expressions, none of which uses a hyphen, are implicitly valid elements of the terminology in consequence of including "In-Bailiwick". I feel that having entries for "In-Bailiwick" and "Out-of-Bailiwick" is unnecessarily prescriptive, and that a single entry for "Bailiwick" would give sufficient clarity without unduly constraining the style of future authors. I hope this helps. Best wishes for Christmas and the New Year, and apologies for being late for Hannukah. Niall O'Reilly --=_MailMate_84571C96-CB4D-47A2-ACAC-9257C8104B89_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJJBAEBCgAzFiEE8gFTJFuOkmd9Gtxz5N4O614kXW8FAlo767wVHG5pYWxsLm9y ZWlsbHlAdWNkLmllAAoJEOTeDuteJF1vD+MQAMu43hKdEItbOw34MQU0Ya9BQg+8 eeTm6FnyirFqJW79HWdIo3I0afnOcmrAfEwgR3cfajNinKXKbPJtP3wRgp9AhjLb jyjzrpPDsdXNhGLbbjzJTg4l45N/t/u73llbrW7ZU9bOxyn2vKlCnwelzBGmylPY kuq5TC6Vyc9JlKO0tVqoxp+8qQPZtg7PtrfLyW6ZvE4xJZq9cveU/p1WAfiBd61Z +VGm9RoimE8BJUGWlIueq2Ds/IRZKW4dPA+rwvsrmg4GekIS4XIa7oeOykoY11Dj GluHmqADzoaGtAMon93PCmJnsbX3IEmNDxm1o+gHcvsvKoTGSWHT5l75Fx0vq0h8 Qes/Zhvq5hbQjK6WUajgdTjwOvXGDVjDcVb1MZMsuITG/+kZClM+IJKXj51L5dJP lJGaNaSCaQ7iObDFegxazVj+315oNhdV7wvFja/s96HCJA5stuSgdW47qV+PaQ/O gMh24Qfs/2S02pkpMTeBtBusDOgPHZVT5GujJh9sAJwFIfzSiJ+ztsBDqkrbyxB9 bheKArtTfIUb0nJ712hvbNIQxa+gM6uERJNQAkIyNm2EuGNuV4xMDyTKOuVHdQiB UxKWdmn+zx27THz7p7YJRgO5utoyUYfg0JUVjhb/rmsSvyUpqLTaTB1odtjKu1Wa 9Kk+wyU+qH5/yJD0 =5lqH -----END PGP SIGNATURE----- --=_MailMate_84571C96-CB4D-47A2-ACAC-9257C8104B89_=-- From nobody Thu Dec 21 11:17:51 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D40124C27 for ; Thu, 21 Dec 2017 11:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ucd-ie.20150623.gappssmtp.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 0Hfr4Ih46o9D for ; Thu, 21 Dec 2017 11:17:48 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 C1F8512D7EA for ; Thu, 21 Dec 2017 11:17:45 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id n138so17932365wmg.2 for ; Thu, 21 Dec 2017 11:17:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=jQNkR42etmkVJMFSm0mfP4npcjB12Ty7j4ia5I/Ky7I=; b=OhTm2QbtRSSHjtQbu9nC1voDQNXPzfCmblcXln0UhwiIUmF8VSqHVcR0H0xvbQgvT2 DxtJlwISQm90gzAmIIs3iTVaPxcsPfBWJsSUZHw8wnwxLgpNEX8NtVq5qjMshk7+WpC9 xiCmyN8CX/qwSqmsI4nLet1jq6TXn4rU6x81WD/sXq24b4cQDXUhR+uf7F5tiWP2jRX7 x0ZwGCN3VJGEkS1Dw7qEYq7ht3wLu0xxl7SK/A4cUwZrld012EgZdjeDLXW9M5WjfZkG 5/P7Wm2Sq7HAyaJTjjweRkFy7Byoz7KB5Xbjc7ZiSlbzXxukvt5XawE586q3xBF0Bwzb F0CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=jQNkR42etmkVJMFSm0mfP4npcjB12Ty7j4ia5I/Ky7I=; b=nv/3yhExRZHbPGOnG7cDJteg4St9xyEagkCQXXxNbsXughVIMLJgbheOpGL7hV3tml QvRRE7D3TikLjQTYGAwEhBOtiP+ClAvpU95Qca0LuJ+6Wh0SIJs6QQDfbBLgUS/g0QjO z3axlTy5u/dF7Bks/0UyGRTN7Dc7exhyJETyCIz60lVMIGQX984uxCqBZaIy86nch2KI 7nLFxtdir7+OdXFChd+HCbKUX7ZLQ3Qoti/swe+WAxWgzD0+YS0LzuOpqM9AvGMksowA T68OgpxGzGbNleNjnHwc+FKUD1odr090SxI9uOT11Wq63zYOhKyxxJr3ZIW8r+Cpl2jL IWeA== X-Gm-Message-State: AKGB3mLtzZ+79L41FAit4k+WC3mdBXmrH9HygFaKMK/oc/kfIynM23yN /rgizsX5Y6u2yFB4ea6mgOQ+4SB4ncE= X-Google-Smtp-Source: ACJfBov52Y6AJRxiT1esrvkxULICZJPpES32X/zojFxtCsvcfLg0ZElTjEyl8nlRfJrf0EspYK6U4w== X-Received: by 10.80.164.27 with SMTP id u27mr11276063edb.11.1513883864142; Thu, 21 Dec 2017 11:17:44 -0800 (PST) Received: from [10.0.1.162] ([2001:bb6:506:8e01:837:412b:5b47:dab0]) by smtp.gmail.com with ESMTPSA id w2sm19245451edb.4.2017.12.21.11.17.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Dec 2017 11:17:43 -0800 (PST) From: "Niall O'Reilly" X-Google-Original-From: "Niall O'Reilly" To: dnsop@ietf.org Cc: "Richard Gibson" Date: Thu, 21 Dec 2017 19:17:40 +0000 X-Mailer: MailMate (1.10r5443) Message-ID: <0F976D6F-B0BC-433A-868C-B55584EE3BA6@ucd.ie> In-Reply-To: <90cb3520-a714-d93d-f113-776d936de489@oracle.com> References: <20171130133600.447a2904@grisu.home.partim.org> <20171218141112.56cxoc5nvt3wlsdf@nic.fr> <20171219042014.390cbfd7@grisu.home.partim.org> <95695b68-9506-1ab3-ae1a-f2c1f780ed69@oracle.com> <90cb3520-a714-d93d-f113-776d936de489@oracle.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_9F9A59A6-BBBD-4052-8C81-E934AD47BCC2_="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 19:17:49 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_9F9A59A6-BBBD-4052-8C81-E934AD47BCC2_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 21 Dec 2017, at 16:06, Richard Gibson wrote: > Two reasons why I presume edge direction to be away from the root: > first, because it's consistent with the rest of the document in its cur= rent form (for example, the very next sentence after my quoted text descr= ibes how a fully qualified domain name "begins at the common root of the = graph"), But, as you pointed out in an earlier message, this depends on which port= ions of the rest of the document you pick. Under "Domain name" and "Composition of names"= the order described is away from the root, while under "presentation format", "wire format", = and "display format", the opposite is the case. > and second, because parent-to-child directionality is inherent to the D= NS for delegations. That's an enticing analogy. I'm not sure whether it's compelling. > RFC 1034 seems to contemplate an undirected graph, so can happily use t= owards-the-root for domain names and away-from-the-root for delegations. = But I don't think 7719bis has that luxury, because "domain name" should r= emain valid even in a "naming system" without a single common root. I'ld be surprised, because of what I understood of how the development of= 7719 was approached, to learn that 7719bis can be permitted to revise a founda= tional document such as 1034. I may be mistaken in this. Best regards, Niall O'Reilly --=_MailMate_9F9A59A6-BBBD-4052-8C81-E934AD47BCC2_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQJJBAEBCgAzFiEE8gFTJFuOkmd9Gtxz5N4O614kXW8FAlo8CNQVHG5pYWxsLm9y ZWlsbHlAdWNkLmllAAoJEOTeDuteJF1vGBAQAMNJcNyJHrk5LReghDmsmjjVwKGI N52HzjgBtZzOB82GE3id5ZCfr0SercPu2liz11HaR96b2/tZdGpRQAz4oriVEAAr cVqzeV6SeR1cEVlyawB0AEZD1ieulDDw6U5GxIbXc+EKRFvbwts/GdCUBA7HwDiz cbdEkgbyY9SWZt/7YgK/K4I4Ii+FLO0TDwCXWNnpTOoJPjms4pwoCXUotc+Lp7rg y6oSdBBU5b3meUmWsZOECLl5hMzVPmvFJRhX3ntmRLwfZ1AtTfTjdW8HPTApmo5s Ara5QF3S6i4qSFR0wfMub04YeH0EC8M6EMh+hzup8j3zhOiFskWHR/oNVR6HVvop kECkRsRmqa+fELUZBGoNbsdd7lTH3AXv4sAxmDl2dLyFKRtMyHib/UYAldzuI+di cXtGrjiqzWluEGvdmtl1QLsxTv6ueWzwofLMXI2Pj2OZ36PLizdylBFykbpwRGo7 nGcs6IQDUGjmzBBPytwvX3FmuJkD0ZaeN1A9eHIxO7GF+DqVyqxRv+6YUpem4QtB 7zt0IuDwJibkAKYup3+hZc6PIRgOc+WkOyJmfzXSYV0ci6jEd9M0MrJi9Eh9d0qr N1XHeZC75ySnBR9NKcL1RTU6XIx1RiRfGPt+GBtP+YHu7vX59ztnUHhTElT2yYk1 s23nHu5Qgt7a5f7g =ZDVp -----END PGP SIGNATURE----- --=_MailMate_9F9A59A6-BBBD-4052-8C81-E934AD47BCC2_=-- From nobody Thu Dec 21 11:44:15 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946A612D82F for ; Thu, 21 Dec 2017 11:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 wIGh_uDwU7p6 for ; Thu, 21 Dec 2017 11:44:11 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 3A747129C6F for ; Thu, 21 Dec 2017 11:44:11 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id w127so22222539iow.11 for ; Thu, 21 Dec 2017 11:44:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PPGpqxZh7VoY+O6c6ZdFSauaPo8ssSNzsoY4r+WRJz8=; b=t5pODEIllRCL28XnIyfC58BUp9ah16qMzXXtLRe7lXjnqLoKmvUwyhGd2d5l84C+DT FA4kWwOAtI7lLkZ8XD7eXi/Mp800WmpQXPdfaCACy7AT5SxgUW+Dpi/p7a+tdzvF+In6 Qk76zzu+owZFGqKjp8eDJjP0Dt8oF065WPaMo02CLfcKKwHfHDWyqKKwShSJ0lwGOGvJ uSMAl2ZJUTclT8La8sNO7ozp7ENGhTbsFdKKbbTS4LsNE+ZyR8l3XEPT12mwdOqqkrec orV/nvXBj85vja3f5vYElKdNYFRu18IGTmpSXWL4bhLiptrFGjcX97ked6fvaKWAwURC LTvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PPGpqxZh7VoY+O6c6ZdFSauaPo8ssSNzsoY4r+WRJz8=; b=ZPE+IBhOS1+HYLnt0grVGcmyHM941yO2zGiWCcvw2QYFu16tOJqDUWc1T8yRVLjVaP BfzjM2/t1SuhB9aTn6JyQ1PLnMWQu9vylq1ijXoDdh7wA71+W/KV3nVX/O4CSXOU9cYZ gtWTDIvGFdzYEGjeLi02v/M5wVYAsaaVzdl04a/qunHKGMiMRuen596opfAK0ZJK3mrv 7uENZIskNgIkEoHGXkPoClDZd2PkoELP6g3D0N/SROAydRHloWnoMkfhnwCcrQtZP+LR QPZIcmNYs9aSubnjpK/8i+cvSHppbYH+qFguCuZlv3hA+TMduZ5vrA5Bgnf8W3pKv72G AVvA== X-Gm-Message-State: AKGB3mI0TqR2tli3m1kIz2tFFGzBikssrvjm/i5IuhFkEkGxdFvsHEmT KSuhTctx9cxlCgi7pI0eMvK7RlVGbXkQ1jKAvco= X-Google-Smtp-Source: ACJfBotcCrbZ9JwMsBOOJq6o8cMDcT369/8xOSeYgapUUNA7ryFbDnzRdAFSdxwoIISxvz4knLmdcpMcFKmKcxQDlOQ= X-Received: by 10.107.135.106 with SMTP id j103mr13931356iod.181.1513885450204; Thu, 21 Dec 2017 11:44:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.15.71 with HTTP; Thu, 21 Dec 2017 11:44:09 -0800 (PST) In-Reply-To: <20171221162955.y4her5sdyggsnf5l@nic.fr> References: <20171221162955.y4her5sdyggsnf5l@nic.fr> From: Tariq Saraj Date: Fri, 22 Dec 2017 00:44:09 +0500 Message-ID: To: Stephane Bortzmeyer Cc: dnsop@ietf.org Content-Type: multipart/alternative; boundary="001a113ed26a7d7b8a0560deec43" Archived-At: Subject: Re: [DNSOP] DNSOP Digest, Vol 132, Issue 53 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 19:44:14 -0000 --001a113ed26a7d7b8a0560deec43 Content-Type: text/plain; charset="UTF-8" hi Bortzmeyer, there are still some issues with >Any 50 US $ OpenWRT router can do it (iptables accepts domain names). >% sudo iptables -A OUTPUT -d www.example.com -j DROP >% sudo iptables -n -v -L OUTPUT >Chain OUTPUT (policy ACCEPT 184 packets, 22306 bytes) > pkts bytes target prot opt in out source destination > 0 0 DROP all -- * * 0.0.0.0/0 93.184.216.34 First these rules are still bypassed by the client. Below I have two commands ping and the dig. with the ping command the IP address is different, while when the dig command is passed for the domain facebook.com the answer is a different IP address. . ****@ubuntu:~$ ping facebook.com PING facebook.com (157.240.1.35) 56(84) bytes of data. 64 bytes from edge-star-mini-shv-01-lht6.facebook.com (157.240.1.35): icmp_seq=1 ttl=50 time=148 ms 64 bytes from edge-star-mini-shv-01-lht6.facebook.com (157.240.1.35): icmp_seq=2 ttl=50 time=149 ms 64 bytes from edge-star-mini-shv-01-lht6.facebook.com (157.240.1.35): icmp_seq=3 ttl=50 time=148 ms ^C --- facebook.com ping statistics --- 11 packets transmitted, 11 received, 0% packet loss, time 10010ms rtt min/avg/max/mdev = 148.903/148.997/149.096/0.372 ms [The dig command] ****@ubuntu:~$ dig facebook.com A ; <<>> DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> facebook.com A ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62852 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;facebook.com. IN A ;; ANSWER SECTION: facebook.com. 212 IN A 185.60.216.35 ;; Query time: 41 msec ;; SERVER: 127.0.1.1#53(127.0.1.1) ;; WHEN: Thu Dec 21 11:28:46 PST 2017 ;; MSG SIZE rcvd: 57 Also, even if all this is keep aside for the time being, what about all those IP addresses or IPv6 addresses that are configured on any of the network security component such as firewall in my usecase? One still need to resolve the corresponding IP address if rules are based on IPv6 address or IPv6 address if rules are based on IP address. On Thu, Dec 21, 2017 at 9:29 PM, Stephane Bortzmeyer wrote: > On Tue, Dec 19, 2017 at 02:58:57PM +0500, > Tariq Saraj wrote > a message of 1158 lines which said: > > > using a firewall based on domain names can be simply bypassed by > > accessing websites through IP address. > > No, no, this is absolutely not what I was talking about. Instead, I > referred to: > > > Second, there are some firewalls such as Cisco and Kaspersky that handle > > this situation when someone configure a firewall rule based on domain > name, > > it automatically resolves the IPv4 and IPv6 addresses for that domain and > > update the firewall rules so that it cannot be bypassed through > accessing a > > server through IP based. > > Exactly. > > > But, these are highly expensive firewalls and normally not > > affordable for every organization. > > Any 50 US $ OpenWRT router can do it (iptables accepts domain names). > > % sudo iptables -A OUTPUT -d www.example.com -j DROP > > % sudo iptables -n -v -L OUTPUT > Chain OUTPUT (policy ACCEPT 184 packets, 22306 bytes) > pkts bytes target prot opt in out source > destination > 0 0 DROP all -- * * 0.0.0.0/0 > 93.184.216.34 > -- Regards Tariq Saraj Riphah Institute of Systems Engineering, Islamabad --001a113ed26a7d7b8a0560deec43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hi Bortzmeyer,
there are still some issues = with

>Any 50 US $ OpenWRT router can do it (iptables accep= ts domain names).

>% sudo iptables -A OUTPUT -d www.example.com= -j DROP

>% sudo iptables -n -v -L OUTPUT
>Chain OUTPUT (po= licy ACCEPT 184 packets, 22306 bytes)
> pkts bytes target=C2=A0 =C2= =A0 =C2=A0prot opt in=C2=A0 =C2=A0 =C2=A0out=C2=A0 =C2=A0 =C2=A0source=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0destination
=C2=A0&g= t; =C2=A0 0=C2=A0 =C2=A0 =C2=A00 DROP=C2=A0 =C2=A0 =C2=A0 =C2=A0all=C2=A0 -= -=C2=A0 *=C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0 =C2=A0 =C2=A00.0.0.0/0=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 93.184.216.34

= First these rules are still bypassed by the client. Below I have two comman= ds ping and the dig. with the ping command the IP address is different, whi= le when the dig command is passed for the domain facebook.com the answer is a different IP address.
.
****@ubuntu:~$ ping facebook.com
PING facebook.com (157.240.1.35) 5= 6(84) bytes of data.
64 bytes from edge-star-mini-shv-01-lht6.facebook.com (157.240.= 1.35): icmp_seq=3D1 ttl=3D50 time=3D148 ms
64 bytes from edge-star-mini-shv-01-lht6.face= book.com (157.240.1.35): icmp_seq=3D2 ttl=3D50 time=3D149 ms
64 byte= s from edge-star= -mini-shv-01-lht6.facebook.com (157.240.1.35): icmp_seq=3D3 ttl=3D50 ti= me=3D148 ms
^C
--- facebook.com p= ing statistics ---
11 packets transmitted, 11 received, 0% packet loss, = time 10010ms
rtt min/avg/max/mdev =3D 148.903/148.997/149.096/0.372 ms

[The dig command]
****@ubuntu:~$ dig facebook.com A
; <<>>= DiG 9.9.5-3ubuntu0.16-Ubuntu <<>> facebook.com A
;; global options: +cmd
;; Got answer:
;; -= >>HEADER<<- opcode: QUERY, status: NOERROR, id: 62852
;; fla= gs: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;;= OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION = SECTION:
;facebook.com.=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 IN=C2=A0=C2=A0=C2=A0 A
;; ANSWER SECTION:
facebook.com.= =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 212=C2=A0=C2=A0=C2=A0 IN=C2=A0=C2=A0= =C2=A0 A=C2=A0=C2=A0=C2=A0 185.60.216.35
;; Query time: 41 msec;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Dec 21 11:28:46 PST 20= 17
;; MSG SIZE=C2=A0 rcvd: 57

Also, even if all= this is keep aside for the time being, what about all those IP addresses o= r IPv6 addresses that are configured on any of the network security compone= nt such as firewall in my usecase? One still need to resolve the correspond= ing IP address if rules are based on IPv6 address or IPv6 address if rules = are based on IP address.



On Thu, Dec 21, 2017 at 9:= 29 PM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Dec 19, 2017 at 02:58:57PM +0500,
=C2=A0Tariq Saraj <tariqsaraj@gm= ail.com> wrote
=C2=A0a message of 1158 lines which said:

> using a firewall based on domain names can be simply bypassed by
> accessing websites through IP address.

No, no, this is absolutely not what I was talking about. Instead, I<= br> referred to:

> Second, there are some firewalls such as Cisco and Kaspersky that hand= le
> this situation when someone configure a firewall rule based on domain = name,
> it automatically resolves the IPv4 and IPv6 addresses for that domain = and
> update the firewall rules so that it cannot be bypassed through access= ing a
> server through IP based.

Exactly.

> But, these are highly expensive firewalls and normally not
> affordable for every organization.

Any 50 US $ OpenWRT router can do it (iptables accepts domain names)= .

% sudo iptables -A OUTPUT -d www.example.com -j DROP

% sudo iptables -n -v -L OUTPUT
Chain OUTPUT (policy ACCEPT 184 packets, 22306 bytes)
=C2=A0pkts bytes target=C2=A0 =C2=A0 =C2=A0prot opt in=C2=A0 =C2=A0 =C2=A0o= ut=C2=A0 =C2=A0 =C2=A0source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0destination
=C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A00 DROP=C2=A0 =C2=A0 =C2=A0 =C2=A0all=C2= =A0 --=C2=A0 *=C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0 =C2=A0 =C2=A00.0.0.0/0=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 93.184.216.34



--
Regards
Tariq Saraj
Riphah Institute of Sy= stems Engineering, Islamabad

=
--001a113ed26a7d7b8a0560deec43-- From nobody Thu Dec 21 12:31:09 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4581C127136 for ; Thu, 21 Dec 2017 12:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 tBt9mdW--I73 for ; Thu, 21 Dec 2017 12:31:06 -0800 (PST) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 B41B81241F5 for ; Thu, 21 Dec 2017 12:31:06 -0800 (PST) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.21/8.16.0.21) with SMTP id vBLKRNaB129904; Thu, 21 Dec 2017 20:31:04 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=corp-2017-10-26; bh=RXsQ93obbLbZDLDvuGlHeyK5CymqRF5Kch7IBelpI9o=; b=u/2k3fSCTjfkKkn3Vy1IaaAvVgdpSaAuWwvLkEfZkN25JmPC8MYMnkF8b42SPuBarE2F V6tYoU7zCHjIeBQIEl0QH6cKDF5cyQAQYas3bTW0w+6qbBH0TbKuYh1VfRT8jjZZ5f5j IozN5Fhq3tvKHKg6XrJH/U6bO/pvmKukeap/m5J8Lx4COSxRWc6RiYqk71ds8O8Mhx2q gtsM0zBSF8FV343MBaSpwJGf/36ERl1WSHstz6ARIk6kI2vvSILm+MTgTwiQwSx1jqRL 6ltKy1OK3Qiv1K1QqkSsHlrNqD7GBSycfswhMaScN5epy+TJ2YKc4eIWKBbMy4jWzn+E 9g== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2f0kakr8ne-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 21 Dec 2017 20:31:04 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vBLKV3V2003580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 21 Dec 2017 20:31:03 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vBLKV1k7030723; Thu, 21 Dec 2017 20:31:01 GMT Received: from [172.16.4.245] (/216.146.45.243) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 21 Dec 2017 12:31:01 -0800 To: "Niall O'Reilly" , dnsop@ietf.org References: <20171130133600.447a2904@grisu.home.partim.org> <20171218141112.56cxoc5nvt3wlsdf@nic.fr> <20171219042014.390cbfd7@grisu.home.partim.org> <95695b68-9506-1ab3-ae1a-f2c1f780ed69@oracle.com> <90cb3520-a714-d93d-f113-776d936de489@oracle.com> <0F976D6F-B0BC-433A-868C-B55584EE3BA6@ucd.ie> From: Richard Gibson Message-ID: <04d5b3be-d27c-e90a-aa24-0361febe1ad4@oracle.com> Date: Thu, 21 Dec 2017 15:31:00 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <0F976D6F-B0BC-433A-868C-B55584EE3BA6@ucd.ie> Content-Type: multipart/alternative; boundary="------------A0DD236DEDE54CB540104672" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8752 signatures=668651 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=511 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712210275 Archived-At: Subject: Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 20:31:08 -0000 This is a multi-part message in MIME format. --------------A0DD236DEDE54CB540104672 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/21/2017 02:17 PM, Niall O'Reilly wrote: > On 21 Dec 2017, at 16:06, Richard Gibson wrote: >> first, because it's consistent with the rest of the document in its current form (for example, the very next sentence after my quoted text describes how a fully qualified domain name "begins at the common root of the graph"), > But, as you pointed out in an earlier message, this depends on which portions of the rest > of the document you pick. Under "Domain name" and "Composition of names" the order described > is away from the root, while under "presentation format", "wire format", and "display format", > the opposite is the case. The text is consistent in identifying "domain name" with "a list of labels ordered from parent to child", it's just confusing that wire format and presentation format are each /also/ "a list of [the same] labels" but ordered in reverse. >> RFC 1034 seems to contemplate an undirected graph, so can happily use towards-the-root for domain names and away-from-the-root for delegations. But I don't think 7719bis has that luxury, because "domain name" should remain valid even in a "naming system" without a single common root. > I'ld be surprised, because of what I understood of how the development of 7719 > was approached, to learn that 7719bis can be permitted to revise a foundational > document such as 1034. I may be mistaken in this. RFC 1034 defines domain name as "the list of the labels on the path… to the root of the tree" and references a /convention/ that labels "are printed or read… from the most specific (lowest, farthest from the root) to the least specific". I still think the original text applies to an undirected graph, so describing it in terms of a directed graph (specifically with edges from parents to children, as it is in the protocol) constitutes a clarification rather than a revision. That said, though, nailing down the ordering of domain name labels to /oppose/ the direction of such edges is most in accord with 1034 and seems like it would eliminate the most confusion in 7719bis. --------------A0DD236DEDE54CB540104672 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 12/21/2017 02:17 PM, Niall O'Reilly wrote:
On 21 Dec 2017, at 16:06, Richard Gibson wrote:

first, because it's consistent with the rest of the document in its current form (for example, the very next sentence after my quoted text describes how a fully qualified domain name "begins at the common root of the graph"),

But, as you pointed out in an earlier message, this depends on which portions of the rest
of the document you pick.  Under "Domain name" and "Composition of names" the order described
is away from the root, while under "presentation format", "wire format", and "display format",
the opposite is the case.
The text is consistent in identifying "domain name" with "a list of labels ordered from parent to child", it's just confusing that wire format and presentation format are each also "a list of [the same] labels" but ordered in reverse.
RFC 1034 seems to contemplate an undirected graph, so can happily use towards-the-root for domain names and away-from-the-root for delegations. But I don't think 7719bis has that luxury, because "domain name" should remain valid even in a "naming system" without a single common root.

I'ld be surprised, because of what I understood of how the development of 7719
was approached, to learn that 7719bis can be permitted to revise a foundational
document such as 1034.  I may be mistaken in this.
RFC 1034 defines domain name as "the list of the labels on the path… to the root of the tree" and references a convention that labels "are printed or read… from the most specific (lowest, farthest from the root) to the least specific". I still think the original text applies to an undirected graph, so describing it in terms of a directed graph (specifically with edges from parents to children, as it is in the protocol) constitutes a clarification rather than a revision. That said, though, nailing down the ordering of domain name labels to oppose the direction of such edges is most in accord with 1034 and seems like it would eliminate the most confusion in 7719bis.
--------------A0DD236DEDE54CB540104672-- From nobody Thu Dec 21 13:44:07 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A247312D7E2 for ; Thu, 21 Dec 2017 13:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.452 X-Spam-Level: X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 6uK9gcpN22Fv for ; Thu, 21 Dec 2017 13:44:04 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF2C1275FD for ; Thu, 21 Dec 2017 13:44:03 -0800 (PST) Received: from 46-227-151-81.customer.gigaclear.net ([46.227.151.81]:52557 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1eS8dC-00004v-2G (Exim 4.72) for dnsop@ietf.org (return-path ); Thu, 21 Dec 2017 21:43:58 +0000 To: dnsop References: <20171221103623.045eed5e@titan.int.futz.org> From: Ray Bellis Message-ID: Date: Thu, 21 Dec 2017 21:44:01 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171221103623.045eed5e@titan.int.futz.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] kskroll-sentinel responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 21:44:05 -0000 On 21/12/2017 15:36, Robert Story wrote: > I reread the draft today, and noticed that two things aren't specified. > The first is the contents of the A/AAAA RRSET returned, and the second > is the TTL for the records. > > Maybe the A/AAAA record values could be used to return additional > details? For example, whether or not the key is part of static > configuration, or learned via 5011. I had also wondered about this. A browser-based system for triggering these queries can't do so without also then attempting a download of some resource via whatever IP address is returned. (in other words, you can't make a browser "just" do a DNS lookup, the DNS lookup is a side effect of attempting to access a URL) Ray From nobody Thu Dec 21 14:38:22 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB438120454 for ; Thu, 21 Dec 2017 14:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 5M2NsIs8x5VV for ; Thu, 21 Dec 2017 14:38:17 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8751200C5 for ; Thu, 21 Dec 2017 14:38:17 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc] (unknown [IPv6:2001:559:8000:c9:dc3:59e3:1fa5:69dc]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 6A86861FA2; Thu, 21 Dec 2017 22:38:17 +0000 (UTC) Message-ID: <5A3C37D7.5050202@redbarn.org> Date: Thu, 21 Dec 2017 14:38:15 -0800 From: Paul Vixie User-Agent: Postbox 5.0.22 (Windows/20171208) MIME-Version: 1.0 To: Richard Gibson CC: Niall O'Reilly , dnsop@ietf.org References: <20171130133600.447a2904@grisu.home.partim.org> <20171218141112.56cxoc5nvt3wlsdf@nic.fr> <20171219042014.390cbfd7@grisu.home.partim.org> <95695b68-9506-1ab3-ae1a-f2c1f780ed69@oracle.com> <90cb3520-a714-d93d-f113-776d936de489@oracle.com> <0F976D6F-B0BC-433A-868C-B55584EE3BA6@ucd.ie> <04d5b3be-d27c-e90a-aa24-0361febe1ad4@oracle.com> In-Reply-To: <04d5b3be-d27c-e90a-aa24-0361febe1ad4@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2017 22:38:20 -0000 you guys are killing me with this thread. <> http://queue.acm.org/detail.cfm?id=1242499 From nobody Fri Dec 22 09:40:56 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101F6126DED for ; Fri, 22 Dec 2017 09:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 BRKZjUI1liSW for ; Fri, 22 Dec 2017 09:40:53 -0800 (PST) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (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 7E043126D74 for ; Fri, 22 Dec 2017 09:40:53 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:53489) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:cet1) id 1eSRJT-000RBR-hB (Exim 4.89) for dnsop@ietf.org (return-path ); Fri, 22 Dec 2017 17:40:51 +0000 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1eSRJT-00046y-Ba (Exim 4.89) for dnsop@ietf.org (return-path ); Fri, 22 Dec 2017 17:40:51 +0000 Received: from [128.232.254.153] by old-webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 22 Dec 2017 17:40:51 +0000 Date: 22 Dec 2017 17:40:51 +0000 From: Chris Thompson To: dnsop@ietf.org Reply-To: cet1@cam.ac.uk Message-ID: In-Reply-To: <5A3C37D7.5050202@redbarn.org> References: <20171130133600.447a2904@grisu.home.partim.org> <20171218141112.56cxoc5nvt3wlsdf@nic.fr> <20171219042014.390cbfd7@grisu.home.partim.org> <95695b68-9506-1ab3-ae1a-f2c1f780ed69@oracle.com> <90cb3520-a714-d93d-f113-776d936de489@oracle.com> <0F976D6F-B0BC-433A-868C-B55584EE3BA6@ucd.ie> <04d5b3be-d27c-e90a-aa24-0361febe1ad4@oracle.com> <5A3C37D7.5050202@redbarn.org> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Archived-At: Subject: Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 17:40:55 -0000 On Dec 21 2017, Paul Vixie wrote: >you guys are killing me with this thread. > ><except the root node, which is its own parent. Well, that doesn't make sense already. Either the root node has no parent (which seems to me to be the natural way to think of a tree structure), or it is its own parent. They can't both be true. -- Chris Thompson Email: cet1@cam.ac.uk From nobody Sat Dec 23 11:59:46 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855F412025C for ; Sat, 23 Dec 2017 11:59:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 luGlqLVjgxan for ; Sat, 23 Dec 2017 11:59:41 -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 A3F1C1200F3 for ; Sat, 23 Dec 2017 11:59:39 -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=AKQ5W+vbIrJlzcqywWWaFrVCogl5XgDM8oI/zpfPdV0=; b=UvXG9aYf+wwZMHsPqBMZ7wKL9nmQi99dT1g9/Ye1pNnLlutNi8IwYJj8ZmjTw2cCWzJHk9L9Gg4ZqkVRLsgCw6K6qVEsZaGrZNa+sVulnW7nIFy/+uprMOz0V3FRfgQApgikxKmL3EbLQq0lvs+5tL58VZ97aFI8g3yBOksoEf4= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=gih@apnic.net; Received: from 2001-44b8-1121-1a00-69be-0484-4d13-76fc.static.ipv6.internode.on.net (2001:44b8:1121:1a00:69be:484:4d13:76fc) 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.302.9; Sat, 23 Dec 2017 19:59:32 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Geoff Huston In-Reply-To: Date: Sun, 24 Dec 2017 06:59:19 +1100 Cc: dnsop Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171221103623.045eed5e@titan.int.futz.org> To: Ray Bellis X-Mailer: Apple Mail (2.3445.5.20) X-Originating-IP: [2001:44b8:1121:1a00:69be:484:4d13:76fc] X-ClientProxiedBy: HK2PR0302CA0022.apcprd03.prod.outlook.com (2603:1096:202::32) To SIXPR04MB0698.apcprd04.prod.outlook.com (2a01:111:e400:51ee::21) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6a030553-6d91-4a84-cdd5-08d54a3fb0bb X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:SIXPR04MB0698; X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0698; 3:3gIkRcIpG6CN2DjE00bYzB+TE8dckrHV3ISPiBg9cJkPq+v9A1y+V9ywrZqLSrxSdEMaVfLSALW+3TSrFtFNMZzzMRuKgxNMx8OI/7YPvaR7oHW4QT4Vt+t6pXGtZ11Dri7WpsF+yVs6qkXhd1FMeWi3iVsM88cc/1nyUjo/dGmJpm5o5P6QsRwk7xUut3IUERkZkuYVF+rFX8v0J8J2s+kl8TH/resIr5Hft+aWpTRNIMbWhCEEyLoeP/DypzaR; 25:UpkZOVgfr8n5rQHVI3nFzeIMdpPQHAbqzOZZEliFSTiXrQlhXLbm7NkEkmiYcnrUpy2elmTeZe8N3Me/ajSi3dDFwbquHDNsgnJw7K7m909sF9nSkhwLFJN9BqoZ7WZbW/udhwv6LsKm5Aq9PtcuKGET7XN5dUNKtSiY4O4z9Qffpi4gGC2rm91C3LoJ7KiPfS05UsUw14DXlg+OXEbcraqB5b3wZ5q6OjZBTl/TyAVx0BPHHyBny0FlMvAnDeImkqkcXVWVaEfTCrlVYo/dQ0HRLCRE8fL1Ma43Xa9uFI+Jt60m9hswidAQsRMEwqS1wcqUUMMMpU4Hd6UYrERtSLt989MA7eFHVzSl4yeoNcA=; 31:JjEURYeI0dCZ0inbJQ36FJnwUQg44BXiEQZKZB6Zaurw6cTXwz90loVpJxOl1fl39JTHy0H/1O3VMFRYCxRU8tjya7UPw5BMznYPXfdbwrjLhsyd37LISesGCn6hmEAuJnB2r0coOrXYf1tQsI5Xojpnhyu5MGWLi6+vEpRYe2Ftmq9nH+ecsNbUuIc8RYpPcsElr615DVpCXIDMSRQStfuuTB3rVLELWVffnAFKBOA= X-MS-TrafficTypeDiagnostic: SIXPR04MB0698: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(10201501046)(3231023)(93006095)(93001095)(3002001)(6041268)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:SIXPR04MB0698; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SIXPR04MB0698; X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0698; 4:1zYWw/K3upbh/YgMaxqnptWhpJThpZQShJ2hODBS7wihLZ/Xr29RhDMI0+LhMqBjxHEmhmzZEjwHsfoyqEWC+QJCy++RgYLNGE6CIe27WwMNT5uXh9xbiBNXQ8ikkqnipW/zp+ZlFopkNg8gUQoDmcr6PgZ99Z9tFaRSivZNcqmaN5YeuPrEWGO2Dq51fEclx7p+X7yHw29wef5HuYHtNyqAsRG7zG3UHK5jIhJ84s0tbnBpKLKww1epsp4zH6Pn9RBfw0y3WzG2oTzeA5P6Aw== X-Forefront-PRVS: 0530FCB552 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(366004)(39380400002)(396003)(376002)(39830400003)(346002)(199004)(24454002)(189003)(2950100002)(36756003)(52116002)(50466002)(6506007)(2486003)(52396003)(83716003)(386003)(8936002)(57306001)(4326008)(53546011)(316002)(59450400001)(23676004)(52146003)(97736004)(76176011)(6666003)(50226002)(47776003)(6916009)(105586002)(68736007)(6246003)(2906002)(86362001)(305945005)(8676002)(81166006)(33656002)(478600001)(106356001)(6512007)(53936002)(229853002)(5660300001)(81156014)(6486002)(6116002)(8746002)(25786009)(82746002)(7736002)(42262002); DIR:OUT; SFP:1101; SCL:1; SRVR:SIXPR04MB0698; H:2001-44b8-1121-1a00-69be-0484-4d13-76fc.static.ipv6.internode.on.net; 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?MTtTSVhQUjA0TUIwNjk4OzIzOmVhdFhqcmI2aFB0eFRyaDdwU0l3dGo3N1FV?= =?utf-8?B?MCs4bHB5aW04aUxGMDIrWHBGVkt1VHY1cllURitNeDNvbEdMRVFmbmw5Rk1W?= =?utf-8?B?bmt1QWFpdFlLQXVZdk1YZlZ5N3l5YW1qUXpkOEt2azAycHAxcGQwRXk4amZI?= =?utf-8?B?TnlVYmFhQTUxd1pYYTJrVk4rUFpjTVlHV3FZUXhLLyt2a0lQTXZ4L2h2dnJs?= =?utf-8?B?QS9WeDZSa1I2UGdZWkJsL2dUdm05Z3FiMnRqNVVOc2FIOGlGWjVYZEhvT2pV?= =?utf-8?B?OFdua3dmZkt1RWZ3bk9DREw1Qk8xSGEyVTd6Q25ESHVsa3MrNzd2eDNjb3Y5?= =?utf-8?B?RGg4S1lVTU50L1c3SkI3YWlJOVJGWStQa3FRd2VQaTU0SHAxaU53QUhKZm1n?= =?utf-8?B?QmtqZElETTEva0MvSHJYZzhHTTRldnYyZzNUc2lDVlJVVnJ4ckV0NkNwaTg3?= =?utf-8?B?THF5S3J3OHVMQ3hvSWZQdzhxRE5laTZkcTRtZ0FNL09JL2xEcW8vZDZpRXY3?= =?utf-8?B?NWJJVEV6RHFHYlFOb2lEUUY0c2FsTUo4T2t1d3FEanBreDhQdmlyc1dtMlBt?= =?utf-8?B?R1RVNUJGb0EwQWtKUkNqV0VqbXlLTWIwSi9NMUUyamdlTDlnZEFjNDlaZWpy?= =?utf-8?B?TXNpcVU5ZDlyclhmV2Z6eDdMV3pkbVkxWXUzZWpIeVcvVkZXdURzN3g2cE5J?= =?utf-8?B?SFRrbmlKckZaVVBkZVQxUllLMHV0L1cvQ1ZJMmRYYXN0V0JUZHcxRUFNVG9r?= =?utf-8?B?Q0gwVkdFdkZuNE8vT3ppZjVXODc3bGtLamFEM0NBQmVoVWdwYzA3bk8zOVow?= =?utf-8?B?ak1OL1dtajVXWlhTamdtUUlhd2FTNGZKNHVkTVdqdWc1RklsVjYrbkxGYTZo?= =?utf-8?B?SG5CazV0MzhIMmZTT0dPcVp1NWhtWEdaOHFQVlFvOHhxMDA2ZWlGRWNIQzdE?= =?utf-8?B?aktJVHQ2TGtkT3Zzc050U3FrNGNpQkZkUUx6RHRIZUNXMFA0M1JCUFlDODhx?= =?utf-8?B?NXJPYm9Dd2hRcHVGcGRpSVlEL1BmLytMVWV0cEZsd2xKUmRwdFU1TUdGejVn?= =?utf-8?B?TlJXbFZpY0RpQ1N4S2VCdWpEME96YXA5RW9hUjBJTE9nM0JwLzRUR3NmdEdJ?= =?utf-8?B?bVoycXVneFBMZTBYR1FCcFRQU2VyS1VLTGduOEJtRXR4TVFXNkVZckVTb1cv?= =?utf-8?B?eDZnTEJNNXhiNklWRWNsbHpwbGo4NmtDVUxORnQ3dXNsdlQ5ZFp2T3BIOFha?= =?utf-8?B?ZXRJaU5KaEMxaWVaQ2hZS2RjR2pvQ2lSbnh2b0NReWtKTzgva2ZTU1lRWXhz?= =?utf-8?B?U09KL3ZyL3ZxZVlqVlVwMXA0WHhLUzRLYzlwSnZQNjUxZWF4djdIaUpPL1dY?= =?utf-8?B?cU1OVnIydTRqUm5VVllVYUV2aU1HNWtWSjJIaTRKVk50UmtPNW0wNTQrVmt4?= =?utf-8?B?REFHaFNWVWl3VUE3RTIrUFY0L21ZV2hGRkpFcHJoeHRVRGQwdXZTM09tV3lx?= =?utf-8?B?Z0NLLzhIQWRnaWpuek9zS2dyZXZVV3NMaEp5VURIdTE2bnNaYlpGTmI2NXpB?= =?utf-8?B?M1lhSlY5TnhCUVFmMDAvQXgwdUVKNHQxcVN5dU12aGswaWFsMHY0RlQ3clRF?= =?utf-8?B?NFdJRldmQm40dks1YkxsQ042RExmaUFMQmNSSU1VVW12dXI4VlRMWUJseE9O?= =?utf-8?Q?ojJrpynxTu6YNVuW1jfWR26TjDBFo9HxvRrQYE3?= X-Microsoft-Exchange-Diagnostics: 1; SIXPR04MB0698; 6:9bvG3b96EJZhnZbpc/hgbUmk4Kj397ebu4vh6zpbeyo86yNbqCvAhgDQ3cgRYc4O7EhRZ0f8fCpI4jx5qq3YkGiaqB+HGuW4x58GKB7F46FSKIyJrwd0uNGomM8PGaptkkEPMxzF+NHNEXEJYv5szF2gAvk6ymUx3IWbm6iZvgAIuulhbuDtlKzqbhcwKXuSCgXk5+HOasoB77V3GRJXsImXAQ5zCpbiyKk6SyGxb4LkCS2CNPhVY9WRxZwhOU30J1bW6cB7DpVgrdW/WZPAEqi/8HuFqiC5RJMXU4aHngoBjmgP1xrQjJpCMta2+J1FLlDZ7/Jj+/dC/aG+su+BD3ZtnDkpLodIVTDUNtjlAgo=; 5:PKPUeJSH1LlD+ozBNnp5aserEdqcMwZb5vUtoWskWyj93V923t68WZuwjiy6C+LOo40fp8O62yHTPHgV5KwAymJh+uplAJtH1Asv+ZHEmjnktiZAKsZPzM3EQa6uhmXlQLekyXPQJO/w1T5e30KkJIiCkz/CZ8wnKLwrgZN/37c=; 24:sGef5yjMI18ZawdkmpfsVZ6g9ZE2jVeOsIc0WrGyjC9EetaFVlJi7dstwNswjKamRgWykcxz1GbABQMk+H+p7cpRikAyTDh/+y0tBWMfFmo=; 7:7YdBZg7eHi50TzB3Ur/y2R/FwE2J0Rs6Gy8acuNcS3SE8ELLkkPJL/VU6AVxm+cqAq6+zhDr7hcCrCctA8B+mvGutfilY8DRtvvwHk4yLWrP4q0ZX1VHv0DGW+/TfAKOKAGdnywxZHA6AtrpRb23c87BdKPfosYgwzk8jP3grw6z2PuQtG9D6ovtSWpHeSbx534Fji2fpM+2nZqgnG06z+y432QgeQHTpFpypReiQwb73BrJr3HqV27Q65Kwj2M/ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: apnic.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Dec 2017 19:59:32.2691 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6a030553-6d91-4a84-cdd5-08d54a3fb0bb 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: [DNSOP] kskroll-sentinel responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Dec 2017 19:59:45 -0000 > On 22 Dec 2017, at 8:44 am, Ray Bellis wrote: >=20 >=20 >=20 > On 21/12/2017 15:36, Robert Story wrote: >> I reread the draft today, and noticed that two things aren't = specified. >> The first is the contents of the A/AAAA RRSET returned, and the = second >> is the TTL for the records. >>=20 >> Maybe the A/AAAA record values could be used to return additional >> details? For example, whether or not the key is part of static >> configuration, or learned via 5011. >=20 > I had also wondered about this. >=20 > A browser-based system for triggering these queries can't do so = without > also then attempting a download of some resource via whatever IP = address > is returned. >=20 > (in other words, you can't make a browser "just" do a DNS lookup, the > DNS lookup is a side effect of attempting to access a URL) >=20 As Ray points out, if a browser is conducting the experiment, and the only visible indication of successful resolution is the retrieval of the named object, then a reasonable test would use some sentinel object as the named target (a 1x1 pixel gif is conventional in these circumstances). In this case the TTL of the DNS record is not directly visible to the browser. In situations where a client may have multiple resolvers in their local=20= /etc/resolv.conf configuration, and recursive resolvers may themselves /use forwarders, it is not immediately obvious which resolver generated the response, so I=E2=80=99m unsure of the interpretation of = any attempt to embed some form of additional information into either the IP address of the named object. The intent of the test is to establish a usable test along the lines of "If you can retrieve this named object you are ready for a Root Zone KSK roll" The issues around the diversity of behaviours in the DNS turn this dsimple songle fetch into a compound fetch of three named objects, but the semantic intent is the same. That is: "=46rom the pattern of the results of performing these three tests we can compute a likelihood of concluding whether or not, you, the end user, will, or will not, be affected by a pending KSK roll. =46rom a large enough sample of users = was can then estimate the 'impact' of a KSK roll on the total user population. Note that the intent is not to try and isolate the behaviour of a single resolver, nor to attempt to diagnose the reasons for that behaviour. The intent is to look at the user and the set of resolvers that the user's DNS is configured to use, and determine if the user's DNS will be "stranded" in the even of a KSK roll. From nobody Sat Dec 23 14:30:56 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136FD1267BB for ; Sat, 23 Dec 2017 14:30:54 -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] 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 mF9bxLZcSaDb for ; Sat, 23 Dec 2017 14:30:52 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 8C1521200C1 for ; Sat, 23 Dec 2017 14:30:52 -0800 (PST) Received: from [10.32.60.51] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id vBNMUeVL095086 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 23 Dec 2017 15:30:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.51] From: "Paul Hoffman" To: "Geoff Huston" Cc: dnsop Date: Sat, 23 Dec 2017 14:30:43 -0800 X-Mailer: MailMate (1.10r5443) Message-ID: <6615AB2F-F579-4F9C-9869-271EAB544181@vpnc.org> In-Reply-To: References: <20171221103623.045eed5e@titan.int.futz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] kskroll-sentinel responses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Dec 2017 22:30:54 -0000 On 23 Dec 2017, at 11:59, Geoff Huston wrote: > In situations where a client may have multiple resolvers in their > local > /etc/resolv.conf configuration, and recursive resolvers may themselves > /use forwarders, it is not immediately obvious which resolver > generated the response, so I’m unsure of the interpretation of any > attempt to embed some form of additional information into either the > IP > address of the named object. Exactly right. Having a browser run this test can easily lead to false positive and false negative results for a user who expects that seeing something in their browser means something. > The intent of the test is to establish a usable test along the lines > of > "If you can retrieve this named object you are ready for a Root Zone > KSK > roll" The issues around the diversity of behaviours in the DNS turn > this > dsimple songle fetch into a compound fetch of three named objects, but > the semantic intent is the same. That is: "From the pattern of the > results of performing these three tests we can compute a likelihood of > concluding whether or not, you, the end user, will, or will not, be > affected by a pending KSK roll. ... for the current set of resolvers that you are using. A quite believable scenario is that while you're sitting in a coffee shop, you get one set of results, but a different set when you change to your home ISP or your organization's network. > From a large enough sample of users was > can then estimate the 'impact' of a KSK roll on the total user > population. To get a good estimate, you'll need to sample the same user multiple times, looking for changes in the results. The design methodology for such a study will be daunting. > Note that the intent is not to try and isolate the behaviour of a > single > resolver, nor to attempt to diagnose the reasons for that behaviour. Agree. Note, however, that the sentinel can indeed be used to isolate the behavior of a single resolver if you run the test against a known address, not against "whatever /etc/resolv.conf gives me". > The > intent is to look at the user and the set of resolvers that the user's > DNS is configured to use, and determine if the user's DNS will be > "stranded" in the even of a KSK roll. How can this protocol tell the set of resolvers that the user's DNS is configured to use? Either you are seeing the results as an amorphous blob (as described in Section 4), or as a specific result because you are sending the queries to a single known resolver address. --Paul Hoffman From nobody Tue Dec 26 10:27:19 2017 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67A5124234 for ; Tue, 26 Dec 2017 10:27:18 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.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 2vCOBt2r4V0v for ; Tue, 26 Dec 2017 10:27:16 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 282831200FC for ; Tue, 26 Dec 2017 10:27:16 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id f2so45700979qtj.4 for ; Tue, 26 Dec 2017 10:27:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=6F1QNX8LDnEnceZoROyJ0Ghl02yUFpF5W7m53VZN5WA=; b=Kb6TOEwLcxq0h3jbZnO4ztgWeFmvZKsORjHGrAeEFuLCs4lbOox1Ma86KucSqC5p8Q 80WGIeeaAUCUG1zPbMs5DHw0DEcUmxeiSZz0Ap34JQtFipw8wyclMbZjJsLcRh4Blv7e QOrKBhE17a8ZPvWFPcWfvjjdI/e4y+S860NadAIGefCQ9wIA0vAVD20bC2xTxvpmWzIr Ml2CAcClljAAimxBeyqkonTCJjUHzvx0U+lnkfoWjkx/G3826gi5NugQ2+Y7bx/SrWWZ jDAUfkC8Ek+6KCW/AnCr6Mvs38hYa9DuOra2ecltPpHXmsd9dPQZMgHZxZGyFpK1WPLc Zn0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=6F1QNX8LDnEnceZoROyJ0Ghl02yUFpF5W7m53VZN5WA=; b=rqIOUXy4XJ1wlQRr+50/AzP9o75rU8dLqdH0eBj/B8wSxK53ewWAVSJMme8rPHc54O 9T4yTDs66aV8H5iiHl/kZ0rH2ZjdPyETZVdnROuowXX96iBAYpWil+hKvTok54dYB/lm l4TP2iwynH/gzvYwFo39CIZMw4SHIvQc2SXRUx+L0TM3H7VZnfaK1EOh/ueeGMi365c5 HI9ogjBxbjz9mW/Hkya89Dxfv4o+a24eNYD9soSZxVwjvsrKD4KVY1x733IetqEaNBQA zT0fAM6fJ51xg7qatWs/UW/b5qHfA33fIdovA25GbKq+O3UFzPc1cREPuy8dEEDwOcLR LtYw== X-Gm-Message-State: AKGB3mJ2IQdxtr1zm0RFRzCS9LOoXOcJ3BqMd0acDoYWYf0IM2vETBHx dPwkVnAsrzL3q7Oy2ptUTuq0bXe1 X-Google-Smtp-Source: ACJfBovFudlHUgBV3Lf7zkb8gnNyOsbXPOMOC0t8dI3UXV2IofYBUxtBHON5C+Uo3RPaiDe5oxdftw== X-Received: by 10.200.3.23 with SMTP id q23mr38113726qtg.229.1514312834503; Tue, 26 Dec 2017 10:27:14 -0800 (PST) Received: from [192.168.1.110] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id l125sm19949282qkc.3.2017.12.26.10.27.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Dec 2017 10:27:13 -0800 (PST) To: Wes Hardaker Cc: dnsop@ietf.org References: <151370939722.7367.18068254315788230511@ietfa.amsl.com> From: Michael StJohns Message-ID: Date: Tue, 26 Dec 2017 13:27:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-10.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 18:27:19 -0000 On 12/20/2017 1:15 PM, Wes Hardaker wrote: > Michael StJohns writes: > >> 1) Drift happens per query. > Agreed. I'll go double check that I didn't imply that, or better: make > sure I state that in the document. Take it out of any formula.  It has little impact outside of the addHoldDown interval and in there all it does is shift the end point.  It's OK to mention it as part of the general slop, but in reality it turns out to have only very minor impacts. > >> 2) Any drift that happens related to the multiple queries in the >> addHoldDown interval can safely be ignored with respect to its impact >> on the overall wait time for the publisher.  (e.g. all the drift is >> going to do is change the phase of the last query in the interval with >> respect to the end of the addHoldDown time) > Most likely, but I could see bad code calculating total waited time by > adding time between queries together, rather than doing a wall clock > subtraction from new - start_hold_down like they should. > > Anyway, I agree only the last one should be shifted in the correct case. That's not what I said.  What I said was that the cumulative effect of drift within the add hold down interval is to shift the phase of the last query before the end of the period.  The intermediate queries also shift phase, but are subsumed in analysis by the cumulative shift within the interval. > >> 3) The only other drift that may be of interest is the drift at the >> beginning and end of the queryInterval where the end of the interval >> is the beginning of the addHoldDown interval. Given that a typical >> drift is something like 1-60 seconds it can safely be ignored related >> to all the other stuff. > I think I agree with that too. Only a small percentage of clients will > end up needing the extra queryInterval. No.  Drift per query is ~<= 10 seconds or so.   queryInterval ~>= hours.    Drift for these two queries can safely be ignored in the evaluation. > >> (And yes, I realize that Wes has set driftSafetyMargin to >> activeRefresh meaning that calculated results are identical to what I >> want, but there's no analysis that supports the use of a >> driftSafetyMargin and this just seems to be sleight of hand to replace >> activeRefreshOffset with a term that has a value >> activeRefresh... *pounds head against wall*) > Hmm... I'll try to clean up the wording some more to make the analysis > more clear. But in the end, yes: when real world conditions occur > you're right and the extra activeRefresh is needed. Again, you're right > there is *another* new issue with 5011 that had to be spelled out, and > I'm glad you caught yet another needed length extension during last > call. I'm glad you got here, but if you were showing your work, you would not be getting a good grade.....  sorry. The activeRefresh before the addHoldDown interval is from the worst-case assumption that at least one out of N resolvers will have made a query just before the lastSigExpire date. The activeRefresh after the addHoldDown interval is from the worst-case assumption that at least one out of N resolvers will have made a query just before ITS addHoldDown expired and will have to wait an entire activeRefresh interval These assumptions are made without reference to any assumptions about drift or retransmissions. > > But no, it wasn't slight of hand and have no idea why you think I'd be > trying to trick you. I'm sorry if you thought my words implied I thought you were trying to trick me.  However, given that you had no real reason for setting driftOffset to activeRefresh it really did look like "and then a miracle occurs" type of logic. > Again, Mike, I can't state this more clearly: I > admit you were right and found a more important timing constraint than > activeRefreshOffset. That being said, I left (and want to leave) > activeRefreshOffset in the document so that others performing similar > analysis of the whole 5011 process understand all the ramifications of > both the theoretical and practical applications of the 5011 algorithm > and usage. Thus, we actually agree. You just want to limit what goes > into it. Wes - I just want to not have "fake math" in this document. timingSafetyMargin depends on driftSafetyMargin. driftSafetyMargin seems to have been pulled out of thin air and has no support which means that timingSafetyMargin also makes no sense. Neither of these terms are of any use in either the equations or analysis. Delete them and refactor any text that references them. > >> Again: >> >> addWaitClockTime = lastSigExpirationTime + activeRefresh + >> addHoldDownTime + activeRefresh + safetyMargin (which now seems to be >> labeled retrySafetyMargin). > Which is exactly what's in ... *crap* ... I missed a term in an > equation. > > But 6.2.1.1 *will* state: > > addWaitTime = addHoldDownTime > + sigExpirationTimeRemaining > + MAX(1 hour, > MIN(sigExpirationTime / 2, > MAX(TTL of K_old DNSKEY RRSet) / 2, > 15 days) > ) > + 2 * activeRefresh > + retrySafetyMargin > > So your desired equation is there. > > (the current published document doesn't have the 2*, even though the > previous non-expanded version should have lead to it). > > I'll do a final check of equations again today, as well as look to make > sure I didn't state drift can only happen for one query (though I'm sure > I didn't say that). *sigh* As currently written you get the second activeRefresh from the random setting of driftSafetyOffset (see 6.1.7) via timingSafetyMargin (6.1.8). That's wrong.     Since 6.2.1 uses timingSafetyMargin - its also wrong.  Since the rest of the equations derive from 6.2.1 they are suspect. Delete these (6.1.7) (6.1.8) section and fix any references to these terms in the base equation.  From there fix the rest of the math. Later, Mike