From nobody Fri Feb 20 17:19:11 2015 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE3F1A0387 for ; Fri, 20 Feb 2015 17:19:10 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpfdghJYBdFE for ; Fri, 20 Feb 2015 17:19:08 -0800 (PST) Received: from mail-qg0-f100.google.com (mail-qg0-f100.google.com [209.85.192.100]) (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 2C6961A0687 for ; Fri, 20 Feb 2015 17:19:08 -0800 (PST) Received: by mail-qg0-f100.google.com with SMTP id f51so1683992qge.3 for ; Fri, 20 Feb 2015 17:19:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:content-type :mime-version; bh=ySmsK9c7RjUduDNiP2VrWRNwhCpMJBiyCtnhwmCIAuY=; b=e6Q1WexzqyM2+QPokmtGjrI5C4juM6cbxmlXcflVBdd5hKR4u8Zmc1uQrrltXJdvdz QNPf9dnlrT7xmOX/hB7chTtboUf0h/l0/TwC6edmFF6NscJmWSTz+wGtpZoAcJvY704S vKG+8U2GnQ0zuPFfLL+Uj636mBxzrbkPyUxBonGWrKnVfxSf5xzYOY2b66sQ+u1m8kWr F61zajmJzl64jLdXkJlNFu3U5sqyV5XWXIuw8tL9kWWZa7URDgwMAOUFTQoLZyMslM44 AOjxDxJiRBEy22GFbsMby5f5xkTJBKYv+sKJa4idZbJTZUVy1Km1W4jL5z7y6u02M46P CTFw== X-Gm-Message-State: ALoCoQn8BnG445uI70j83jwKQG4kZjYJeS8er+8d4xWhfwGwMuZXy0E49NEw1C6ASTGX3/h1p++aLxpRsOwaCXhlEHpk/StZ5Q== X-Received: by 10.140.20.226 with SMTP id 89mr1237523qgj.16.1424481547416; Fri, 20 Feb 2015 17:19:07 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by mx.google.com with ESMTPS id j6sm7445684qcm.4.2015.02.20.17.19.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 20 Feb 2015 17:19:07 -0800 (PST) X-Relaying-Domain: verisign.com Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t1L1J6mi021187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 20 Feb 2015 20:19:06 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Fri, 20 Feb 2015 20:19:05 -0500 From: "Wessels, Duane" To: "dnsext@ietf.org" Thread-Topic: TTL on DS records Thread-Index: AQHQTXRiA48Y24/0eE+eVFKI53a0WQ== Date: Sat, 21 Feb 2015 01:19:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/signed; boundary="Apple-Mail=_9D36D4C2-06A9-44EC-B199-1495EB7FB495"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [dnsext] TTL on DS records X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 01:19:10 -0000 --Apple-Mail=_9D36D4C2-06A9-44EC-B199-1495EB7FB495 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Section 5 of RFC 4034 says: The DS RR has no special TTL requirements. While RFC 4035 Section 2.4 says: The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset Due the "SHOULD" I'm not sure this is worthy of an errata, but seems = rather unfortunate. Apologies if this is a previously known issue. DW --Apple-Mail=_9D36D4C2-06A9-44EC-B199-1495EB7FB495 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJU590JAAoJEGyZpGmowJiNPpYH/2WcYQ+ZYbuh0RlOoQeJmeBw YRf5TzHLM6ajIqVqZv4X3RDycWErFSHLuWQg7fHp7zkRo63Apc9lroaRC12otXIA rhvy8iUUDWhK5DA0DHR6A3IA8iHLVYDtxBWdYbRbeA9aqJ7XYHZlT4NRsgxuCeTe 3V/WDpgW3mAvtH5tyv8sloY9CpDRnZfifQH/fviZCbJwhXYEf9jhEa0P+PWDxWMM uuC3zIE97qUJ2ITVNNPZ0T1obR5Gr/oJGDkYeIMDxiJiM+JLKnHlsIahEaEarwWh vqzjjBXh1fQuNV5Q/eQL5crn5IbR1XS/4gm+33DBl1rueVVPcuh1ATt0Wkuhb8k= =AWvS -----END PGP SIGNATURE----- --Apple-Mail=_9D36D4C2-06A9-44EC-B199-1495EB7FB495-- From nobody Sat Feb 21 02:50:52 2015 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B422C1A3B9B for ; Sat, 21 Feb 2015 02:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] autolearn=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 1lp9f_UhIkQx for ; Sat, 21 Feb 2015 02:50:49 -0800 (PST) Received: from vic20.blipp.com (cl-682.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:2a9::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBAEA1A1EFD for ; Sat, 21 Feb 2015 02:50:48 -0800 (PST) Received: from bodot.local (unknown [IPv6:2001:16d8:cc4f:1000:38db:e2e8:75cb:d86f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by vic20.blipp.com (Postfix) with ESMTPSA id 96A1D381E0; Sat, 21 Feb 2015 11:50:45 +0100 (CET) Message-ID: <54E862FF.1080808@blipp.com> Date: Sat, 21 Feb 2015 11:50:39 +0100 From: =?windows-1252?Q?Patrik_Wallstr=F6m?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Wessels, Duane" , "dnsext@ietf.org" References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AAM67q2HJe5oeFE5QG2Ae6xpwIfiRKWD1" Archived-At: Subject: Re: [dnsext] TTL on DS records X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 10:50:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AAM67q2HJe5oeFE5QG2Ae6xpwIfiRKWD1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 21/02/15 02:19, Wessels, Duane wrote: > Section 5 of RFC 4034 says: > > The DS RR has no special TTL requirements. > > While RFC 4035 Section 2.4 says: > > The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRse= t > > Due the "SHOULD" I'm not sure this is worthy of an errata, but seems ra= ther unfortunate. > > Apologies if this is a previously known issue. Several TLD operators have a lower TTL on the DS. The reason is to help the registrant to recover from a signature failure and be fast to remove the DS. I think this is one of the reasons to why there is a SHOULD there= =2E --AAM67q2HJe5oeFE5QG2Ae6xpwIfiRKWD1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJU6GMDAAoJENv/4te3Ykny/JcP/1EqybmYWFLRK+uzuCRWJux4 ysS3qra1W6d7TimfCK1cfbMGHtlc9YVtiAw3n1g08ZgG9ZR9a1qXXVIpMvcb8F00 6d2LhvfyYC+03D4SPe05IihR+dKL5MVFH0XQTWot60ed+b+YN4Qj7PFJwnZPpnpJ 8dGn+r6AHA+MPlQzggfZcGnqqtt2MJ3BbT47R1RiGy33J1chHmgjIMrLfWEgnBnS PT2sFt4cCWqQtqWbEXt7sIb6JrJRW4HdE4oS2rxTf+j+ONOeX8oBk1Tr6wKbCBUs xIzom7oisZOIufIFuh8Qyv5M0JG4WSFj60ck33M9kYrgeQ1gR8R2wSfBd0ORpTDC npf5/wL1Lh1ZaP/6qAKk6Ukj648GIur0V0L7aLckRqfjxhR0p7/KfCzOsIbE1hhz bf0mnB6Qu+JrhxUiXU+PMB/JVOUGz5WNc340SnOqyho9DxB3Ejaw23qcXCKdKNLH ed5V0hCY/U5JYy6XnhELSbAZu5jonzBqKulXV6+iCzpvcT3MSvul1YaCq7bKshCd r0MG4yFp55KxIyTSt5uhhYHIdzvaXf2P7czazZIa5IIPSdkpXgdhi/IC5UTkiEwB Z1vdSIu0Agl/tllE4ftTyFbJDZQz1DKPJj3m+nBpGo7EnYShcREkZvx+qs45CI55 lbWk2qVqj0oXlq/9kiT5 =Qoda -----END PGP SIGNATURE----- --AAM67q2HJe5oeFE5QG2Ae6xpwIfiRKWD1-- From nobody Sat Feb 21 03:15:35 2015 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E3E1A6EE8 for ; Sat, 21 Feb 2015 03:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.139 X-Spam-Level: X-Spam-Status: No, score=0.139 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 dpElTSs-mhx7 for ; Sat, 21 Feb 2015 03:15:32 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538C41A6EFB for ; Sat, 21 Feb 2015 03:15:32 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::20c8:70ba:697c:fc3] (unknown [IPv6:2a02:80:3ffc:0:20c8:70ba:697c:fc3]) by mail.frobbit.se (Postfix) with ESMTPSA id 71259202B6; Sat, 21 Feb 2015 12:15:30 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_421311D6-15F2-4ABA-A14A-FE8E7B0A15DE"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <54E862FF.1080808@blipp.com> Date: Sat, 21 Feb 2015 12:15:29 +0100 Message-Id: References: <54E862FF.1080808@blipp.com> To: Patrik Wallstrom X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "dnsext@ietf.org" Subject: Re: [dnsext] TTL on DS records X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 11:15:33 -0000 --Apple-Mail=_421311D6-15F2-4ABA-A14A-FE8E7B0A15DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On 21 feb 2015, at 11:50, Patrik Wallstr=F6m wrote: >=20 > On 21/02/15 02:19, Wessels, Duane wrote: >> Section 5 of RFC 4034 says: >>=20 >> The DS RR has no special TTL requirements. >>=20 >> While RFC 4035 Section 2.4 says: >>=20 >> The TTL of a DS RRset SHOULD match the TTL of the delegating NS = RRset >>=20 >> Due the "SHOULD" I'm not sure this is worthy of an errata, but seems = rather unfortunate. >>=20 >> Apologies if this is a previously known issue. > Several TLD operators have a lower TTL on the DS. The reason is to = help > the registrant to recover from a signature failure and be fast to = remove > the DS. I think this is one of the reasons to why there is a SHOULD = there. My personal view is that the TTL for the DS should be really short. I.e. = much shorter than what people might think. This because any kind of key = rollover (when doing transfer etc) or forwarding of private keys, or any = other "correct" theoretical model of how to do transfer in reality I = think is just...theory. Specifically as one of the main reasons for = doing transfer is that the loosing registrar/dns operator is that they = do not do their job. And because of that have double reasons for not = cooperating in the transfer. But, I would like some really smart people think about what "really = short" should be. 15 minutes? Patrik --Apple-Mail=_421311D6-15F2-4ABA-A14A-FE8E7B0A15DE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFU6GjRrMabGguI180RAp3nAKCGCu0jgAu8DIusMPxG79uV7MvaagCeN0fc uGr1FH0PBEW94xUDEuEh5Y8= =7ZlH -----END PGP SIGNATURE----- --Apple-Mail=_421311D6-15F2-4ABA-A14A-FE8E7B0A15DE-- From nobody Sat Feb 21 04:21:10 2015 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7691A6FEB for ; Sat, 21 Feb 2015 04:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.559 X-Spam-Level: ** X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=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 eeKBRe_wz5xS for ; Sat, 21 Feb 2015 04:21:08 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0541A6FE9 for ; Sat, 21 Feb 2015 04:21:08 -0800 (PST) Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id EDAC08A035 for ; Sat, 21 Feb 2015 12:21:05 +0000 (UTC) Date: Sat, 21 Feb 2015 07:21:04 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20150221122103.GJ13877@mx1.yitter.info> References: <54E862FF.1080808@blipp.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.5.23 (2014-03-12) Archived-At: Subject: Re: [dnsext] TTL on DS records X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 12:21:09 -0000 On Sat, Feb 21, 2015 at 12:15:29PM +0100, Patrik Fältström wrote: > > My personal view is that the TTL for the DS should be really short. This would be yet another reason for people not to turn on validation, because validating will become an excellent way to increase latency in page loading. It seems to me that you want to defend against one problem (lousy operator) by creating a new one (poor caching). I'm not convinced that's an excellent trade off. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sat Feb 21 06:05:36 2015 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C921A6FF1 for ; Sat, 21 Feb 2015 06:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.062 X-Spam-Level: X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBCmhhrh5clr for ; Sat, 21 Feb 2015 06:05:32 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8832E1A6FF0 for ; Sat, 21 Feb 2015 06:05:32 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::20c8:70ba:697c:fc3] (unknown [IPv6:2a02:80:3ffc:0:20c8:70ba:697c:fc3]) by mail.frobbit.se (Postfix) with ESMTPSA id 508A322E68; Sat, 21 Feb 2015 15:05:30 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_42CCFBBD-B1A9-49F9-9C1F-751CC3CF3B3E"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <20150221122103.GJ13877@mx1.yitter.info> Date: Sat, 21 Feb 2015 15:05:29 +0100 Message-Id: <53DC0FD9-6C5D-4132-9FD5-EF56162641D2@frobbit.se> References: <54E862FF.1080808@blipp.com> <20150221122103.GJ13877@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dnsext@ietf.org Subject: Re: [dnsext] TTL on DS records X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 14:05:34 -0000 --Apple-Mail=_42CCFBBD-B1A9-49F9-9C1F-751CC3CF3B3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21 feb 2015, at 13:21, Andrew Sullivan = wrote: >=20 > On Sat, Feb 21, 2015 at 12:15:29PM +0100, Patrik F=C3=A4ltstr=C3=B6m = wrote: >>=20 >> My personal view is that the TTL for the DS should be really short. >=20 > This would be yet another reason for people not to turn on validation, > because validating will become an excellent way to increase latency in > page loading. It seems to me that you want to defend against one > problem (lousy operator) by creating a new one (poor caching). I'm > not convinced that's an excellent trade off. Well, my point is that there is a balance, and I ask for a calculation = of that balance. Today, with a lousy operator that one move a domain away from have a = delay in effect of that move which is based on the TTL of the DS. My question is how long we think that delay should be, to not affect = caching too much. Given we see caching issues anyway around the net that question why we = have 48h TTL on some records. I am not after 1 second TTL, but maybe it should be recommended to be 1h = and not 48h. I also btw do see complaints on registries only updating their zone = every 4h or 8h, so I see a clear trend to have shorter caching. I was just after a discussion :-) Patrik --Apple-Mail=_42CCFBBD-B1A9-49F9-9C1F-751CC3CF3B3E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFU6JCqrMabGguI180RArn6AJoCNRnvG9LG0fnBt0xKSU+RKIBGcwCfcpBK R7XhyPPTu5lsGVplFCSyXqs= =HVov -----END PGP SIGNATURE----- --Apple-Mail=_42CCFBBD-B1A9-49F9-9C1F-751CC3CF3B3E-- From nobody Sat Feb 21 08:18:38 2015 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BAD1A7030 for ; Sat, 21 Feb 2015 08:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334] autolearn=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 MJD2FlkYZRTJ for ; Sat, 21 Feb 2015 08:18:36 -0800 (PST) Received: from abenaki.wabanaki.net (nike.wampumpeag.net [67.42.198.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 05A611A702F for ; Sat, 21 Feb 2015 08:18:35 -0800 (PST) Received: from frog.local ([67.42.198.93]) by abenaki.wabanaki.net (8.14.9/8.14.9) with ESMTP id t1LGHv6w093394 for ; Sat, 21 Feb 2015 08:18:24 -0800 (PST) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <54E8AFAB.7090109@abenaki.wabanaki.net> Date: Sat, 21 Feb 2015 08:17:47 -0800 From: Eric Brunner-Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <54E862FF.1080808@blipp.com> <20150221122103.GJ13877@mx1.yitter.info> <53DC0FD9-6C5D-4132-9FD5-EF56162641D2@frobbit.se> In-Reply-To: <53DC0FD9-6C5D-4132-9FD5-EF56162641D2@frobbit.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dnsext] TTL on DS records X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 16:18:37 -0000 On 2/21/15 6:05 AM, Patrik Fältström wrote: > I also btw do see complaints on registries only updating their zone every 4h or 8h, so I see a clear trend to have shorter caching. Paf, Could you expand on what you've seen as complaints? Are these from registrants (or their agents) attempting "stupid dns tricks", or monitization schemes, or ... In my limited experience, registrants pursuing a plan of making more than nominal resources available are insensitive to zone update frequency. Eric From nobody Sat Feb 21 08:28:46 2015 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C89E1A702F for ; Sat, 21 Feb 2015 08:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 TKqfgIYZnOjk for ; Sat, 21 Feb 2015 08:28:44 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFED81A702D for ; Sat, 21 Feb 2015 08:28:44 -0800 (PST) Received: from [192.168.1.138] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 4DCB622AB4; Sat, 21 Feb 2015 17:28:43 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DBFE3344-1ED8-43D0-BAE0-D215150A5ACD"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <54E8AFAB.7090109@abenaki.wabanaki.net> Date: Sat, 21 Feb 2015 17:28:43 +0100 Message-Id: References: <54E862FF.1080808@blipp.com> <20150221122103.GJ13877@mx1.yitter.info> <53DC0FD9-6C5D-4132-9FD5-EF56162641D2@frobbit.se> <54E8AFAB.7090109@abenaki.wabanaki.net> To: Eric Brunner-Williams X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dnsext@ietf.org Subject: Re: [dnsext] TTL on DS records X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 16:28:46 -0000 --Apple-Mail=_DBFE3344-1ED8-43D0-BAE0-D215150A5ACD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On 21 feb 2015, at 17:17, Eric Brunner-Williams = wrote: >=20 > On 2/21/15 6:05 AM, Patrik F=E4ltstr=F6m wrote: >> I also btw do see complaints on registries only updating their zone = every 4h or 8h, so I see a clear trend to have shorter caching. >=20 > Paf, >=20 > Could you expand on what you've seen as complaints? Are these from = registrants (or their agents) attempting "stupid dns tricks", or = monitization schemes, or ... Registrants asking registrars why they have to wait to get to use the = domain names they just procured. And the problem might not be the wait, but that some TLDs have "instant = update" and some others have "longer wait". And the difference is what registrars have to try to explain to = registrants. > In my limited experience, registrants pursuing a plan of making more = than nominal resources available are insensitive to zone update = frequency. Patrik --Apple-Mail=_DBFE3344-1ED8-43D0-BAE0-D215150A5ACD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFU6LI7rMabGguI180RAkufAJwKKPPX+U18LaX2tShhB+SPR1rgOQCeNtm2 f479b3xm78jITKZRp0oKfog= =SD5x -----END PGP SIGNATURE----- --Apple-Mail=_DBFE3344-1ED8-43D0-BAE0-D215150A5ACD-- From nobody Sat Feb 21 11:19:43 2015 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7EB1A1A1B for ; Sat, 21 Feb 2015 11:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.547 X-Spam-Level: *** X-Spam-Status: No, score=3.547 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, HOST_EQ_STATICB=1.372, SPF_PASS=-0.001] autolearn=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 nCE18xuTdLCl for ; Sat, 21 Feb 2015 11:19:40 -0800 (PST) Received: from smtp.guxx.net (static.85-10-208-173.clients.your-server.de [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF321A039F for ; Sat, 21 Feb 2015 11:19:40 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id D93745F40E3F; Sat, 21 Feb 2015 20:19:37 +0100 (CET) Received: from PorcupineTree.Speedport_W_724V_01011601_00_009 (p5DD46E20.dip0.t-ipconnect.de [93.212.110.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 47EA25F40E16; Sat, 21 Feb 2015 20:19:36 +0100 (CET) Date: Sat, 21 Feb 2015 20:19:34 +0100 From: Ralf Weber To: Andrew Sullivan Message-ID: <20150221191934.GA43112@PorcupineTree.Speedport_W_724V_01011601_00_009> References: <54E862FF.1080808@blipp.com> <20150221122103.GJ13877@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150221122103.GJ13877@mx1.yitter.info> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: dnsext@ietf.org Subject: Re: [dnsext] TTL on DS records X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 19:19:41 -0000 Moin! On Sat, Feb 21, 2015 at 07:21:04AM -0500, Andrew Sullivan wrote: > On Sat, Feb 21, 2015 at 12:15:29PM +0100, Patrik Fältström wrote: > > > > My personal view is that the TTL for the DS should be really short. > > This would be yet another reason for people not to turn on validation, > because validating will become an excellent way to increase latency in > page loading. It seems to me that you want to defend against one > problem (lousy operator) by creating a new one (poor caching). I'm > not convinced that's an excellent trade off. I don't see how this will increase latency of page loading. Most recursive resolvers these day do pre fetching for often used records and if the record isn't in the cache the difference in latency comes from validation anyway. I think we need to move away from TTLs in the days or even week range to TTLs that are in the hours range. I think one hour is a good TTL for DNSSEC stuff. If your domain isn't asked once an hour in a big providers network chances are it would have fallen out of the cache becuse of LRU anyway during that time frame. So long -Ralf From nobody Sat Feb 21 12:50:53 2015 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673D71A6EF3 for ; Sat, 21 Feb 2015 12:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.559 X-Spam-Level: ** X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=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 Yz5hqyX5Qvvp for ; Sat, 21 Feb 2015 12:50:51 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A121A7016 for ; Sat, 21 Feb 2015 12:50:37 -0800 (PST) Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 2B4C88A031 for ; Sat, 21 Feb 2015 20:50:36 +0000 (UTC) Date: Sat, 21 Feb 2015 15:50:34 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20150221205034.GT13877@mx1.yitter.info> References: <54E862FF.1080808@blipp.com> <20150221122103.GJ13877@mx1.yitter.info> <20150221191934.GA43112@PorcupineTree.Speedport_W_724V_01011601_00_009> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150221191934.GA43112@PorcupineTree.Speedport_W_724V_01011601_00_009> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnsext] TTL on DS records X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2015 20:50:52 -0000 On Sat, Feb 21, 2015 at 08:19:34PM +0100, Ralf Weber wrote: > I don't see how this will increase latency of page loading. Most > recursive resolvers these day do pre fetching for often used records > and if the record isn't in the cache the difference in latency comes > from validation anyway. Well, this could be, but if you're validating, reducing the TTL on the DS automatically entails a lookup as frequently as the DS. Now of course, if browsers are doing this validation themselves (and not relying on the system validator), they might pin anyway. > I think we need to move away from TTLs in the days or even week range > to TTLs that are in the hours range. What do you mean _we_? Your zone, your rules. That's part of why I'm objecting to parents having very short DS TTLs: it affects what the child's cache behaviour is like, and we have historically supposed that zone administrators have pretty good control over that for their own zones. If the parent side TTL gets short, then setting the TTL on the child side isn't the only thing one can do to affect caching. That seems like a pretty big change to the operational environment. > I think one hour is a good TTL for DNSSEC stuff. If your domain > isn't asked once an hour in a big providers network chances are it > would have fallen out of the cache becuse of LRU anyway during that > time frame. That could be. It seems to me that without actually studying this, we could all make up numbers. I gather that OARC is going to run another DITL this year. Maybe that'd be something worth getting large recursive operators involved in so that we have something to study. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sat Feb 21 17:42:45 2015 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9E41A0196 for ; Sat, 21 Feb 2015 17:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vGw6U5gomqG for ; Sat, 21 Feb 2015 17:42:41 -0800 (PST) Received: from smtp91.ord1c.emailsrvr.com (smtp91.ord1c.emailsrvr.com [108.166.43.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05E81A0191 for ; Sat, 21 Feb 2015 17:42:41 -0800 (PST) Received: from smtp20.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp20.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 2A710800F0; Sat, 21 Feb 2015 20:42:41 -0500 (EST) Received: by smtp20.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id E32AC800D0; Sat, 21 Feb 2015 20:42:39 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-74-96-189-180.washdc.fios.verizon.net [74.96.189.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Sun, 22 Feb 2015 01:42:41 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Olafur Gudmundsson In-Reply-To: <20150221205034.GT13877@mx1.yitter.info> Date: Sat, 21 Feb 2015 20:42:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8025FA20-9C5D-4CB9-9A6F-C43080C35229@ogud.com> References: <54E862FF.1080808@blipp.com> <20150221122103.GJ13877@mx1.yitter.info> <20150221191934.GA43112@PorcupineTree.Speedport_W_724V_01011601_00_009> <20150221205034.GT13877@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dnsext@ietf.org Subject: Re: [dnsext] TTL on DS records X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 01:42:44 -0000 > On Feb 21, 2015, at 3:50 PM, Andrew Sullivan = wrote: >=20 > On Sat, Feb 21, 2015 at 08:19:34PM +0100, Ralf Weber wrote: >> I don't see how this will increase latency of page loading. Most >> recursive resolvers these day do pre fetching for often used records >> and if the record isn't in the cache the difference in latency comes=20= >> from validation anyway. >=20 > Well, this could be, but if you're validating, reducing the TTL on the > DS automatically entails a lookup as frequently as the DS. Now of > course, if browsers are doing this validation themselves (and not > relying on the system validator), they might pin anyway. No Andrew it effectively is the MAX( DS TTL, DNSKEY TTL)=20 and with prefetching you can compare existing records to the new ones = thus avoid validation.=20 In most cases there is plenty of headroom for calculations so I think we = should be thinking about what is good for the internet.=20 Long TTL=E2=80=99s are good for unstable networks, Short TTL meet = customers expectations.=20 >=20 >> I think we need to move away from TTLs in the days or even week range >> to TTLs that are in the hours range. >=20 > What do you mean _we_? Your zone, your rules. That's part of why I'm > objecting to parents having very short DS TTLs: it affects what the > child's cache behaviour is like, and we have historically supposed > that zone administrators have pretty good control over that for their > own zones. If the parent side TTL gets short, then setting the TTL on > the child side isn't the only thing one can do to affect caching. > That seems like a pretty big change to the operational environment. Not putting words in Ralph=E2=80=99s mouth, but I agree with him.=20 Long TTL are artifacts of decisions taken long time ago and they need to be reexamined.=20 >=20 >> I think one hour is a good TTL for DNSSEC stuff. If your domain >> isn't asked once an hour in a big providers network chances are it >> would have fallen out of the cache becuse of LRU anyway during that >> time frame. >=20 > That could be. It seems to me that without actually studying this, we > could all make up numbers. I gather that OARC is going to run another > DITL this year. Maybe that'd be something worth getting large > recursive operators involved in so that we have something to study. Yep we need to study and experiment.=20 A simple study is to compare how much more traffic a resolver with = MAXCACHE =3D 1H=20 asks than one with MAXCACHE =3D 6H or 12H=20 Olafur From nobody Sat Feb 21 19:14:03 2015 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9521A005D for ; Sat, 21 Feb 2015 19:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.758 X-Spam-Level: * X-Spam-Status: No, score=1.758 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=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 KL4k3rTGIryu for ; Sat, 21 Feb 2015 19:14:00 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6961A0039 for ; Sat, 21 Feb 2015 19:13:59 -0800 (PST) Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id A8F1A8A031 for ; Sun, 22 Feb 2015 03:13:58 +0000 (UTC) Date: Sat, 21 Feb 2015 22:13:57 -0500 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20150222031357.GY13877@mx1.yitter.info> References: <54E862FF.1080808@blipp.com> <20150221122103.GJ13877@mx1.yitter.info> <20150221191934.GA43112@PorcupineTree.Speedport_W_724V_01011601_00_009> <20150221205034.GT13877@mx1.yitter.info> <8025FA20-9C5D-4CB9-9A6F-C43080C35229@ogud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8025FA20-9C5D-4CB9-9A6F-C43080C35229@ogud.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnsext] TTL on DS records X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 03:14:02 -0000 On Sat, Feb 21, 2015 at 08:42:38PM -0500, Olafur Gudmundsson wrote: > > No Andrew it effectively is the MAX( DS TTL, DNSKEY TTL) I suppose it's true that, having validated the DNSKEY once, you're not going to check it again. It does still entail that the parent zone gets to make TTL decisions that affect the lookups necessary for use of child-side data. > Long TTL are artifacts of decisions taken long time ago > and they need to be reexamined. I don't have any trouble with the idea that most caches aren't going to keep anything for a week, and I know lots of zones that have very short TTLs. But as I said, it's almost completely novel in the DNS that the parent-side decisions affect things for the child in this way, and I think we shouldn't be cavalier about that change. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Sun Feb 22 20:17:18 2015 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA531A0187 for ; Sun, 22 Feb 2015 20:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.547 X-Spam-Level: *** X-Spam-Status: No, score=3.547 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_NET=0.611, HOST_EQ_STATICB=1.372, SPF_PASS=-0.001] autolearn=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 EFhutronrUUl for ; Sun, 22 Feb 2015 20:17:16 -0800 (PST) Received: from smtp.guxx.net (static.85-10-208-173.clients.your-server.de [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9579D1A0167 for ; Sun, 22 Feb 2015 20:17:16 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id 1E8425F40E38; Mon, 23 Feb 2015 05:17:13 +0100 (CET) Received: from PorcupineTree.Speedport_W_724V_01011601_00_009 (p5DD46E20.dip0.t-ipconnect.de [93.212.110.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 664B95F402D3; Mon, 23 Feb 2015 05:17:12 +0100 (CET) Date: Mon, 23 Feb 2015 05:17:10 +0100 From: Ralf Weber To: Andrew Sullivan Message-ID: <20150223041710.GA43131@PorcupineTree.Speedport_W_724V_01011601_00_009> References: <54E862FF.1080808@blipp.com> <20150221122103.GJ13877@mx1.yitter.info> <20150221191934.GA43112@PorcupineTree.Speedport_W_724V_01011601_00_009> <20150221205034.GT13877@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150221205034.GT13877@mx1.yitter.info> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: dnsext@ietf.org Subject: Re: [dnsext] TTL on DS records X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 04:17:17 -0000 Moin! On Sat, Feb 21, 2015 at 03:50:34PM -0500, Andrew Sullivan wrote: > Well, this could be, but if you're validating, reducing the TTL on the > DS automatically entails a lookup as frequently as the DS. Now of > course, if browsers are doing this validation themselves (and not > relying on the system validator), they might pin anyway. Don't most browser validators still use at least the system stub resolvers and thus your configured recursive resolver anyway? What you describe is correct, but the lookup only has to fill the DS from the parent and nothing from the child (unless it expired of course). > > I think we need to move away from TTLs in the days or even week range > > to TTLs that are in the hours range. > > What do you mean _we_? The DNS community within the IETF (and possible other venues). > Your zone, your rules. That's part of why I'm > objecting to parents having very short DS TTLs: it affects what the > child's cache behaviour is like, and we have historically supposed > that zone administrators have pretty good control over that for their > own zones. If the parent side TTL gets short, then setting the TTL on > the child side isn't the only thing one can do to affect caching. > That seems like a pretty big change to the operational environment. Yes there may be one round trip to the parent name server when the DS expires, but you still control how often your server is asked with the TTL of your records (unless there is an attack ;-). > That could be. It seems to me that without actually studying this, we > could all make up numbers. I gather that OARC is going to run another > DITL this year. Maybe that'd be something worth getting large > recursive operators involved in so that we have something to study. You have to as in the DITL run you might not see the effect of different DS TTL because the root might not be asked in the cache refill scenario. Just one side note of personal experience running or helping people to run large resolver farms over the last 20 years. While the average TTL, especially for often used records has gone down during that time frame, the cache hit rate has gone up. These days it is not uncommon to see cache hit rates of 90% or more. So I don't think lowering the TTL of the DS record will have an impact on the cache hotness and thus performance of resolution. So long -Ralf