From nobody Tue Dec 2 08:37:18 2014 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 8E6CA1A1C04 for ; Tue, 2 Dec 2014 08:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 YQZMtXIbYCyy for ; Tue, 2 Dec 2014 08:37:15 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 295D61A1BF3 for ; Tue, 2 Dec 2014 08:37:15 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E4BFC18123F; Tue, 2 Dec 2014 08:36:46 -0800 (PST) To: weiler@tislabs.com, davidb@verisign.com, brian@innovationslab.net, ted.lemon@nominum.com, ogud@ogud.com, ajs@anvilwalrusden.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141202163646.E4BFC18123F@rfc-editor.org> Date: Tue, 2 Dec 2014 08:36:46 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/4KM5gHO84ndayHWbvVZpOcBr9JU Cc: edward.lewis@icann.org, dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] [Editorial Errata Reported] RFC6840 (4191) 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: Tue, 02 Dec 2014 16:37:16 -0000 The following errata report has been submitted for RFC6840, "Clarifications and Implementation Notes for DNS Security (DNSSEC)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6840&eid=4191 -------------------------------------- Type: Editorial Reported by: Edward Lewis Section: 5.11 Original Text ------------- ... A signed zone MUST include a DNSKEY for each algorithm present in the zone's DS RRset and expected trust anchors for the zone. The zone MUST also be signed with each algorithm (though not each key) present in the DNSKEY RRset. Corrected Text -------------- A signed zone MUST include a DNSKEY for each algorithm present in the zone's DS RRset and expected trust anchors for the zone. Each authoritative RRset in the zone MUST be signed with each algorithm (though not each key) present in the DNSKEY RRset. Notes ----- Zones aren't signed (per se), the data sets within them are. But not cut point (NS) and glue. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6840 (draft-ietf-dnsext-dnssec-bis-updates-20) -------------------------------------- Title : Clarifications and Implementation Notes for DNS Security (DNSSEC) Publication Date : February 2013 Author(s) : S. Weiler, Ed., D. Blacka, Ed. Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From nobody Tue Dec 2 09:12:02 2014 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 790421A1EEC for ; Tue, 2 Dec 2014 09:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 IQWmNP0ZMnkI for ; Tue, 2 Dec 2014 09:11:50 -0800 (PST) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67911A6F8E for ; Tue, 2 Dec 2014 09:10:41 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id gq1so10171600obb.12 for ; Tue, 02 Dec 2014 09:10:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dAFOozjNYwjua1Qx1P6yWo6nyggqS0HDDo5x7ebww7A=; b=jcvIuWiwQSMGcy/dP2FuGEO6mJ+GLMu+jqzSHeBcJRO1sTN15LhZaOEQCmb7TnYsBk w84TfaRCDoa29QfvMMeKClkqGrSpKCvFGVf+7nSmPTP9Y5RZ4xTEGdW9AAjHMcavF6bg 03zUdBcf7gK/CF7lWZPsWq/QxOTw9gQ/rj/4iOfIjrNo5UoZje08HdCg5QormlVmtGHn MsDWohV6EQSmMNdKfyXhTWxQw15FJANAv7TpbkUP3WU70ff0Bf+bEJ6wgW3IVl1YiufV NOa+bsx/G3pS45bmR6xLfhTMMj3zlPZYUkTd1zCsTm6KNE+kRdfnbA99wNT9a1iZP8m6 kH9w== X-Received: by 10.182.120.10 with SMTP id ky10mr241928obb.68.1417540240165; Tue, 02 Dec 2014 09:10:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.147.105 with HTTP; Tue, 2 Dec 2014 09:10:19 -0800 (PST) In-Reply-To: <20141202163646.E4BFC18123F@rfc-editor.org> References: <20141202163646.E4BFC18123F@rfc-editor.org> From: Donald Eastlake Date: Tue, 2 Dec 2014 12:10:19 -0500 Message-ID: To: RFC Errata System Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/UcI860eDqeV4w6GmXoJsjX3FIUk Cc: edward.lewis@icann.org, Brian Haberman , IETF DNSEXT WG , Ted Lemon , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191) 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: Tue, 02 Dec 2014 17:11:52 -0000 While the new text is OK, I do not think the old text is wrong. "signing a zone" is a well known term of art for signing the authoritative RRsets in the zone. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Dec 2, 2014 at 11:36 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC6840, > "Clarifications and Implementation Notes for DNS Security (DNSSEC)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6840&eid=4191 > > -------------------------------------- > Type: Editorial > Reported by: Edward Lewis > > Section: 5.11 > > Original Text > ------------- > ... > > A signed zone MUST include a DNSKEY for each algorithm present in > the zone's DS RRset and expected trust anchors for the zone. The > zone MUST also be signed with each algorithm (though not each key) > present in the DNSKEY RRset. > > Corrected Text > -------------- > A signed zone MUST include a DNSKEY for each algorithm present in > the zone's DS RRset and expected trust anchors for the zone. Each > authoritative RRset in the zone MUST be signed with each > algorithm (though not each key) present in the DNSKEY RRset. > > Notes > ----- > Zones aren't signed (per se), the data sets within them are. But not cut point (NS) and glue. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6840 (draft-ietf-dnsext-dnssec-bis-updates-20) > -------------------------------------- > Title : Clarifications and Implementation Notes for DNS Security (DNSSEC) > Publication Date : February 2013 > Author(s) : S. Weiler, Ed., D. Blacka, Ed. > Category : PROPOSED STANDARD > Source : DNS Extensions > Area : Internet > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From nobody Tue Dec 2 12:21:31 2014 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 E4F031A6FBE for ; Tue, 2 Dec 2014 12:21:28 -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 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 CCbr_2QzVvts for ; Tue, 2 Dec 2014 12:21:27 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF5A1A6F0D for ; Tue, 2 Dec 2014 12:21:27 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 428A3880EA; Tue, 2 Dec 2014 12:21:27 -0800 (PST) Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 71BFF71C0002; Tue, 2 Dec 2014 12:21:26 -0800 (PST) Message-ID: <547E1F3F.5040400@innovationslab.net> Date: Tue, 02 Dec 2014 15:21:19 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: RFC Errata System , weiler@tislabs.com, davidb@verisign.com, ted.lemon@nominum.com, ogud@ogud.com, ajs@anvilwalrusden.com References: <20141202163646.E4BFC18123F@rfc-editor.org> In-Reply-To: <20141202163646.E4BFC18123F@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Crl43d0NQhXQ5i0mFk8QjWKvr9dXWwp3e" Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/ox1OzgO_pMLRXWian7WdhQ2rr6I Cc: edward.lewis@icann.org, dnsext@ietf.org Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191) 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: Tue, 02 Dec 2014 20:21:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Crl43d0NQhXQ5i0mFk8QjWKvr9dXWwp3e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Despite Donald's assertion, I think this is a valid erratum and should be marked Verified. However, I will wait for others to chime in on the subject before doing so. Regards, Brian On 12/2/14 11:36 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC6840, > "Clarifications and Implementation Notes for DNS Security (DNSSEC)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6840&eid=3D4191 >=20 > -------------------------------------- > Type: Editorial > Reported by: Edward Lewis >=20 > Section: 5.11 >=20 > Original Text > ------------- > ... >=20 > A signed zone MUST include a DNSKEY for each algorithm present in > the zone's DS RRset and expected trust anchors for the zone. The= > zone MUST also be signed with each algorithm (though not each key= ) > present in the DNSKEY RRset. =20 >=20 > Corrected Text > -------------- > A signed zone MUST include a DNSKEY for each algorithm present in > the zone's DS RRset and expected trust anchors for the zone. Eac= h > authoritative RRset in the zone MUST be signed with each=20 > algorithm (though not each key) present in the DNSKEY RRset. =20 >=20 > Notes > ----- > Zones aren't signed (per se), the data sets within them are. But not c= ut point (NS) and glue. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6840 (draft-ietf-dnsext-dnssec-bis-updates-20) > -------------------------------------- > Title : Clarifications and Implementation Notes for DNS S= ecurity (DNSSEC) > Publication Date : February 2013 > Author(s) : S. Weiler, Ed., D. Blacka, Ed. > Category : PROPOSED STANDARD > Source : DNS Extensions > Area : Internet > Stream : IETF > Verifying Party : IESG >=20 --Crl43d0NQhXQ5i0mFk8QjWKvr9dXWwp3e 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.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUfh9FAAoJEBOZRqCi7goqw+QIAIWTWGTSt7ULBbR+0wdAnZxu 5ROESijH8DEMyeWjZceEstHA0HQjuQ9H142434XvVH/XZYP45l4afqkRKVR7EfFC 63AbMNbDKpLV1oKgs6KYYiUQvxAlspSvuG9CtfaP2Xw2kq3/NXNJX/JGet2a2OKq YJNH4H3X1GC5jM0jADLZEeDZjsl8ShEjpZ7Sy0ZQcGm7Io52U4qaujQAqYiI1RZ6 Z/BYT8wrJvgT175UDpSReDcK2/bItKYjKAWHQiUhLajMVLRRtU2hppyxDAq6wp/J Jipip/wg9CGrng1oadvZomS8UtJk+CgUq1C5PM1k1hK2mwOH5V3A2gO+JTbBV4o= =fxfb -----END PGP SIGNATURE----- --Crl43d0NQhXQ5i0mFk8QjWKvr9dXWwp3e-- From nobody Tue Dec 2 13:07:26 2014 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 045A41A8766 for ; Tue, 2 Dec 2014 13:07:23 -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 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 bZyZ0_-gjqwi for ; Tue, 2 Dec 2014 13:07:18 -0800 (PST) Received: from smtp107.ord1c.emailsrvr.com (smtp107.ord1c.emailsrvr.com [108.166.43.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F6B1A7015 for ; Tue, 2 Dec 2014 13:06:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp14.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 7F7403803A5; Tue, 2 Dec 2014 16:06:49 -0500 (EST) X-Virus-Scanned: OK Received: by smtp14.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id E3E073802E0; Tue, 2 Dec 2014 16:06:47 -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.3.2); Tue, 02 Dec 2014 21:06:49 GMT Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Olafur Gudmundsson In-Reply-To: <547E1F3F.5040400@innovationslab.net> Date: Tue, 2 Dec 2014 16:06:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <792B8DE9-6E5A-4638-8D5B-5A12B15E680D@ogud.com> References: <20141202163646.E4BFC18123F@rfc-editor.org> <547E1F3F.5040400@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/FSxcDFbVInqXjK5pOYNhti93jZM Cc: edward.lewis@icann.org, dnsext@ietf.org, ted.lemon@nominum.com, RFC Errata System Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191) 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: Tue, 02 Dec 2014 21:07:23 -0000 I agree the text Ed supplied is clearer to outsiders and has the same = meaning to=20 insiders as the original text.=20 I recommend you approve the errata.=20 Olafur > On Dec 2, 2014, at 3:21 PM, Brian Haberman = wrote: >=20 > Despite Donald's assertion, I think this is a valid erratum and should > be marked Verified. However, I will wait for others to chime in on = the > subject before doing so. >=20 > Regards, > Brian >=20 > On 12/2/14 11:36 AM, RFC Errata System wrote: >> The following errata report has been submitted for RFC6840, >> "Clarifications and Implementation Notes for DNS Security (DNSSEC)". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6840&eid=3D4191 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Edward Lewis >>=20 >> Section: 5.11 >>=20 >> Original Text >> ------------- >> ... >>=20 >> A signed zone MUST include a DNSKEY for each algorithm present in >> the zone's DS RRset and expected trust anchors for the zone. = The >> zone MUST also be signed with each algorithm (though not each = key) >> present in the DNSKEY RRset. =20 >>=20 >> Corrected Text >> -------------- >> A signed zone MUST include a DNSKEY for each algorithm present in >> the zone's DS RRset and expected trust anchors for the zone. = Each >> authoritative RRset in the zone MUST be signed with each=20 >> algorithm (though not each key) present in the DNSKEY RRset. =20 >>=20 >> Notes >> ----- >> Zones aren't signed (per se), the data sets within them are. But not = cut point (NS) and glue. >>=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC6840 (draft-ietf-dnsext-dnssec-bis-updates-20) >> -------------------------------------- >> Title : Clarifications and Implementation Notes for DNS = Security (DNSSEC) >> Publication Date : February 2013 >> Author(s) : S. Weiler, Ed., D. Blacka, Ed. >> Category : PROPOSED STANDARD >> Source : DNS Extensions >> Area : Internet >> Stream : IETF >> Verifying Party : IESG >>=20 >=20 From nobody Tue Dec 2 13:08:14 2014 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 3A3EB1A6FC8 for ; Tue, 2 Dec 2014 10:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Wfs3xKuoSWQP for ; Tue, 2 Dec 2014 10:13:33 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806C01A6FA9 for ; Tue, 2 Dec 2014 10:11:48 -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.847.32; Tue, 2 Dec 2014 10:11:46 -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.0847.030; Tue, 2 Dec 2014 10:11:46 -0800 From: Edward Lewis To: Donald Eastlake , RFC Errata System Thread-Topic: [dnsext] [Editorial Errata Reported] RFC6840 (4191) Thread-Index: AQHQDlL1qlXfNw4PC0WJ/rKir6IeeJx8zH0A Date: Tue, 2 Dec 2014 18:11:45 +0000 Message-ID: References: <20141202163646.E4BFC18123F@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [192.0.47.235] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3500370702_8678210" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/sNWmFOrjBKJWYjWs88qabtX_ubM X-Mailman-Approved-At: Tue, 02 Dec 2014 13:08:06 -0800 Cc: Brian Haberman , IETF DNSEXT WG , Ted Lemon , =?utf-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191) 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: Tue, 02 Dec 2014 18:13:43 -0000 --B_3500370702_8678210 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable That may be - but there=E2=80=99s currently yet another call for a SIG(AXFR), which to me is =E2=80=9Csigning the zone.=E2=80=9D When I was reading the RFC (just to catch up) that was in the back of my mind. FWIW, I have corrected anyone who says they 'sign the zone=E2=80=99. Partly because that is not what is done in much of today=E2=80=99s operations - most of the signing is incremental (a few sets at a time). Implementations that assume they can do batch-style signing of zones never survive the testing phase (never the load test). On 12/2/14, 12:10, "Donald Eastlake" wrote: >While the new text is OK, I do not think the old text is wrong. >"signing a zone" is a well known term of art for signing the >authoritative RRsets in the zone. > >Thanks, >Donald >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > > >On Tue, Dec 2, 2014 at 11:36 AM, RFC Errata System > wrote: >> The following errata report has been submitted for RFC6840, >> "Clarifications and Implementation Notes for DNS Security (DNSSEC)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6840&eid=3D4191 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Edward Lewis >> >> Section: 5.11 >> >> Original Text >> ------------- >> ... >> >> A signed zone MUST include a DNSKEY for each algorithm present in >> the zone's DS RRset and expected trust anchors for the zone. The >> zone MUST also be signed with each algorithm (though not each key) >> present in the DNSKEY RRset. >> >> Corrected Text >> -------------- >> A signed zone MUST include a DNSKEY for each algorithm present in >> the zone's DS RRset and expected trust anchors for the zone. Each >> authoritative RRset in the zone MUST be signed with each >> algorithm (though not each key) present in the DNSKEY RRset. >> >> Notes >> ----- >> Zones aren't signed (per se), the data sets within them are. But not >>cut point (NS) and glue. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6840 (draft-ietf-dnsext-dnssec-bis-updates-20) >> -------------------------------------- >> Title : Clarifications and Implementation Notes for DNS >>Security (DNSSEC) >> Publication Date : February 2013 >> Author(s) : S. Weiler, Ed., D. Blacka, Ed. >> Category : PROPOSED STANDARD >> Source : DNS Extensions >> Area : Internet >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext --B_3500370702_8678210 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR+AYJKoZIhvcNAQcCoIIR6TCCEeUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D8EwggWwMIIEmKADAgECAhAOWKbdwJ1jDL89eBrwPJq7MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNDA1MjMw MDAwMDBaFw0xNzA1MjMxMjAwMDBaMIHPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEZMBcGA1UECxMQUmVnaXN0cnkg TGlhaXNvbjEVMBMGA1UEAxMMRWR3YXJkIExld2lzMSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQu bGV3aXNAaWNhbm4ub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0JEom0oS 4pUrB2WBIm2wlbHpZHfieug7mzF6dSQ4ko95ZtjYdBoD9bPg5DGJqbbYJPXW5QjtONH87Tks HYfgBJFGLghTdJQ7S0gG2Ey9gmqf0xkLZGLS/h5+8UUyuKsF33TZboycSEMQjpS/9NiyeCP1 IG7QA69VL//WzCcsMXfcYrqQy1++YNbCLO//h1sdOVHX1RAS5PjpBzqJkMaz+zeHPMGbO6p3 kVU5ww+z5bXOxPV7mg2aEYBGReOLE9AEcxC7G4p2JbhOIuFDrqReXNfP96+2gSSiIblZ5rvC 4CvDQngJkl8QpCDgIWivPwPd+pV7lIECnElyx7hID0XtrwIDAQABo4IB7zCCAeswHwYDVR0j BBgwFoAU5wIjgABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFInPVvBX6bjyb+ptVCyB9MCo AjCLMAwGA1UdEwEB/wQCMAAwIQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8 MDowOAYKYIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j b20vQ1BTMIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGsw JAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0 cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDAN BgkqhkiG9w0BAQsFAAOCAQEAXSa/5kRotclqD20zg8Q4k1CbLJXVEADyKZToYa/hwdv30MPe f+ahkFnqqL2tWMbCYydAzAwkdQInmMTB1LfriPaOieJiSA3HmCukmTuf8sW8DvpruIG2jl70 ZXStMKICbkmdQhnArVYqezzBbwJTMVQlTmaMOaZ3fLqsi5XzyD3l5llvR4AIkKwhWZU68q4m 4kGXPBpiPWMwEHX2DEixM/h1rGl1RXmG+FqjEG5H3wrPim3hUXcNyostwiZyRUVIuRlLGzJh nlJhql0YfTNg1YkLlX/YxbFov1nzobR84U39QLaqxiZ5F96WwBZLxW4nDn7rTDGG0l3W09yy EoOSczCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTEL MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEw NTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgR Iz9qte/AJ3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pj eFkeIiwr+Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdT QDK9T+ZQelAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdf auIagkEK3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16 CzfgT8uCig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYD VR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4 oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGi BgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t L0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIj gABP2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJ KoZIhvcNAQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFR XJmOtfrgYhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+ W0L2zpFg4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0 UIBOAtmwXZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCwe knjGVT1YEhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+Di bsIwggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAw MDAwMDBaFw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFz c3VyZWQgSUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7k Q4BcsYfzt2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrn eVNcMYQq9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9Sw OD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyCh z+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrk VxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/ BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgP MB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCi Drzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVp GqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybt eL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y9 8/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRsl bWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA5Ypt3A nWMMvz14GvA8mrswCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQB0Btu9F/Sc37M1KZo OM/VAF4LpDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEy MDIxODExNDJaMA0GCSqGSIb3DQEBAQUABIIBAEURuk5oTfhS5ueoDZZvfPaQvYBTIBB8Ey6P P7JbqwISs7Um0rD/fbPdU/Z/amUbloTZx2gMCWUB9bxTeeiVxnb+My7Sq3W9qK1Xx1L30jBY yTD5899SI2McR7nVxqWLv0oL8H48qIu0pAyC2W4nLO0J3sLF2yOHlyWZ2wTaUWfCEGEKWIM1 ejivkHD5byQga8qp7M2d277diR/rSl0K0ellJy69xP4XmJfrUcSJgYxHMQsohi4QtgYuUy7N AYEE3x/ztBLKB8RTasOA6daIZCJUCCQOE1Jv0GkIOPTPFk6KKzGDTjEbT0u4aQR0UlK0J0NM 2QqmN8yn+OeZY0HMucg= --B_3500370702_8678210-- From nobody Tue Dec 2 13:12:31 2014 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 3C3061A1A78 for ; Tue, 2 Dec 2014 13:12:22 -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 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 xBmJjzfMAYg0 for ; Tue, 2 Dec 2014 13:12:14 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 253B61A8748 for ; Tue, 2 Dec 2014 13:11:58 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 76A1328B0017; Tue, 2 Dec 2014 16:11:57 -0500 (EST) Received: from nova.tislabs.com (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id 53A661F8036; Tue, 2 Dec 2014 16:11:57 -0500 (EST) Date: Tue, 2 Dec 2014 16:11:57 -0500 (EST) From: Samuel Weiler To: RFC Errata System In-Reply-To: <20141202163646.E4BFC18123F@rfc-editor.org> Message-ID: References: <20141202163646.E4BFC18123F@rfc-editor.org> User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/QjTELeq7SywTMLT4nF-vIJA0jTg Cc: edward.lewis@icann.org, brian@innovationslab.net, dnsext@ietf.org, ted.lemon@nominum.com, ogud@ogud.com Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191) 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: Tue, 02 Dec 2014 21:12:22 -0000 The errata is correct, but I agree with Donald - the old text is adequate and unlikely to lead to confusion. (Well ... plenty of people are confused about this particular piece of the spec, but this clarification is unlikely to change that. I am probably also biased, as the writer of that old text.) I have no objection to marking this as verified, but I do not see it as necessary. -- Sam From nobody Tue Dec 2 13:29:11 2014 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 24D931A6FC7 for ; Tue, 2 Dec 2014 13:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 chDjsuKNixlr for ; Tue, 2 Dec 2014 13:29:05 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BC31A8731 for ; Tue, 2 Dec 2014 13:29:05 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id n12so9895737wgh.8 for ; Tue, 02 Dec 2014 13:29:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K2BUYRlkPulZmSqY4AyqwP6i426xI+lnBvJFn5/Z+RM=; b=fqZ4fCw+h+q04iATDpuAMYDgxeyk4Ysdp4i5DDSa5L2u9sxnpq5OitquysqU8adkLT t9FIbQwoGH3kn+nJNmc/XnMPGKwN3COjV7DZW5eWFSuCqhs07QJlNw+GSMuP6/V3GWP1 M95+J2yezPd1AmsIQ7y2mUrm/BzzXn/zC1dhCEcf0GpPCPxG+UEpYy1gfDPzw0L+0o8t 3BvpGw7zR9VQ93CoV5+tlfLW1msDLc6QLSXELxkwPg+CSpLmU0duEur4sAkRKRrmlm7U 6H6OsxV4iPQqKFJEJdcrtm9OYZzJFmLB7Un0fuU7Oeab8ST5CZTeunP0BNVm/f6vbFqq p9Mw== X-Gm-Message-State: ALoCoQkzIpDPx8EtywTrZZeF4zm2BllNzpDOEcfodrPGfQQkMqnTy+GamyFPOOC8NWZW2en3Lq+g MIME-Version: 1.0 X-Received: by 10.180.86.38 with SMTP id m6mr8191316wiz.65.1417555743976; Tue, 02 Dec 2014 13:29:03 -0800 (PST) Received: by 10.194.64.37 with HTTP; Tue, 2 Dec 2014 13:29:03 -0800 (PST) In-Reply-To: References: <20141202163646.E4BFC18123F@rfc-editor.org> Date: Tue, 2 Dec 2014 16:29:03 -0500 Message-ID: From: Warren Kumari To: Samuel Weiler Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/M2fD4uslQV4HGiUQT6Px1WUHnJs Cc: Edward Lewis , Brian Haberman , dnsext@ietf.org, Ted Lemon , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , RFC Errata System Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191) 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: Tue, 02 Dec 2014 21:29:07 -0000 On Tue, Dec 2, 2014 at 4:11 PM, Samuel Weiler wrote: > The errata is correct, but I agree with Donald - the old text is adequate > and unlikely to lead to confusion. (Well ... plenty of people are confused > about this particular piece of the spec, but this clarification is unlikely > to change that. I am probably also biased, as the writer of that old text.) > > I have no objection to marking this as verified, but I do not see it as > necessary. I think it is not necessary. We have tools called things like "dnssec-signzone", not "dnssec-sign_authorative_rrset". While the amended text is technically correct (which is the best type if correct), it isn't IMO necessary. But, I don't really care any more than the effort required to write this mail, so whatever... W > > -- Sam > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- 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 Tue Dec 2 13:29:52 2014 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 307111A6FC7 for ; Tue, 2 Dec 2014 13:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 fdv1gRrYGmdh for ; Tue, 2 Dec 2014 13:29:48 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3E11A8763 for ; Tue, 2 Dec 2014 13:29:48 -0800 (PST) Received: from [198.32.4.206] ([198.32.4.206]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id sB2LSTlH022184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 2 Dec 2014 13:28:39 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: manning bill In-Reply-To: Date: Tue, 2 Dec 2014 13:28:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141202163646.E4BFC18123F@rfc-editor.org> To: Samuel Weiler X-Mailer: Apple Mail (2.1878.6) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/xetwdUg-ZAqvEdasqw3-GG6d0kU Cc: edward.lewis@icann.org, brian@innovationslab.net, dnsext@ietf.org, ted.lemon@nominum.com, ogud@ogud.com, RFC Errata System Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191) 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: Tue, 02 Dec 2014 21:29:50 -0000 concur with Donald & Sam. =20 /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 2December2014Tuesday, at 13:11, Samuel Weiler = wrote: > The errata is correct, but I agree with Donald - the old text is = adequate and unlikely to lead to confusion. (Well ... plenty of people = are confused about this particular piece of the spec, but this = clarification is unlikely to change that. I am probably also biased, as = the writer of that old text.) >=20 > I have no objection to marking this as verified, but I do not see it = as necessary. >=20 > -- Sam >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From nobody Tue Dec 2 13:54:34 2014 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 643931A6EFB for ; Tue, 2 Dec 2014 13:54:32 -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 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 pplzIg5Ccqb5 for ; Tue, 2 Dec 2014 13:54:30 -0800 (PST) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91161A6F40 for ; Tue, 2 Dec 2014 13:54:01 -0800 (PST) Received: from brn1lxmailout02.vcorp.ad.vrsn.com ([72.13.63.42]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKVH40+bkmnYSgxo2fDD+un0XuDBlQuJrK@postini.com; Tue, 02 Dec 2014 13:54:30 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by brn1lxmailout02.vcorp.ad.vrsn.com (8.13.8/8.13.8) with ESMTP id sB2LrvD5004238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 16:53:58 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 2 Dec 2014 16:53:57 -0500 From: "Blacka, David" To: Samuel Weiler Thread-Topic: [Editorial Errata Reported] RFC6840 (4191) Thread-Index: AQHQDk49UbVMgzMS2U2hfUiRBw9k5px9IGqA//+36jE= Date: Tue, 2 Dec 2014 21:53:56 +0000 Message-ID: <03E542B6-38B0-40F6-A928-5FF89999B038@verisign.com> References: <20141202163646.E4BFC18123F@rfc-editor.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/wu9XZjesYs-B2TR-54-XUhhEWHk Cc: "edward.lewis@icann.org" , "brian@innovationslab.net" , "dnsext@ietf.org" , "ted.lemon@nominum.com" , "ogud@ogud.com" , RFC Errata System Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191) 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: Tue, 02 Dec 2014 21:54:32 -0000 Agreed.=20 Sent from my iPhone > On Dec 2, 2014, at 4:12 PM, Samuel Weiler wrote: >=20 > The errata is correct, but I agree with Donald - the old text is adequate= and unlikely to lead to confusion. (Well ... plenty of people are confuse= d about this particular piece of the spec, but this clarification is unlike= ly to change that. I am probably also biased, as the writer of that old te= xt.) >=20 > I have no objection to marking this as verified, but I do not see it as n= ecessary. >=20 > -- Sam From nobody Wed Dec 3 00:52:33 2014 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 0EA9A1A0262 for ; Wed, 3 Dec 2014 00:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.098 X-Spam-Level: * X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_VPILL=1.014, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 UPdvLU06eKor for ; Wed, 3 Dec 2014 00:52:30 -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 752421A0217 for ; Wed, 3 Dec 2014 00:52:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:x-originating-ip; bh=yc92b4bvfbc+CEN3hq5hkXadRAT38HOhVGt4dBuKAPM=; b=P71inf/Bi654rdJ3qjpYED2kQUaTJHtlSii09GXYn4Q2gm4Ko7fFDyP3/xmCX9cLfJmagW45vaute9qI+SW7pKDj0+FJ9lV/0YnNILQcO94jErU/AeMZxNLr4/3sUzzOA10J5seAZ/uhZVSTdIg23OI6NxtkEaYyM9eoRhM6CCE= Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by arn2-kamx.sidn.nl with ESMTP id sB38q3rW007184-sB38q3rY007184 (version=TLSv1.0 cipher=AES256-SHA bits=256 verify=CAFAIL); Wed, 3 Dec 2014 09:52:03 +0100 Received: from zen.sidnlabs.nl (94.198.152.218) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 3 Dec 2014 09:52:01 +0100 Message-ID: <547ECF19.5020006@sidn.nl> Date: Wed, 3 Dec 2014 09:51:37 +0100 From: Jelte Jansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: Brian Haberman , RFC Errata System , , , , , References: <20141202163646.E4BFC18123F@rfc-editor.org> <547E1F3F.5040400@innovationslab.net> In-Reply-To: <547E1F3F.5040400@innovationslab.net> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [94.198.152.218] Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/nzMfGS42Ung98Brk7Ywcsx6BzXE Cc: edward.lewis@icann.org, dnsext@ietf.org Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191) 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: Wed, 03 Dec 2014 08:52:32 -0000 On 12/02/2014 09:21 PM, Brian Haberman wrote: > Despite Donald's assertion, I think this is a valid erratum and should > be marked Verified. However, I will wait for others to chime in on the > subject before doing so. > I see a few pros and cons; yes the proposed text is correct and better than the original. However, this is not the only place that 'signing the zone' is used, and used with the meaning 'signing each authoritative RRset within the zone' in the set of RFC4033-4035 (and possibly outside of those as well). But I have had people ask me what 'signing the zone' actually means, usually in the context of KSK vs ZSK (and hence, is the DNSKEY set part of 'the zone'), not necesarily in the context of algorithm downgrade protection. Then again, RFC4033 actually defines a 'signed zone' as 'A zone whose RRsets are signed and ...'. So while signing full zones in AXFRs might add confusion here, I do think it is stated correctly as it is. Then again (again), that is about whether there are signatures at all and 'signed' there doesn't mention signed by what (keys/algorithms/autographs). So I don't think the errata is necessary, but I wouldn't exactly be opposed either. Jelte From nobody Wed Dec 3 01:33:00 2014 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 9F03C1A026E for ; Wed, 3 Dec 2014 01:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.184 X-Spam-Level: X-Spam-Status: No, score=0.184 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 iVYHNyN1XBCT for ; Wed, 3 Dec 2014 01:32:56 -0800 (PST) Received: from bela.nlnetlabs.nl (bela.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:15]) (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 20F9A1A0242 for ; Wed, 3 Dec 2014 01:32:55 -0800 (PST) Received: from bela.nlnetlabs.nl (localhost [127.0.0.1]) by bela.nlnetlabs.nl (8.14.9/8.14.9) with ESMTP id sB39WljG056257; Wed, 3 Dec 2014 10:32:47 +0100 (CET) (envelope-from jaap@NLnetLabs.nl) Message-Id: <201412030932.sB39WljG056257@bela.nlnetlabs.nl> To: Warren Kumari From: Jaap Akkerhuis In-reply-to: References: <20141202163646.E4BFC18123F@rfc-editor.org> Comments: In-reply-to Warren Kumari message dated "Tue, 02 Dec 2014 16:29:03 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <56255.1417599167.1@bela.nlnetlabs.nl> Content-Transfer-Encoding: quoted-printable Date: Wed, 03 Dec 2014 10:32:47 +0100 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (bela.nlnetlabs.nl [127.0.0.1]); Wed, 03 Dec 2014 10:32:52 +0100 (CET) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/tJQeil9Skrt2BuF1Bi1QFza-r_Y Cc: Edward Lewis , Brian Haberman , dnsext@ietf.org, Ted Lemon , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , RFC Errata System Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191) 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: Wed, 03 Dec 2014 09:32:57 -0000 Warren Kumari writes: > On Tue, Dec 2, 2014 at 4:11 PM, Samuel Weiler wrot= e: > > The errata is correct, but I agree with Donald - the old text is adeq= uate > > and unlikely to lead to confusion. (Well ... plenty of people are co= nfused > > about this particular piece of the spec, but this clarification is un= likely > > to change that. I am probably also biased, as the writer of that old= text.) > > > > I have no objection to marking this as verified, but I do not see it = as > > necessary. > = > I think it is not necessary. We have tools called things like > "dnssec-signzone", not "dnssec-sign_authorative_rrset". > While the amended text is technically correct (which is the best type > if correct), it isn't IMO necessary. But, I don't really care any more > than the effort required to write this mail, so whatever... The DNS RFC are already plagued with a lot of fuzzy wordings leading to confusion by non DNS experts. Therefore it will be good to be have this errata. jaap From nobody Wed Dec 3 07:15:58 2014 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 5D05A1A1B5D for ; Wed, 3 Dec 2014 07:15:56 -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 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 qZf-gQvzOzyu for ; Wed, 3 Dec 2014 07:15:54 -0800 (PST) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973551A1AD0 for ; Wed, 3 Dec 2014 07:15:54 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id DF2893F432; Wed, 3 Dec 2014 10:15:52 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21631.10536.718334.94547@gro.dd.org> Date: Wed, 3 Dec 2014 10:15:52 -0500 From: Dave Lawrence To: Jaap Akkerhuis In-Reply-To: <201412030932.sB39WljG056257@bela.nlnetlabs.nl> References: <20141202163646.E4BFC18123F@rfc-editor.org> <201412030932.sB39WljG056257@bela.nlnetlabs.nl> Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/Vv3TN5kidYc1iutr_fnp7PDw-90 Cc: Edward Lewis , Brian Haberman , dnsext@ietf.org, Ted Lemon , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , RFC Errata System Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191) 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: Wed, 03 Dec 2014 15:15:56 -0000 Jaap Akkerhuis writes: > The DNS RFC are already plagued with a lot of fuzzy wordings leading > to confusion by non DNS experts. Therefore it will be good to be > have this errata. I agree with Jaap. This is such a minor step to take to increase the precision of the wording, with seemingly no disagreement that the new wording is deficient. From nobody Wed Dec 3 08:38:12 2014 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 D31AF1A702F for ; Wed, 3 Dec 2014 08:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 iulh1tg5fcme for ; Wed, 3 Dec 2014 08:37:56 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.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 73B511A1BA4 for ; Wed, 3 Dec 2014 08:37:55 -0800 (PST) Received: from [10.20.30.90] (142-254-17-119.dsl.dynamic.fusionbroadband.com [142.254.17.119]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sB3GbrBg035991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2014 09:37:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-119.dsl.dynamic.fusionbroadband.com [142.254.17.119] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: <547ECF19.5020006@sidn.nl> Date: Wed, 3 Dec 2014 08:37:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141202163646.E4BFC18123F@rfc-editor.org> <547E1F3F.5040400@innovationslab.net> <547ECF19.5020006@sidn.nl> To: Jelte Jansen X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/-LND9-oFMezIqipiKqAIpZsuBgc Cc: Brian Haberman , DNSEXT Group Working Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191) 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: Wed, 03 Dec 2014 16:38:03 -0000 On Dec 3, 2014, at 12:51 AM, Jelte Jansen wrote: > I see a few pros and cons; yes the proposed text is correct and better > than the original. However, this is not the only place that 'signing = the > zone' is used, and used with the meaning 'signing each authoritative > RRset within the zone' in the set of RFC4033-4035 (and possibly = outside > of those as well). >=20 > But I have had people ask me what 'signing the zone' actually means, > usually in the context of KSK vs ZSK (and hence, is the DNSKEY set = part > of 'the zone'), not necesarily in the context of algorithm downgrade > protection. >=20 > Then again, RFC4033 actually defines a 'signed zone' as 'A zone whose > RRsets are signed and ...'. So while signing full zones in AXFRs might > add confusion here, I do think it is stated correctly as it is. Just to drive the point home a bit further, since you brought up the = definition in RFC 4033: Signed Zone: A zone whose RRsets are signed and that contains properly constructed DNSKEY, Resource Record Signature (RRSIG), Next Secure (NSEC), and (optionally) DS records. A developer asked me a few years ago "does that mean that all the RRsets = are signed? What if just the A records are signed?" That's a valid = question given the definition. It is only by reading the rest of the = document do you get the feeling (but never the actual statement) that it = means *all* of the RRsets in the zone. --Paul Hoffman= From nobody Wed Dec 3 09:40:44 2014 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 E3A9A1A8AAA for ; Wed, 3 Dec 2014 09:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 RkRtZqFuuHz0 for ; Wed, 3 Dec 2014 09:40:37 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F15E1A8AAC for ; Wed, 3 Dec 2014 09:40:32 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id b13so20516039wgh.3 for ; Wed, 03 Dec 2014 09:40:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2IT34yqkFCfHKjkOk61i38soiTjCiptH+l1Y2tqI7V8=; b=bsgqH6P/LJfBrcrm8pc5Kt7RHsE177b8P8un4m+hNgmyTnsm8r5lwO9QFnw6a3xMGj Obn0hjzSFsYLKFcvodYlO7HDMftRvGU9rJYYzbL+m1Ix49GT2ahaqfp74P5yn+8pGEPT EJErUPzWknI/VNwyyrTDhZIkh8XhVJfuKpXyM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2IT34yqkFCfHKjkOk61i38soiTjCiptH+l1Y2tqI7V8=; b=IqmBlEl1ski49rVfSOddCH/0DjEQXFlBcMGhKFbvZIUxngbLYhVF68rVQ7ZwDvVLns /yMcc3KPjU/2vBw7TzhDrudYgFZK6WuQeB8Lz4n14Yk5IN5qtZZJ4Nb0W6veJimJfRjs dI7vPNklosnSPymZWbrAFZYEbtFFsqFgnmV+po6o87EsFuLj0rqL5gnA+3XGDfrtq/Ls zsQKavreQRp5iyT5w1tCmS5T+pgJz7odxHnLf3spCcZVL6Mos5yfONHTfeCFyvKC+9UG 54uf8lLg03RHlYvkgcyOloWlmDBnsKvh2gL73tn/aH+aHhV1KwRC55rElkWdVycV5c0j AMfg== X-Gm-Message-State: ALoCoQkck+xYc4HJmEgXhlDjacBuq+eT5xRfuUh4fO9Y8jDwWUyCPFGY6qJE37YNbgNqivLbm/ng X-Received: by 10.194.249.232 with SMTP id yx8mr9417369wjc.1.1417628431050; Wed, 03 Dec 2014 09:40:31 -0800 (PST) Received: from ?IPv6:2001:981:19be:1:160:7d97:db8e:511e? ([2001:981:19be:1:160:7d97:db8e:511e]) by mx.google.com with ESMTPSA id qg11sm31153657wic.17.2014.12.03.09.40.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Dec 2014 09:40:30 -0800 (PST) Message-ID: <547F4B0E.9000608@dyn.com> Date: Wed, 03 Dec 2014 18:40:30 +0100 From: Matthijs Mekking User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Paul Hoffman , Jelte Jansen References: <20141202163646.E4BFC18123F@rfc-editor.org> <547E1F3F.5040400@innovationslab.net> <547ECF19.5020006@sidn.nl> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/ObwaTRuWyP2TyWNUTqk9VexWuRU Cc: Brian Haberman , DNSEXT Group Working Subject: Re: [dnsext] [Editorial Errata Reported] RFC6840 (4191) 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: Wed, 03 Dec 2014 17:40:40 -0000 On 03-12-14 17:37, Paul Hoffman wrote: > On Dec 3, 2014, at 12:51 AM, Jelte Jansen > wrote: >> I see a few pros and cons; yes the proposed text is correct and >> better than the original. However, this is not the only place that >> 'signing the zone' is used, and used with the meaning 'signing each >> authoritative RRset within the zone' in the set of RFC4033-4035 >> (and possibly outside of those as well). >> >> But I have had people ask me what 'signing the zone' actually >> means, usually in the context of KSK vs ZSK (and hence, is the >> DNSKEY set part of 'the zone'), not necesarily in the context of >> algorithm downgrade protection. >> >> Then again, RFC4033 actually defines a 'signed zone' as 'A zone >> whose RRsets are signed and ...'. So while signing full zones in >> AXFRs might add confusion here, I do think it is stated correctly >> as it is. > > Just to drive the point home a bit further, since you brought up the > definition in RFC 4033: > > Signed Zone: A zone whose RRsets are signed and that contains > properly constructed DNSKEY, Resource Record Signature (RRSIG), Next > Secure (NSEC), and (optionally) DS records. > > A developer asked me a few years ago "does that mean that all the > RRsets are signed? What if just the A records are signed?" That's a > valid question given the definition. It is only by reading the rest > of the document do you get the feeling (but never the actual > statement) that it means *all* of the RRsets in the zone. It actually means all *authoritative* RRsets are signed. Glue and occluded data for example are not signed. The devil is in the details :) - Matthijs > > --Paul Hoffman _______________________________________________ dnsext > mailing list dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From nobody Fri Dec 12 12:51:11 2014 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 3182C1A8723 for ; Fri, 12 Dec 2014 11:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 2hymzgEtqzCZ for ; Fri, 12 Dec 2014 11:08:57 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE291A1BC4 for ; Fri, 12 Dec 2014 11:08:56 -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.847.32; Fri, 12 Dec 2014 11:08:55 -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.0847.030; Fri, 12 Dec 2014 11:08:55 -0800 From: KSK Rollover SOI To: "dnsext@ietf.org" Thread-Topic: Solicitation for Statements of Interest regarding Root KSK Rollover Thread-Index: AQHQFj8SurXZfTz7kUGG/Ldix6TXug== Date: Fri, 12 Dec 2014 19:08:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [192.0.47.235] Content-Type: text/plain; charset="utf-8" Content-ID: <358FB823E677014CB1EE108A7F2DB565@pexch112.icann.org> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/9Wuc20Rvha7Mz3fNv-_7H1o1n7k X-Mailman-Approved-At: Fri, 12 Dec 2014 12:51:08 -0800 Subject: [dnsext] Solicitation for Statements of Interest regarding Root KSK Rollover 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: Fri, 12 Dec 2014 19:08:59 -0000 SUNBTk4sIGFzIHRoZSBJQU5BIGZ1bmN0aW9ucyBvcGVyYXRvciwgaW4gY29vcGVyYXRpb24gd2l0 aCBWZXJpc2lnbiBhcyB0aGUNClJvb3QgWm9uZSBNYWludGFpbmVyIGFuZCB0aGUgTmF0aW9uYWwg VGVsZWNvbW11bmljYXRpb25zIEluZm9ybWF0aW9uDQpBZG1pbmlzdHJhdGlvbiAoTlRJQSkgYXMg dGhlIFJvb3QgWm9uZSBBZG1pbmlzdHJhdG9yLCB0b2dldGhlciBrbm93biBhcw0KdGhlIFJvb3Qg Wm9uZSBNYW5hZ2VtZW50IChSWk0pIHBhcnRuZXJzLCBzZWVrIHRvIGRldmVsb3AgYSBwbGFuIGZv cg0Kcm9sbGluZyB0aGUgRE5TIHJvb3Qgem9uZSBrZXktc2lnbmluZyBrZXkgKEtTSykuIFRoZSBL U0sgaXMgdXNlZCB0byBzaWduDQp0aGUNCnJvb3Qgem9uZSB6b25lLXNpZ25pbmcga2V5IChaU0sp LCB3aGljaCBpbiB0dXJuIGlzIHVzZWQgdG8gRE5TU0VDLXNpZ24gdGhlDQpJbnRlcm5ldOKAmXMg cm9vdCB6b25lLiBUaGUgUm9vdCBab25lIFBhcnRuZXJzIGFyZSBzb2xpY2l0aW5nIGZpdmUgdG8g c2V2ZW4NCnZvbHVudGVlcnMgZnJvbSB0aGUgY29tbXVuaXR5IHRvIHBhcnRpY2lwYXRlIGluIGEg RGVzaWduIFRlYW0gdG8gZGV2ZWxvcA0KdGhlIFJvb3QgWm9uZSBLU0sgUm9sbG92ZXIgUGxhbiAo 4oCcVGhlIFBsYW7igJ0pLiBUaGVzZSB2b2x1bnRlZXJzIGFsb25nIHdpdGgNCnRoZSBSWk0gcGFy dG5lcnMgd2lsbCBmb3JtIHRoZSBEZXNpZ24gVGVhbSB0byBkZXZlbG9wIFRoZSBQbGFuLg0KDQpJ bmRpdmlkdWFscyBpbnRlcmVzdGVkIGluIHZvbHVudGVlcmluZyBhcHByb3hpbWF0ZWx5IDUgaG91 cnMgcGVyIHdlZWsgZm9yDQp0aGUgRGVzaWduIFRlYW0gc2hvdWxkIGNvbnN1bHQgdGhlIGFubm91 bmNlbWVudDoNCg0KaHR0cHM6Ly93d3cuaWNhbm4ub3JnL2VuL3N5c3RlbS9maWxlcy9maWxlcy9r c2stc29pLTExZGVjMTQtZW4ucGRmDQoNCmFuZCBzdWJtaXQgdGhlaXIgU3RhdGVtZW50IG9mIElu dGVyZXN0IHRvIGtzay1yb2xsb3Zlci1zb2lAaWNhbm4ub3JnIG5vDQpsYXRlciB0aGFuIEphbnVh cnkgMTYsIDIwMTUuDQoNCg== From nobody Sun Dec 14 14:30:31 2014 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 4178D1A026F for ; Sun, 14 Dec 2014 14:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 4T6ELbePUzXC for ; Sun, 14 Dec 2014 14:30:28 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.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 544571A0217 for ; Sun, 14 Dec 2014 14:30:28 -0800 (PST) Received: from [10.20.30.90] (50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sBEMUQat090545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 14 Dec 2014 15:30:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <64670FEB-4AF3-4014-ABF3-95C7249E08EE@vpnc.org> Date: Sun, 14 Dec 2014 14:30:26 -0800 To: DNSEXT Group Working Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/YNazoUkulwYJsISb9GP4Fp3hmO0 Subject: [dnsext] Middleboxes and EDNS(0) 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, 14 Dec 2014 22:30:29 -0000 Greetings again. Section 6.1.1.1 of RFC 6891 says: OPT RRs MUST NOT be cached, forwarded, or stored in or loaded from master files. Section 6.2.6 says: Middleboxes that simply forward requests to a recursive resolver MUST NOT modify and MUST NOT delete the OPT record contents in either direction. If I'm a middlebox that is acting as a DNS forwarder, and I see an OPT = RR on a query coming in my left side, what do I send that OPT RR out the = right side? Do I follow the first or the second quote? --Paul Hoffman= From nobody Sun Dec 14 14:43:00 2014 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 1D4761A0354 for ; Sun, 14 Dec 2014 14:42:59 -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, 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 nERAD5BKRLas for ; Sun, 14 Dec 2014 14:42:57 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5863B1A01F6 for ; Sun, 14 Dec 2014 14:42:57 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id r2so4170622igi.6 for ; Sun, 14 Dec 2014 14:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZNAGeMvBD/yneN72pCKfypHiAXessKE2Grvl9SKTCtQ=; b=a7M6h1UD4WbFf3panbRrgmhP8ieNtaNiMX/7m4tCR6CaFmyL4dMMA58/NTB9SGls2R +HuZf4znHhrYxnqCryZBfs1ojwOJ6nbJ9Qf/uSckQCj0qLU2tUwHO8rl8WmyhKOPvip0 oq4KlwDhMDaWTYBjLts/OnX1tDQcdtoYpalpgf8eZY3mOFOLvhT5wQ7FwKMU4F3pA2VZ H7ZOCgKr390dmKkOvOeY3EpXD2ZoGnHV7wxDQH8iiUy1JACrNbJCKDJwqr02gnfl+adp QFImcpbtVaeuJLvLFSi2UO6aP2KjZbRXVpT4nELip+OLJrwpGkOTR0CH9HCzHiBa5FOR o0GA== MIME-Version: 1.0 X-Received: by 10.50.225.1 with SMTP id rg1mr15182476igc.39.1418596976437; Sun, 14 Dec 2014 14:42:56 -0800 (PST) Received: by 10.64.69.167 with HTTP; Sun, 14 Dec 2014 14:42:56 -0800 (PST) In-Reply-To: <64670FEB-4AF3-4014-ABF3-95C7249E08EE@vpnc.org> References: <64670FEB-4AF3-4014-ABF3-95C7249E08EE@vpnc.org> Date: Sun, 14 Dec 2014 14:42:56 -0800 Message-ID: From: Brian Dickson To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a1132f15edc314c050a34d8e8 Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/HOdOfQhg_hmU5iFx1MrhlnXTn4c Cc: DNSEXT Group Working Subject: Re: [dnsext] Middleboxes and EDNS(0) 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, 14 Dec 2014 22:42:59 -0000 --001a1132f15edc314c050a34d8e8 Content-Type: text/plain; charset=UTF-8 My read would be, use the second quote. I suspect the first quote is referring to caching forwarding DNS servers, not dumb non-caching middle boxes. I think any other interpretation creates an actual paradox, while this reading does not. And I think it is the only thing that enables OPT (EDNS) to work. Brian On Sun, Dec 14, 2014 at 2:30 PM, Paul Hoffman wrote: > Greetings again. Section 6.1.1.1 of RFC 6891 says: > > OPT RRs MUST NOT be cached, > forwarded, or stored in or loaded from master files. > > Section 6.2.6 says: > > Middleboxes that simply forward requests to a recursive resolver MUST > NOT modify and MUST NOT delete the OPT record contents in either > direction. > > If I'm a middlebox that is acting as a DNS forwarder, and I see an OPT RR > on a query coming in my left side, what do I send that OPT RR out the right > side? Do I follow the first or the second quote? > > --Paul Hoffman > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --001a1132f15edc314c050a34d8e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My read would be, use the second quote.

I suspect the first quote is referring to caching forwarding DNS servers, = not dumb non-caching middle boxes.

I think any oth= er interpretation creates an actual paradox, while this reading does not.

And I think it is the only thing that enables OPT (= EDNS) to work.

Brian

On Sun, Dec 14, 2014 at 2:30 PM, Pa= ul Hoffman <paul.hoffman@vpnc.org> wrote:
Greetings again. Section 6.1.1.1 of RFC 6891 says:

=C2=A0 =C2=A0OPT RRs MUST NOT be cached,
=C2=A0 =C2=A0forwarded, or stored in or loaded from master files.

Section 6.2.6 says:

=C2=A0 =C2=A0Middleboxes that simply forward requests to a recursive resolv= er MUST
=C2=A0 =C2=A0NOT modify and MUST NOT delete the OPT record contents in eith= er
=C2=A0 =C2=A0direction.

If I'm a middlebox that is acting as a DNS forwarder, and I see an OPT = RR on a query coming in my left side, what do I send that OPT RR out the ri= ght side? Do I follow the first or the second quote?

--Paul Hoffman
_______________________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext

--001a1132f15edc314c050a34d8e8-- From nobody Sun Dec 14 17:01:58 2014 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 684C41A0266 for ; Sun, 14 Dec 2014 17:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.187 X-Spam-Level: * X-Spam-Status: No, score=1.187 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MISSING_MID=0.497, 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 38RhVQzVCzxI for ; Sun, 14 Dec 2014 17:01:54 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F701A0263 for ; Sun, 14 Dec 2014 17:01:54 -0800 (PST) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-08v.sys.comcast.net with comcast id Td1A1p0022VvR6D01d1tQR; Mon, 15 Dec 2014 01:01:53 +0000 Received: from Mike-T530ssd.comcast.net ([69.255.115.150]) by resomta-ch2-19v.sys.comcast.net with comcast id Td1s1p00u3Em2Kp01d1tPY; Mon, 15 Dec 2014 01:01:53 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 14 Dec 2014 20:01:52 -0500 To: KSK Rollover SOI , "dnsext@ietf.org" From: Michael StJohns In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418605313; bh=T4tkFujfkg9uHk03Un9mQLgrBOvX18u4O8KmBtgGvcA=; h=Received:Received:Date:To:From:Subject:Mime-Version:Content-Type; b=YfT43E7pRKSVRYRXlrzN2OBTB8N9fGqQBA1dhcMwlmGSC5aX2gp+2F3XpygenfNF9 E4hJBSGpqPrf1aveJdA7/ivnOwXaAGnNsPOHyc1V5yhDe2CeE146/zWa+mySEkQxN0 fo7DoTwUYhgfL7CT7PmlA1G7PPf/42Y+H5csJnHCXUAemCwn4M/5LDMMhjwdnTExPo flqPfqI+S3aoGzagrIpA87DwHJlxy13I2n1oRdyuMXGOkfIQ+xpRrpo4veKcj8CaE6 Vq8sGBFKedARi3DYn53ofv8vCfUW5MG1/0HQihsifhSIq6m1UirTwhrEf1uZBqNPu/ PVZnkWTpnmkvQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/QIN8enOQ7k-wRWsGZyEP9xDHKf8 Subject: Re: [dnsext] Solicitation for Statements of Interest regarding Root KSK Rollover 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, 15 Dec 2014 01:01:56 -0000 Any chance at all that the originator of the referenced document could= provide an editable version of Appendix A please? I tried to use Acrobat 9 to convert it to word or RTF and got an error= related to page structure. Mike At 02:08 PM 12/12/2014, KSK Rollover SOI wrote: >ICANN, as the IANA functions operator, in cooperation with Verisign as the >Root Zone Maintainer and the National Telecommunications Information >Administration (NTIA) as the Root Zone Administrator, together known as >the Root Zone Management (RZM) partners, seek to develop a plan for >rolling the DNS root zone key-signing key (KSK). The KSK is used to sign >the >root zone zone-signing key (ZSK), which in turn is used to DNSSEC-sign the >Internet=E2=80=99s root zone. The Root Zone Partners are soliciting five to= seven >volunteers from the community to participate in a Design Team to develop >the Root Zone KSK Rollover Plan (=E2=80=9CThe Plan=E2=80=9D). These= volunteers along with >the RZM partners will form the Design Team to develop The Plan. > >Individuals interested in volunteering approximately 5 hours per week for >the Design Team should consult the announcement: > >https://www.icann.org/en/system/files/files/ksk-soi-11dec14-en.pdf > >and submit their Statement of Interest to ksk-rollover-soi@icann.org no >later than January 16, 2015. > >_______________________________________________ dnsext mailing list= dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext=20 From nobody Mon Dec 15 01:57:32 2014 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 C02631A1A91 for ; Mon, 15 Dec 2014 01:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, 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 RRDTNKyOpwe4 for ; Mon, 15 Dec 2014 01:57:28 -0800 (PST) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id DB70C1A0A85 for ; Mon, 15 Dec 2014 01:57:27 -0800 (PST) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=M5Nmc6xdmZu3daiscZzhyTizqHgLnaikP0PouGkwmU+mYk54uK/cyvXy v5azY/JL8dl42ikMSuWr3TxSTLl4+GhgczEKmA4hhDLLOZK698CEnxBtL mYxDXakROHcldUrqS5Y8q2A2NytbeYSur+UAh47Y7gOK248gZoGpFGWXd xZ3+oWbM/r7FO0BYEi//dusakt+8redpebVaHwzZ/YeLjQT8QPDlbojeK wyHkBsZY8qGT7rMRN6+T0gNO97MTk; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1418637448; x=1450173448; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=06shlvEUksp/bamxItYrUeaRaD8oovQ4pjpMADQ/iWI=; b=KKnxR/SzzvBqHEnHAmoy92fhyb2Ig7fEfx+yOUe3LfA8UwuRixMiSCaj 91axqmjBa4ro+UzPzRAgcKIiUHGYYtmN4UxhHOsVAIYHRhbMwdZHdos65 bQsrr6tiJ3iV711cllkuVOeMGNsK/FjdicrWWKF2HDoDOBal01gTlRhvn z4+JR20jAjzNwZBYXxLfNFJFMG8svVrGHbtxwMdj9mPlQVd6ch9HErmbz Oy1KD+cVTjZUWqC6j/4R/vrODhQ0W; X-IronPort-AV: E=Sophos;i="5.07,578,1413241200"; d="scan'208";a="14588305" X-IPAS-Result: AoIFAAGwjlTV+MWR/2dsb2JhbABagmQigSoEy08CgRgWAQEBAQEBfIQMAQEBAQIBOhkmBQsCAQgYHhAyJQIEDgWIJAkD0gQBAQEBBgEBAQEBAQEBAQEBF48/MweDFoETBagoIoNsboFFfgEBAQ Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 15 Dec 2014 09:57:26 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%16]) with mapi id 14.03.0181.006; Mon, 15 Dec 2014 09:57:26 +0000 From: Ray Bellis To: Paul Hoffman Thread-Topic: [dnsext] Middleboxes and EDNS(0) Thread-Index: AQHQF+2aIOsBJUtIFk+bLbYVSsNPQpyQazKA Date: Mon, 15 Dec 2014 09:57:25 +0000 Message-ID: References: <64670FEB-4AF3-4014-ABF3-95C7249E08EE@vpnc.org> In-Reply-To: <64670FEB-4AF3-4014-ABF3-95C7249E08EE@vpnc.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <253167BBC9A61549A89616132EAFECBC@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/FQu6yMr1CWsw3dvtksso32vbn9o Cc: DNSEXT Group Working Subject: Re: [dnsext] Middleboxes and EDNS(0) 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, 15 Dec 2014 09:57:30 -0000 > On 14 Dec 2014, at 22:30, Paul Hoffman wrote: >=20 > Greetings again. Section 6.1.1.1 of RFC 6891 says: >=20 > OPT RRs MUST NOT be cached, > forwarded, or stored in or loaded from master files. >=20 > Section 6.2.6 says: >=20 > Middleboxes that simply forward requests to a recursive resolver MUST > NOT modify and MUST NOT delete the OPT record contents in either > direction. >=20 > If I'm a middlebox that is acting as a DNS forwarder, and I see an OPT RR= on a query coming in my left side, what do I send that OPT RR out the righ= t side? Do I follow the first or the second quote? The second - that being consistent with RFC 5625, too. The text in both 6891 and 5625 is supposed to relate to the case of a middl= ebox that just dumb proxies the DNS traffic at the (UDP) packet layer witho= ut performing any processing on that traffic other than the bare minimum ne= cessary to get the responses back to the correct client. Ray From nobody Mon Dec 15 07:48:47 2014 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 F2EE31A700A for ; Mon, 15 Dec 2014 07:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 Jx2eQ11_VdNn for ; Mon, 15 Dec 2014 07:48:43 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.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 B1EC51A7003 for ; Mon, 15 Dec 2014 07:48:43 -0800 (PST) Received: from [10.20.30.90] (50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sBFFmf2Z065857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2014 08:48:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: Date: Mon, 15 Dec 2014 07:48:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <64670FEB-4AF3-4014-ABF3-95C7249E08EE@vpnc.org> To: Brian Dickson X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/bQWd2x7WedcbDPzLhOCs4-BT-A8 Cc: DNSEXT Group Working Subject: Re: [dnsext] Middleboxes and EDNS(0) 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, 15 Dec 2014 15:48:46 -0000 On Dec 14, 2014, at 2:42 PM, Brian Dickson = wrote: > My read would be, use the second quote. >=20 > I suspect the first quote is referring to caching forwarding DNS = servers, not dumb non-caching middle boxes. >=20 > I think any other interpretation creates an actual paradox, while this = reading does not. >=20 > And I think it is the only thing that enables OPT (EDNS) to work. The problem is that the first quote is in a section called "6.1.1. = Basic Elements". This seems, well, basic. So, is this an errata for the first quote? --Paul Hoffman > On Sun, Dec 14, 2014 at 2:30 PM, Paul Hoffman = wrote: > Greetings again. Section 6.1.1.1 of RFC 6891 says: >=20 > OPT RRs MUST NOT be cached, > forwarded, or stored in or loaded from master files. >=20 > Section 6.2.6 says: >=20 > Middleboxes that simply forward requests to a recursive resolver = MUST > NOT modify and MUST NOT delete the OPT record contents in either > direction. >=20 > If I'm a middlebox that is acting as a DNS forwarder, and I see an OPT = RR on a query coming in my left side, what do I send that OPT RR out the = right side? Do I follow the first or the second quote? From nobody Mon Dec 15 09:57:23 2014 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 D9A041A8712 for ; Mon, 15 Dec 2014 09:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, 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 dlcZxvmSoqbp for ; Mon, 15 Dec 2014 09:57:20 -0800 (PST) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F401A8714 for ; Mon, 15 Dec 2014 09:57:19 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so9738083wib.4 for ; Mon, 15 Dec 2014 09:57:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=43EoVIxFIZZ+1Rw62ZtnLn890onpnCymWAJopddtuXE=; b=mO4A3la1Eik5pLMv7AOA0H2tIcqMPsGAzf/0oudh00IUG16ro/8FADm0cU6i8RTuTM wqzq2LbxVXiw2zMyo5eyaWsXgfYDWZIJnDsSZNmT4QrLAbRpdL7X5p1BOolc6taNDIOH MO6rchlWMlOThgySZCckokoibITzjmQVK0uorq1NKtMA5ubH4Mh7UWUU+lQu2cQZl2Iw fKsg6I/8gFMCeyUrmjF+9b0YZc55oMHjZvznGjfCv0P3ASFSssHhhX3V9seJ8nwpUZwI Yc85Zgg+6uPDv+nn2ZTzgsOS8bbtgsccl5NQ/siAHbOzecgizC1j64DxhH72IbFWTfNR 94vQ== X-Gm-Message-State: ALoCoQnTTD/nxkBdPTuihSU8QH7QhOM6hTVt0e8Au2OiBLh6prdmw8n7YmyGhbG72HCN7EOqlJ56 MIME-Version: 1.0 X-Received: by 10.194.63.229 with SMTP id j5mr54635425wjs.23.1418666238680; Mon, 15 Dec 2014 09:57:18 -0800 (PST) Received: by 10.194.64.37 with HTTP; Mon, 15 Dec 2014 09:57:18 -0800 (PST) In-Reply-To: <64670FEB-4AF3-4014-ABF3-95C7249E08EE@vpnc.org> References: <64670FEB-4AF3-4014-ABF3-95C7249E08EE@vpnc.org> Date: Mon, 15 Dec 2014 12:57:18 -0500 Message-ID: From: Warren Kumari To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/WduOeeiuinD2earwS9FPWwDlZrQ Cc: DNSEXT Group Working Subject: Re: [dnsext] Middleboxes and EDNS(0) 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, 15 Dec 2014 17:57:22 -0000 On Sun, Dec 14, 2014 at 5:30 PM, Paul Hoffman wrote: > Greetings again. Section 6.1.1.1 of RFC 6891 says: > > OPT RRs MUST NOT be cached, > forwarded, or stored in or loaded from master files. > > Section 6.2.6 says: > > Middleboxes that simply forward requests to a recursive resolver MUST > NOT modify and MUST NOT delete the OPT record contents in either > direction. > > If I'm a middlebox that is acting as a DNS forwarder, and I see an OPT RR on a query coming in my left side, what do I send that OPT RR out the right side? Do I follow the first or the second quote? Based on observation, if you are a middlebox that is acting as a DNS forwarder, and you see an OPT RR on a query coming in your left side, you arbitrarily choose between: A: the first B: the second C: a very small rock named Edgar. I think that the Section 6.2.6 is more correct, but middleboxes seem to take perverse pleasure in ignoring "correct" as it related to the DNS.... W > > --Paul Hoffman > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- 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 15 10:20:20 2014 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 D7B9C1A8731 for ; Mon, 15 Dec 2014 10:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 0KVUzW6ItlHP for ; Mon, 15 Dec 2014 10:19:57 -0800 (PST) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52CD1A873C for ; Mon, 15 Dec 2014 10:19:56 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so15277668wgg.21 for ; Mon, 15 Dec 2014 10:19:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PHNwafwPgLCebeSpLx5brWMhunfC43tbMfJ2qt6skVU=; b=OGlgN0zNatg3PD6LIumqbfPUeK1Zf5pJQy099o75XVQMpi0GSXrZVc+42HDsnj094n 3AuUfiK+PBll2AvHKrfEv4p/CRP/B3w6m6QIXtl2qbYNSQZZTEH6PGXIN7UTyaRWzhU2 1yEuf+ARVLKlBCwKhGMBL+CGEoPJsDNnqWEwasal3Drtqko+nQ3+1Vws8LStMZ8EHUfA ZVYe4DBzHSUgZPT8PGZYGJVMvbeBTKDF0IYI8qcT+ky0uwuD2rqzzGL0mQ4B9XNcLsJI M2X1Mwnbc7x7Qzr3b7uZCm5ltnFG5pvopB3tEsjtpMdk+ZIMDBZ20NibWPybQo9b+wGQ E8xQ== X-Gm-Message-State: ALoCoQnZ5qnCAlNeVYfPbOal0URq+bDpTsvuqe9QmnZL/mINZuIS1P/JReNmTXTSHHtLrA3o+5LK MIME-Version: 1.0 X-Received: by 10.180.103.162 with SMTP id fx2mr23180545wib.42.1418667595237; Mon, 15 Dec 2014 10:19:55 -0800 (PST) Received: by 10.194.64.37 with HTTP; Mon, 15 Dec 2014 10:19:54 -0800 (PST) In-Reply-To: <20141215010158.025F31A0266@ietfa.amsl.com> References: <20141215010158.025F31A0266@ietfa.amsl.com> Date: Mon, 15 Dec 2014 13:19:54 -0500 Message-ID: From: Warren Kumari To: Michael StJohns Content-Type: multipart/mixed; boundary=f46d04428d1211c0dc050a454a3e Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/gW6X94wHOZl3rYxiy3l2XL1QGf8 Cc: KSK Rollover SOI , "dnsext@ietf.org" Subject: Re: [dnsext] Solicitation for Statements of Interest regarding Root KSK Rollover 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, 15 Dec 2014 18:20:01 -0000 --f46d04428d1211c0dc050a454a3e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Dec 14, 2014 at 8:01 PM, Michael StJohns wro= te: > Any chance at all that the originator of the referenced document could pr= ovide an editable version of Appendix A please? Dunno, but I got bored and cut-n-pasted from the document. They say that they'll take plain ASCII... SECTION A. Identifying and Contact Information ------------------------------------------------------------------- (A.1) Your name: given name(s) and FAMILY NAME (in capital letters). (A.2) Male/Female? (A.3) Your e-mail address(s). (A.4) Your telephone number(s). (A.5) Your country of citizenship. (A.6) Your country of residence. SECTION B. Education and Professional Background ------------------------------------------------------------------------- (B.1) Provide details of your current job, title, employer or affiliation. (B.2) Describe your educational background and past professional positions. (B.3) If you have a personal web page, you may wish to provide a link to it here: SECTION C. Experience ---------------------------------- Provide a short description of your experience with one or more of: =E2=80=A2 DNSSEC; =E2=80=A2 Implementation of the DNS protocols; =E2=80=A2 Operation of DNS servers and the provision of DNS services; =E2=80=A2 External independent audit and trust services principle and crite= ria; =E2=80=A2 Secure facilities management and/or HSMs (particularly AEP Keyper= ); or =E2=80=A2 Rolling a DNSSEC KSK for a production zone of non-trivial size. Section D. Support --------------------------- (D.1) Do you have the support from your organization to volunteer your time= for this activity? [ ] YES, My organization supports my volunteering to be on the Design Team [ ] NO, My organization does not support my volunteering for this activity [ ] Not Applicable (D.2) Do you anticipate the need for partial or full reimbursement of trave= l expenses? [ ] Full reimbursement will be required. [ ] Partial reimbursement will be required. [ ] No reimbursement will be required. SECTION E. Consent and Authorization ------------------------------------------------------- (E.1) You authorize ICANN to investigate information publicly available about you, and to conduct additional third-party reference checks. You will not be entitled to review or access any of the information received, obtained, generated, or considered by ICANN regarding any Candidate Design Team member, or any of the RZM partners' discussions or deliberations regarding any Candidate Design Team member. Candidate Design Team members have no right to challenge or seek review of the RZM partners' selections. When the RZM partners have completed their selections, they will publish th= e identities of the Selected Design Team members and all Candidates (whether or not selected). Statistical information, such as the size and nature of the candidate pool, may be published at the close of the process. Please indicate that you understand this statement (E.1) and agree to becom= e a candidate under the conditions described above. Please indicate Yes or No: [ ] YES, I understand this statement and agree to these conditions [ ] NO, I do not agree to these conditions (E.2) Interim vacancies If you are NOT selected for the Design Team, would you permit the RZM partners to retain your name and other related information for possible consideration i= n the event that a vacancy occurs? Please indicate Yes or No: [ ] YES [ ] NO > > I tried to use Acrobat 9 to convert it to word or RTF and got an error re= lated to page structure. Well, thar's your problem... Attached (assuming mailman didn't eat it) is a somewhat RTF version as well= ... W > > Mike > > > > At 02:08 PM 12/12/2014, KSK Rollover SOI wrote: >>ICANN, as the IANA functions operator, in cooperation with Verisign as th= e >>Root Zone Maintainer and the National Telecommunications Information >>Administration (NTIA) as the Root Zone Administrator, together known as >>the Root Zone Management (RZM) partners, seek to develop a plan for >>rolling the DNS root zone key-signing key (KSK). The KSK is used to sign >>the >>root zone zone-signing key (ZSK), which in turn is used to DNSSEC-sign th= e >>Internet=C3=A2=E2=82=AC=E2=84=A2s root zone. The Root Zone Partners are s= oliciting five to seven >>volunteers from the community to participate in a Design Team to develop >>the Root Zone KSK Rollover Plan (=C3=A2=E2=82=AC=C5=93The Plan=C3=A2=E2= =82=AC ). These volunteers along with >>the RZM partners will form the Design Team to develop The Plan. >> >>Individuals interested in volunteering approximately 5 hours per week for >>the Design Team should consult the announcement: >> >>https://www.icann.org/en/system/files/files/ksk-soi-11dec14-en.pdf >> >>and submit their Statement of Interest to ksk-rollover-soi@icann.org no >>later than January 16, 2015. >> >>_______________________________________________ dnsext mailing list dnsex= t@ietf.org https://www.ietf.org/mailman/listinfo/dnsext > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --=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 --f46d04428d1211c0dc050a454a3e Content-Type: application/rtf; name="KSK-SOI-WK.rtf" Content-Disposition: attachment; filename="KSK-SOI-WK.rtf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i3q621hn0 e1xydGYxXGFkZWZsYW5nMTAyNVxhbnNpXGFuc2ljcGcxMDAwMFx1YzFcYWRlZmYzMTUwN1xkZWZm MFxzdHNoZmRiY2gzMTUwNVxzdHNoZmxvY2gzMTUwNlxzdHNoZmhpY2gzMTUwNlxzdHNoZmJpMzE1 MDdcZGVmbGFuZzEwMzNcZGVmbGFuZ2ZlMTAzM1x0aGVtZWxhbmcxMDMzXHRoZW1lbGFuZ2ZlMTA0 MVx0aGVtZWxhbmdjczB7XGZvbnR0Ymx7XGYwXGZiaWRpIFxmbmlsXGZjaGFyc2V0MFxmcHJxMntc KlxwYW5vc2UgMDIwMjA2MDMwNTA0MDUwMjAzMDR9VGltZXMgTmV3IFJvbWFuO317XGYxXGZiaWRp IFxmbmlsXGZjaGFyc2V0MFxmcHJxMntcKlxwYW5vc2UgMDIwYjA2MDQwMjAyMDIwMjAyMDR9QXJp YWw7fQ17XGY0XGZiaWRpIFxmbmlsXGZjaGFyc2V0MFxmcHJxMntcKlxwYW5vc2UgMDIwMDA1MDAw MDAwMDAwMDAwMDB9VGltZXM7fXtcZjE1XGZiaWRpIFxmbmlsXGZjaGFyc2V0NzhcZnBycTJ7XCpc cGFub3NlIDAwMDAwMDAwMDAwMDAwMDAwMDAwfVwnODJcJzZjXCc4MlwnNzIgXCc5NlwnYmVcJzky XCdhOTt9e1xmMzRcZmJpZGkgXGZuaWxcZmNoYXJzZXQwXGZwcnEye1wqXHBhbm9zZSAwMjA0MDUw MzA1MDQwNjAzMDIwNH1DYW1icmlhIE1hdGg7fQ17XGYzNlxmYmlkaSBcZm5pbFxmY2hhcnNldDBc ZnBycTJ7XCpccGFub3NlIDAyMDQwNTAzMDUwNDA2MDMwMjA0fUNhbWJyaWE7fXtcZmxvbWFqb3Jc ZjMxNTAwXGZiaWRpIFxmbmlsXGZjaGFyc2V0MFxmcHJxMntcKlxwYW5vc2UgMDIwYjA2MDQwMjAy MDIwMjAyMDR9QXJpYWw7fQ17XGZkYm1ham9yXGYzMTUwMVxmYmlkaSBcZm5pbFxmY2hhcnNldDc4 XGZwcnEye1wqXHBhbm9zZSAwMDAwMDAwMDAwMDAwMDAwMDAwMH1cJzgyXCc2Y1wnODJcJzcyIFwn ODNcJzUzXCc4M1wnNTZcJzgzXCc2MlwnODNcJzRlO317XGZoaW1ham9yXGYzMTUwMlxmYmlkaSBc Zm5pbFxmY2hhcnNldDBcZnBycTJ7XCpccGFub3NlIDAyMGYwNTAyMDIwMjA0MDMwMjA0fUNhbGli cmk7fQ17XGZiaW1ham9yXGYzMTUwM1xmYmlkaSBcZm5pbFxmY2hhcnNldDBcZnBycTJ7XCpccGFu b3NlIDAyMDIwNjAzMDUwNDA1MDIwMzA0fVRpbWVzIE5ldyBSb21hbjt9e1xmbG9taW5vclxmMzE1 MDRcZmJpZGkgXGZuaWxcZmNoYXJzZXQwXGZwcnEye1wqXHBhbm9zZSAwMjAyMDYwMzA1MDQwNTAy MDMwNH1UaW1lcyBOZXcgUm9tYW47fQ17XGZkYm1pbm9yXGYzMTUwNVxmYmlkaSBcZm5pbFxmY2hh cnNldDc4XGZwcnEye1wqXHBhbm9zZSAwMDAwMDAwMDAwMDAwMDAwMDAwMH1cJzgyXCc2Y1wnODJc JzcyIFwnOTZcJ2JlXCc5MlwnYTk7fXtcZmhpbWlub3JcZjMxNTA2XGZiaWRpIFxmbmlsXGZjaGFy c2V0MFxmcHJxMntcKlxwYW5vc2UgMDIwNDA1MDMwNTA0MDYwMzAyMDR9Q2FtYnJpYTt9DXtcZmJp bWlub3JcZjMxNTA3XGZiaWRpIFxmbmlsXGZjaGFyc2V0MFxmcHJxMntcKlxwYW5vc2UgMDIwMjA2 MDMwNTA0MDUwMjAzMDR9VGltZXMgTmV3IFJvbWFuO317XGY1NDlcZmJpZGkgXGZuaWxcZmNoYXJz ZXQyMzhcZnBycTIgVGltZXMgTmV3IFJvbWFuIENFO317XGY1NTBcZmJpZGkgXGZuaWxcZmNoYXJz ZXQyMDRcZnBycTIgVGltZXMgTmV3IFJvbWFuIEN5cjt9DXtcZjU1MlxmYmlkaSBcZm5pbFxmY2hh cnNldDE2MVxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gR3JlZWs7fXtcZjU1M1xmYmlkaSBcZm5pbFxm Y2hhcnNldDE2MlxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gVHVyO317XGY1NTRcZmJpZGkgXGZuaWxc ZmNoYXJzZXQxNzdcZnBycTIgVGltZXMgTmV3IFJvbWFuIChIZWJyZXcpO317XGY1NTVcZmJpZGkg XGZuaWxcZmNoYXJzZXQxNzhcZnBycTIgVGltZXMgTmV3IFJvbWFuIChBcmFiaWQpO30Ne1xmNTU2 XGZiaWRpIFxmbmlsXGZjaGFyc2V0MTg2XGZwcnEyIFRpbWVzIE5ldyBSb21hbiBCYWx0aWM7fXtc ZjU1N1xmYmlkaSBcZm5pbFxmY2hhcnNldDE2M1xmcHJxMiBUaW1lcyBOZXcgUm9tYW4gKFZpZXRu YW1lc2UpO317XGY1NTlcZmJpZGkgXGZuaWxcZmNoYXJzZXQyMzhcZnBycTIgQXJpYWwgQ0U7fXtc ZjU2MFxmYmlkaSBcZm5pbFxmY2hhcnNldDIwNFxmcHJxMiBBcmlhbCBDeXI7fQ17XGY1NjJcZmJp ZGkgXGZuaWxcZmNoYXJzZXQxNjFcZnBycTIgQXJpYWwgR3JlZWs7fXtcZjU2M1xmYmlkaSBcZm5p bFxmY2hhcnNldDE2MlxmcHJxMiBBcmlhbCBUdXI7fXtcZjU2NFxmYmlkaSBcZm5pbFxmY2hhcnNl dDE3N1xmcHJxMiBBcmlhbCAoSGVicmV3KTt9e1xmNTY1XGZiaWRpIFxmbmlsXGZjaGFyc2V0MTc4 XGZwcnEyIEFyaWFsIChBcmFiaWQpO317XGY1NjZcZmJpZGkgXGZuaWxcZmNoYXJzZXQxODZcZnBy cTIgQXJpYWwgQmFsdGljO30Ne1xmNTY3XGZiaWRpIFxmbmlsXGZjaGFyc2V0MTYzXGZwcnEyIEFy aWFsIChWaWV0bmFtZXNlKTt9e1xmODg5XGZiaWRpIFxmbmlsXGZjaGFyc2V0MjM4XGZwcnEyIENh bWJyaWEgTWF0aCBDRTt9e1xmODkwXGZiaWRpIFxmbmlsXGZjaGFyc2V0MjA0XGZwcnEyIENhbWJy aWEgTWF0aCBDeXI7fXtcZjg5MlxmYmlkaSBcZm5pbFxmY2hhcnNldDE2MVxmcHJxMiBDYW1icmlh IE1hdGggR3JlZWs7fQ17XGY4OTNcZmJpZGkgXGZuaWxcZmNoYXJzZXQxNjJcZnBycTIgQ2FtYnJp YSBNYXRoIFR1cjt9e1xmODk2XGZiaWRpIFxmbmlsXGZjaGFyc2V0MTg2XGZwcnEyIENhbWJyaWEg TWF0aCBCYWx0aWM7fXtcZjg5N1xmYmlkaSBcZm5pbFxmY2hhcnNldDE2M1xmcHJxMiBDYW1icmlh IE1hdGggKFZpZXRuYW1lc2UpO317XGY5MDlcZmJpZGkgXGZuaWxcZmNoYXJzZXQyMzhcZnBycTIg Q2FtYnJpYSBDRTt9DXtcZjkxMFxmYmlkaSBcZm5pbFxmY2hhcnNldDIwNFxmcHJxMiBDYW1icmlh IEN5cjt9e1xmOTEyXGZiaWRpIFxmbmlsXGZjaGFyc2V0MTYxXGZwcnEyIENhbWJyaWEgR3JlZWs7 fXtcZjkxM1xmYmlkaSBcZm5pbFxmY2hhcnNldDE2MlxmcHJxMiBDYW1icmlhIFR1cjt9e1xmOTE2 XGZiaWRpIFxmbmlsXGZjaGFyc2V0MTg2XGZwcnEyIENhbWJyaWEgQmFsdGljO30Ne1xmOTE3XGZi aWRpIFxmbmlsXGZjaGFyc2V0MTYzXGZwcnEyIENhbWJyaWEgKFZpZXRuYW1lc2UpO317XGZsb21h am9yXGYzMTUwOFxmYmlkaSBcZm5pbFxmY2hhcnNldDIzOFxmcHJxMiBBcmlhbCBDRTt9e1xmbG9t YWpvclxmMzE1MDlcZmJpZGkgXGZuaWxcZmNoYXJzZXQyMDRcZnBycTIgQXJpYWwgQ3lyO317XGZs b21ham9yXGYzMTUxMVxmYmlkaSBcZm5pbFxmY2hhcnNldDE2MVxmcHJxMiBBcmlhbCBHcmVlazt9 DXtcZmxvbWFqb3JcZjMxNTEyXGZiaWRpIFxmbmlsXGZjaGFyc2V0MTYyXGZwcnEyIEFyaWFsIFR1 cjt9e1xmbG9tYWpvclxmMzE1MTNcZmJpZGkgXGZuaWxcZmNoYXJzZXQxNzdcZnBycTIgQXJpYWwg KEhlYnJldyk7fXtcZmxvbWFqb3JcZjMxNTE0XGZiaWRpIFxmbmlsXGZjaGFyc2V0MTc4XGZwcnEy IEFyaWFsIChBcmFiaWQpO317XGZsb21ham9yXGYzMTUxNVxmYmlkaSBcZm5pbFxmY2hhcnNldDE4 NlxmcHJxMiBBcmlhbCBCYWx0aWM7fQ17XGZsb21ham9yXGYzMTUxNlxmYmlkaSBcZm5pbFxmY2hh cnNldDE2M1xmcHJxMiBBcmlhbCAoVmlldG5hbWVzZSk7fXtcZmhpbWFqb3JcZjMxNTI4XGZiaWRp IFxmbmlsXGZjaGFyc2V0MjM4XGZwcnEyIENhbGlicmkgQ0U7fXtcZmhpbWFqb3JcZjMxNTI5XGZi aWRpIFxmbmlsXGZjaGFyc2V0MjA0XGZwcnEyIENhbGlicmkgQ3lyO317XGZoaW1ham9yXGYzMTUz MVxmYmlkaSBcZm5pbFxmY2hhcnNldDE2MVxmcHJxMiBDYWxpYnJpIEdyZWVrO30Ne1xmaGltYWpv clxmMzE1MzJcZmJpZGkgXGZuaWxcZmNoYXJzZXQxNjJcZnBycTIgQ2FsaWJyaSBUdXI7fXtcZmhp bWFqb3JcZjMxNTM1XGZiaWRpIFxmbmlsXGZjaGFyc2V0MTg2XGZwcnEyIENhbGlicmkgQmFsdGlj O317XGZoaW1ham9yXGYzMTUzNlxmYmlkaSBcZm5pbFxmY2hhcnNldDE2M1xmcHJxMiBDYWxpYnJp IChWaWV0bmFtZXNlKTt9DXtcZmJpbWFqb3JcZjMxNTM4XGZiaWRpIFxmbmlsXGZjaGFyc2V0MjM4 XGZwcnEyIFRpbWVzIE5ldyBSb21hbiBDRTt9e1xmYmltYWpvclxmMzE1MzlcZmJpZGkgXGZuaWxc ZmNoYXJzZXQyMDRcZnBycTIgVGltZXMgTmV3IFJvbWFuIEN5cjt9e1xmYmltYWpvclxmMzE1NDFc ZmJpZGkgXGZuaWxcZmNoYXJzZXQxNjFcZnBycTIgVGltZXMgTmV3IFJvbWFuIEdyZWVrO30Ne1xm YmltYWpvclxmMzE1NDJcZmJpZGkgXGZuaWxcZmNoYXJzZXQxNjJcZnBycTIgVGltZXMgTmV3IFJv bWFuIFR1cjt9e1xmYmltYWpvclxmMzE1NDNcZmJpZGkgXGZuaWxcZmNoYXJzZXQxNzdcZnBycTIg VGltZXMgTmV3IFJvbWFuIChIZWJyZXcpO317XGZiaW1ham9yXGYzMTU0NFxmYmlkaSBcZm5pbFxm Y2hhcnNldDE3OFxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gKEFyYWJpZCk7fQ17XGZiaW1ham9yXGYz MTU0NVxmYmlkaSBcZm5pbFxmY2hhcnNldDE4NlxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gQmFsdGlj O317XGZiaW1ham9yXGYzMTU0NlxmYmlkaSBcZm5pbFxmY2hhcnNldDE2M1xmcHJxMiBUaW1lcyBO ZXcgUm9tYW4gKFZpZXRuYW1lc2UpO317XGZsb21pbm9yXGYzMTU0OFxmYmlkaSBcZm5pbFxmY2hh cnNldDIzOFxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gQ0U7fQ17XGZsb21pbm9yXGYzMTU0OVxmYmlk aSBcZm5pbFxmY2hhcnNldDIwNFxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gQ3lyO317XGZsb21pbm9y XGYzMTU1MVxmYmlkaSBcZm5pbFxmY2hhcnNldDE2MVxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gR3Jl ZWs7fXtcZmxvbWlub3JcZjMxNTUyXGZiaWRpIFxmbmlsXGZjaGFyc2V0MTYyXGZwcnEyIFRpbWVz IE5ldyBSb21hbiBUdXI7fQ17XGZsb21pbm9yXGYzMTU1M1xmYmlkaSBcZm5pbFxmY2hhcnNldDE3 N1xmcHJxMiBUaW1lcyBOZXcgUm9tYW4gKEhlYnJldyk7fXtcZmxvbWlub3JcZjMxNTU0XGZiaWRp IFxmbmlsXGZjaGFyc2V0MTc4XGZwcnEyIFRpbWVzIE5ldyBSb21hbiAoQXJhYmlkKTt9e1xmbG9t aW5vclxmMzE1NTVcZmJpZGkgXGZuaWxcZmNoYXJzZXQxODZcZnBycTIgVGltZXMgTmV3IFJvbWFu IEJhbHRpYzt9DXtcZmxvbWlub3JcZjMxNTU2XGZiaWRpIFxmbmlsXGZjaGFyc2V0MTYzXGZwcnEy IFRpbWVzIE5ldyBSb21hbiAoVmlldG5hbWVzZSk7fXtcZmhpbWlub3JcZjMxNTY4XGZiaWRpIFxm bmlsXGZjaGFyc2V0MjM4XGZwcnEyIENhbWJyaWEgQ0U7fXtcZmhpbWlub3JcZjMxNTY5XGZiaWRp IFxmbmlsXGZjaGFyc2V0MjA0XGZwcnEyIENhbWJyaWEgQ3lyO30Ne1xmaGltaW5vclxmMzE1NzFc ZmJpZGkgXGZuaWxcZmNoYXJzZXQxNjFcZnBycTIgQ2FtYnJpYSBHcmVlazt9e1xmaGltaW5vclxm MzE1NzJcZmJpZGkgXGZuaWxcZmNoYXJzZXQxNjJcZnBycTIgQ2FtYnJpYSBUdXI7fXtcZmhpbWlu b3JcZjMxNTc1XGZiaWRpIFxmbmlsXGZjaGFyc2V0MTg2XGZwcnEyIENhbWJyaWEgQmFsdGljO30N e1xmaGltaW5vclxmMzE1NzZcZmJpZGkgXGZuaWxcZmNoYXJzZXQxNjNcZnBycTIgQ2FtYnJpYSAo VmlldG5hbWVzZSk7fXtcZmJpbWlub3JcZjMxNTc4XGZiaWRpIFxmbmlsXGZjaGFyc2V0MjM4XGZw cnEyIFRpbWVzIE5ldyBSb21hbiBDRTt9e1xmYmltaW5vclxmMzE1NzlcZmJpZGkgXGZuaWxcZmNo YXJzZXQyMDRcZnBycTIgVGltZXMgTmV3IFJvbWFuIEN5cjt9DXtcZmJpbWlub3JcZjMxNTgxXGZi aWRpIFxmbmlsXGZjaGFyc2V0MTYxXGZwcnEyIFRpbWVzIE5ldyBSb21hbiBHcmVlazt9e1xmYmlt aW5vclxmMzE1ODJcZmJpZGkgXGZuaWxcZmNoYXJzZXQxNjJcZnBycTIgVGltZXMgTmV3IFJvbWFu IFR1cjt9e1xmYmltaW5vclxmMzE1ODNcZmJpZGkgXGZuaWxcZmNoYXJzZXQxNzdcZnBycTIgVGlt ZXMgTmV3IFJvbWFuIChIZWJyZXcpO30Ne1xmYmltaW5vclxmMzE1ODRcZmJpZGkgXGZuaWxcZmNo YXJzZXQxNzhcZnBycTIgVGltZXMgTmV3IFJvbWFuIChBcmFiaWQpO317XGZiaW1pbm9yXGYzMTU4 NVxmYmlkaSBcZm5pbFxmY2hhcnNldDE4NlxmcHJxMiBUaW1lcyBOZXcgUm9tYW4gQmFsdGljO317 XGZiaW1pbm9yXGYzMTU4NlxmYmlkaSBcZm5pbFxmY2hhcnNldDE2M1xmcHJxMiBUaW1lcyBOZXcg Um9tYW4gKFZpZXRuYW1lc2UpO319e1xjb2xvcnRibDtccmVkMFxncmVlbjBcYmx1ZTA7DVxyZWQw XGdyZWVuMFxibHVlMjU1O1xyZWQwXGdyZWVuMjU1XGJsdWUyNTU7XHJlZDBcZ3JlZW4yNTVcYmx1 ZTA7XHJlZDI1NVxncmVlbjBcYmx1ZTI1NTtccmVkMjU1XGdyZWVuMFxibHVlMDtccmVkMjU1XGdy ZWVuMjU1XGJsdWUwO1xyZWQyNTVcZ3JlZW4yNTVcYmx1ZTI1NTtccmVkMFxncmVlbjBcYmx1ZTEy ODtccmVkMFxncmVlbjEyOFxibHVlMTI4O1xyZWQwXGdyZWVuMTI4XGJsdWUwO1xyZWQxMjhcZ3Jl ZW4wXGJsdWUxMjg7DVxyZWQxMjhcZ3JlZW4wXGJsdWUwO1xyZWQxMjhcZ3JlZW4xMjhcYmx1ZTA7 XHJlZDEyOFxncmVlbjEyOFxibHVlMTI4O1xyZWQxOTJcZ3JlZW4xOTJcYmx1ZTE5MjtccmVkMzRc Z3JlZW4zNFxibHVlMzQ7fXtcKlxkZWZjaHAgXGZzMjRcbG9jaFxhZjMxNTA2XGhpY2hcYWYzMTUw NlxkYmNoXGFmMzE1MDUgfXtcKlxkZWZwYXAgDVxxbCBcbGkwXHJpMFx3aWRjdGxwYXJcd3JhcGRl ZmF1bHRcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDAg fVxub3FmcHJvbW90ZSB7XHN0eWxlc2hlZXR7XHFsIFxsaTBccmkwXHdpZGN0bHBhclx3cmFwZGVm YXVsdFxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMCBc cnRsY2hcZmNzMSBcYWYzMTUwN1xhZnMyNFxhbGFuZzEwMzMgXGx0cmNoXGZjczAgDVxmczI0XGxh bmcxMDMzXGxhbmdmZTEwMzNcbG9jaFxmMzE1MDZcaGljaFxhZjMxNTA2XGRiY2hcYWYzMTUwNVxj Z3JpZFxsYW5nbnAxMDMzXGxhbmdmZW5wMTAzMyBcc25leHQwIFxzcWZvcm1hdCBcc3ByaW9yaXR5 MCBOb3JtYWw7fXtcKlxjczEwIFxhZGRpdGl2ZSBcc3NlbWloaWRkZW4gXHN1bmhpZGV1c2VkIFxz cHJpb3JpdHkxIERlZmF1bHQgUGFyYWdyYXBoIEZvbnQ7fXtcKg1cdHMxMVx0c3Jvd2RcdHJmdHNX aWR0aEIzXHRycGFkZGwxMDhcdHJwYWRkcjEwOFx0cnBhZGRmbDNcdHJwYWRkZnQzXHRycGFkZGZi M1x0cnBhZGRmcjNcdGJsaW5kMFx0YmxpbmR0eXBlM1x0c3ZlcnRhbHRcdHNicmRydFx0c2JyZHJs XHRzYnJkcmJcdHNicmRyclx0c2JyZHJkZ2xcdHNicmRyZGdyXHRzYnJkcmhcdHNicmRydiANXHFs IFxsaTBccmkwXHdpZGN0bHBhclx3cmFwZGVmYXVsdFxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFk anVzdHJpZ2h0XHJpbjBcbGluMFxpdGFwMCBccnRsY2hcZmNzMSBcYWYzMTUwN1xhZnMyNFxhbGFu ZzEwMzMgXGx0cmNoXGZjczAgXGZzMjRcbGFuZzEwMzNcbGFuZ2ZlMTAzM1xsb2NoXGYzMTUwNlxo aWNoXGFmMzE1MDZcZGJjaFxhZjMxNTA1XGNncmlkXGxhbmducDEwMzNcbGFuZ2ZlbnAxMDMzIA1c c25leHQxMSBcc3NlbWloaWRkZW4gXHN1bmhpZGV1c2VkIE5vcm1hbCBUYWJsZTt9fXtcKlxwZ3B0 Ymwge1xwZ3BcaXBncDEwXGl0YXAwXGxpMFxyaTBcc2IwXHNhMH17XHBncFxpcGdwOVxpdGFwMFxs aTBccmkwXHNiMFxzYTB9e1xwZ3BcaXBncDEwXGl0YXAwXGxpMFxyaTBcc2IwXHNhMH17XHBncFxp cGdwOVxpdGFwMFxsaTBccmkwXHNiMFxzYTB9e1xwZ3BcaXBncDlcaXRhcDBcbGkwXHJpMFxzYjBc c2EwfXtccGdwXGlwZ3AxMFxpdGFwMFxsaTANXHJpMFxzYjBcc2EwfXtccGdwXGlwZ3AxMFxpdGFw MFxsaTBccmkwXHNiMFxzYTB9e1xwZ3BcaXBncDlcaXRhcDBcbGkwXHJpMFxzYjBcc2EwfXtccGdw XGlwZ3AxMFxpdGFwMFxsaTBccmkwXHNiMFxzYTB9e1xwZ3BcaXBncDBcaXRhcDBcbGkwXHJpMFxz YjBcc2EwfX17XCpccnNpZHRibCBccnNpZDMwOTQ3NTFccnNpZDMzNDI2OTJccnNpZDE1NDc5NjM3 fXtcbW1hdGhQclxtbWF0aEZvbnQzNFxtYnJrQmluMFxtYnJrQmluU3ViMA1cbXNtYWxsRnJhYzBc bWRpc3BEZWYxXG1sTWFyZ2luMFxtck1hcmdpbjBcbWRlZkpjMVxtd3JhcEluZGVudDE0NDBcbWlu dExpbTBcbW5hcnlMaW0xfXtcaW5mb3tcYXV0aG9yIFdhcnJlbiBLdW1hcml9e1xvcGVyYXRvciBX YXJyZW4gS3VtYXJpfXtcY3JlYXRpbVx5cjIwMTRcbW8xMlxkeTE1XGhyMTNcbWluMTN9e1xyZXZ0 aW1ceXIyMDE0XG1vMTJcZHkxNVxocjEzXG1pbjE4fXtcdmVyc2lvbjF9e1xlZG1pbnM0fXtcbm9m cGFnZXMyfQ17XG5vZndvcmRzNDI1fXtcbm9mY2hhcnMyNDIzfXtcbm9mY2hhcnN3czI4NDN9e1x2 ZXJuNDk2NzV9e1wqXHNhdmVwcmV2cGljdH19e1wqXHhtbG5zdGJsIHtceG1sbnMxIGh0dHA6Ly9z Y2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlL3dvcmQvMjAwMy93b3JkbWx9fVxwYXBlcncxMjI0 MFxwYXBlcmgxNTg0MFxtYXJnbDE4MDBcbWFyZ3IxODAwXG1hcmd0MTQ0MFxtYXJnYjE0NDBcZ3V0 dGVyMFxsdHJzZWN0IA1cZnRuYmpcYWVuZGRvY1x0cmFja21vdmVzMFx0cmFja2Zvcm1hdHRpbmcx XGRvbm90ZW1iZWRzeXNmb250MVxyZWx5b252bWwwXGRvbm90ZW1iZWRsaW5nZGF0YTBcZ3JmZG9j ZXZlbnRzMFx2YWxpZGF0ZXhtbDFcc2hvd3BsYWNlaG9sZHRleHQwXGlnbm9yZW1peGVkY29udGVu dDBcc2F2ZWludmFsaWR4bWwwXHNob3d4bWxlcnJvcnMxXG5veGxhdHRveWVuDVxleHBzaHJ0blxu b3VsdHJsc3BjXGRudGJsbnNiZGJcbm9zcGFjZWZvcnVsXGZvcm1zaGFkZVxob3J6ZG9jXGRnbWFy Z2luXGRnaHNwYWNlMTgwXGRndnNwYWNlMTgwXGRnaG9yaWdpbjE4MDBcZGd2b3JpZ2luMTQ0MFxk Z2hzaG93MVxkZ3ZzaG93MQ1camV4cGFuZFx2aWV3a2luZDFcdmlld3NjYWxlMTAwXHBnYnJkcmhl YWRccGdicmRyZm9vdFxzcGx5dHduaW5lXGZ0bmx5dHduaW5lXGh0bWF1dHNwXG5vbG5odGFkanRi bFx1c2VsdGJhbG5cYWxudGJsaW5kXGx5dGNhbGN0Ymx3ZFxseXR0YmxydGdyXGxuYnJrcnVsZVxu b2Jya3dycHRibFxzbmFwdG9ncmlkaW5jZWxsXGFsbG93ZmllbGRlbmRzZWxcd3JwcHVuY3QNXGFz aWFuYnJrcnVsZVxyc2lkcm9vdDMzNDI2OTJcbmV3dGJsc3R5cnVsc1xub2dyb3dhdXRvZml0XHVz ZW5vcm1zdHlmb3JsaXN0XG5vaW5kbm1icnRzXGZlbG5icmVsZXZcbm9jeHNwdGFibGVcaW5kcmxz d2VsZXZlblxub2FmY25zdHRibFxhZmVsZXZcdXRpbmxcaHdlbGV2XHNwbHRwZ3Bhclxub3RjdmFz cFxub3RicmtjbnN0ZnJjdGJsXG5vdHZhdHhieFxrcm5wcnNuZXRcY2FjaGVkY29sYmFsXG91dGRp c3Bvbmx5aHRtbCANXG5vdWljb21wYXQgXGZldDB7XCpcd2dyZmZtdGZpbHRlciAyNDUwfVxub2Zl YXR1cmV0aHJvdHRsZTFcaWxmb21hY2F0Y2xudXAwXGx0cnBhciBcc2VjdGQgXGx0cnNlY3RcbGlu ZXgwXGVuZG5oZXJlXHNlY3RsaW5lZ3JpZDM2MFxzZWN0ZGVmYXVsdGNsXHNlY3Ryc2lkMTU0Nzk2 Mzdcc2Z0bmJqIHtcKlxwbnNlY2x2bDFccG51Y3JtXHBuc3RhcnQxXHBuaW5kZW50NzIwXHBuaGFu ZyB7XHBudHh0YSAufX17XCpccG5zZWNsdmwyDVxwbnVjbHRyXHBuc3RhcnQxXHBuaW5kZW50NzIw XHBuaGFuZyB7XHBudHh0YSAufX17XCpccG5zZWNsdmwzXHBuZGVjXHBuc3RhcnQxXHBuaW5kZW50 NzIwXHBuaGFuZyB7XHBudHh0YSAufX17XCpccG5zZWNsdmw0XHBubGNsdHJccG5zdGFydDFccG5p bmRlbnQ3MjBccG5oYW5nIHtccG50eHRhICl9fXtcKlxwbnNlY2x2bDVccG5kZWNccG5zdGFydDFc cG5pbmRlbnQ3MjBccG5oYW5nIHtccG50eHRiICh9e1xwbnR4dGEgKX19e1wqXHBuc2VjbHZsNg1c cG5sY2x0clxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmcge1xwbnR4dGIgKH17XHBudHh0YSAp fX17XCpccG5zZWNsdmw3XHBubGNybVxwbnN0YXJ0MVxwbmluZGVudDcyMFxwbmhhbmcge1xwbnR4 dGIgKH17XHBudHh0YSApfX17XCpccG5zZWNsdmw4XHBubGNsdHJccG5zdGFydDFccG5pbmRlbnQ3 MjBccG5oYW5nIHtccG50eHRiICh9e1xwbnR4dGEgKX19e1wqXHBuc2VjbHZsOVxwbmxjcm1ccG5z dGFydDFccG5pbmRlbnQ3MjBccG5oYW5nIA17XHBudHh0YiAofXtccG50eHRhICl9fVxwYXJkXHBs YWluIFxsdHJwYXJccWwgXGxpMFxyaTBcd2lkY3RscGFyXHdyYXBkZWZhdWx0XGFzcGFscGhhXGFz cG51bVxmYWF1dG9cYWRqdXN0cmlnaHRccmluMFxsaW4wXGl0YXAwXHBhcmFyc2lkMzM0MjY5MiBc cnRsY2hcZmNzMSBcYWYzMTUwN1xhZnMyNFxhbGFuZzEwMzMgXGx0cmNoXGZjczAgDVxmczI0XGxh bmcxMDMzXGxhbmdmZTEwMzNcbG9jaFxhZjMxNTA2XGhpY2hcYWYzMTUwNlxkYmNoXGFmMzE1MDVc Y2dyaWRcbGFuZ25wMTAzM1xsYW5nZmVucDEwMzMge1xydGxjaFxmY3MxIFxhZjAgXGx0cmNoXGZj czAgXGYxXGNmMTdcY2hzaGRuZzBcY2hjZnBhdDBcY2hjYnBhdDhcaW5zcnNpZDMzNDI2OTJcY2hh cnJzaWQzMzQyNjkyIA1ccGFyIH17XHJ0bGNoXGZjczEgXGFmMCBcbHRyY2hcZmNzMCBcYlxmMVxj ZjE3XGNoc2hkbmcwXGNoY2ZwYXQwXGNoY2JwYXQ4XGluc3JzaWQzMzQyNjkyXGNoYXJyc2lkMzM0 MjY5MiBTRUNUSU9OIEEuIElkZW50aWZ5aW5nIGFuZCBDb250YWN0IEluZm9ybWF0aW9ufXtccnRs Y2hcZmNzMSBcYWYwXGFmczIwIFxsdHJjaFxmY3MwIFxiXGY0XGZzMjBcaW5zcnNpZDMzNDI2OTIg DVxwYXIgfXtccnRsY2hcZmNzMSBcYWYwIFxsdHJjaFxmY3MwIFxmMVxjZjE3XGluc3JzaWQzMzQy NjkyXGNoYXJyc2lkMzM0MjY5MiBcbGluZSB9e1xydGxjaFxmY3MxIFxhZjAgXGx0cmNoXGZjczAg XGJcZjFcY2YxN1xpbnNyc2lkMzM0MjY5MlxjaGFycnNpZDMzNDI2OTIgKEEuMSkgfXtccnRsY2hc ZmNzMSBcYWYwIFxsdHJjaFxmY3MwIFxmMVxjZjE3XGluc3JzaWQzMzQyNjkyXGNoYXJyc2lkMzM0 MjY5MiANWW91ciBuYW1lOiBnaXZlbiBuYW1lKHMpIGFuZCBGQU1JTFkgTkFNRSAoaW4gY2FwaXRh bCBsZXR0ZXJzKS5cbGluZSBcbGluZSB9e1xydGxjaFxmY3MxIFxhZjAgXGx0cmNoXGZjczAgXGJc ZjFcY2YxN1xpbnNyc2lkMzM0MjY5MlxjaGFycnNpZDMzNDI2OTIgKEEuMil9e1xydGxjaFxmY3Mx IFxhZjAgXGx0cmNoXGZjczAgXGYxXGNmMTdcaW5zcnNpZDMzNDI2OTJcY2hhcnJzaWQzMzQyNjky ICBNYWxlL0ZlbWFsZT9cbGluZSBcbGluZSB9ew1ccnRsY2hcZmNzMSBcYWYwIFxsdHJjaFxmY3Mw IFxiXGYxXGNmMTdcaW5zcnNpZDMzNDI2OTJcY2hhcnJzaWQzMzQyNjkyIChBLjMpfXtccnRsY2hc ZmNzMSBcYWYwIFxsdHJjaFxmY3MwIFxmMVxjZjE3XGluc3JzaWQzMzQyNjkyXGNoYXJyc2lkMzM0 MjY5MiAgWW91ciBlLW1haWwgYWRkcmVzcyhzKS5cbGluZSBcbGluZSB9e1xydGxjaFxmY3MxIFxh ZjAgXGx0cmNoXGZjczAgDVxiXGYxXGNmMTdcaW5zcnNpZDMzNDI2OTJcY2hhcnJzaWQzMzQyNjky IChBLjQpfXtccnRsY2hcZmNzMSBcYWYwIFxsdHJjaFxmY3MwIFxmMVxjZjE3XGluc3JzaWQzMzQy NjkyXGNoYXJyc2lkMzM0MjY5MiAgWW91ciB0ZWxlcGhvbmUgbnVtYmVyKHMpLlxsaW5lIFxsaW5l IH17XHJ0bGNoXGZjczEgXGFmMCBcbHRyY2hcZmNzMCBcYlxmMVxjZjE3XGluc3JzaWQzMzQyNjky XGNoYXJyc2lkMzM0MjY5MiAoQS41KX17XHJ0bGNoXGZjczEgXGFmMCANXGx0cmNoXGZjczAgXGYx XGNmMTdcaW5zcnNpZDMzNDI2OTJcY2hhcnJzaWQzMzQyNjkyICBZb3VyIGNvdW50cnkgb2YgY2l0 aXplbnNoaXAuXGxpbmUgXGxpbmUgfXtccnRsY2hcZmNzMSBcYWYwIFxsdHJjaFxmY3MwIFxiXGYx XGNmMTdcaW5zcnNpZDMzNDI2OTJcY2hhcnJzaWQzMzQyNjkyIChBLjYpfXtccnRsY2hcZmNzMSBc YWYwIFxsdHJjaFxmY3MwIFxmMVxjZjE3XGluc3JzaWQzMzQyNjkyXGNoYXJyc2lkMzM0MjY5MiAN IFlvdXIgY291bnRyeSBvZiByZXNpZGVuY2UuXGxpbmUgXGxpbmUgXGxpbmUgfXtccnRsY2hcZmNz MSBcYWYwIFxsdHJjaFxmY3MwIFxiXGYxXGNmMTdcaW5zcnNpZDMzNDI2OTJcY2hhcnJzaWQzMzQy NjkyIFNFQ1RJT04gQi4gRWR1Y2F0aW9uIGFuZCBQcm9mZXNzaW9uYWwgQmFja2dyb3VuZH17XHJ0 bGNoXGZjczEgXGFmMFxhZnMyMCBcbHRyY2hcZmNzMCBcYlxmNFxmczIwXGluc3JzaWQzMzQyNjky XGNoYXJyc2lkMzM0MjY5MiANXHBhciB9e1xydGxjaFxmY3MxIFxhZjAgXGx0cmNoXGZjczAgXGYx XGNmMTdcaW5zcnNpZDMzNDI2OTJcY2hhcnJzaWQzMzQyNjkyIFxsaW5lIH17XHJ0bGNoXGZjczEg XGFmMCBcbHRyY2hcZmNzMCBcYlxmMVxjZjE3XGluc3JzaWQzMzQyNjkyXGNoYXJyc2lkMzM0MjY5 MiAoQi4xKX17XHJ0bGNoXGZjczEgXGFmMCBcbHRyY2hcZmNzMCBcZjFcY2YxN1xpbnNyc2lkMzM0 MjY5MlxjaGFycnNpZDMzNDI2OTIgDSBQcm92aWRlIGRldGFpbHMgb2YgeW91ciBjdXJyZW50IGpv YiwgdGl0bGUsIGVtcGxveWVyIG9yIGFmZmlsaWF0aW9uLlxsaW5lIFxsaW5lIH17XHJ0bGNoXGZj czEgXGFmMCBcbHRyY2hcZmNzMCBcYlxmMVxjZjE3XGluc3JzaWQzMzQyNjkyXGNoYXJyc2lkMzM0 MjY5MiAoQi4yKX17XHJ0bGNoXGZjczEgXGFmMCBcbHRyY2hcZmNzMCBcZjFcY2YxN1xpbnNyc2lk MzM0MjY5MlxjaGFycnNpZDMzNDI2OTIgDSBEZXNjcmliZSB5b3VyIGVkdWNhdGlvbmFsIGJhY2tn cm91bmQgYW5kIHBhc3QgcHJvZmVzc2lvbmFsIHBvc2l0aW9ucy5cbGluZSBcbGluZSB9e1xydGxj aFxmY3MxIFxhZjAgXGx0cmNoXGZjczAgXGJcZjFcY2YxN1xpbnNyc2lkMzM0MjY5MlxjaGFycnNp ZDMzNDI2OTIgKEIuMyl9e1xydGxjaFxmY3MxIFxhZjAgXGx0cmNoXGZjczAgXGYxXGNmMTdcaW5z cnNpZDMzNDI2OTJcY2hhcnJzaWQzMzQyNjkyICBJZiB5bw11IGhhdmUgYSBwZXJzb25hbCB3ZWIg cGFnZSwgeW91IG1heSB3aXNoIHRvIHByb3ZpZGUgYSBsaW5rIHRvIGl0IGhlcmU6XGxpbmUgXGxp bmUgXGxpbmUgfXtccnRsY2hcZmNzMSBcYWYwIFxsdHJjaFxmY3MwIFxiXGYxXGNmMTdcaW5zcnNp ZDMzNDI2OTJcY2hhcnJzaWQzMzQyNjkyIFNFQ1RJT04gQy4gRXhwZXJpZW5jZX17XHJ0bGNoXGZj czEgXGFmMCBcbHRyY2hcZmNzMCBcZjFcY2YxN1xpbnNyc2lkMzM0MjY5MlxjaGFycnNpZDMzNDI2 OTIgDVxsaW5lIFByb3ZpZGUgYSBzaG9ydCBkZXNjcmlwdGlvbiBvZiB5b3VyIGV4cGVyaWVuY2Ug d2l0aCBvbmUgb3IgbW9yZSBvZjpcbGluZSB9e1xydGxjaFxmY3MxIFxhZjAgXGx0cmNoXGZjczAg XGYxXGNmMTdcaW5zcnNpZDMzNDI2OTIgICB9e1xydGxjaFxmY3MxIFxhZjAgXGx0cmNoXGZjczAg XGYxXGNmMTdcaW5zcnNpZDMzNDI2OTJcY2hhcnJzaWQzMzQyNjkyIFxidWxsZXQgIEROU1NFQztc bGluZSB9e1xydGxjaFxmY3MxIFxhZjAgDVxsdHJjaFxmY3MwIFxmMVxjZjE3XGluc3JzaWQzMzQy NjkyICAgfXtccnRsY2hcZmNzMSBcYWYwIFxsdHJjaFxmY3MwIFxmMVxjZjE3XGluc3JzaWQzMzQy NjkyXGNoYXJyc2lkMzM0MjY5MiBcYnVsbGV0ICBJbXBsZW1lbnRhdGlvbiBvZiB0aGUgRE5TIHBy b3RvY29scztcbGluZSB9e1xydGxjaFxmY3MxIFxhZjAgXGx0cmNoXGZjczAgXGYxXGNmMTdcaW5z cnNpZDMzNDI2OTIgICB9e1xydGxjaFxmY3MxIFxhZjAgXGx0cmNoXGZjczAgDVxmMVxjZjE3XGlu c3JzaWQzMzQyNjkyXGNoYXJyc2lkMzM0MjY5MiBcYnVsbGV0ICBPcGVyYXRpb24gb2YgRE5TIHNl cnZlcnMgYW5kIHRoZSBwcm92aXNpb24gb2YgRE5TIHNlcnZpY2VzO1xsaW5lIH17XHJ0bGNoXGZj czEgXGFmMCBcbHRyY2hcZmNzMCBcZjFcY2YxN1xpbnNyc2lkMzM0MjY5MiAgIH17XHJ0bGNoXGZj czEgXGFmMCBcbHRyY2hcZmNzMCBcZjFcY2YxN1xpbnNyc2lkMzM0MjY5MlxjaGFycnNpZDMzNDI2 OTIgXGJ1bGxldCANIEV4dGVybmFsIGluZGVwZW5kZW50IGF1ZGl0IGFuZCB0cnVzdCBzZXJ2aWNl cyBwcmluY2lwbGUgYW5kIGNyaXRlcmlhO1xsaW5lIH17XHJ0bGNoXGZjczEgXGFmMCBcbHRyY2hc ZmNzMCBcZjFcY2YxN1xpbnNyc2lkMzM0MjY5MiAgIH17XHJ0bGNoXGZjczEgXGFmMCBcbHRyY2hc ZmNzMCBcZjFcY2YxN1xpbnNyc2lkMzM0MjY5MlxjaGFycnNpZDMzNDI2OTIgXGJ1bGxldCANIFNl Y3VyZSBmYWNpbGl0aWVzIG1hbmFnZW1lbnQgYW5kL29yIEhTTXMgKHBhcnRpY3VsYXJseSBBRVAg S2V5cGVyKTsgb3JcbGluZSB9e1xydGxjaFxmY3MxIFxhZjAgXGx0cmNoXGZjczAgXGYxXGNmMTdc aW5zcnNpZDMzNDI2OTIgICB9e1xydGxjaFxmY3MxIFxhZjAgXGx0cmNoXGZjczAgXGYxXGNmMTdc aW5zcnNpZDMzNDI2OTJcY2hhcnJzaWQzMzQyNjkyIFxidWxsZXQgDSBSb2xsaW5nIGEgRE5TU0VD IEtTSyBmb3IgYSBwcm9kdWN0aW9uIHpvbmUgb2Ygbm9uLXRyaXZpYWwgc2l6ZS5cbGluZSBcbGlu ZSBcbGluZSB9e1xydGxjaFxmY3MxIFxhZjAgXGx0cmNoXGZjczAgXGJcZjFcY2YxN1xpbnNyc2lk MzM0MjY5MlxjaGFycnNpZDMzNDI2OTIgU2VjdGlvbiBELiBTdXBwb3J0fXtccnRsY2hcZmNzMSBc YWYwIFxsdHJjaFxmY3MwIFxmMVxjZjE3XGluc3JzaWQzMzQyNjkyXGNoYXJyc2lkMzM0MjY5MiBc bGluZSB9ew1ccnRsY2hcZmNzMSBcYWYwIFxsdHJjaFxmY3MwIFxiXGYxXGNmMTdcaW5zcnNpZDMz NDI2OTJcY2hhcnJzaWQzMzQyNjkyIChELjEpfXtccnRsY2hcZmNzMSBcYWYwIFxsdHJjaFxmY3Mw IFxmMVxjZjE3XGluc3JzaWQzMzQyNjkyXGNoYXJyc2lkMzM0MjY5MiAgRG8geW91IGhhdmUgdGhl IHN1cHBvcnQgZnJvbSB5b3VyIG9yZ2FuaXphdGlvbiB0byB2b2x1bnRlZXIgeW91ciB0aW1lIGZv clxsaW5lIHRoaXMgYWN0aXZpdHk/XGxpbmUgDVsgXSBZRVMsIE15IG9yZ2FuaXphdGlvbiBzdXBw b3J0cyBteSB2b2x1bnRlZXJpbmcgdG8gYmUgb24gdGhlIERlc2lnbiBUZWFtXGxpbmUgWyBdIE5P LCBNeSBvcmdhbml6YXRpb24gZG9lcyBub3Qgc3VwcG9ydCBteSB2b2x1bnRlZXJpbmcgZm9yIHRo aXMgYWN0aXZpdHlcbGluZSBbIF0gTm90IEFwcGxpY2FibGVcbGluZSBcbGluZSB9e1xydGxjaFxm Y3MxIFxhZjAgXGx0cmNoXGZjczAgDVxiXGYxXGNmMTdcaW5zcnNpZDMzNDI2OTJcY2hhcnJzaWQz MzQyNjkyIChELjIpfXtccnRsY2hcZmNzMSBcYWYwIFxsdHJjaFxmY3MwIFxmMVxjZjE3XGluc3Jz aWQzMzQyNjkyXGNoYXJyc2lkMzM0MjY5MiAgRG8geW91IGFudGljaXBhdGUgdGhlIG5lZWQgZm9y IHBhcnRpYWwgb3IgZnVsbCByZWltYnVyc2VtZW50IG9mIHRyYXZlbFxsaW5lIGV4cGVuc2VzP1xs aW5lIFsgXSBGdWxsIHJlaW1idXJzZW1lbnQgd2lsbCBiZSByZXF1aXJlZC4NXGxpbmUgWyBdIFBh cnRpYWwgcmVpbWJ1cnNlbWVudCB3aWxsIGJlIHJlcXVpcmVkLlxsaW5lIFsgXSBObyByZWltYnVy c2VtZW50IHdpbGwgYmUgcmVxdWlyZWQuXGxpbmUgXGxpbmUgXGxpbmUgfXtccnRsY2hcZmNzMSBc YWYwIFxsdHJjaFxmY3MwIFxiXGYxXGNmMTdcaW5zcnNpZDMzNDI2OTJcY2hhcnJzaWQzMzQyNjky IFNFQ1RJT04gRS4gQ29uc2VudCBhbmQgQXV0aG9yaXphdGlvbn17XHJ0bGNoXGZjczEgXGFmMCBc bHRyY2hcZmNzMCANXGYxXGNmMTdcaW5zcnNpZDMzNDI2OTJcY2hhcnJzaWQzMzQyNjkyIFxsaW5l IH17XHJ0bGNoXGZjczEgXGFmMCBcbHRyY2hcZmNzMCBcYlxmMVxjZjE3XGluc3JzaWQzMzQyNjky XGNoYXJyc2lkMzM0MjY5MiAoRS4xKX17XHJ0bGNoXGZjczEgXGFmMCBcbHRyY2hcZmNzMCBcZjFc Y2YxN1xpbnNyc2lkMzM0MjY5MlxjaGFycnNpZDMzNDI2OTIgDSBZb3UgYXV0aG9yaXplIElDQU5O IHRvIGludmVzdGlnYXRlIGluZm9ybWF0aW9uIHB1YmxpY2x5IGF2YWlsYWJsZSBhYm91dCB5b3Us XGxpbmUgYW5kIHRvIGNvbmR1Y3QgYWRkaXRpb25hbCB0aGlyZC1wYXJ0eSByZWZlcmVuY2UgY2hl Y2tzLiBZb3Ugd2lsbCBub3QgYmUgZW50aXRsZWQgdG9cbGluZSANcmV2aWV3IG9yIGFjY2VzcyBh bnkgb2YgdGhlIGluZm9ybWF0aW9uIHJlY2VpdmVkLCBvYnRhaW5lZCwgZ2VuZXJhdGVkLCBvciBj b25zaWRlcmVkXGxpbmUgYnkgSUNBTk4gcmVnYXJkaW5nIGFueSBDYW5kaWRhdGUgRGVzaWduIFRl YW0gbWVtYmVyLCBvciBhbnkgb2YgdGhlIFJaTVxsaW5lIHBhcnRuZXJzJyBkaXNjdXNzaW9ucyBv ciBkZWxpYmVyYXRpb25zIHJlZ2FyZGluZyBhbnkgQ2FuZGlkYXRlIERlc2lnbiBUZWFtXGxpbmUg DW1lbWJlci4gQ2FuZGlkYXRlIERlc2lnbiBUZWFtIG1lbWJlcnMgaGF2ZSBubyByaWdodCB0byBj aGFsbGVuZ2Ugb3Igc2Vla1xsaW5lIHJldmlldyBvZiB0aGUgUlpNIHBhcnRuZXJzJyBzZWxlY3Rp b25zLlxsaW5lIFdoZW4gdGhlIFJaTSBwYXJ0bmVycyBoYXZlIGNvbXBsZXRlZCB0aGVpciBzZWxl Y3Rpb25zLCB0aGV5IHdpbGwgcHVibGlzaCB0aGVcbGluZSANaWRlbnRpdGllcyBvZiB0aGUgU2Vs ZWN0ZWQgRGVzaWduIFRlYW0gbWVtYmVycyBhbmQgYWxsIENhbmRpZGF0ZXMgKHdoZXRoZXIgb3Ig bm90XGxpbmUgc2VsZWN0ZWQpLiBTdGF0aXN0aWNhbCBpbmZvcm1hdGlvbiwgc3VjaCBhcyB0aGUg c2l6ZSBhbmQgbmF0dXJlIG9mIHRoZSBjYW5kaWRhdGUgcG9vbCxcbGluZSBtYXkgYmUgcHVibGlz aGVkIGF0IHRoZSBjbG9zZSBvZiB0aGUgcHJvY2Vzcy59e1xydGxjaFxmY3MxIFxhZjAgXGx0cmNo XGZjczAgDVxiXGYxXGNmMTdcaW5zcnNpZDMzNDI2OTJcY2hhcnJzaWQzMzQyNjkyIA1ccGFyIH17 XHJ0bGNoXGZjczEgXGFmMCBcbHRyY2hcZmNzMCBcZjFcY2YxN1xpbnNyc2lkMzM0MjY5MlxjaGFy cnNpZDMzNDI2OTIgUGxlYXNlIGluZGljYXRlIHRoYXQgeW91IHVuZGVyc3RhbmQgdGhpcyBzdGF0 ZW1lbnQgKEUuMSkgYW5kIGFncmVlIHRvIGJlY29tZSBhXGxpbmUgY2FuZGlkYXRlIHVuZGVyIHRo ZSBjb25kaXRpb25zIGRlc2NyaWJlZCBhYm92ZS4gUGxlYXNlIGluZGljYXRlIFllcyBvciBObzoN XHBhciB9XHBhcmQgXGx0cnBhclxxbCBcbGkwXHJpMFxzYTI0MFx3aWRjdGxwYXJcd3JhcGRlZmF1 bHRcYXNwYWxwaGFcYXNwbnVtXGZhYXV0b1xhZGp1c3RyaWdodFxyaW4wXGxpbjBcaXRhcDBccGFy YXJzaWQzMzQyNjkyIHtccnRsY2hcZmNzMSBcYWYwIFxsdHJjaFxmY3MwIFxmMVxjZjE3XGluc3Jz aWQzMzQyNjkyXGNoYXJyc2lkMzM0MjY5MiANWyBdIFlFUywgSSB1bmRlcnN0YW5kIHRoaXMgc3Rh dGVtZW50IGFuZCBhZ3JlZSB0byB0aGVzZSBjb25kaXRpb25zXGxpbmUgWyBdIE5PLCBJIGRvIG5v dCBhZ3JlZSB0byB0aGVzZSBjb25kaXRpb25zDVxwYXIgfVxwYXJkIFxsdHJwYXJccWwgXGxpMFxy aTBcd2lkY3RscGFyXHdyYXBkZWZhdWx0XGFzcGFscGhhXGFzcG51bVxmYWF1dG9cYWRqdXN0cmln aHRccmluMFxsaW4wXGl0YXAwXHBhcmFyc2lkMzM0MjY5MiB7XHJ0bGNoXGZjczEgXGFmMCBcbHRy Y2hcZmNzMCBcZjFcY2YxN1xpbnNyc2lkMzM0MjY5MlxjaGFycnNpZDMzNDI2OTIgDVxwYXIgfXtc cnRsY2hcZmNzMSBcYWYwIFxsdHJjaFxmY3MwIFxiXGYxXGNmMTdcaW5zcnNpZDMzNDI2OTJcY2hh cnJzaWQzMzQyNjkyIChFLjIpfXtccnRsY2hcZmNzMSBcYWYwIFxsdHJjaFxmY3MwIFxmMVxjZjE3 XGluc3JzaWQzMzQyNjkyXGNoYXJyc2lkMzM0MjY5MiAgSW50ZXJpbSB2YWNhbmNpZXNcbGluZSBJ ZiB5b3UgYXJlIE5PVCBzZWxlY3RlZCBmb3IgdGhlIERlc2lnbiBUZWFtLCB3b3VsZCB5b3UgcGVy bWl0IHRoZSBSWk0gcGFydG5lcnMgdG8NXGxpbmUgcmV0YWluIHlvdXIgbmFtZSBhbmQgb3RoZXIg cmVsYXRlZCBpbmZvcm1hdGlvbiBmb3IgcG9zc2libGUgY29uc2lkZXJhdGlvbiBpbiB0aGVcbGlu ZSBldmVudCB0aGF0IGEgdmFjYW5jeSBvY2N1cnM/IFBsZWFzZSBpbmRpY2F0ZSBZZXMgb3IgTm86 XGxpbmUgWyBdIFlFU1xsaW5lIFsgXSBOTw1ccGFyIH1ccGFyZCBcbHRycGFyXHFsIFxsaTBccmkw XHdpZGN0bHBhclx3cmFwZGVmYXVsdFxhc3BhbHBoYVxhc3BudW1cZmFhdXRvXGFkanVzdHJpZ2h0 XHJpbjBcbGluMFxpdGFwMCB7XHJ0bGNoXGZjczEgXGFmMzE1MDcgXGx0cmNoXGZjczAgXGluc3Jz aWQzMDk0NzUxIA1ccGFyIH17XCpcdGhlbWVkYXRhIDUwNGIwMzA0MTQwMDA2MDAwODAwMDAwMDIx MDA5YmU4NzA0ZmZjMDAwMDAwMWMwMjAwMDAxMzAwMDAwMDViNDM2ZjZlNzQ2NTZlNzQ1ZjU0Nzk3 MDY1NzM1ZDJlNzg2ZDZjYWM5MWNiNmFjMzMwMTA0NWY3ODVmZTgzZDBiNmQ4DTcyYmEyOGE1ZDhj ZWEyOGY1ZDFmOGJmNDAzMDY3OTZjOGJkODIzMjE0ZDQyZjJmNzFkM2IyZTk0MTIwMjg1NmUwNGQy Y2NiZGY3Y2NhODVjMWZjNjQxZWQzMTI2ZTdhOWQyYWJiY2QwMGFjOWZhYzY1MTU3ZTljZmNkNGI3 NmFmDTU1NjJhMDA2MDY0ZjU4ZTkyMzI2YmRhZWFmYWZjYWNkMzE2MDUyYTJhNjU0ZTk5ZTM5M2Mx ODkzNmM4ZjIzYTRkYzA3MjRhOWI0M2U4ZWMwNzI4ZDlkMDk2MGI3ZDBhMWI5MmQ4YTNiNjMzZDMx MTI2NzNjNzllOGJhN2NjMjE2DTc2MDNhYmU3ODMzYzlmNDg0NGFlZDVlM2E5NmY4YWFhMzQ4NDMw MzgwYjJjYTA2NmFhOWFiM2JhODg0M2JhMjBkYzUzZjM4YjJlNWJjODcyNTFjZWU2YTk3NzIxZGQy YzA5ZWZiMjlhZTgxYTU0MWYxMGY5MGQ0NmUxMzAyYzQzDWUyY2ZmMzE1NDg0NjhiZjk2NWU2MzNk MWJlNmQ5ZGM1YzZkYmRkMjhlYmM4NjdlM2M1ZWM0ZjAwYWJmZjg5ZmVjZTM0ZjNkZmQ2NWYwMDAw MDBmZmZmMDMwMDUwNGIwMzA0MTQwMDA2MDAwODAwMDAwMDIxMDBhNWQ2YTdlN2MwDTAwMDAwMDM2 MDEwMDAwMGIwMDAwMDA1ZjcyNjU2YzczMmYyZTcyNjU2YzczODQ4ZmNmNmFjMzMwMGM4N2VmODVi ZDgzZDE3ZDUxZDJjMzE4MjU3NjJmYTU5MDQzMmZhMzdkMDBlMTI4N2Y2ODIyMWJkYjFiZWJkYjRm YzcwNjBhDWJiMDg4NGE0ZWZmN2E5M2RmZWFlOGJmOWUxOTRlNzIwMTY5YWFhMDZjM2UyNDMzZmNi NjhlMTc2M2RiZjdmODJjOTg1YTRhNzI1MDg1Yjc4NzA4NmEzN2JkYmI1NWZiYzUwZDFhMzNjY2Qz MTFiYTU0OGI2MzA5NTEyMGY4OGQ5DTRmYmM1MmFlNDI2NGQxYzkxMGQyNGE0NWRiMzQ2MjI0N2Zh NzkxNzE1ZmQ3MWY5ODllMTllMDM2NGNkM2Y1MTY1MmQ3Mzc2MGFlOGZhOGM5ZmZiM2MzMzBjYzll NGZjMTdmYWYyY2U1NDUwNDZlMzc5NDRjNjllNDYyYTFhODJmDWUzNTNiZDkwYTg2NWFhZDQxZWQw YjViOGY5ZDZmZDAxMDAwMGZmZmYwMzAwNTA0YjAzMDQxNDAwMDYwMDA4MDAwMDAwMjEwMDZiNzk5 NjE2ODMwMDAwMDA4YTAwMDAwMDFjMDAwMDAwNzQ2ODY1NmQ2NTJmNzQ2ODY1NmQ2NTJmDTc0Njg2 NTZkNjU0ZDYxNmU2MTY3NjU3MjJlNzg2ZDZjMGNjYzRkMGFjMzIwMTA0MGUxN2RhMTc3OTBkOTM3 NjNiYjI4NDU2MmIyY2JhZWJiZjYwMDQzOWMxYTQxYzdhMGQyOWZkYmQ3ZTVlMzgzMzdjZWRmMTRk NTliNGIwZDU5DTJjOWMwNzBkOGE2NWNkMmU4OGI3ZjA3YzJjYTcxYmE4ZGE0ODFjYzUyYzZjZTFj NzE1ZTZlOTc4MThjOWI0OGQxM2RmNDljODczNTE3ZDIzZDU5MDg1YWRiNWRkMjBkNmI1MmJkNTIx ZWYyY2RkNWViOTI0NmEzZDhiNDc1N2U4DWQzZjcyOWUyNDVlYjJiMjYwYTAyMzhmZDAxMDAwMGZm ZmYwMzAwNTA0YjAzMDQxNDAwMDYwMDA4MDAwMDAwMjEwMDIxNWFhMjg0MjEwNzAwMDBkYjFkMDAw MDE2MDAwMDAwNzQ2ODY1NmQ2NTJmNzQ2ODY1NmQ2NTJmNzQ2ODY1DTZkNjUzMTJlNzg2ZDZjZWM1 OTRmNmYxYjQ1MTRiZjIzZjExZDQ2N2IyZmIxMTMyNzRkYTIzYTU1ZWNkODBkYjQ2OWEzZDgyZGVh NzFiYzNiZjY0ZTMzYmJiMzlhMTkyN2YxMGRiNTQ3MjQyNDQ0NDExY2E4YzQ4ZDAzMDIyYWI1DTEy OTdmMjY5MDI0NTUwYTQ3ZTA1ZGVjY2VjYWU3N2UyNzE5Mzk0MDAxNTM0ODdkNjNiZmI3YjZmZGVm YmJkM2ZmMzY3YWY1YzNkNGExODNhMjA0MjUyOWUzNjgzZmE3YmI1MDA5MTM0ZTQxMTRkNDdjZGUw NzZiZjdiNjkzNTQwDTUyZTEzNGMyOGNhN2E0MTk0Yzg4MGNhZTZlYmNmYmNlMTViY2FlNjI5MjEw MDRmMmE5NWNjN2NkMjA1NjJhNWI1ZjU4OTAyMTBjNjNmOTFlY2Y0ODBhZWY4NjVjMjQ1OGMxYTMx ODJkNDQwMjFmODJkZTg0MmQyY2Q2NmEyYjBiDTA5YTY2OTgwNTI5YzgwZGE1YmMzMjEwZDA5ZWE2 Yjk1YzE0NmExYmNjM2UwMzE1NTUyMGY4NDRjZjRiNDZhZTI0ODE4NmNiNDVmZDcwODM5OTE2ZDI2 ZDAwMTY2Y2QwMGU2ODlmODYxOWYxY2E5MDAzMTJjMTViYzY4MDYzNWYzDTE3MmM2YzVjNTljMGVi YjkxMDUzNzM2NDJiNzI1ZGYzOTdjYmU1MDJkMWZlYTI5OTUzOGMwNmU1YTRmNTZlNjNlZGYyNTZh OWRmMDA5ODlhYzU3NTNhOWQ3NmE3NWVlYTMzMDAxYzg2ZTBhOWI1YTVhYWIzZDE1ZGFkYjcwYTlk DTE1OTBmZDM5YWJiYjVkNWJhZTM1NWM3YzQ1ZmZkMjhjY2Q2YmFkNTY2Yjc5MmRiN2M1MmEzNTIw ZmJiMzMxODM1ZmFkYWQzNDM2MTcxZGJjMDE1OWZjZjIwY2JlZDFkYTZjYjc1NzFjYmMwMTU5ZmNj YTBjYmU3Yjc5NmRhNWUxDWUyMGQyODY2MzRkZDlmNDFlYjgwNzZiYmI5ZjYxMjMyZTQ2Y2RiMGI1 ZjA1Zjg2YTJkODc0ZjUxOTAwZDY1NzZlOTI5ODYzYzU1ZjM3MjJkYzFmN2I4ZTgwMjQwMDMxOTU2 MzQ0NTZhOTI5MTIxMGUyMThiZGI5OGQxODFhMDdhDTAyYmM0ZTcwZTU4ZDFkMGFlNWNjOTA5ZTBi Yzk1MGQwNGMzNTgzMGYzMjBjMTUzMWQ1ZjdmMmQ5NzcyZjlmM2Q0MWM3Zjc5ZjFlZGZmZmYxZjhj MTgzZTNmYjNmNTg0NThlZDQzNjRlNDc1NWE5MTdkZjdjZmFjN2EzOGZkMGVmDTRmYmU3ZWYxZjA3 MzNmNWU1NmYxYmY3Y2ZmZjFjZjNmN2RlNjA3NDJmOTRjY2Q3OWZlYzVlMzVmOWYzZTdlZmVlNTI3 YmY3ZGZiZDAwM2RmMTQ3ODUwODVmNzY5NDIyNGJhNDkwZWQxMWU0ZmMwMzFjMzhhNmIzOTE5ODhm MzQ5DWY0NjM0Y2FiMTI5YmU5NDhlMjE0ZWI1OTNjZmEzYjJhNzZkMDM3Mjc5ODYxMGZhZTQ1NWMw NmVmMDg2ODFmM2VlMGI1ZjEzZGM3ZTA1ZTJjYzYyYThmYjdlM2Q5ZjUzODcxODAzYjljYjMxNjE3 NWUxNmFlZWJiOTJhMzRmN2M3DWU5YzgzZmI5MTg1NzcxN2IxODFmZjhlNjZlZTNkNDg5NmY2Nzlj NDFkZmE0M2U5NWVkOTgzODY2ZWUzMjljMmEzYzIyMjk1MTQ4YmZlM2ZiODQ3OGY4YmE0YmE5YzNl YjBlMGQwNTk3N2NhOGQwNWQ4YTVhOTg3YTI5ZTlkMzgxDTkzNGQ1M2ExNmQ5YTQwNWMyNjNlMDMy MWRlMGUzNzNiNzc1MDhiMzM5ZmQ3NWJlNGMwNDU0MjU1NjBlNjMxYmU0Zjk4NDNlMzM1M2M1NjM4 ZjFhOWVjZTM4NDU1MDliZjgxNTVlYzMzYjIzNzExNjExNWQ3OTEwYTIyM2QyMjhjDWEzNGU0NGE0 ZjRjOWRjMTJlMDZmMjVlOGQ3YTE3NWY4YzNiZWMzMjY4OThiMTQ4YWVlZmI3NGRlYzA5YzU3OTE1 YjdjYmYxZGUzMjRmMzYxN2IzNDhkYWJkOGY3ZTUzZWE0Mjg0NmJiNWNmOWUwM2JkY2FkMTBmZDBj NzFjMGU5DWRjNzBkZmExYzQwOWY3ZTlkZGUwMzYxZDM5MjY0ZDEzNDRiZjE5MGI0ZjJjYWYxMWVl ZTQ2ZjZmYzI4Njk4OTg1NjAzNGRkZGU5ZDUwOTRkNWZkNWI4MTNlOGRiYjllMzE3ZDdiOGExNTUz ZWZmZWE5MWM3ZWUzN2I1NjU2ZjAyDTA5YmU5YWQ5M2VkMWE4ZTdlMTRlYjZlNzM2MTcxMTdkZjNi YmYzMTYxZWE3YmIwNDBhNjI3Njg5N2FkYjljZGYzNmU3ZTAzZmRmOWNlN2Q1ZjNjNWI3ZTQ2OTE3 ODYwNmFkYjc0Yzc2YTM2ZGI2ZGRjOWRjNWRmNzkwMzJkNjUzDTEzNDY2ZTQ4YjNmMTk2YjBmNjQ0 NWQxOGQ0NzJlNmM0NDljYTUzNTgxNmMzNGY1ZGM5MzA4MTgzMWIwOTZjNjQ5MGUwZWE0M2FhZTI1 ZThjMzNkOGI0ZDcwM2FkNjQyNDczZDUyMzg5MzIyZWUxYjA2ODg2YmRiYTM1MWUzNmZlDWNhMWUz NTk3ZjUyMWM0NzYwZTg5ZDUwZThmZWNmMDkyMWUyZWNlMWFhNTFhNjNkNWM4MWM2ODhiODk5NmI0 ODJiMzRlYjY3NDM5NTcwYWJlYmRjZTY0NzU2ZGQ0OTk2N2FiMWJkMzRjNTM3NDY2MmI1ZGQ2MTQ5 YjQzMzk1MDVlDWJhMDY4MzI1OWJiMGE5NDFiMDE1MDI5NjU3ZTBjY2FmYTc4NmMzMGU2NjI0ZDJi Y2RiMTgxNTYxMzE1MWY4N2I0Mjk0N2I2ZDFkODk3MTQ0NmM4ODljZTEwYTliNzUxM2JiMjI4NTY2 ZmNkM2VlZDkxYzM5MWY5YjI1NmI0MGRhDWU5NDY5OGI0OTg5ZjNmNjcyNGI5NTAzMDI1MTkwNDRm NTYxMzRiYWJiNWM1NTI3NGQ4MGNkNjk2MTc5NzAzMTRlMmFjMTkwY2UxOTgwYjNmOTMwYzgyMjZm NTM2MTBiMzExZGMxNTg1NGFkOGFjM2RiNTE2NGQ5MTRlM2Q1ZWYzDTY3NTUxZDZlMmVlNjE0OGM1 M2M2OTk5MDZhMGJjYmQ4YzZkMGJjY2E0M2M1NTIzZDkzYjU3ZjcxYjlhMTkzZWQ2MjFjZjAzNDkz YjM1OWIxYjQwYTI5ZjJhZjU5MDFhMTc2NDM0Yjg2NDMxMmFhNmFiMDJiMjM5YTNiZmI5ODc3DTQy M2U1NjQ0ZjRlMmU4MTAwZGQ4NThlYzYxMDgzZjcwYWFmZDg5YTg4NGRiMGE1M2QwZmEwMWFlZDYz NGRiZTY5NWRiNWJmMzRlNTNiZGQwMzIzODNiOGU1OTE2ZTNiYzViZWFhYjk5YTJlMjJjZGNmNDkz ZDIwNmYzNTQzMTBmDTdjZjNkYTZlOWMzYmJmMmJiYWUyMmZjYTk1NmExYWZmY2Y1Y2QxY2IwMTVj MWUyYzQ1M2EwMjIxZGNlYzBhOGM3NGE1MzQwMzJlNTRjY2ExMGI2NTMxMGRiYjAyZDY3ZGQzM2Iy MDViZTA3YTE2NWUwM2Y5NzBiZjZjZmUxN2U0DTQwZmY2ZjZiY2VlYTMwNjUwZDY3NDBiNTQ3NDc0 ODUwNTg0ZTU0MmMwOGQ5ODViNjY0YjJlZjE0NjVmNTdjZTliMTJhNTlhZWM4NjQ1NGM1NWM5OTU5 YjMwN2U0ODBiMGJlZWU4MTJiYmEwNzA3Mjg4NjU0MzdkZDI0NmYwMzA2DTc3MzJmZmRjZTdiYzgy MDYyM2JkNDdhOWQ2OWJkM2M5Y2FhNWQzZDZjMDNmYmQ3MWIxYzUwYzRlOWRkODRiZThmYzJkZjgy ZjRkMmM1N2Y3ZTllYTY3ZTU4ZDc4YjE0NjU2MWRkMTJmYTZiYmE0NDY1MTE1Y2VlMmI3YjY5NjRm DWY1OWEyNjljNjUwMWFlYWNiNWI2NjNjZDc4YmNiODVjMTgwNzUxOWNmNTE4MDZjYmZkNGMwNjU3 NDA0OGZmMDNlYjFmMTUyMWIzMWYyYmY0ODJkYWU3N2JkMDViMTE3YzdiYjBmYzIxYzhlYTRiYmFh YjQxMDZlOTA2Njk3ZjBkDTYwZGY2MzA3NmQzMjY5NTU5NmRhN2NlN2EzNTkyYjE2ZWIwYmRlYTg5 NmYzOWUyMDViNWI3Njk2Nzg5ZjkzZWM3MjEzZTU0ZWU3ZDRlMjQ1OTI5ZDMzZWM3MDZkYzdlNjUy MGQ5MTNkNTlhMjMwMzQyY2NlMjEyNjMwZTYyYjU3DWY1NDMxNDFmZGM4MzQwNmZjMTk1ZmY5OGQ5 NGY1MzMyODMyNzUzMDdkOWFlMzBkOTM1ZTBkMTI0ZmZjOWE0NWQ3MDZkZDZlOTMzOGM0NmIyNzQ4 ZjBjMTE4ZDhlOGFmMzQ3Yzk4NDJkMjFmYjc5YTRkODIyMWJiNDE2ZDM4OTU2DTBhMmVmOTBlMGRh ZTYwOGVkN2EyNzZiNTJjODUxNzRmMTcyZTI1Y2NjY2QwYjI0YjYxNzM5N2U2NTMwMDFmYzdmMmM2 YWQ4Zjc2ODBiNzRkZDY3YWFkOGJhYjYwOGFhNTdmODViMjMzMThlZmE3Y2M3YmYyMzkyYjY1ZjZh MGY4DWNhNDBiZDA2NjVlYWU4ZDU5NGU1NGMwMTc5YjM4OTA3OWYzNzA1ODZhMzU3Y2ZmNDVmNTg3 NDZjYTY5Yjk0ZGRmODEzMDAwMGZmZmYwMzAwNTA0YjAzMDQxNDAwMDYwMDA4MDAwMDAwMjEwMDBk ZDE5MDlmYjYwMDAwMDAxYjAxDTAwMDAyNzAwMDAwMDc0Njg2NTZkNjUyZjc0Njg2NTZkNjUyZjVm NzI2NTZjNzMyZjc0Njg2NTZkNjU0ZDYxNmU2MTY3NjU3MjJlNzg2ZDZjMmU3MjY1NmM3Mzg0OGY0 ZDBhYzIzMDE0ODRmNzgyNzcwODZmNmZkM2JhMTA5MTI2DWRkODhkMGFkZDQwMzg0ZTQzNTBkMzYz ZjI0NTFlY2VkMGRhZTJjMDgyZTg3NjFiZTk5NjliYjk3OWRjOTEzNjMzMmRlMzE2OGFhMWEwODNh ZTk5NTcxOWFjMTZkYjhlYzhlNDA1MjE2NGU4OWQ5M2I2NGIwNjA4MjhlNmYzN2VkDTE1Njc5MTRi Mjg0ZDI2MjQ1MjI4MmUzMTk4NzIwZTI3NGE5MzljZDA4YTU0Zjk4MGFlMzhhMzhmNTZlNDIyYTNh NjQxYzhiYmQwNDhmNzc1N2RhMGYxOWIwMTdjYzUyNGJkNjIxMDdiZDUwMDE5OTY1MDlhZmZiM2Zk MzgxYTg5DTY3MmYxZjE2NWRmZTUxNDE3M2Q5ODUwNTI4YTJjNmNjZTAyMzliYWE0YzA0Y2E1YmJh YmFjNGRmMDAwMDAwZmZmZjAzMDA1MDRiMDEwMjJkMDAxNDAwMDYwMDA4MDAwMDAwMjEwMDliZTg3 MDRmZmMwMDAwMDAxYzAyMDAwMDEzDTAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA1 YjQzNmY2ZTc0NjU2ZTc0NWY1NDc5NzA2NTczNWQyZTc4NmQ2YzUwNGIwMTAyMmQwMDE0MDAwNjAw MDgwMDAwMDAyMTAwYTVkNmE3ZTdjMDAwMDAwMDM2MDEwMDAwDTBiMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAyZDAxMDAwMDVmNzI2NTZjNzMyZjJlNzI2NTZjNzM1MDRiMDEwMjJkMDAxNDAwMDYw MDA4MDAwMDAwMjEwMDZiNzk5NjE2ODMwMDAwMDA4YTAwMDAwMDFjMDAwMDAwMDAwMDAwDTAwMDAw MDAwMDAwMDAwMTYwMjAwMDA3NDY4NjU2ZDY1MmY3NDY4NjU2ZDY1MmY3NDY4NjU2ZDY1NGQ2MTZl NjE2NzY1NzIyZTc4NmQ2YzUwNGIwMTAyMmQwMDE0MDAwNjAwMDgwMDAwMDAyMTAwMjE1YWEyODQy MTA3MDAwMGRiDTFkMDAwMDE2MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDBkMzAyMDAwMDc0Njg2 NTZkNjUyZjc0Njg2NTZkNjUyZjc0Njg2NTZkNjUzMTJlNzg2ZDZjNTA0YjAxMDIyZDAwMTQwMDA2 MDAwODAwMDAwMDIxMDAwZGQxOTA5ZmI2DTAwMDAwMDFiMDEwMDAwMjcwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDI4MGEwMDAwNzQ2ODY1NmQ2NTJmNzQ2ODY1NmQ2NTJmNWY3MjY1NmM3MzJmNzQ2 ODY1NmQ2NTRkNjE2ZTYxNjc2NTcyMmU3ODZkNmMyZTcyNjU2YzczNTA0YjA1MDYwMDAwMDAwMDA1 MDAwNTAwNWQwMTAwMDAyMzBiMDAwMDAwMDB9DXtcKlxjb2xvcnNjaGVtZW1hcHBpbmcgM2MzZjc4 NmQ2YzIwNzY2NTcyNzM2OTZmNmUzZDIyMzEyZTMwMjIyMDY1NmU2MzZmNjQ2OTZlNjczZDIyNTU1 NDQ2MmQzODIyMjA3Mzc0NjE2ZTY0NjE2YzZmNmU2NTNkMjI3OTY1NzMyMjNmM2UwZDBhM2M2MTNh NjM2YzcyNGQNNjE3MDIwNzg2ZDZjNmU3MzNhNjEzZDIyNjg3NDc0NzAzYTJmMmY3MzYzNjg2NTZk NjE3MzJlNmY3MDY1NmU3ODZkNmM2NjZmNzI2ZDYxNzQ3MzJlNmY3MjY3MmY2NDcyNjE3NzY5NmU2 NzZkNmMyZjMyMzAzMDM2MmY2ZDYxNjkNNmUyMjIwNjI2NzMxM2QyMjZjNzQzMTIyMjA3NDc4MzEz ZDIyNjQ2YjMxMjIyMDYyNjczMjNkMjI2Yzc0MzIyMjIwNzQ3ODMyM2QyMjY0NmIzMjIyMjA2MTYz NjM2NTZlNzQzMTNkMjI2MTYzNjM2NTZlNzQzMTIyMjA2MTYzNjMNNjU2ZTc0MzIzZDIyNjE2MzYz NjU2ZTc0MzIyMjIwNjE2MzYzNjU2ZTc0MzMzZDIyNjE2MzYzNjU2ZTc0MzMyMjIwNjE2MzYzNjU2 ZTc0MzQzZDIyNjE2MzYzNjU2ZTc0MzQyMjIwNjE2MzYzNjU2ZTc0MzUzZDIyNjE2MzYzNjU2ZTc0 MzUyMjIwNjE2MzYzNjU2ZTc0MzYzZDIyNjE2MzYzNjU2ZTc0MzYyMjIwNjg2YzY5NmU2YjNkMjI2 ODZjNjk2ZTZiMjIyMDY2NmY2YzQ4NmM2OTZlNmIzZDIyNjY2ZjZjNDg2YzY5NmU2YjIyMmYzZX0N e1wqXGxhdGVudHN0eWxlc1xsc2RzdGltYXgyNzZcbHNkbG9ja2VkZGVmMFxsc2RzZW1paGlkZGVu ZGVmMVxsc2R1bmhpZGV1c2VkZGVmMVxsc2RxZm9ybWF0ZGVmMFxsc2Rwcmlvcml0eWRlZjk5e1xs c2Rsb2NrZWRleGNlcHQgXGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcWZvcm1h dDEgXGxzZHByaW9yaXR5MCBcbHNkbG9ja2VkMCBOb3JtYWw7DVxsc2RzZW1paGlkZGVuMCBcbHNk dW5oaWRldXNlZDAgXGxzZHFmb3JtYXQxIFxsc2Rwcmlvcml0eTkgXGxzZGxvY2tlZDAgaGVhZGlu ZyAxO1xsc2RxZm9ybWF0MSBcbHNkcHJpb3JpdHk5IFxsc2Rsb2NrZWQwIGhlYWRpbmcgMjtcbHNk cWZvcm1hdDEgXGxzZHByaW9yaXR5OSBcbHNkbG9ja2VkMCBoZWFkaW5nIDM7XGxzZHFmb3JtYXQx IFxsc2Rwcmlvcml0eTkgXGxzZGxvY2tlZDAgaGVhZGluZyA0Ow1cbHNkcWZvcm1hdDEgXGxzZHBy aW9yaXR5OSBcbHNkbG9ja2VkMCBoZWFkaW5nIDU7XGxzZHFmb3JtYXQxIFxsc2Rwcmlvcml0eTkg XGxzZGxvY2tlZDAgaGVhZGluZyA2O1xsc2RxZm9ybWF0MSBcbHNkcHJpb3JpdHk5IFxsc2Rsb2Nr ZWQwIGhlYWRpbmcgNztcbHNkcWZvcm1hdDEgXGxzZHByaW9yaXR5OSBcbHNkbG9ja2VkMCBoZWFk aW5nIDg7XGxzZHFmb3JtYXQxIFxsc2Rwcmlvcml0eTkgXGxzZGxvY2tlZDAgaGVhZGluZyA5Ow1c bHNkcHJpb3JpdHkzOSBcbHNkbG9ja2VkMCB0b2MgMTtcbHNkcHJpb3JpdHkzOSBcbHNkbG9ja2Vk MCB0b2MgMjtcbHNkcHJpb3JpdHkzOSBcbHNkbG9ja2VkMCB0b2MgMztcbHNkcHJpb3JpdHkzOSBc bHNkbG9ja2VkMCB0b2MgNDtcbHNkcHJpb3JpdHkzOSBcbHNkbG9ja2VkMCB0b2MgNTtcbHNkcHJp b3JpdHkzOSBcbHNkbG9ja2VkMCB0b2MgNjtcbHNkcHJpb3JpdHkzOSBcbHNkbG9ja2VkMCB0b2Mg NzsNXGxzZHByaW9yaXR5MzkgXGxzZGxvY2tlZDAgdG9jIDg7XGxzZHByaW9yaXR5MzkgXGxzZGxv Y2tlZDAgdG9jIDk7XGxzZHFmb3JtYXQxIFxsc2Rwcmlvcml0eTM1IFxsc2Rsb2NrZWQwIGNhcHRp b247XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcWZvcm1hdDEgXGxzZHByaW9y aXR5MTAgXGxzZGxvY2tlZDAgVGl0bGU7XGxzZHByaW9yaXR5MSBcbHNkbG9ja2VkMCBEZWZhdWx0 IFBhcmFncmFwaCBGb250Ow1cbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2RxZm9y bWF0MSBcbHNkcHJpb3JpdHkxMSBcbHNkbG9ja2VkMCBTdWJ0aXRsZTtcbHNkc2VtaWhpZGRlbjAg XGxzZHVuaGlkZXVzZWQwIFxsc2RxZm9ybWF0MSBcbHNkcHJpb3JpdHkyMiBcbHNkbG9ja2VkMCBT dHJvbmc7XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcWZvcm1hdDEgXGxzZHBy aW9yaXR5MjAgXGxzZGxvY2tlZDAgRW1waGFzaXM7DVxsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRl dXNlZDAgXGxzZHByaW9yaXR5NTkgXGxzZGxvY2tlZDAgVGFibGUgR3JpZDtcbHNkdW5oaWRldXNl ZDAgXGxzZGxvY2tlZDAgUGxhY2Vob2xkZXIgVGV4dDtcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlk ZXVzZWQwIFxsc2RxZm9ybWF0MSBcbHNkcHJpb3JpdHkxIFxsc2Rsb2NrZWQwIE5vIFNwYWNpbmc7 DVxsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NjAgXGxzZGxvY2tl ZDAgTGlnaHQgU2hhZGluZztcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlv cml0eTYxIFxsc2Rsb2NrZWQwIExpZ2h0IExpc3Q7XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1 c2VkMCBcbHNkcHJpb3JpdHk2MiBcbHNkbG9ja2VkMCBMaWdodCBHcmlkOw1cbHNkc2VtaWhpZGRl bjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTYzIFxsc2Rsb2NrZWQwIE1lZGl1bSBTaGFk aW5nIDE7XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2NCBcbHNk bG9ja2VkMCBNZWRpdW0gU2hhZGluZyAyO1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAg XGxzZHByaW9yaXR5NjUgXGxzZGxvY2tlZDAgTWVkaXVtIExpc3QgMTsNXGxzZHNlbWloaWRkZW4w IFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2NiBcbHNkbG9ja2VkMCBNZWRpdW0gTGlzdCAy O1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NjcgXGxzZGxvY2tl ZDAgTWVkaXVtIEdyaWQgMTtcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlv cml0eTY4IFxsc2Rsb2NrZWQwIE1lZGl1bSBHcmlkIDI7DVxsc2RzZW1paGlkZGVuMCBcbHNkdW5o aWRldXNlZDAgXGxzZHByaW9yaXR5NjkgXGxzZGxvY2tlZDAgTWVkaXVtIEdyaWQgMztcbHNkc2Vt aWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTcwIFxsc2Rsb2NrZWQwIERhcmsg TGlzdDtcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTcxIFxsc2Rs b2NrZWQwIENvbG9yZnVsIFNoYWRpbmc7DVxsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAg XGxzZHByaW9yaXR5NzIgXGxzZGxvY2tlZDAgQ29sb3JmdWwgTGlzdDtcbHNkc2VtaWhpZGRlbjAg XGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTczIFxsc2Rsb2NrZWQwIENvbG9yZnVsIEdyaWQ7 XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2MCBcbHNkbG9ja2Vk MCBMaWdodCBTaGFkaW5nIEFjY2VudCAxOw1cbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQw IFxsc2Rwcmlvcml0eTYxIFxsc2Rsb2NrZWQwIExpZ2h0IExpc3QgQWNjZW50IDE7XGxzZHNlbWlo aWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2MiBcbHNkbG9ja2VkMCBMaWdodCBH cmlkIEFjY2VudCAxO1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5 NjMgXGxzZGxvY2tlZDAgTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMTsNXGxzZHNlbWloaWRkZW4w IFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2NCBcbHNkbG9ja2VkMCBNZWRpdW0gU2hhZGlu ZyAyIEFjY2VudCAxO1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5 NjUgXGxzZGxvY2tlZDAgTWVkaXVtIExpc3QgMSBBY2NlbnQgMTtcbHNkdW5oaWRldXNlZDAgXGxz ZGxvY2tlZDAgUmV2aXNpb247DVxsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHFm b3JtYXQxIFxsc2Rwcmlvcml0eTM0IFxsc2Rsb2NrZWQwIExpc3QgUGFyYWdyYXBoO1xsc2RzZW1p aGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHFmb3JtYXQxIFxsc2Rwcmlvcml0eTI5IFxsc2Rs b2NrZWQwIFF1b3RlO1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHFmb3JtYXQx IFxsc2Rwcmlvcml0eTMwIFxsc2Rsb2NrZWQwIEludGVuc2UgUXVvdGU7DVxsc2RzZW1paGlkZGVu MCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NjYgXGxzZGxvY2tlZDAgTWVkaXVtIExpc3Qg MiBBY2NlbnQgMTtcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTY3 IFxsc2Rsb2NrZWQwIE1lZGl1bSBHcmlkIDEgQWNjZW50IDE7XGxzZHNlbWloaWRkZW4wIFxsc2R1 bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2OCBcbHNkbG9ja2VkMCBNZWRpdW0gR3JpZCAyIEFjY2Vu dCAxOw1cbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTY5IFxsc2Rs b2NrZWQwIE1lZGl1bSBHcmlkIDMgQWNjZW50IDE7XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1 c2VkMCBcbHNkcHJpb3JpdHk3MCBcbHNkbG9ja2VkMCBEYXJrIExpc3QgQWNjZW50IDE7XGxzZHNl bWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk3MSBcbHNkbG9ja2VkMCBDb2xv cmZ1bCBTaGFkaW5nIEFjY2VudCAxOw1cbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxs c2Rwcmlvcml0eTcyIFxsc2Rsb2NrZWQwIENvbG9yZnVsIExpc3QgQWNjZW50IDE7XGxzZHNlbWlo aWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk3MyBcbHNkbG9ja2VkMCBDb2xvcmZ1 bCBHcmlkIEFjY2VudCAxO1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9y aXR5NjAgXGxzZGxvY2tlZDAgTGlnaHQgU2hhZGluZyBBY2NlbnQgMjsNXGxzZHNlbWloaWRkZW4w IFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2MSBcbHNkbG9ja2VkMCBMaWdodCBMaXN0IEFj Y2VudCAyO1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NjIgXGxz ZGxvY2tlZDAgTGlnaHQgR3JpZCBBY2NlbnQgMjtcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVz ZWQwIFxsc2Rwcmlvcml0eTYzIFxsc2Rsb2NrZWQwIE1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDI7 DVxsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NjQgXGxzZGxvY2tl ZDAgTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMjtcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVz ZWQwIFxsc2Rwcmlvcml0eTY1IFxsc2Rsb2NrZWQwIE1lZGl1bSBMaXN0IDEgQWNjZW50IDI7XGxz ZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2NiBcbHNkbG9ja2VkMCBN ZWRpdW0gTGlzdCAyIEFjY2VudCAyOw1cbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxs c2Rwcmlvcml0eTY3IFxsc2Rsb2NrZWQwIE1lZGl1bSBHcmlkIDEgQWNjZW50IDI7XGxzZHNlbWlo aWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2OCBcbHNkbG9ja2VkMCBNZWRpdW0g R3JpZCAyIEFjY2VudCAyO1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9y aXR5NjkgXGxzZGxvY2tlZDAgTWVkaXVtIEdyaWQgMyBBY2NlbnQgMjsNXGxzZHNlbWloaWRkZW4w IFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk3MCBcbHNkbG9ja2VkMCBEYXJrIExpc3QgQWNj ZW50IDI7XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk3MSBcbHNk bG9ja2VkMCBDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAyO1xsc2RzZW1paGlkZGVuMCBcbHNkdW5o aWRldXNlZDAgXGxzZHByaW9yaXR5NzIgXGxzZGxvY2tlZDAgQ29sb3JmdWwgTGlzdCBBY2NlbnQg MjsNXGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk3MyBcbHNkbG9j a2VkMCBDb2xvcmZ1bCBHcmlkIEFjY2VudCAyO1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNl ZDAgXGxzZHByaW9yaXR5NjAgXGxzZGxvY2tlZDAgTGlnaHQgU2hhZGluZyBBY2NlbnQgMztcbHNk c2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTYxIFxsc2Rsb2NrZWQwIExp Z2h0IExpc3QgQWNjZW50IDM7DVxsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHBy aW9yaXR5NjIgXGxzZGxvY2tlZDAgTGlnaHQgR3JpZCBBY2NlbnQgMztcbHNkc2VtaWhpZGRlbjAg XGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTYzIFxsc2Rsb2NrZWQwIE1lZGl1bSBTaGFkaW5n IDEgQWNjZW50IDM7XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2 NCBcbHNkbG9ja2VkMCBNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAzOw1cbHNkc2VtaWhpZGRlbjAg XGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTY1IFxsc2Rsb2NrZWQwIE1lZGl1bSBMaXN0IDEg QWNjZW50IDM7XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2NiBc bHNkbG9ja2VkMCBNZWRpdW0gTGlzdCAyIEFjY2VudCAzO1xsc2RzZW1paGlkZGVuMCBcbHNkdW5o aWRldXNlZDAgXGxzZHByaW9yaXR5NjcgXGxzZGxvY2tlZDAgTWVkaXVtIEdyaWQgMSBBY2NlbnQg MzsNXGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2OCBcbHNkbG9j a2VkMCBNZWRpdW0gR3JpZCAyIEFjY2VudCAzO1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNl ZDAgXGxzZHByaW9yaXR5NjkgXGxzZGxvY2tlZDAgTWVkaXVtIEdyaWQgMyBBY2NlbnQgMztcbHNk c2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTcwIFxsc2Rsb2NrZWQwIERh cmsgTGlzdCBBY2NlbnQgMzsNXGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJp b3JpdHk3MSBcbHNkbG9ja2VkMCBDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzO1xsc2RzZW1paGlk ZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NzIgXGxzZGxvY2tlZDAgQ29sb3JmdWwg TGlzdCBBY2NlbnQgMztcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0 eTczIFxsc2Rsb2NrZWQwIENvbG9yZnVsIEdyaWQgQWNjZW50IDM7DVxsc2RzZW1paGlkZGVuMCBc bHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NjAgXGxzZGxvY2tlZDAgTGlnaHQgU2hhZGluZyBB Y2NlbnQgNDtcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTYxIFxs c2Rsb2NrZWQwIExpZ2h0IExpc3QgQWNjZW50IDQ7XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1 c2VkMCBcbHNkcHJpb3JpdHk2MiBcbHNkbG9ja2VkMCBMaWdodCBHcmlkIEFjY2VudCA0Ow1cbHNk c2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTYzIFxsc2Rsb2NrZWQwIE1l ZGl1bSBTaGFkaW5nIDEgQWNjZW50IDQ7XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBc bHNkcHJpb3JpdHk2NCBcbHNkbG9ja2VkMCBNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA0O1xsc2Rz ZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NjUgXGxzZGxvY2tlZDAgTWVk aXVtIExpc3QgMSBBY2NlbnQgNDsNXGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNk cHJpb3JpdHk2NiBcbHNkbG9ja2VkMCBNZWRpdW0gTGlzdCAyIEFjY2VudCA0O1xsc2RzZW1paGlk ZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NjcgXGxzZGxvY2tlZDAgTWVkaXVtIEdy aWQgMSBBY2NlbnQgNDtcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0 eTY4IFxsc2Rsb2NrZWQwIE1lZGl1bSBHcmlkIDIgQWNjZW50IDQ7DVxsc2RzZW1paGlkZGVuMCBc bHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NjkgXGxzZGxvY2tlZDAgTWVkaXVtIEdyaWQgMyBB Y2NlbnQgNDtcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTcwIFxs c2Rsb2NrZWQwIERhcmsgTGlzdCBBY2NlbnQgNDtcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVz ZWQwIFxsc2Rwcmlvcml0eTcxIFxsc2Rsb2NrZWQwIENvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQ7 DVxsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NzIgXGxzZGxvY2tl ZDAgQ29sb3JmdWwgTGlzdCBBY2NlbnQgNDtcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQw IFxsc2Rwcmlvcml0eTczIFxsc2Rsb2NrZWQwIENvbG9yZnVsIEdyaWQgQWNjZW50IDQ7XGxzZHNl bWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2MCBcbHNkbG9ja2VkMCBMaWdo dCBTaGFkaW5nIEFjY2VudCA1Ow1cbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rw cmlvcml0eTYxIFxsc2Rsb2NrZWQwIExpZ2h0IExpc3QgQWNjZW50IDU7XGxzZHNlbWloaWRkZW4w IFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2MiBcbHNkbG9ja2VkMCBMaWdodCBHcmlkIEFj Y2VudCA1O1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NjMgXGxz ZGxvY2tlZDAgTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNTsNXGxzZHNlbWloaWRkZW4wIFxsc2R1 bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2NCBcbHNkbG9ja2VkMCBNZWRpdW0gU2hhZGluZyAyIEFj Y2VudCA1O1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NjUgXGxz ZGxvY2tlZDAgTWVkaXVtIExpc3QgMSBBY2NlbnQgNTtcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlk ZXVzZWQwIFxsc2Rwcmlvcml0eTY2IFxsc2Rsb2NrZWQwIE1lZGl1bSBMaXN0IDIgQWNjZW50IDU7 DVxsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NjcgXGxzZGxvY2tl ZDAgTWVkaXVtIEdyaWQgMSBBY2NlbnQgNTtcbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQw IFxsc2Rwcmlvcml0eTY4IFxsc2Rsb2NrZWQwIE1lZGl1bSBHcmlkIDIgQWNjZW50IDU7XGxzZHNl bWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2OSBcbHNkbG9ja2VkMCBNZWRp dW0gR3JpZCAzIEFjY2VudCA1Ow1cbHNkc2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rw cmlvcml0eTcwIFxsc2Rsb2NrZWQwIERhcmsgTGlzdCBBY2NlbnQgNTtcbHNkc2VtaWhpZGRlbjAg XGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTcxIFxsc2Rsb2NrZWQwIENvbG9yZnVsIFNoYWRp bmcgQWNjZW50IDU7XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk3 MiBcbHNkbG9ja2VkMCBDb2xvcmZ1bCBMaXN0IEFjY2VudCA1Ow1cbHNkc2VtaWhpZGRlbjAgXGxz ZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTczIFxsc2Rsb2NrZWQwIENvbG9yZnVsIEdyaWQgQWNj ZW50IDU7XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2MCBcbHNk bG9ja2VkMCBMaWdodCBTaGFkaW5nIEFjY2VudCA2O1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRl dXNlZDAgXGxzZHByaW9yaXR5NjEgXGxzZGxvY2tlZDAgTGlnaHQgTGlzdCBBY2NlbnQgNjsNXGxz ZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2MiBcbHNkbG9ja2VkMCBM aWdodCBHcmlkIEFjY2VudCA2O1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHBy aW9yaXR5NjMgXGxzZGxvY2tlZDAgTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNjtcbHNkc2VtaWhp ZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTY0IFxsc2Rsb2NrZWQwIE1lZGl1bSBT aGFkaW5nIDIgQWNjZW50IDY7DVxsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHBy aW9yaXR5NjUgXGxzZGxvY2tlZDAgTWVkaXVtIExpc3QgMSBBY2NlbnQgNjtcbHNkc2VtaWhpZGRl bjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTY2IFxsc2Rsb2NrZWQwIE1lZGl1bSBMaXN0 IDIgQWNjZW50IDY7XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2 NyBcbHNkbG9ja2VkMCBNZWRpdW0gR3JpZCAxIEFjY2VudCA2Ow1cbHNkc2VtaWhpZGRlbjAgXGxz ZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTY4IFxsc2Rsb2NrZWQwIE1lZGl1bSBHcmlkIDIgQWNj ZW50IDY7XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcHJpb3JpdHk2OSBcbHNk bG9ja2VkMCBNZWRpdW0gR3JpZCAzIEFjY2VudCA2O1xsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRl dXNlZDAgXGxzZHByaW9yaXR5NzAgXGxzZGxvY2tlZDAgRGFyayBMaXN0IEFjY2VudCA2Ow1cbHNk c2VtaWhpZGRlbjAgXGxzZHVuaGlkZXVzZWQwIFxsc2Rwcmlvcml0eTcxIFxsc2Rsb2NrZWQwIENv bG9yZnVsIFNoYWRpbmcgQWNjZW50IDY7XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBc bHNkcHJpb3JpdHk3MiBcbHNkbG9ja2VkMCBDb2xvcmZ1bCBMaXN0IEFjY2VudCA2O1xsc2RzZW1p aGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHByaW9yaXR5NzMgXGxzZGxvY2tlZDAgQ29sb3Jm dWwgR3JpZCBBY2NlbnQgNjsNXGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcWZv cm1hdDEgXGxzZHByaW9yaXR5MTkgXGxzZGxvY2tlZDAgU3VidGxlIEVtcGhhc2lzO1xsc2RzZW1p aGlkZGVuMCBcbHNkdW5oaWRldXNlZDAgXGxzZHFmb3JtYXQxIFxsc2Rwcmlvcml0eTIxIFxsc2Rs b2NrZWQwIEludGVuc2UgRW1waGFzaXM7DVxsc2RzZW1paGlkZGVuMCBcbHNkdW5oaWRldXNlZDAg XGxzZHFmb3JtYXQxIFxsc2Rwcmlvcml0eTMxIFxsc2Rsb2NrZWQwIFN1YnRsZSBSZWZlcmVuY2U7 XGxzZHNlbWloaWRkZW4wIFxsc2R1bmhpZGV1c2VkMCBcbHNkcWZvcm1hdDEgXGxzZHByaW9yaXR5 MzIgXGxzZGxvY2tlZDAgSW50ZW5zZSBSZWZlcmVuY2U7DVxsc2RzZW1paGlkZGVuMCBcbHNkdW5o aWRldXNlZDAgXGxzZHFmb3JtYXQxIFxsc2Rwcmlvcml0eTMzIFxsc2Rsb2NrZWQwIEJvb2sgVGl0 bGU7XGxzZHByaW9yaXR5MzcgXGxzZGxvY2tlZDAgQmlibGlvZ3JhcGh5O1xsc2RxZm9ybWF0MSBc bHNkcHJpb3JpdHkzOSBcbHNkbG9ja2VkMCBUT0MgSGVhZGluZzt9fXtcKlxkYXRhc3RvcmUgMDEw MDAxMDAwMjAwMDAwMDA4MDAwMDAwNTU2ZTZiNmU2Zjc3NmUwMDAwMDAwMDAwMDAwMDAwMDAwMDA2 MDAwMA1kMGNmMTFlMGExYjExYWUxMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzZTAw MDMwMGZlZmYwOTAwMDYwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDEwMDAwMDAwMTAwMDAwMDAwMDAw MDAwMDAxMDAwMDBmZWZmZmZmZjAwMDAwMDAwZmVmZmZmZmYwMDAwMDAwMDAwMDAwMDAwZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmYNZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmDWZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZg1mZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmYNZmZmZmZmZmZm ZmZmZmZmZmZkZmZmZmZmZmVmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmDWZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZg1mZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmYNZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmDWZmZmZmZmZmZmZmZmZmZmZmZmZmZmZm ZmZmZmZmZmZmNTIwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMjAwMDUwMGZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZjBj NmFkOTg4OTJmMWQ0MTFhNjVmMDA0MDk2MzI1MWU1MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwODE3 Mw02ZjkwOTMxOGQwMDFmZWZmZmZmZjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDANMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDBmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmYw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwDTAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMGZmZmZmZmZmZmZmZmZmZmZmZmZmZmZmZjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMA0wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMTAwMDEwMDAwMDAwMDAwfX0= --f46d04428d1211c0dc050a454a3e-- From nobody Tue Dec 16 01:19:54 2014 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 01EB11A90DC for ; Tue, 16 Dec 2014 01:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 VCs55dyT-Lfl for ; Tue, 16 Dec 2014 01:19:46 -0800 (PST) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 617171ACD42 for ; Tue, 16 Dec 2014 01:19:45 -0800 (PST) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=hMeeRIepcuLueiL+dWeF/HEKA/JIa1Wu1WqNRPv0xqFPIGS0Wr4LrvhF yHQm1SRm/D7VxCY3acxHUpYmJJ2NzIRudP1biTTqsS555K409CiSdGntt RPZq9cTuis0pmfRhq8oWla0pylX0Ap8mPy3gL39xTEkeeAm8weRzVNrTl Ko3piNbX8idYC08R+OO67rGQymmfcpWvvd+1mY8gshfIrNBV/A1jiRNq6 4F4PyxWEjtnvIe01sPAr8JAAZ1R/0; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1418721586; x=1450257586; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v1AwPqOtrdOve07O0lBtmR9vhuoFverM7ZD8JZ5a2FI=; b=fujj8teWIb1Ay1HjmsFG0/I3LhgBGBvJO2vd8h0kfRTUDeQodDThuVsI h4YIXWf2hKhaiEYi3/8qKz0dvg3/WG1zNgGzAKDv7nDNPwMx5NphGsfeq ub0wpu2IlaESsTgbZhxlyXoab7QoSP8SRERn6t3k0rvc40g3g7evssO9W 1ZLUHdyG7RME6G6ihsgiMnnpyLPx4heqT2Sx3V9XmDRj44vCwhsmvGqRc XT/X0hxWVZSnks1ZMxtjhPPS2GiIp; X-IronPort-AV: E=Sophos;i="5.07,585,1413241200"; d="scan'208";a="14610610" X-IPAS-Result: AoQFAPD3j1TV+MWR/2dsb2JhbABagmQigSoEy2QCgRwWAQEBAQEBfIQMAQEBAQIBOhkmBQsCAQgYHhAyJQIEDgWIJAkD1FABAQEBBgEBAQEBAQEBAQEBF48/MweDFoETBZd8hQ+LHyKDbG6BAwU9fgEBAQ Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 16 Dec 2014 09:19:44 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%16]) with mapi id 14.03.0181.006; Tue, 16 Dec 2014 09:19:44 +0000 From: Ray Bellis To: Paul Hoffman Thread-Topic: [dnsext] Middleboxes and EDNS(0) Thread-Index: AQHQF+2aIOsBJUtIFk+bLbYVSsNPQpyPrr8AgAEemICAASWogA== Date: Tue, 16 Dec 2014 09:19:43 +0000 Message-ID: References: <64670FEB-4AF3-4014-ABF3-95C7249E08EE@vpnc.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/MUZj3fu1xwVXorkgTOqEiqeI_cc Cc: DNSEXT Group Working Subject: Re: [dnsext] Middleboxes and EDNS(0) 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: Tue, 16 Dec 2014 09:19:50 -0000 > On 15 Dec 2014, at 15:48, Paul Hoffman wrote: >>=20 > The problem is that the first quote is in a section called "6.1.1. Basic= Elements". This seems, well, basic. >=20 > So, is this an errata for the first quote? >=20 I wouldn't say the first quote is incorrect - a protocol-savvy forwarder (e= .g. BIND configured as a forwarder) _should_ strip EDNS options and insert = its own. IMHO the fault is in the working of the second quote, where the word "forwa= rder" has been used again, but in practise should probably have read "proxy= ". I believe it was intended to be a nod towards this from Section 3 of RF= C 5625: "The role of the proxy should therefore be no more and no less than to receive DNS requests from clients on the LAN side, forward those verbatim to one of the known upstream recursive resolvers on the WAN side, and ensure that the whole response is returned verbatim to the original client. It is RECOMMENDED that proxies should be as transparent as possible, such that any "hop-by-hop" mechanisms or newly introduced protocol extensions operate as if the proxy were not there." Ray From nobody Thu Dec 18 20:30:33 2014 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 24A431A913E for ; Thu, 18 Dec 2014 20:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 DGIX0A81s3zx for ; Thu, 18 Dec 2014 20:30:28 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0763.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:763]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6792E1A0140 for ; Thu, 18 Dec 2014 20:30:28 -0800 (PST) Received: from BY2PR03CA044.namprd03.prod.outlook.com (10.141.249.17) by BY1PR0301MB1205.namprd03.prod.outlook.com (25.161.203.154) with Microsoft SMTP Server (TLS) id 15.1.36.22; Fri, 19 Dec 2014 04:30:04 +0000 Received: from BY2FFO11FD054.protection.gbl (2a01:111:f400:7c0c::115) by BY2PR03CA044.outlook.office365.com (2a01:111:e400:2c5d::17) with Microsoft SMTP Server (TLS) id 15.1.49.12 via Frontend Transport; Fri, 19 Dec 2014 04:30:03 +0000 Received: from 064-smtp-out.microsoft.com (206.191.249.100) by BY2FFO11FD054.mail.protection.outlook.com (10.1.15.191) with Microsoft SMTP Server (TLS) id 15.1.26.17 via Frontend Transport; Fri, 19 Dec 2014 04:30:01 +0000 Received: from SINPRD3002HT003.064d.mgd.msft.net (141.251.55.16) by AM3PR30MB019.064d.mgd.msft.net (141.251.50.84) with Microsoft SMTP Server (TLS) id 15.1.36.23; Fri, 19 Dec 2014 04:29:55 +0000 Received: from SINPRD3002MB024.064d.mgd.msft.net ([169.254.5.99]) by SINPRD3002HT003.064d.mgd.msft.net ([141.251.55.16]) with mapi id 14.16.0472.000; Fri, 19 Dec 2014 04:29:32 +0000 From: Kumar Ashutosh To: Warren Kumari , Paul Hoffman Thread-Topic: [dnsext] Middleboxes and EDNS(0) Thread-Index: AQHQF+2Y24lKePOpGkWMTwMzIXSX5pyQ8UYAgAVmGTA= Date: Fri, 19 Dec 2014 04:29:32 +0000 Message-ID: <9A8CF5EF94B2EB4D8C90D69BC0E0F6A9144F7AA2@SINPRD3002MB024.064d.mgd.msft.net> References: <64670FEB-4AF3-4014-ABF3-95C7249E08EE@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [49.205.71.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 Received-SPF: Fail (protection.outlook.com: domain of microsoft.com does not designate 206.191.249.100 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.249.100; helo=064-smtp-out.microsoft.com; Authentication-Results: spf=fail (sender IP is 206.191.249.100) smtp.mailfrom=askuma@microsoft.com; X-Forefront-Antispam-Report: CIP:206.191.249.100; CTRY:US; IPV:CAL; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(339900001)(189002)(24454002)(51444003)(377454003)(51704005)(199003)(13464003)(47776003)(85426001)(86146001)(50466002)(4396001)(20776003)(84676001)(87936001)(64706001)(66066001)(55846006)(46406003)(106466001)(23726002)(19580395003)(2656002)(69596002)(81156004)(107046002)(2920100001)(105606002)(2950100001)(102836002)(97736003)(68736005)(97756001)(106116001)(15975445007)(2900100001)(16796002)(31966008)(46102003)(120916001)(26826002)(62966003)(19580405001)(54356999)(6806004)(76176999)(50986999)(86362001)(77156002)(99396003)(33656002)(92566001)(86612001)(21056001)(372894003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0301MB1205; H:064-smtp-out.microsoft.com; FPR:; SPF:Fail; MLV:ovrnspm; PTR:ErrorRetry; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR0301MB1205; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BY1PR0301MB1205; X-Forefront-PRVS: 0430FA5CB7 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:; SRVR:BY1PR0301MB1205; X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2014 04:30:01.8018 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.249.100] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0301MB1205 Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/9SL1NpT4RuV8FI9hysu751TjQRA Cc: DNSEXT Group Working Subject: Re: [dnsext] Middleboxes and EDNS(0) 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: Fri, 19 Dec 2014 04:30:31 -0000 I had a tough time interpreting this as well. Finally closed in on: If DNS gets OPT RR (A) in an incoming packet, it will return back the same = OPT RR in the final response back to the sender. If it needs to forward the query, DNS can chose to add new OPT RR as requir= ed for its own needs. There is no mandate on the DNS server to keep the or= iginal OPT RR. (needless to say the received and sent OPT RR can be also chosen to be same= ) Ashu Microsoft -----Original Message----- From: dnsext [mailto:dnsext-bounces@ietf.org] On Behalf Of Warren Kumari Sent: Monday, December 15, 2014 23:27 To: Paul Hoffman Cc: DNSEXT Group Working Subject: Re: [dnsext] Middleboxes and EDNS(0) On Sun, Dec 14, 2014 at 5:30 PM, Paul Hoffman wrote= : > Greetings again. Section 6.1.1.1 of RFC 6891 says: > > OPT RRs MUST NOT be cached, > forwarded, or stored in or loaded from master files. > > Section 6.2.6 says: > > Middleboxes that simply forward requests to a recursive resolver MUST > NOT modify and MUST NOT delete the OPT record contents in either > direction. > > If I'm a middlebox that is acting as a DNS forwarder, and I see an OPT RR= on a query coming in my left side, what do I send that OPT RR out the righ= t side? Do I follow the first or the second quote? Based on observation, if you are a middlebox that is acting as a DNS forwar= der, and you see an OPT RR on a query coming in your left side, you arbitra= rily choose between: A: the first B: the second C: a very small rock named Edgar. I think that the Section 6.2.6 is more correct, but middleboxes seem to tak= e perverse pleasure in ignoring "correct" as it related to the DNS.... W > > --Paul Hoffman > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- 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 regr= et at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext From nobody Fri Dec 19 05:12:33 2014 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 29BE61A914A for ; Fri, 19 Dec 2014 05:12:31 -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, 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 1jLt98fllF0s for ; Fri, 19 Dec 2014 05:12:30 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 E47201A901E for ; Fri, 19 Dec 2014 05:12:29 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id BBACBDA010C for ; Fri, 19 Dec 2014 13:12:43 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id A12D853E084; Fri, 19 Dec 2014 05:11:59 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 19 Dec 2014 05:11:59 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <9A8CF5EF94B2EB4D8C90D69BC0E0F6A9144F7AA2@SINPRD3002MB024.064d.mgd.msft.net> Date: Fri, 19 Dec 2014 08:11:38 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <64670FEB-4AF3-4014-ABF3-95C7249E08EE@vpnc.org> <9A8CF5EF94B2EB4D8C90D69BC0E0F6A9144F7AA2@SINPRD3002MB024.064d.mgd.msft.net> To: Kumar Ashutosh X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/6MsK2Z3Dc9TToSUeGchGImKNhTA Cc: Paul Hoffman , DNSEXT Group Working Subject: Re: [dnsext] Middleboxes and EDNS(0) 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: Fri, 19 Dec 2014 13:12:31 -0000 On Dec 18, 2014, at 11:29 PM, Kumar Ashutosh = wrote: > If DNS gets OPT RR (A) in an incoming packet, it will return back the = same OPT RR in the final response back to the sender. No, that's not what the text says. If you read the whole section, it = says that if the middlebox isn't being intelligent about what's in the = OPT RR, it should forward it without modification. If it is = intelligent, it is assumed to be able to do the right thing, and the = interaction between it and the upstream server is a separate transaction = from the interaction between it and the downstream client: that is, = state must somehow be maintained. Having implemented a proxy that = fiddles with EDNS0 on the way through, this is how I handled it, and it = seems to work nicely. Section 6.1.1 says that if an OPT RR is received, one must be returned, = but there is no requirement that it be the _same_ one. Indeed, that = doesn't really make sense. Of course, I am not exactly an expert on this, so I'm curious whether = the assertion I have just made will provoke a stern correction, but I = would be surprised if it did. From nobody Fri Dec 19 08:25:27 2014 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 4C70E1A897E for ; Fri, 19 Dec 2014 08:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 p90Cf4dGjvUS for ; Fri, 19 Dec 2014 08:25:25 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.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 E1BCF1A8948 for ; Fri, 19 Dec 2014 08:25:24 -0800 (PST) Received: from [10.20.30.90] (50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sBJGPNZZ056971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2014 09:25:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: Date: Fri, 19 Dec 2014 08:25:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <64670FEB-4AF3-4014-ABF3-95C7249E08EE@vpnc.org> <9A8CF5EF94B2EB4D8C90D69BC0E0F6A9144F7AA2@SINPRD3002MB024.064d.mgd.msft.net> To: Ted Lemon X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/gibEZGc5euzis8LO0_Me6YAwTA4 Cc: DNSEXT Group Working Subject: Re: [dnsext] Middleboxes and EDNS(0) 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: Fri, 19 Dec 2014 16:25:26 -0000 On Dec 19, 2014, at 5:11 AM, Ted Lemon wrote: >=20 > On Dec 18, 2014, at 11:29 PM, Kumar Ashutosh = wrote: >> If DNS gets OPT RR (A) in an incoming packet, it will return back the = same OPT RR in the final response back to the sender. >=20 > No, that's not what the text says. If you read the whole section, it = says that if the middlebox isn't being intelligent about what's in the = OPT RR, it should forward it without modification. If it is = intelligent, it is assumed to be able to do the right thing, and the = interaction between it and the upstream server is a separate transaction = from the interaction between it and the downstream client: that is, = state must somehow be maintained. =20 Huh? The text says no such thing, which is why I asked the question. = That is a consistent interpretation, but it is certainly not in the = text. > Of course, I am not exactly an expert on this, so I'm curious whether = the assertion I have just made will provoke a stern correction, but I = would be surprised if it did. When you say "the text says" and you don't quote the text, you should = not be surprised. --Paul Hoffman= From nobody Fri Dec 19 11:46:43 2014 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 678861ACD80 for ; Fri, 19 Dec 2014 11:46:42 -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, 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 FH51m-WX_8H8 for ; Fri, 19 Dec 2014 11:46:41 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 5A6F41AC39F for ; Fri, 19 Dec 2014 11:46:41 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C2C82DA00DF for ; Fri, 19 Dec 2014 19:46:56 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 0446653E084; Fri, 19 Dec 2014 11:46:11 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 19 Dec 2014 11:46:10 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Fri, 19 Dec 2014 14:45:45 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <003C006A-FC72-428A-99ED-CAFC44E63949@nominum.com> References: <64670FEB-4AF3-4014-ABF3-95C7249E08EE@vpnc.org> <9A8CF5EF94B2EB4D8C90D69BC0E0F6A9144F7AA2@SINPRD3002MB024.064d.mgd.msft.net> To: Paul Hoffman X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/lUk-OqjL6AlBWsSAqK_FsvBQkYE Cc: DNSEXT Group Working Subject: Re: [dnsext] Middleboxes and EDNS(0) 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: Fri, 19 Dec 2014 19:46:42 -0000 On Dec 19, 2014, at 11:25 AM, Paul Hoffman = wrote: > Huh? The text says no such thing, which is why I asked the question. = That is a consistent interpretation, but it is certainly not in the = text. Here's what the text says: Middleboxes that simply forward requests to a recursive resolver MUST NOT modify and MUST NOT delete the OPT record contents in either direction. Middleboxes that have additional functionality, such as answering queries or acting as intelligent forwarders, SHOULD be able to process the OPT record and act based on its contents. These middleboxes MUST consider the incoming request and any outgoing requests as separate transactions if the characteristics of the messages are different. I read the last sentence as saying what I paraphrased: > No, that's not what the text says. If you read the whole section, it = says that if the middlebox isn't being intelligent about what's in the = OPT RR, it should forward it without modification. If it is = intelligent, it is assumed to be able to do the right thing, and the = interaction between it and the upstream server is a separate transaction = from the interaction between it and the downstream client: that is, = state must somehow be maintained. I don't see another way to read this. Now, to be honest, I interjected here in response to Kumar Ashutosh's = comment, not with the motivation of actually answering your original = question. The answer to your original question seems obvious to me: = follow the advice on middleboxes. The other advice is for DNS = _servers_ of various flavors, not for middleboxes. This seems explicit = to me in the text; I can understand how you could be confused if the = section on middleboxes were not present, but since it is, it doesn't = make sense to prefer the other text for your use case. From nobody Sat Dec 20 04:58:13 2014 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 4B74C1ACEDD for ; Sat, 20 Dec 2014 04:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.39 X-Spam-Level: * X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_62=0.6, 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 XmxjAJLfnVg4 for ; Sat, 20 Dec 2014 04:58:10 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49991ACEDB for ; Sat, 20 Dec 2014 04:58:10 -0800 (PST) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1Y2Jbi-00033Y-3l for dnsext@ietf.org; Sat, 20 Dec 2014 13:58:06 +0100 Date: Sat, 20 Dec 2014 13:58:06 +0100 From: bert hubert To: DNSEXT Group Working Message-ID: <20141220125805.GB20765@xs.powerdns.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/mMRrvsLvZNOu6coyPoO6nrOKcSI Subject: [dnsext] Empty AA=0 AD=1 answers to AAAA queries: your thoughts pls 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, 20 Dec 2014 12:58:12 -0000 Hi everybody, I have a question if I am right in concluding something is a protocol violation, and if we should reward it by papering it over or (finally) concluding that enough is enough. A few weeks ago we posted this http://mailman.powerdns.com/pipermail/pdns-users/2014-December/011004.html about Microsoft Azure nameservers sending empty answers (AD=1 no less) to AAAA queries. Microsoft has indicated they'll get to addressing this early 2015, by the way (thanks Mehmet). However, we're now seeing more and more of this, for example from the most popular news site in the Netherlands nu.nl: $ dig +trace -t aaaa nu-nl.gslb.sanomaservices.nl. Which ends on: $ dig -t aaaa nu-nl.gslb.sanomaservices.nl. @62.69.175.251 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58444 ;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1280 ;; QUESTION SECTION: ;nu-nl.gslb.sanomaservices.nl. IN AAAA Note that this is the same pattern as Microsoft Azure. But this empty AA=0 answer leads PowerDNS to: nu-nl.gslb.sanomaservices.nl.: Trying IP 62.69.175.251:53 1, asking 'nu-nl.gslb.sanomaservices.nl.|AAAA' nu-nl.gslb.sanomaservices.nl.: Got 0 answers from gslb2.sanomaservices.nl. (62.69.175.251), rcode=0 (No Error), aa=0, in 6ms nu-nl.gslb.sanomaservices.nl.: determining status after receiving this packet nu-nl.gslb.sanomaservices.nl.: status=NS gslb2.sanomaservices.nl. (62.69.175.251) is lame for 'gslb.sanomaservices.nl.', trying sibling IP or NS nu-nl.gslb.sanomaservices.nl.: Failed to resolve via any of the 2 offered NS at level 'gslb.sanomaservices.nl.' nu-nl.gslb.sanomaservices.nl.: failed (res=-1) And this means we send out a SERVFAIL to our client, since all servers are 'lame'. This makes some programs very unhappy. We are (as is any resolver implementor) receiving pressure not to do this, and to paper over this behaviour. There is a workaround available in the URL above. We think the time has to come to say 'no, if you run a non-confirming implementation, you deserve all the pain you get'. But before we make a stand, what do you think? Should we accept empty AA=0 AD=1 answers as "NO ERROR"? Please let us know. Bert From nobody Sat Dec 20 06:25:21 2014 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 45F801A889A for ; Sat, 20 Dec 2014 06:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.389 X-Spam-Level: * X-Spam-Status: No, score=1.389 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_62=0.6, 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 tA9_4GZQ4i2o for ; Sat, 20 Dec 2014 06:25:17 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27E31A8876 for ; Sat, 20 Dec 2014 06:25:16 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id E34171FCB85; Sat, 20 Dec 2014 14:25:10 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D323F160067; Sat, 20 Dec 2014 14:30:20 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 9C83E160064; Sat, 20 Dec 2014 14:30:20 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id C7EA12630502; Sun, 21 Dec 2014 01:25:06 +1100 (EST) To: bert hubert From: Mark Andrews References: <20141220125805.GB20765@xs.powerdns.com> In-reply-to: Your message of "Sat, 20 Dec 2014 13:58:06 +0100." <20141220125805.GB20765@xs.powerdns.com> Date: Sun, 21 Dec 2014 01:25:06 +1100 Message-Id: <20141220142506.C7EA12630502@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/dY6SHxCgHA8m7VjItlOUOyzjVSU Cc: DNSEXT Group Working Subject: Re: [dnsext] Empty AA=0 AD=1 answers to AAAA queries: your thoughts pls 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, 20 Dec 2014 14:25:19 -0000 In message <20141220125805.GB20765@xs.powerdns.com>, bert hubert writes: > Hi everybody, > > I have a question if I am right in concluding something is a protocol > violation, and if we should reward it by papering it over or (finally) > concluding that enough is enough. I've been thinking for a long time that enough is enough. Named tried to reject all non referral "aa=0" from supposedly authoritative servers a while back and we had to reverse the change. While pandora.tv has fixed the aa=0 issue they still return malformed answers. What we really need is for TLD operators to audit all the delegated servers and inform their owners when they see a broken one. They are the ones with the lists of authoritative servers and the contact information. See draft-andrews-dns-no-response-issue. > A few weeks ago we posted this > http://mailman.powerdns.com/pipermail/pdns-users/2014-December/011004.html > about Microsoft Azure nameservers sending empty answers (AD=1 no less) to > AAAA queries. Microsoft has indicated they'll get to addressing this early > 2015, by the way (thanks Mehmet). > > However, we're now seeing more and more of this, for example from the most > popular news site in the Netherlands nu.nl: > > $ dig +trace -t aaaa nu-nl.gslb.sanomaservices.nl. > > Which ends on: > > $ dig -t aaaa nu-nl.gslb.sanomaservices.nl. @62.69.175.251 > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58444 > ;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 1280 > ;; QUESTION SECTION: > ;nu-nl.gslb.sanomaservices.nl. IN AAAA > > Note that this is the same pattern as Microsoft Azure. But this empty AA=0 > answer leads PowerDNS to: > > nu-nl.gslb.sanomaservices.nl.: Trying IP 62.69.175.251:53 1, asking 'nu-nl.g > slb.sanomaservices.nl.|AAAA' > nu-nl.gslb.sanomaservices.nl.: Got 0 answers from gslb2.sanomaservices.nl. ( > 62.69.175.251), rcode=0 (No Error), aa=0, in 6ms > nu-nl.gslb.sanomaservices.nl.: determining status after receiving this packe > t > nu-nl.gslb.sanomaservices.nl.: status=NS gslb2.sanomaservices.nl. (62.69.175 > .251) is lame for 'gslb.sanomaservices.nl.', trying sibling IP or NS > nu-nl.gslb.sanomaservices.nl.: Failed to resolve via any of the 2 offered NS > at level 'gslb.sanomaservices.nl.' > nu-nl.gslb.sanomaservices.nl.: failed (res=-1) > > And this means we send out a SERVFAIL to our client, since all servers are > 'lame'. This makes some programs very unhappy. > > We are (as is any resolver implementor) receiving pressure not to do this, > and to paper over this behaviour. There is a workaround available in the URL > above. > > We think the time has to come to say 'no, if you run a non-confirming > implementation, you deserve all the pain you get'. > > But before we make a stand, what do you think? Should we accept empty AA=0 > AD=1 answers as "NO ERROR"? Personally I would like to take a stand. Whether we can convince others is another matter. > Please let us know. > > Bert > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat Dec 20 06:41:36 2014 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 C75A21A9149 for ; Sat, 20 Dec 2014 06:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 qRwTsSmkCU8t for ; Sat, 20 Dec 2014 06:41:34 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA8E1A90B4 for ; Sat, 20 Dec 2014 06:41:34 -0800 (PST) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1Y2LDm-0003FO-Mb; Sat, 20 Dec 2014 15:41:30 +0100 Date: Sat, 20 Dec 2014 15:41:30 +0100 From: bert hubert To: Mark Andrews Message-ID: <20141220144130.GA13389@xs.powerdns.com> References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141220142506.C7EA12630502@rock.dv.isc.org> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/5WETi-nLQWqFyWuMJaK4UMpS8GQ Cc: ted.lemon@nominum.com, DNSEXT Group Working Subject: Re: [dnsext] Empty AA=0 AD=1 answers to AAAA queries: your thoughts pls 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, 20 Dec 2014 14:41:36 -0000 On Sun, Dec 21, 2014 at 01:25:06AM +1100, Mark Andrews wrote: > > I have a question if I am right in concluding something is a protocol > > violation, and if we should reward it by papering it over or (finally) > > concluding that enough is enough. > > I've been thinking for a long time that enough is enough. Named tried > to reject all non referral "aa=0" from supposedly authoritative servers > a while back and we had to reverse the change. While pandora.tv has > fixed the aa=0 issue they still return malformed answers. What about if (say) ISC, NLNetlabs, Nominum, PowerDNS and Google DNS say "enough is enough"? Because right now, the dynamics we all know are "yeah but you must fix it since it works on X" (where X isn't you). If we had a nice manifesto to point to, we could make this stick. I estimate that >25% of the PowerDNS recursor now consists of "stuff we have to do because the internet sucks". The horrible thing is that every workaround we add increases the chance we break legitimate things, or open ourselves up to attacks that make good use of our willingness to bend things to make them work. > Personally I would like to take a stand. Whether we can convince others > is another matter. Benno, Wilmer, Ted, Kumar, what do you think? We could coordinate off-list perhaps? Bert From nobody Sat Dec 20 08:21:34 2014 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 1E9301A8A12 for ; Sat, 20 Dec 2014 08:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 th2WGMUdXxoZ for ; Sat, 20 Dec 2014 08:21:31 -0800 (PST) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A261A8A14 for ; Sat, 20 Dec 2014 08:21:31 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 64204242143B; Sat, 20 Dec 2014 16:21:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jim Reid In-Reply-To: <20141220142506.C7EA12630502@rock.dv.isc.org> Date: Sat, 20 Dec 2014 16:21:25 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/xStZ8w_lxWNlYKV0L0uZKqD3HLw Cc: DNSEXT Group Working , bert hubert Subject: [dnsext] getting TLDs to fix other people's problems 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, 20 Dec 2014 16:21:33 -0000 On 20 Dec 2014, at 14:25, Mark Andrews wrote: > What we really need is for TLD operators to audit all the delegated > servers and inform their owners when they see a broken one. Mark, this is a ridiculous idea. It's utterly unworkable. just like it = would be to get TLDs to act as the lame delegation police. It simply = isn't going to happen. Even if this contact was viable, it will be rare = to find a registrant who understands this aa=3D0 issue and is willing to = fix the broken implementation: "the DNS for my domain is working just = fine for me, so why should I care about the troubles it causes someone = else or pay to fix their problem?". I wish you every success getting ICANN to adopt that policy for gTLDs = and then steering it through the policy-making machinery and/or = legislation for each of the 200-odd ccTLDs. Once that's done, good luck = with implementing and enforcing those policies. > They are the ones with the lists of authoritative servers and the = contact > information. No they are not. Lots of registrants hide behind proxy/privacy services. = Some of them publish non-functioning contact data for the registrant, = Other registrants supply ficticious contact data, myself included. = Draining these festering swamps will take forever and no matter how hard = registries try, they will always be stuck with them. Don't take my word = for it. Ask the IPR and law enforcement types who have been screaming = for years at ICANN about bogus whois data. Remember too that the two largest TLDs (which have ~50% of the world's = registered delegations) operate the thin registry model where the = registrars and not the registry hold registrant contact data. Verisign = couldn't even contact the holder of domain-with-aa=3D0-issues.com if = they wanted to.= From nobody Sat Dec 20 12:43:45 2014 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 3BB781A6FF3 for ; Sat, 20 Dec 2014 12:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.012 X-Spam-Level: X-Spam-Status: No, score=-5.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, 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 RMVeUWYn9h8G for ; Sat, 20 Dec 2014 12:43:42 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61BB1A1B80 for ; Sat, 20 Dec 2014 12:43:42 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 8ABA034930F; Sat, 20 Dec 2014 20:43:40 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 292CC160067; Sat, 20 Dec 2014 20:48:52 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id B3CDC160064; Sat, 20 Dec 2014 20:48:51 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 4F47026313BC; Sun, 21 Dec 2014 07:43:37 +1100 (EST) To: Jim Reid From: Mark Andrews References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> In-reply-to: Your message of "Sat, 20 Dec 2014 16:21:25 -0000." Date: Sun, 21 Dec 2014 07:43:37 +1100 Message-Id: <20141220204337.4F47026313BC@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/jOGUHVEeiRrqHmgPO4_Iq3fqu8Y Cc: DNSEXT Group Working , bert hubert Subject: Re: [dnsext] getting TLDs to fix other people's problems 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, 20 Dec 2014 20:43:44 -0000 In message , Jim Reid writes: > On 20 Dec 2014, at 14:25, Mark Andrews wrote: > > > What we really need is for TLD operators to audit all the delegated > > servers and inform their owners when they see a broken one. > > Mark, this is a ridiculous idea. It's utterly unworkable. just like it > would be to get TLDs to act as the lame delegation police. It simply > isn't going to happen. Even if this contact was viable, it will be rare > to find a registrant who understands this aa=0 issue and is willing to > fix the broken implementation: "the DNS for my domain is working just > fine for me, so why should I care about the troubles it causes someone > else or pay to fix their problem?". The problems listed in my draft are problems with the software. You tell them to contact the DNS vendor for a fix. The DNS vendor should understand and fix it themselves in the case of a hosted service or be able to advise them of which version of the software they need to run or generate a fix and advise them to run it. Most of the problem is that the operators don't know that there is a issue. You would assume that your DNS supplier actually produces protocol compliant software. Informing them that they have a problem is the first step to getting it fixed. > I wish you every success getting ICANN to adopt that policy for gTLDs and > then steering it through the policy-making machinery and/or legislation > for each of the 200-odd ccTLDs. Once that's done, good luck with > implementing and enforcing those policies. > > > They are the ones with the lists of authoritative servers and the > contact > > information. > > No they are not. Lots of registrants hide behind proxy/privacy services. > Some of them publish non-functioning contact data for the registrant, > Other registrants supply ficticious contact data, myself included. > Draining these festering swamps will take forever and no matter how hard > registries try, they will always be stuck with them. Don't take my word > for it. Ask the IPR and law enforcement types who have been screaming for > years at ICANN about bogus whois data. They still have the lists of registrants. If they choose to hide behind proxy/privacy services then the contact is through them. It is their job to sort out what is legitimate communication from spam. > Remember too that the two largest TLDs (which have ~50% of the world's > registered delegations) operate the thin registry model where the > registrars and not the registry hold registrant contact data. Verisign > couldn't even contact the holder of domain-with-aa=0-issues.com if they > wanted to. Then they go through the registrars. They and the registrars choose to operate in then model. They need to deal with it. It isn't like registries didn't know that this is part of their job. Contacting the parent to deal with problems in the child zone is listed as part of the problem resolution proceedures so that should have the mechanisms to do this. If they don't then they failed to do due diligence when they got into the registry business and they need to rectify their proceedures. The registrars should have also realised that they are part of the compliants process. RFC 1033, COMPLAINTS These are the suggested steps you should take if you are having problems that you believe are caused by someone else's name server: 1. Complain privately to the responsible person for the domain. You can find their mailing address in the SOA record for the domain. 2. Complain publicly to the responsible person for the domain. 3. Ask the NIC for the administrative person responsible for the domain. Complain. You can also find domain contacts on the NIC in the file NETINFO:DOMAIN-CONTACTS.TXT 4. Complain to the parent domain authorities. 5. Ask the parent authorities to excommunicate the domain. With systemic problem you often modifiy the proceedures to identify the problem sources enmass which is what I'm trying to arrange to happen here. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sat Dec 20 17:35:05 2014 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 472511A00F7 for ; Sat, 20 Dec 2014 17:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 hUzi2hnaX-Ve for ; Sat, 20 Dec 2014 17:35:02 -0800 (PST) Received: from insensate.co.uk (norman.insensate.co.uk [81.174.156.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDBF1A00F1 for ; Sat, 20 Dec 2014 17:35:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 23F8F491D51; Sun, 21 Dec 2014 01:35:00 +0000 (GMT) Received: from insensate.co.uk ([127.0.0.1]) by localhost (psyche.insensate.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90ckhfrgm25d; Sun, 21 Dec 2014 01:34:59 +0000 (GMT) Received: from [IPv6:::1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTPSA id 451E8491D46; Sun, 21 Dec 2014 01:34:59 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lawrence Conroy In-Reply-To: <20141220204337.4F47026313BC@rock.dv.isc.org> Date: Sun, 21 Dec 2014 01:34:58 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220204337.4F47026313BC@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/AmQfPcMUbvkoSYIe2JQpfFMOrFE Cc: DNSEXT Group Working , bert hubert Subject: Re: [dnsext] getting TLDs to fix other people's problems 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, 21 Dec 2014 01:35:04 -0000 Hi Mark, Jim, Bert, folks, What makes me think this is an IETF mailing list, as opposed to what = infests the real world? Where, in ICANN contracts (choose one), does it say that a gTLD operator = has to police the lameness/whackiness of delegated authoritative server = responses? [note -- not the GTLD's responses, those of servers authoritative for = delegated domains] That doesn't even cover the CCTLDs, which are pretty much all over the = shop with their disparate policies (and gawd knows what the contracts = are each of them have with their customers). Seriously ... Registries may be OK, but do you expect them to spam their = customers' customers? With thin registries, that will naff off the Registrars (look at the = apologetic tone of the spam gTLD Registrars are forced to send each year = to ask customers to not do what Jim might have hinted he does to his = contact info). As for fixing the server software: you have to know that this will be = seen by the hard of thinking as "all new DNS software is broken". Don't get me wrong -- I'd love this to happen (as long as I have popcorn = and a comfy sofa to watch the fun). all the best=20 Lawrence [a poor customer's customer's customer] On 20 Dec 2014, at 20:43, Mark Andrews wrote: > In message , Jim = Reid writes: >> On 20 Dec 2014, at 14:25, Mark Andrews wrote: >>=20 >>> What we really need is for TLD operators to audit all the delegated >>> servers and inform their owners when they see a broken one. >>=20 >> Mark, this is a ridiculous idea. It's utterly unworkable. just like = it >> would be to get TLDs to act as the lame delegation police. It simply >> isn't going to happen. Even if this contact was viable, it will be = rare >> to find a registrant who understands this aa=3D0 issue and is willing = to >> fix the broken implementation: "the DNS for my domain is working just >> fine for me, so why should I care about the troubles it causes = someone >> else or pay to fix their problem?". >=20 > The problems listed in my draft are problems with the software. > You tell them to contact the DNS vendor for a fix. The DNS vendor > should understand and fix it themselves in the case of a hosted > service or be able to advise them of which version of the software > they need to run or generate a fix and advise them to run it. >=20 > Most of the problem is that the operators don't know that there is > a issue. You would assume that your DNS supplier actually produces > protocol compliant software. Informing them that they have a problem > is the first step to getting it fixed. >=20 >> I wish you every success getting ICANN to adopt that policy for gTLDs = and >> then steering it through the policy-making machinery and/or = legislation >> for each of the 200-odd ccTLDs. Once that's done, good luck with >> implementing and enforcing those policies. >>=20 >>> They are the ones with the lists of authoritative servers and the >> contact >>> information. >>=20 >> No they are not. Lots of registrants hide behind proxy/privacy = services. >> Some of them publish non-functioning contact data for the registrant, >> Other registrants supply ficticious contact data, myself included. >> Draining these festering swamps will take forever and no matter how = hard >> registries try, they will always be stuck with them. Don't take my = word >> for it. Ask the IPR and law enforcement types who have been screaming = for >> years at ICANN about bogus whois data. >=20 > They still have the lists of registrants. If they choose to hide = behind > proxy/privacy services then the contact is through them. It is their > job to sort out what is legitimate communication from spam. >=20 >> Remember too that the two largest TLDs (which have ~50% of the = world's >> registered delegations) operate the thin registry model where the >> registrars and not the registry hold registrant contact data. = Verisign >> couldn't even contact the holder of domain-with-aa=3D0-issues.com if = they >> wanted to. >=20 > Then they go through the registrars. They and the registrars choose > to operate in then model. They need to deal with it. It isn't > like registries didn't know that this is part of their job. = Contacting > the parent to deal with problems in the child zone is listed as > part of the problem resolution proceedures so that should have the > mechanisms to do this. If they don't then they failed to do due > diligence when they got into the registry business and they need > to rectify their proceedures. The registrars should have also > realised that they are part of the compliants process. >=20 > RFC 1033, COMPLAINTS >=20 > These are the suggested steps you should take if you are having > problems that you believe are caused by someone else's name server: >=20 > 1. Complain privately to the responsible person for the domain. = You > can find their mailing address in the SOA record for the domain. >=20 > 2. Complain publicly to the responsible person for the domain. >=20 > 3. Ask the NIC for the administrative person responsible for the > domain. Complain. You can also find domain contacts on the NIC in > the file NETINFO:DOMAIN-CONTACTS.TXT >=20 > 4. Complain to the parent domain authorities. >=20 > 5. Ask the parent authorities to excommunicate the domain. >=20 > With systemic problem you often modifiy the proceedures to identify = the > problem sources enmass which is what I'm trying to arrange to happen = here. >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From nobody Sat Dec 20 21:34:10 2014 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 902FD1A0161 for ; Sat, 20 Dec 2014 21:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kXrI-ITe8HSR for ; Sat, 20 Dec 2014 21:34:07 -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 EB09D1A015F for ; Sat, 20 Dec 2014 21:34:06 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::b0a7:8760:fd77:de4d] (unknown [IPv6:2a02:80:3ffc:0:b0a7:8760:fd77:de4d]) by mail.frobbit.se (Postfix) with ESMTPSA id 20520205BC; Sun, 21 Dec 2014 06:34:03 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7B804A95-CD46-4E34-8FC8-AA3C06756B15"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> Date: Sun, 21 Dec 2014 06:34:02 +0100 Message-Id: References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220204337.4F47026313BC@rock.dv.isc.org> <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> To: Lawrence Conroy X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/l7B2l7vMFaK2NAOKgrWhjId7__o Cc: bert hubert , DNSEXT Group Working Subject: Re: [dnsext] getting TLDs to fix other people's problems 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, 21 Dec 2014 05:34:08 -0000 --Apple-Mail=_7B804A95-CD46-4E34-8FC8-AA3C06756B15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A few examples of where the world is from my perspective: As long as... - ...policy in some registries require NS records for registrations of a = domain (i.e. no difference between registration and delegation), there = will be lame delegations - ...policy in some registries require NS records for registrations of a = domain (i.e. no difference between registration and delegation), there = will be proxy registrations and registrants that lie - ...data sent to a registry/registrar, regardless of data protection = legislation, is available freely "on the net", there will be proxy = registrations and registrants that lie - ...policy make it impossible to register domain names in some = registries, there will be proxy registrations to circumvent the very = same rules - ...there is no agreement on what data to send to registries for DNSSEC = signed zones, it will be very hard to get lots of DNSSEC signed zones - ...policy in some registries that the registrant should contact them = directly, registrars will lie to the registry during registration period = so that they can give the registrant the service the registrant ask for I.e. the world out there is so messy that what you talk about is a light = warm breeze... Just the notation of "the TLDs" to fix things is confusing to me. Does = "the TLD" imply the registry, whoever is the administrative contact for = the TLD in the IANA database, or the backend provider, or the technical = contact or the one holding the whois record of the delegation the = question is about, or... Patrik --Apple-Mail=_7B804A95-CD46-4E34-8FC8-AA3C06756B15 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 iD8DBQFUllvKrMabGguI180RAiQgAJ9/cvUXmhjSvrO13lKSn99IGNCZTgCfV5Un 9+Nrh2anRNvnKmlW7d3CMys= =OpLX -----END PGP SIGNATURE----- --Apple-Mail=_7B804A95-CD46-4E34-8FC8-AA3C06756B15-- From nobody Sun Dec 21 01:45:07 2014 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 355661A0370 for ; Sun, 21 Dec 2014 01:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 HPYPEQgy4ssv for ; Sun, 21 Dec 2014 01:45:03 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC571A036F for ; Sun, 21 Dec 2014 01:45:03 -0800 (PST) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1Y2d4I-0000Eu-HY; Sun, 21 Dec 2014 10:44:54 +0100 Date: Sun, 21 Dec 2014 10:44:54 +0100 From: bert hubert To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20141221094454.GC13389@xs.powerdns.com> References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220204337.4F47026313BC@rock.dv.isc.org> <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/NKJOHkqmCS1WUwchtEJPmpcHJ74 Cc: DNSEXT Group Working Subject: [dnsext] enough is enough 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, 21 Dec 2014 09:45:05 -0000 On Sun, Dec 21, 2014 at 06:34:02AM +0100, Patrik Fältström wrote: > - ...policy in some registries require NS records for registrations of a domain (i.e. no difference between registration and delegation), there will be lame delegations To clarify, nothing like this is what I intended. Perhaps a prototype will help: "Dear domain operator, nameserver vendor, or load balancer purveyor, The domain x.y.z fails to resolve using our software, and we have determined that this is because the software or hardware publishing the DNS details of x.y.z is not conforming to the DNS standards. The violation is: Sending empty non-aa answers to AAAA queries The result is: our software generates a SERVFAIL response, confusing Microsoft Exchange. The product at fault is: Citrix Netscaler Please find further details attached to this message. While some other software or service is able to resolve your domain, we are not going to work around this issue. For years, all resolver vendors and service providers have papered over DNS protocol violations if one of the other big resolver implementations was able to resolve a domain. There is now a staggering amount of papering over in each nameserver implementation. As a DNS community, we have decided that enough is enough. We encourage you to contact the responsible vendor (see above). We are more than willing to talk to them if this helps them resolve the issue. Kind regards, PowerDNS, also on behalf of ISC, .., .. and .." This would then come with a website with further explanations, and perhaps even a registry of faults that has been decided we're not going to fix. I'm open to providing specific workaround configurations to individual operators if this helps them in the meantime, but they'll hate having to maintain all these workarounds, thus generating rising pressure on the vendors of broken equipment. Ideas? Bert > > - ...policy in some registries require NS records for registrations of a domain (i.e. no difference between registration and delegation), there will be proxy registrations and registrants that lie > > - ...data sent to a registry/registrar, regardless of data protection legislation, is available freely "on the net", there will be proxy registrations and registrants that lie > > - ...policy make it impossible to register domain names in some registries, there will be proxy registrations to circumvent the very same rules > > - ...there is no agreement on what data to send to registries for DNSSEC signed zones, it will be very hard to get lots of DNSSEC signed zones > > - ...policy in some registries that the registrant should contact them directly, registrars will lie to the registry during registration period so that they can give the registrant the service the registrant ask for > > I.e. the world out there is so messy that what you talk about is a light warm breeze... > > Just the notation of "the TLDs" to fix things is confusing to me. Does "the TLD" imply the registry, whoever is the administrative contact for the TLD in the IANA database, or the backend provider, or the technical contact or the one holding the whois record of the delegation the question is about, or... > > Patrik > From nobody Sun Dec 21 01:48:01 2014 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 B3B541A0378 for ; Sun, 21 Dec 2014 01:47:59 -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, 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 C-50BBQcBV-c for ; Sun, 21 Dec 2014 01:47:57 -0800 (PST) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B642E1A0370 for ; Sun, 21 Dec 2014 01:47:56 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 6114C242143B; Sun, 21 Dec 2014 09:47:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jim Reid In-Reply-To: <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> Date: Sun, 21 Dec 2014 09:47:53 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8CC8F3E7-D6D9-47FA-8D58-F4154C5FE4DB@rfc1035.com> References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220204337.4F47026313BC@rock.dv.isc.org> <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> To: Lawrence Conroy X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/TiChgLT1X6zU4QXGQI5ng5Ywqcc Cc: bert hubert , DNSEXT Group Working Subject: Re: [dnsext] getting TLDs to fix other people's problems 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, 21 Dec 2014 09:48:00 -0000 On 21 Dec 2014, at 01:34, Lawrence Conroy = wrote: > Registries may be OK, but do you expect them to spam their customers' = customers? Indeed. My earlier rant overlooked that one. Most registrars do not want registries to contact registrants - ever. = Registrars like to have total control over the communications to their = registrants, usually to the point where the registrant is unaware of the = registry's existence. Quite a few ccTLD registries have policies which = forbid the registry from contacting the registrant. From nobody Sun Dec 21 02:18:26 2014 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 CBAC81A037D for ; Sun, 21 Dec 2014 02:18:23 -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=[BAYES_20=-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 xiXUPM4n9JCf for ; Sun, 21 Dec 2014 02:18:22 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595961A037B for ; Sun, 21 Dec 2014 02:18:22 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 306C3242143B; Sun, 21 Dec 2014 10:18:20 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jim Reid In-Reply-To: <20141221094454.GC13389@xs.powerdns.com> Date: Sun, 21 Dec 2014 10:18:19 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <11AD7639-D2AA-41F4-ACA4-70190E449253@rfc1035.com> References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220204337.4F47026313BC@rock.dv.isc.org> <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> <20141221094454.GC13389@xs.powerdns.com> To: bert hubert X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/NvyB788HQIt3N8y8HvJNckBB2m4 Cc: DNSEXT Group Working Subject: Re: [dnsext] enough is enough 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, 21 Dec 2014 10:18:24 -0000 On 21 Dec 2014, at 09:44, bert hubert wrote: > This would then come with a website with further explanations, and = perhaps > even a registry of faults that has been decided we're not going to = fix. Bert, your prototype email is all very well. Of course it would be nice = if there was some botnet (say) which went looking for these broken DNS = servers and sent an email from the aa=3D0 police like the one you = suggested. However this is howling at the moon. For decades the DNS industry has = been unable to get people to fix their lame delegations or get them to = stop using BIND8 or to use software which does EDNS or... So an attempt = along these lines to fix the aa=3D0 problem will be yet another Epic = Fail. If DNS lameness can't be cured, contacting registrants -- assuming = that was possible and it isn't -- to get software replaced surely won't = succeed either. Everyone here should already know by now that contacting registrants en = masse will never produce the desired outcome. We should also know why = that approach is guaranteed to fail every time. Now who was it that said = =93The definition of insanity is doing the same thing over and over = again, but expecting different results=94? The only sensible approach to take here is to notify the vendors of the = broken software and hope they do the Right Thing. If they don't, or = their customers can't/won't upgrade, the rest of us just have to suck it = up. 'Twas ever thus. At least the DNS developer community is small and = fairly easy to reach. BTW, your Subject: header is appropriate. There's been more than enough = discussion of this deeply flawed approach to fixing the aa=3D0 problem.= From nobody Sun Dec 21 02:33:23 2014 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 9BE811A038D for ; Sun, 21 Dec 2014 02:33:22 -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 iqdlzQJ2lOd4 for ; Sun, 21 Dec 2014 02:33:21 -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 47B501A038A for ; Sun, 21 Dec 2014 02:33:21 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::b0a7:8760:fd77:de4d] (unknown [IPv6:2a02:80:3ffc:0:b0a7:8760:fd77:de4d]) by mail.frobbit.se (Postfix) with ESMTPSA id E474A2054A; Sun, 21 Dec 2014 11:33:18 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A1A68503-A021-4FC2-A615-2B07626DE9EB"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <20141221094454.GC13389@xs.powerdns.com> Date: Sun, 21 Dec 2014 11:33:17 +0100 Message-Id: <55B7725D-1B11-4D8D-BDA3-43748E8E12A7@frobbit.se> References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220204337.4F47026313BC@rock.dv.isc.org> <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> <20141221094454.GC13389@xs.powerdns.com> To: bert hubert X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/tL-WGr_69X-bPIGQDnG4DN0_FQc Cc: DNSEXT Group Working Subject: Re: [dnsext] enough is enough 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, 21 Dec 2014 10:33:22 -0000 --Apple-Mail=_A1A68503-A021-4FC2-A615-2B07626DE9EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > On 21 dec 2014, at 10:44, bert hubert = wrote: >=20 > On Sun, Dec 21, 2014 at 06:34:02AM +0100, Patrik F=E4ltstr=F6m wrote: >> - ...policy in some registries require NS records for registrations = of a domain (i.e. no difference between registration and delegation), = there will be lame delegations >=20 > To clarify, nothing like this is what I intended. Perhaps a prototype = will > help: >=20 > "Dear domain operator, nameserver vendor, or load balancer purveyor, >=20 > The domain x.y.z fails to resolve using our software, and we have = determined > that this is because the software or hardware publishing the DNS = details of > x.y.z is not conforming to the DNS standards. : : As Jim says, your idea is nice as it is, and there is nothing wrong with = the email -- but we have no idea what so ever where to send it. The best path forward is I think still for you to publish clear and = crisp information like this on your web page so that it is found when = searching for help with Google and other search engines. I.e. as long as no one have any issues with the brokenness, it will not = be fixed. And obviously it is not broken enough. The parties involved (the one = looking things up and the domain name holder) obviously either can = communicate anyways with the brokenness or they do not find lack of = communication is bad enough to fix whatever is to be fixed. I feel very sad to have this view today, because I did not have it = earlier. I have though given up on the mass market operational community = and feel one have to spend time where it actually matters, on software, = best practices etc. If not even TLDs are hosted correctly, and registry policies are such = that it encourages broken DNS configurations, I feel there is not much = The Protocol Police can do about it. Patrik --Apple-Mail=_A1A68503-A021-4FC2-A615-2B07626DE9EB 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 iD8DBQFUlqHurMabGguI180RAolyAJsHji3c+fZSgZkICEpUchKUsCJeLQCfRTgB NYYtkXdmyzea/up5ZzdzyNk= =lxPN -----END PGP SIGNATURE----- --Apple-Mail=_A1A68503-A021-4FC2-A615-2B07626DE9EB-- From nobody Sun Dec 21 05:01:26 2014 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 F419C1A03FF for ; Sun, 21 Dec 2014 05:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 1f5buO3oLK6b for ; Sun, 21 Dec 2014 05:01:22 -0800 (PST) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id 32AA61A03E1 for ; Sun, 21 Dec 2014 05:01:19 -0800 (PST) Received: by mail.avalus.com (Postfix) with ESMTPSA id F2420C561DC; Sun, 21 Dec 2014 13:01:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=alex.org.uk; s=mail; t=1419166878; bh=WjislutAnyeupLEn4vaX+qmYfYcUEYRRDp8RNPq1las=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=j6g4zx3XVnediefjcVOQ+pyqdU6ZYKz4X9z1i3JrQbMAkVBgg9tggpdmRwltf8C0L VebBnlc5/Ap7MYzMqSsDahfyWrjlHrDHJkhbsC6CNsBfOROAJ8dBscC06Gxyt5HbmG /7B41O7ALNGiMxzZ0dnCGbgV8PpnCN4IbEgumrmI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alex Bligh In-Reply-To: <20141220144130.GA13389@xs.powerdns.com> Date: Sun, 21 Dec 2014 13:01:08 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220144130.GA13389@xs.powerdns.com> To: bert hubert X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/79TyCgJngjpfH5fMfY8GEoRChtg Cc: "dnsext mailing dnsext@ietf.org" , Ted Lemon Subject: Re: [dnsext] Empty AA=0 AD=1 answers to AAAA queries: your thoughts pls 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, 21 Dec 2014 13:01:24 -0000 On 20 Dec 2014, at 14:41, bert hubert wrote: > On Sun, Dec 21, 2014 at 01:25:06AM +1100, Mark Andrews wrote: >>> I have a question if I am right in concluding something is a protocol >>> violation, and if we should reward it by papering it over or (finally) >>> concluding that enough is enough. >> >> I've been thinking for a long time that enough is enough. Named tried >> to reject all non referral "aa=0" from supposedly authoritative servers >> a while back and we had to reverse the change. While pandora.tv has >> fixed the aa=0 issue they still return malformed answers. > > What about if (say) ISC, NLNetlabs, Nominum, PowerDNS and Google DNS say > "enough is enough"? There are options between SERVFAIL and work-around. One such would be 'delay responses in respect of non-conformant replies by 3 seconds'. I would bet pretty Google Pagespeed etc. will start including a test to see whether the DNS server is broken and thus causes excessive delay with certain resolvers. That's far less antisocial than "surely you didn't you really mean 'aa=0'? Let me just ask you 255 more times to make sure in case you change your mind", no matter how tempting ... -- Alex Bligh From nobody Sun Dec 21 06:33:20 2014 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 96FE01A066C for ; Sun, 21 Dec 2014 06:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, 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 GkxD5AAdbYNd for ; Sun, 21 Dec 2014 06:33:17 -0800 (PST) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25EA71A049A for ; Sun, 21 Dec 2014 06:33:16 -0800 (PST) Received: from ahu by xs.powerdns.com with local (Exim 4.71) (envelope-from ) id 1Y2hZH-0007s8-2Y; Sun, 21 Dec 2014 15:33:11 +0100 Date: Sun, 21 Dec 2014 15:33:11 +0100 From: bert hubert To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= Message-ID: <20141221143310.GA28183@xs.powerdns.com> References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220204337.4F47026313BC@rock.dv.isc.org> <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> <20141221094454.GC13389@xs.powerdns.com> <55B7725D-1B11-4D8D-BDA3-43748E8E12A7@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <55B7725D-1B11-4D8D-BDA3-43748E8E12A7@frobbit.se> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/klS-dVPAl_AfLu6XcDGQsrjXrx0 Cc: DNSEXT Group Working Subject: Re: [dnsext] enough is enough 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, 21 Dec 2014 14:33:18 -0000 On Sun, Dec 21, 2014 at 11:33:17AM +0100, Patrik Fältström wrote: > > The domain x.y.z fails to resolve using our software, and we have determined > > that this is because the software or hardware publishing the DNS details of > > x.y.z is not conforming to the DNS standards. > As Jim says, your idea is nice as it is, and there is nothing wrong with > the email -- but we have no idea what so ever where to send it. Actually, as the authors of a resolver, we know exactly where to send it. To the people telling me I need to fix my resolver so it works with broken domain X. And in turn, we've found that (together with resolver operators) we can quickly find out what broken hardware or software is behind the issue - Citrix Netscalers this time round. It helps if large operators (people with tens of millions of customers) tell them they need to clean up their act. The REAL issue right now is that we can't resist fixing a broken domain "because it works with Google/Unbound/Bind/Microsoft, so you must fix it". What is needed is a pact that none of us will respect that argument on its own if a domain actually should be broken. > The best path forward is I think still for you to publish clear and crisp > information like this on your web page so that it is found when searching > for help with Google and other search engines. > > I.e. as long as no one have any issues with the brokenness, it will not be fixed. Exactly. It should actually break therefore. If you own dodgy equipment or use bad software, your domain should receive lots of reports of brokenness. > If not even TLDs are hosted correctly, and registry policies are such that > it encourages broken DNS configurations, I feel there is not much The > Protocol Police can do about it. I'm afraid this is true. But if all big implementation decide to no longer play the game, the (mostly) load balancer implementations will have to clean up their act. I also note that quite a lot of problems are AAAA related. This in itself is an impediment to IPv6 adoption! Bert From nobody Sun Dec 21 11:54:46 2014 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 F19861A7033 for ; Sun, 21 Dec 2014 11:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ciTf9uqJlWaQ for ; Sun, 21 Dec 2014 11:54:43 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id D70971A8034 for ; Sun, 21 Dec 2014 11:54:42 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 15ACF4BCEAB; Mon, 22 Dec 2014 08:54:41 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqf7ZHwDjhF7; Mon, 22 Dec 2014 08:54:30 +1300 (NZDT) Received: from [192.168.22.129] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 6A2494AE5A0; Mon, 22 Dec 2014 08:54:30 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Jay Daley In-Reply-To: <8CC8F3E7-D6D9-47FA-8D58-F4154C5FE4DB@rfc1035.com> Date: Mon, 22 Dec 2014 08:54:30 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <0BB6FFC2-10FD-46AC-949B-1C837C6B549E@nzrs.net.nz> References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220204337.4F47026313BC@rock.dv.isc.org> <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> <8CC8F3E7-D6D9-47FA-8D58-F4154C5FE4DB@rfc1035.com> To: Jim Reid X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/5IMM6ubkH_zOB8uEC2tDo0ySFF4 Cc: DNSEXT Group Working , bert hubert Subject: Re: [dnsext] getting TLDs to fix other people's problems 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, 21 Dec 2014 19:54:45 -0000 > On 21/12/2014, at 10:47 pm, Jim Reid wrote: >=20 > Most registrars do not want registries to contact registrants - ever. = Registrars like to have total control over the communications to their = registrants, usually to the point where the registrant is unaware of the = registry's existence. Quite a few ccTLD registries have policies which = forbid the registry from contacting the registrant. Indeed. We (.nz) are just about to launch a redesigned registrar portal that = includes notifying registrars about 'bad' data, where 'bad' data = includes errors we see in our zone scan (some example classification = below) and also errors we see in the registrant data. There's no = obligation on the registrars to do anything with this data but in beta = testing we saw most of them act on the data, where they could, because = they wanted to be 'good' registrars. Of course they could all do this = scanning themselves but it's not a high enough priority for them to = write the code themselves and it turns out that they are pleased that we = are doing it for them. To be clear, we are one of those registries where our policy forbids us = from contacting registrants but that doesn't matter here because in our = view there would be no point at all in contacting registrants with this = same information. The only gap is third party DNS providers but we'll = get round to them at some point. cheers Jay Domains with broken delegation Domains with lame delegations Domains with inconsistent nameserver set Domains with extra nameserver at child Domains with extra nameserver at parent Domains with inconsistent serial numbers Domains with missing glue at child Domains with inconsistent glue Domains with nameserver pointing to CNAME Domains with no MX record Domains with nameservers in 1 ASN Domains with at least one nameserver with open recursion=20 Domains with at least one nameserver with open transfer Nameservers with open recursion Nameservers with open zone transfer Nameservers not answering TCP queries Nameservers not answering UDP queries --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From nobody Sun Dec 21 20:07:08 2014 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 A9FD61A0099 for ; Sun, 21 Dec 2014 20:07:06 -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 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 0liKIBx-pLeW for ; Sun, 21 Dec 2014 20:07:02 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097A91A009E for ; Sun, 21 Dec 2014 20:07:02 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id CD0FA1FCAB3; Mon, 22 Dec 2014 04:06:57 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 882A2160066; Mon, 22 Dec 2014 04:12:14 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 5255716004E; Mon, 22 Dec 2014 04:12:14 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 890E4263B845; Mon, 22 Dec 2014 15:06:53 +1100 (EST) To: Jim Reid From: Mark Andrews References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220204337.4F47026313BC@rock.dv.isc.org> <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> <20141221094454.GC13389@xs.powerdns.com> <11AD7639-D2AA-41F4-ACA4-70190E449253@rfc1035.com> In-reply-to: Your message of "Sun, 21 Dec 2014 10:18:19 -0000." <11AD7639-D2AA-41F4-ACA4-70190E449253@rfc1035.com> Date: Mon, 22 Dec 2014 15:06:53 +1100 Message-Id: <20141222040653.890E4263B845@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/UwFkIGUqZ5ye-0INHZMtD4mbbM0 Cc: DNSEXT Group Working , bert hubert Subject: Re: [dnsext] enough is enough 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, 22 Dec 2014 04:07:07 -0000 In message <11AD7639-D2AA-41F4-ACA4-70190E449253@rfc1035.com>, Jim Reid writes: > On 21 Dec 2014, at 09:44, bert hubert wrote: > > > This would then come with a website with further explanations, and > perhaps > > even a registry of faults that has been decided we're not going to fix. > > Bert, your prototype email is all very well. Of course it would be nice > if there was some botnet (say) which went looking for these broken DNS > servers and sent an email from the aa=0 police like the one you suggested. > > However this is howling at the moon. For decades the DNS industry has > been unable to get people to fix their lame delegations or get them to > stop using BIND8 or to use software which does EDNS or... So an attempt > along these lines to fix the aa=0 problem will be yet another Epic Fail. > If DNS lameness can't be cured, contacting registrants -- assuming that > was possible and it isn't -- to get software replaced surely won't > succeed either. To my knowledge no one has attempted to get nameservers upgraded by sending email to delegated server operators. Sending email to TLD operators does have a effect. Whether that can be replicated the next level down we need to see. Additionally classic lameness will come back over time as it is a configuration issue. Once you fix software it stays fixed. The more TLD operators that come on board the more likely it is to succeed. A DNS hosters getting complaints from all TLD operators is much more likely to pay attention to them. Similarly individual operators in multiple TLDs. > Everyone here should already know by now that contacting registrants en > masse will never produce the desired outcome. We should also know why > that approach is guaranteed to fail every time. Now who was it that said > "The definition of insanity is doing the same thing over and over again, > but expecting different results"? > The only sensible approach to take here is to notify the vendors of the > broken software and hope they do the Right Thing. If they don't, or their > customers can't/won't upgrade, the rest of us just have to suck it up. > 'Twas ever thus. At least the DNS developer community is small and fairly > easy to reach. Vendors also need to fix their software and no the DNS developer community isn't small enough to reach everyone. Going through zone operators is the only way to reach some of the players. Ultimately the zone operators need to update their nameservers and firewalls to be DNS compliant. Expecting them to learn that the need to update without a active campain will fail. > BTW, your Subject: header is appropriate. There's been more than enough > discussion of this deeply flawed approach to fixing the aa=0 problem. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Dec 21 21:50:44 2014 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 408F81A8838 for ; Sun, 21 Dec 2014 21:50:39 -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 nW-hox6hABpB for ; Sun, 21 Dec 2014 21:50:37 -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 E76AE1A0163 for ; Sun, 21 Dec 2014 21:50:36 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::b0a7:8760:fd77:de4d] (unknown [IPv6:2a02:80:3ffc:0:b0a7:8760:fd77:de4d]) by mail.frobbit.se (Postfix) with ESMTPSA id 93F631FF88; Mon, 22 Dec 2014 06:50:34 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B709CCBC-BC83-4C5B-8CD8-1B12F0F34DBD"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <20141221143310.GA28183@xs.powerdns.com> Date: Mon, 22 Dec 2014 06:50:33 +0100 Message-Id: <5F95A9A0-EC70-4F3E-9527-373640F9BBD4@frobbit.se> References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220204337.4F47026313BC@rock.dv.isc.org> <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> <20141221094454.GC13389@xs.powerdns.com> <55B7725D-1B11-4D8D-BDA3-43748E8E12A7@frobbit.se> <20141221143310.GA28183@xs.powerdns.com> To: bert hubert X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/BbMQqcoSbo5m-dUgClMyhlC5gd8 Cc: DNSEXT Group Working Subject: Re: [dnsext] enough is enough 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, 22 Dec 2014 05:50:39 -0000 --Apple-Mail=_B709CCBC-BC83-4C5B-8CD8-1B12F0F34DBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > On 21 dec 2014, at 15:33, bert hubert = wrote: >=20 > On Sun, Dec 21, 2014 at 11:33:17AM +0100, Patrik F=E4ltstr=F6m wrote: >>> The domain x.y.z fails to resolve using our software, and we have = determined >>> that this is because the software or hardware publishing the DNS = details of >>> x.y.z is not conforming to the DNS standards. >> As Jim says, your idea is nice as it is, and there is nothing wrong = with >> the email -- but we have no idea what so ever where to send it. >=20 > Actually, as the authors of a resolver, we know exactly where to send = it. To > the people telling me I need to fix my resolver so it works with = broken > domain X. Ok, good. That is exactly what I claim is the most effective way of = solving the issue. > And in turn, we've found that (together with resolver operators) we = can > quickly find out what broken hardware or software is behind the issue = - > Citrix Netscalers this time round. It helps if large operators (people = with > tens of millions of customers) tell them they need to clean up their = act. Yes. > The REAL issue right now is that we can't resist fixing a broken = domain > "because it works with Google/Unbound/Bind/Microsoft, so you must fix = it". >=20 > What is needed is a pact that none of us will respect that argument on = its > own if a domain actually should be broken. >=20 >> The best path forward is I think still for you to publish clear and = crisp >> information like this on your web page so that it is found when = searching >> for help with Google and other search engines. >>=20 >> I.e. as long as no one have any issues with the brokenness, it will = not be fixed. >=20 > Exactly. It should actually break therefore. If you own dodgy = equipment or > use bad software, your domain should receive lots of reports of = brokenness. >=20 >> If not even TLDs are hosted correctly, and registry policies are such = that >> it encourages broken DNS configurations, I feel there is not much The >> Protocol Police can do about it. >=20 > I'm afraid this is true. But if all big implementation decide to no = longer > play the game, the (mostly) load balancer implementations will have to = clean > up their act. >=20 > I also note that quite a lot of problems are AAAA related. This in = itself is > an impediment to IPv6 adoption! Yes. Patrik --Apple-Mail=_B709CCBC-BC83-4C5B-8CD8-1B12F0F34DBD 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 iD8DBQFUl7EqrMabGguI180RAnaXAKCR+u4RdmSLH6bW3pGyIpGFazjl7gCgichW WEY57V9anJBSY37n2EAtiVc= =Q01z -----END PGP SIGNATURE----- --Apple-Mail=_B709CCBC-BC83-4C5B-8CD8-1B12F0F34DBD-- From nobody Sun Dec 21 21:55:34 2014 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 2B06B1A00E1 for ; Sun, 21 Dec 2014 21:55:30 -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 v4sqiVliW3Sl for ; Sun, 21 Dec 2014 21:55:29 -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 270F31A00D1 for ; Sun, 21 Dec 2014 21:55:29 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::b0a7:8760:fd77:de4d] (unknown [IPv6:2a02:80:3ffc:0:b0a7:8760:fd77:de4d]) by mail.frobbit.se (Postfix) with ESMTPSA id BF2A7201B7; Mon, 22 Dec 2014 06:55:27 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A4C6B9DD-1C46-4C1C-AB7A-5BA29977737E"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <20141222040653.890E4263B845@rock.dv.isc.org> Date: Mon, 22 Dec 2014 06:55:27 +0100 Message-Id: References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220204337.4F47026313BC@rock.dv.isc.org> <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> <20141221094454.GC13389@xs.powerdns.com> <11AD7639-D2AA-41F4-ACA4-70190E449253@rfc1035.com> <20141222040653.890E4263B845@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/84PqHPsLxB46sHRAI49rRDPiAs8 Cc: DNSEXT Group Working , bert hubert Subject: Re: [dnsext] enough is enough 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, 22 Dec 2014 05:55:30 -0000 --Apple-Mail=_A4C6B9DD-1C46-4C1C-AB7A-5BA29977737E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 22 dec 2014, at 05:06, Mark Andrews wrote: >=20 > To my knowledge no one has attempted to get nameservers upgraded > by sending email to delegated server operators. Maybe because one do not know who these name server operators are. And = in the cases one do (like in some ccTLDs), that has other drawbacks. > Sending email to TLD operators does have a effect. Well, well... > Whether that can be replicated the next level down we need to see. Some TLD registries have tried to contact DNS operators, some contact = the registrant, some contact the registrar. > Additionally classic lameness will come back over time as it is a = configuration issue. And my point was only that enough registries do have a policy that = REQUIRE lame delegations to be able to just register a domain name (i.e. = one can not register without delegating at the same time). Crazy! But as you say, this is a configuration issue, and not a software issue. Patrik --Apple-Mail=_A4C6B9DD-1C46-4C1C-AB7A-5BA29977737E 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 iD8DBQFUl7JPrMabGguI180RAsdoAKCVkUDIBpC6uYqwB5vzY3WpZq+GwACff8jM lDE+BmVGpvLztGcz6E7HKTQ= =KCht -----END PGP SIGNATURE----- --Apple-Mail=_A4C6B9DD-1C46-4C1C-AB7A-5BA29977737E-- From nobody Sun Dec 21 22:58:10 2014 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 C1BBA1A89F5 for ; Sun, 21 Dec 2014 22:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JqorlI7t8948 for ; Sun, 21 Dec 2014 22:58:08 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC3D1A89EF for ; Sun, 21 Dec 2014 22:58:07 -0800 (PST) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP id 67A6F3493B8; Mon, 22 Dec 2014 06:58:04 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 02AF2160067; Mon, 22 Dec 2014 07:03:22 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 8C844160059; Mon, 22 Dec 2014 07:03:21 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 62ED8263C4C2; Mon, 22 Dec 2014 17:58:00 +1100 (EST) To: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= From: Mark Andrews References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220204337.4F47026313BC@rock.dv.isc.org> <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> <20141221094454.GC13389@xs.powerdns.com> <11AD7639-D2AA-41F4-ACA4-70190E449253@rfc1035.com> <20141222040653.890E4263B845@rock.dv.isc.org> In-reply-to: Your message of "Mon, 22 Dec 2014 06:55:27 +0100." Date: Mon, 22 Dec 2014 17:58:00 +1100 Message-Id: <20141222065800.62ED8263C4C2@rock.dv.isc.org> Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/EqdjTH7AWq5Jif7T3q48T-LHx_o Cc: DNSEXT Group Working , bert hubert Subject: Re: [dnsext] enough is enough 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, 22 Dec 2014 06:58:09 -0000 In message , =?utf-8?Q?Patrik_F=C3=A4lt str=C3=B6m?= writes: > > On 22 dec 2014, at 05:06, Mark Andrews wrote: > > > > To my knowledge no one has attempted to get nameservers upgraded > > by sending email to delegated server operators. > > Maybe because one do not know who these name server operators are. And in > the cases one do (like in some ccTLDs), that has other drawbacks. Send it to the SOA RNAME. If that does not work send it to the registrant (by the registrar if need be). They are ultimately responsible for the domain. If those contact methods bounce initiate the proceedures for broken contacts. > > Sending email to TLD operators does have a effect. > > Well, well... > > > Whether that can be replicated the next level down we need to see. > > Some TLD registries have tried to contact DNS operators, some contact the > registrant, some contact the registrar. The registrant is ultimately responsible for picking the registrar and DNS operator if it is not themselves. It is the registrars job to contact the registrant on behalf of the registry where the contract precludes direct contact. > > Additionally classic lameness will come back over time as it is a > > configuration issue. > > And my point was only that enough registries do have a policy that > REQUIRE lame delegations to be able to just register a domain name (i.e. > one can not register without delegating at the same time). Crazy! > > But as you say, this is a configuration issue, and not a software issue. No. That is a policy issue. Just because you do not like the policy is not a reason to not configure servers if that is the policy of the parent domain. It's not like they won't be running some servers for some zones. Those servers can be configured with minimal zones (soa + ns records). > Patrik -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Dec 21 23:55:52 2014 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 C86011A888A for ; Sun, 21 Dec 2014 23:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tYDL91r7ovAL for ; Sun, 21 Dec 2014 23:55:47 -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 9EB661A0178 for ; Sun, 21 Dec 2014 23:55:47 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::22] (unknown [IPv6:2a02:80:3ffc::22]) by mail.frobbit.se (Postfix) with ESMTPSA id 8DA0722720; Mon, 22 Dec 2014 08:55:45 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_40FFC7EC-131F-445E-B560-D9CBD4F41EFE"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b3 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <20141222065800.62ED8263C4C2@rock.dv.isc.org> Date: Mon, 22 Dec 2014 08:55:43 +0100 Message-Id: <7EF869A5-FCFD-4BC8-8AC8-0C724980FD9A@frobbit.se> References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220204337.4F47026313BC@rock.dv.isc.org> <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> <20141221094454.GC13389@xs.powerdns.com> <11AD7639-D2AA-41F4-ACA4-70190E449253@rfc1035.com> <20141222040653.890E4263B845@rock.dv.isc.org> <20141222065800.62ED8263C4C2@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/uTxSprobnBB4D0M5woIn2Lw47j0 Cc: DNSEXT Group Working , bert hubert Subject: Re: [dnsext] enough is enough 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, 22 Dec 2014 07:55:50 -0000 --Apple-Mail=_40FFC7EC-131F-445E-B560-D9CBD4F41EFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 22 Dec 2014, at 07:58, Mark Andrews wrote: >=20 > Just because you do not like the policy is not a reason to not > configure servers if that is the policy of the parent domain. It's > not like they won't be running some servers for some zones. Those > servers can be configured with minimal zones (soa + ns records). That is exactly my point. As long as registrant and registry disagree = about _policy_ we will see issues like these, regardless of what the = protocol police say. You see it, as I expressed in my list, regarding proxy registrations, = lame delegations and more. If you look at the various TLDs, you see much less issues with proxy and = lame delegations where the policy is such that: - One can register a domain name without delegating - Anyone can register a domain name And my point is that before we have those basic rules in a TLD, chasing = down registrants, registrars, DNS hosting providers and whoever else = will have limited if any effect. In TLDs where those are the basic rules, then the protocol police might = have effect. Patrik --Apple-Mail=_40FFC7EC-131F-445E-B560-D9CBD4F41EFE 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 iEYEARECAAYFAlSXzoAACgkQrMabGguI182DiACfWaxd0tQ+xFBs7jdHsfVw/gBp diwAnjk7rElY3cQbHYgnkhJDrLmjjTxx =4DUU -----END PGP SIGNATURE----- --Apple-Mail=_40FFC7EC-131F-445E-B560-D9CBD4F41EFE-- From nobody Mon Dec 22 01:17:04 2014 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 DB7A51A8A3F for ; Mon, 22 Dec 2014 01:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, 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 eYYJhUEYsQK0 for ; Mon, 22 Dec 2014 01:17:00 -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 0EBB81A8A20 for ; Mon, 22 Dec 2014 01:17:00 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 1C1C12803B1 for ; Mon, 22 Dec 2014 10:16:58 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 185542802E1 for ; Mon, 22 Dec 2014 10:16:58 +0100 (CET) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id 1681CB3803E for ; Mon, 22 Dec 2014 10:16:28 +0100 (CET) Date: Mon, 22 Dec 2014 10:16:28 +0100 From: Stephane Bortzmeyer To: DNSEXT Group Working Message-ID: <20141222091627.GB17938@nic.fr> References: <20141220125805.GB20765@xs.powerdns.com> <20141220142506.C7EA12630502@rock.dv.isc.org> <20141220204337.4F47026313BC@rock.dv.isc.org> <7A31183A-CC1E-4F0A-A2EA-848B10B60A2B@insensate.co.uk> <20141221094454.GC13389@xs.powerdns.com> <11AD7639-D2AA-41F4-ACA4-70190E449253@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11AD7639-D2AA-41F4-ACA4-70190E449253@rfc1035.com> X-Operating-System: Debian GNU/Linux 8.0 X-Kernel: Linux 3.16.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dnsext/5tmlPrxlh4NyZ14-05M-lVeLMxw Subject: Re: [dnsext] enough is enough 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, 22 Dec 2014 09:17:02 -0000 On Sun, Dec 21, 2014 at 10:18:19AM +0000, Jim Reid wrote a message of 34 lines which said: > However this is howling at the moon. For decades the DNS industry > has been unable to get people to fix their lame delegations or get > them to stop using BIND8 or to use software which does EDNS or... An experience at AFNIC: between 1996 and 2012, we had a mandatory pre-delegation (and also pre-registration, which was not a good idea) technical test, implemented by the Zonecheck program. During this period, we had a lot of angry customers, many insults (ranging from "incompetent bastards" to "lazy civil servants"), many calls upon the ghost of Postel ("you should accept what is obviously broken") and our dose of french-bashing Registrars complained, bloggers complained, industry analysts complained. Nobody supported us, not even the people and organisation who have their mouth full of big words like "security and stability". And noone tried to imitate us... Even if you are a non-profit organisation, you have to pay the bills (and the employees) so in the end, the forces of the free market won. Zonecheck mandatory testing was retired in december 2012 (french only)