From internet-drafts@ietf.org Mon Nov 5 12:45:05 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B7121F86CF; Mon, 5 Nov 2012 12:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0-3BzjptZt7; Mon, 5 Nov 2012 12:45:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BED121F84D5; Mon, 5 Nov 2012 12:45:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121105204504.30126.52981.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 12:45:04 -0800 Cc: dnsop@ietf.org Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-dps-framework-11.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 20:45:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Domain Name System Operations Working Gro= up of the IETF. Title : A Framework for DNSSEC Policies and DNSSEC Practice Stat= ements Author(s) : Fredrik Ljunggren Anne-Marie Eklund Lowinder Tomofumi Okubo Filename : draft-ietf-dnsop-dnssec-dps-framework-11.txt Pages : 27 Date : 2012-11-05 Abstract: This document presents a framework to assist writers of DNSSEC Policies and DNSSEC Practice Statements, such as Domain Managers and Zone Operators on both the top-level and secondary level, who are managing and operating a DNS zone with Security Extensions (DNSSEC) implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-dps-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-dnssec-dps-framework-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fredrik@kirei.se Mon Nov 5 13:01:08 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B215B21F85AC for ; Mon, 5 Nov 2012 13:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqcH4oesI1QA for ; Mon, 5 Nov 2012 13:01:07 -0800 (PST) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2A621F874A for ; Mon, 5 Nov 2012 13:01:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer; bh=QnNrGw4As8+83pI+MljWQFkZvAhrBH7nRPBg7TobXp8=; b=Is7Tk3gPrzc5DBpqSVDYwvzJn6YtK6ty3ogy8Ebm07Yi3XEyl6z+odfJ/Rysd7Y3NlqicDcdXOel8 3pdQ/cd+4/q8DptDOwvyEWuP0PWU4h98VuwG0gJ35dTIp9DQRmzk8r9nYR0+1yzTUiuSfI4h6JAbwu xY4ejZnDIcOsJ3DY= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS for ; Mon, 5 Nov 2012 22:01:02 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Fredrik Ljunggren In-Reply-To: <20121105204504.30126.52981.idtracker@ietfa.amsl.com> Date: Mon, 5 Nov 2012 22:00:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4096627B-487C-45F1-B23C-591BC4260C31@kirei.se> References: <20121105204504.30126.52981.idtracker@ietfa.amsl.com> To: "dnsop@ietf.org" X-Mailer: Apple Mail (2.1498) Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-dps-framework-11.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 21:01:09 -0000 WG, Version -11 of the draft-ietf-dnsop-dnssec-dps-framework has been = published and resolves the DISCUSSes raised by the IESG. Apart from = miscellaneous corrections and some rephrasing to make things clearer, = the significant differences between the -08 version sent to the IESG = after WGLC and the latest -11 version are: 1. Introduction * Added paragraph clarifiying that the DP/DPS are not primarily aimed at = DNS users, rather they are aimed at other stakeholders (e.g. regulatory = authorities). * Removed paragraphs contrasting the DPS with PKI. 2. Definitions * Add definition of multi-person control. 4.1.4 Specification administration * Expanded first pragraph to clarify that the subcomponent includes a = description of notification mechanisms used to provide advance notice of = changes to the DP/DPS. 4.4.4 Audit logging procedures * Expanded the list of examples of the types of events recorded. 4.5.5 Computer security controls * Removed sentence about product assurance, as this was mistakenly = mentioned twice * Removed paragraph about the computer security rating. The changes in section 7 (security considerations) introduced in version = -09 suggesting a key could be rolled as a means of signalling a change = of DP/DPS have been removed. These were added as a result of a = misunderstanding of the nature of one of the DISCUSSes and were not = required to overcome objection. Best regards, - Fredrik On 2012-11-05, at 21:45, Internet-Drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Domain Name System Operations Working = Group of the IETF. >=20 > Title : A Framework for DNSSEC Policies and DNSSEC = Practice Statements > Author(s) : Fredrik Ljunggren > Anne-Marie Eklund Lowinder > Tomofumi Okubo > Filename : draft-ietf-dnsop-dnssec-dps-framework-11.txt > Pages : 27 > Date : 2012-11-05 >=20 > Abstract: > This document presents a framework to assist writers of DNSSEC > Policies and DNSSEC Practice Statements, such as Domain Managers and > Zone Operators on both the top-level and secondary level, who are > managing and operating a DNS zone with Security Extensions (DNSSEC) > implemented. >=20 > In particular, the framework provides a comprehensive list of topics > that should be considered for inclusion into a DNSSEC Policy > definition and Practice Statement. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-dps-framework >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework-11 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsop-dnssec-dps-framework-1= 1 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nweaver@icsi.berkeley.edu Thu Nov 8 09:59:16 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300E621F879C for ; Thu, 8 Nov 2012 09:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYXj-Syy9ACY for ; Thu, 8 Nov 2012 09:59:15 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id C660221F8536 for ; Thu, 8 Nov 2012 09:59:15 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 8940C2C4021 for ; Thu, 8 Nov 2012 09:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kPjcDWOhAsRq; Thu, 8 Nov 2012 09:59:15 -0800 (PST) Received: from gala.icir.org (gala [192.150.187.49]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 555922C4004; Thu, 8 Nov 2012 09:59:15 -0800 (PST) From: Nicholas Weaver Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 8 Nov 2012 09:59:15 -0800 Message-Id: To: dnsop@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: Nicholas Weaver Subject: [DNSOP] Question: unknown EDNS0 options and recursive resolvers? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 17:59:16 -0000 How do recursive resolvers react to unknown EDNS0 options? Are the requests simply dropped? Is the unknown option removed and ignored? Passed to the authority unchanged? From Ray.Bellis@nominet.org.uk Thu Nov 8 10:24:35 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B400A21F8550 for ; Thu, 8 Nov 2012 10:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwrXOL88BCkX for ; Thu, 8 Nov 2012 10:24:30 -0800 (PST) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3077B21F850A for ; Thu, 8 Nov 2012 10:24:26 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV: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:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=GF6n+MWx+FTqvHbK+ZSJ6SPpJB6Lv/LQZbtq/lsfoyVXCt7osFy1zAmt 63TZVa3fFFceQIJ+qCsZ7fUokW8RPa4TD1bhN4smgp3/k4Gf3CabRRP/1 VW7tfwEfbKKYINL; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1352399066; x=1383935066; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[DNSOP]=20Question:=20unknown=20EDNS0 =20options=20and=20recursive=20resolvers?|Date:=20Thu,=20 8=20Nov=202012=2018:24:24=20+0000|Message-ID:=20<20658AB5 -41CB-4361-BEA9-5E9429E09AAD@nominet.org.uk>|To:=20Nichol as=20Weaver=20|CC:=20""=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<279b0c03-2eb4-48d7-8078-082c7a191be4> |In-Reply-To:=20|References:=20; bh=iZP4HAo7KwsKmSB8SxOmu3YGDeampkpMLvnEFukIIwg=; b=HFMLTb3dZWcjdo812HWvbTXxGIpdD/4KGCI+zyV5Uq1oP7eJRBJeh0a5 uRP6bV5jhWH4tEXygY/TFeDCbTdGJh/q3QB2MoJMwsA8q6LNn2Pd6NjrH HBCFEaoouwiq/HX; X-IronPort-AV: E=Sophos;i="4.80,739,1344207600"; d="scan'208";a="44479647" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 08 Nov 2012 18:24:25 +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%17]) with mapi; Thu, 8 Nov 2012 18:24:24 +0000 From: Ray Bellis To: Nicholas Weaver Thread-Topic: [DNSOP] Question: unknown EDNS0 options and recursive resolvers? Thread-Index: AQHNvdrQU2z8+m8aH0mJoKB7fOfziJfgQNgA Date: Thu, 8 Nov 2012 18:24:24 +0000 Message-ID: <20658AB5-41CB-4361-BEA9-5E9429E09AAD@nominet.org.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <279b0c03-2eb4-48d7-8078-082c7a191be4> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [DNSOP] Question: unknown EDNS0 options and recursive resolvers? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 18:24:35 -0000 On 8 Nov 2012, at 12:59, Nicholas Weaver wrote: >=20 > How do recursive resolvers react to unknown EDNS0 options? >=20 > Are the requests simply dropped? =20 > Is the unknown option removed and ignored? =20 > Passed to the authority unchanged? They certainly shouldn't do the latter - EDNS is supposed to be "hop by hop= ", not "end to end". RFC 2671 appears silent on drop vs ignore. 2671bis explicitly says "ignore= ". Ray From marka@isc.org Thu Nov 8 12:10:09 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE9321F868D for ; Thu, 8 Nov 2012 12:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHehGUY2fJbg for ; Thu, 8 Nov 2012 12:10:08 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 4865C21F8615 for ; Thu, 8 Nov 2012 12:10:08 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 857E95FA7F1; Thu, 8 Nov 2012 20:09:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:f058:e8e4:a6cf:c415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id B83E5216C3D; Thu, 8 Nov 2012 20:09:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 261A12B099C0; Fri, 9 Nov 2012 07:09:51 +1100 (EST) To: Ray Bellis From: Mark Andrews References: <20658AB5-41CB-4361-BEA9-5E9429E09AAD@nominet.org.uk> In-reply-to: Your message of "Thu, 08 Nov 2012 18:24:24 -0000." <20658AB5-41CB-4361-BEA9-5E9429E09AAD@nominet.org.uk> Date: Fri, 09 Nov 2012 07:09:51 +1100 Message-Id: <20121108200951.261A12B099C0@drugs.dv.isc.org> Cc: "" , Nicholas Weaver Subject: Re: [DNSOP] Question: unknown EDNS0 options and recursive resolvers? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 20:10:09 -0000 In message <20658AB5-41CB-4361-BEA9-5E9429E09AAD@nominet.org.uk>, Ray Bellis writes: > > On 8 Nov 2012, at 12:59, Nicholas Weaver > wrote: > > > > > How do recursive resolvers react to unknown EDNS0 options? > > > > Are the requests simply dropped? > > Is the unknown option removed and ignored? > > Passed to the authority unchanged? > > They certainly shouldn't do the latter - EDNS is supposed to be "hop by > hop", not "end to end". > > RFC 2671 appears silent on drop vs ignore. 2671bis explicitly says > "ignore". And it wouldn't be drop in any case. It would be NOTIMP/FORMERR vs ignore. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From iesg-secretary@ietf.org Tue Nov 13 05:53:17 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3176821F8665; Tue, 13 Nov 2012 05:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcSo4XWMq+aM; Tue, 13 Nov 2012 05:53:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7728221F8695; Tue, 13 Nov 2012 05:53:15 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121113135315.4082.47008.idtracker@ietfa.amsl.com> Date: Tue, 13 Nov 2012 05:53:15 -0800 Cc: dnsop mailing list , dnsop chair , RFC Editor Subject: [DNSOP] Document Action: 'A Framework for DNSSEC Policies and DNSSEC Practice Statements' to Informational RFC (draft-ietf-dnsop-dnssec-dps-framework-11.txt) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 13:53:17 -0000 The IESG has approved the following document: - 'A Framework for DNSSEC Policies and DNSSEC Practice Statements' (draft-ietf-dnsop-dnssec-dps-framework-11.txt) as Informational RFC This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Ronald Bonica and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-dps-framework/ Technical Summary This document presents a framework to assist writers of DNSSEC Policies and DNSSEC Practice Statements, such as Domain Managers and Zone Operators on both the top-level and secondary level, who are managing and operating a DNS zone with Security Extensions (DNSSEC) implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. Working Group Summary This document is the product of the DNSOPS WG. The discussion regarding this document was brief and low-key. Document Quality To assess the applicability and usefulness of the document, a survey about DNSSEC policy and practice statements was conducted by the authors amongst members of CENTR (Council of European National Top Level Domain Registries). Among the questions were some asking whether they had heard about draft-ietf-dnsop-dnssec-dps-framework (then at version -03). Of the 19 respondents, 17 had heard about the draft and 13 had used it as a check list of DNSSEC readiness and/or an outline to create such a document. Personnel Stephen Morris is the document shepherd. Ron Bonica is the responsible Area Director. From bortzmeyer@nic.fr Mon Nov 19 02:19:09 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70B221F858F for ; Mon, 19 Nov 2012 02:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.175 X-Spam-Level: X-Spam-Status: No, score=-100.175 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_20=-0.74, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3E3r9qJz-PY for ; Mon, 19 Nov 2012 02:19:09 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 110CF21F8570 for ; Mon, 19 Nov 2012 02:19:09 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 44A7A280605 for ; Mon, 19 Nov 2012 11:18:34 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 4154B28050C for ; Mon, 19 Nov 2012 11:18:34 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay2.nic.fr (Postfix) with ESMTP id 36121B38004 for ; Mon, 19 Nov 2012 11:18:34 +0100 (CET) Date: Mon, 19 Nov 2012 11:18:34 +0100 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20121119101834.GA23238@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.2.0-3-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [DNSOP] Declaring HTTPS mandatory in the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 10:19:09 -0000 I vaguely remember that there was an Internet-Draft about declaring, in the DNS, that a HTTP server MUST be accessed only by HTTPS. But I cannot find it, either with the Datatracker or with Google. Any pointer? (I know about draft-ietf-websec-strict-transport-sec, which is a HTTP solution, I'm looking for a DNS one.) From kcd@chrysler.com Mon Nov 19 04:33:21 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9B821F8616 for ; Mon, 19 Nov 2012 04:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sst1YKp0Avwu for ; Mon, 19 Nov 2012 04:33:14 -0800 (PST) Received: from odbmap02.extra.chrysler.com (odbmap02.out.extra.chrysler.com [129.9.40.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6B55121F8576 for ; Mon, 19 Nov 2012 04:33:03 -0800 (PST) Received: from odbmap04.oddc.chrysler.com (Unknown_Domain [53.28.32.58]) by odbmap02.extra.chrysler.com (Symantec Messaging Gateway) with SMTP id 1C.28.02812.8F62AA05; Mon, 19 Nov 2012 07:32:56 -0500 (EST) X-AuditID: 8109281a-b7f646d000000afc-79-50aa26f884cf Received: from odmsp089-ipmp.oddc.chrysler.com (odmsp089-ipmp.oddc.chrysler.com [53.231.96.248]) by odbmap04.oddc.chrysler.com (Symantec Messaging Gateway) with SMTP id 55.71.02648.7F62AA05; Mon, 19 Nov 2012 07:32:55 -0500 (EST) Received: from [10.136.151.144] (CITMNCNU1410TPT.cg.chrysler.com [10.136.151.144]) by odmsp089-ipmp.oddc.chrysler.com (8.13.8+Sun/8.13.8/chrysler-relay-1.4-kcd) with ESMTP id qAJCWt2t023942 for ; Mon, 19 Nov 2012 07:32:55 -0500 (EST) Message-ID: <50AA26F7.3030105@chrysler.com> Date: Mon, 19 Nov 2012 07:32:55 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: dnsop@ietf.org References: <20121119101834.GA23238@nic.fr> In-Reply-To: <20121119101834.GA23238@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA11Ta0gUURjtzow6mjfHUdfruKauFpJl9qIn9iDE+uNIZGCFjTq5i7vrNrOb WkhbUIR/ihQySzAwNu2h2UMxyloDH0FmQVHho9KiqCjDHlTU3N0dne3fN+d835zvnI9Lk2wH zdEmq12UrILZEBhCLdMnrFrwY24zn/56mFgx9OExtQ5kNTb+JHiQF7KmSDSb9orSwoxdIca+ rmbCNhJWXnN3MsAJHoVWgWAaMUtR7bsHpLfWoYfDLYFVIIRmmQGATr8cJ9Wmqy3HSS/xBqDf baMB3o8/AF1oGgW4CzKpaGzyJoVripmDPr3oCMR1IJOMOp+7gnAdxeQh95W7Qd7+cNR3aszT H8mwaPLZvQBcRzArUde578osrQikoq7xTAwHM/PRscbTFIZJZjX6dlPCMMnEo/aPZzy7IaY6 CE2ODVDHAVunUaibHqnTjDQAshnElhYVWARb+uI0sdwuCWmFRqlCNotSWmGppQ0o+R4MTuE6 wHg9dIMSmjBEwcHEZp6dVVBaVGEUZGO+5DCLsiESupIUGE7BBQ5ziYGDQcph2Igp1CqWKT+3 K9czzIYxZ8/zbPQUJztkm6nQVOqQ8x2S2Q1iacoQDYmGHTzLFAt2sUQUbaLk1XODMpo2IDg0 R/l9uCQWi+W7TWa7SitzhxIUhtEyno3iYOfPJp7VaQnNUokweUKhOS39/14EHewGxXSo4pnC 7qBsEyyyqdgnHQG/4qVCVdQjGwO/YZBVQY1kHMzDOehUyl+uH1Rw0fAzHmZwh9FhnXLJ6WDv NhfPhmkIrMbp4SDGozT4tCCXAO9jNkbD+muqr+o9KKSB4of3+FHe3LRJFr7E4Ewf6PGI4CvP NXyYxqIeWnPwPj7GX+29kiWhZPmEd+Es7YJdmyXA5whVUTXLL004Sx/ol+VfTOlUyl+JcwJp fOJ2WOrsi7nr2+W0VDp/S9Id/aKJA3sqt2fdaVne+vbUpYGwnMoDR7Jn7Oxa3eTqqVwx2Bqf dLR8c1TRkaqe7l+3nNf1ZbnVBPHVeSLjV7bFmdl/9K91bWY9Wds+kjDU0r0p9kbttSVcyomn 6eatNWhko+UwDI/fsL9nubt33+WTBko2CovmkZIs/AP3UYBoywQAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrAIsWRmVeSWpSXmKPExsVi+jzhh+53tVUBBldvmVrcfXOZxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGSf3r2IquM9fMeXgV9YGxks8XYycHBICJhKb109ghrDFJC7c W8/WxcjFISTwjFHiz6YHrBDOX0aJ1SsfMIJU8QpoSzz5upsFxGYRUJV4d3sHG4jNJqAisevW cnYQW1QgSuLQxoPsEPWCEidnPgGrFxEQkvh68wgriC0sYCmxf+l3oF4OoAXaEvufuoGEOQV0 JPqXzGYBCTMLWEt8210EEmYWkJfY/nYO8wRG/llIhs5CqJqFpGoBI/MqRqn8lKTcxAIDE738 lJRkveSMosrinNQiveT83E2MoICTUbDcwTj3hvwhRgEORiUe3skKqwKEWBPLiitzDzFKcjAp ifJeVAQK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuF9pQSU401JrKxKLcqHSUlzsCiJ8wpZLA0Q EkhPLEnNTk0tSC2CycpwcChJ8AoAI0tIsCg1PbUiLTOnBCHNxMEJMpwHaDgLSA1vcUFibnFm OkT+FKOilDjvB1WghABIIqM0D64XlhBeMYoDvSIM0c4DTCZw3a+ABjMBDb4WsBxkcEkiQkqq gXFCz9K4EOeZJxYuXeQurv886rvNRpl/Vx2bsqdMXTDZqjWn5UxieGfG99y1hvN+aT18nCyk 1HqDIaB/+/MCPp+HV91b/nSU1N2zfi6aHS2RovVmos2VymnBjytNmE8/vHhw14PZL58Wrey8 +adyUQvLA0PDOcczYhNub67f1Lbg6czTwTvC+78rsRRnJBpqMRcVJwIAux9SxuMCAAA= Subject: Re: [DNSOP] Declaring HTTPS mandatory in the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 12:33:21 -0000 On 11/19/2012 5:18 AM, Stephane Bortzmeyer wrote: > I vaguely remember that there was an Internet-Draft about declaring, > in the DNS, that a HTTP server MUST be accessed only by HTTPS. But I > cannot find it, either with the Datatracker or with Google. Any > pointer? The closest you're likely to find that is in http://tools.ietf.org/id/draft-jennings-http-srv-05.txt draft (expired), where an HTTPS SRV record might be published for a given site, but no equivalent HTTP SRV record. That would implicitly be a "declaration" that only HTTPS was supported for the site. Honestly though, I foresee that even if SRV record lookup is adopted by the browser community, for many years after that, browsers will continue to fall back to non-SRV-based connection methods. So the absence of an HTTP SRV record is not likely to prevent many HTTP connection attempts in the short to medium term. > (I know about draft-ietf-websec-strict-transport-sec, which is a HTTP > solution, I'm looking for a DNS one.) > > Despite what the Wikipedia page says, that ID doesn't really define a "declaration" that HTTPS is preferred over HTTP as the transport to be used for accessing a given web host. The use of HTTPS is *assumed*, throughout the ID, in order for the mechanisms defined therein to occur, e.g. the use of the special "Strict-Transport-Security" HTTP header. The only major reference to non-secure HTTP is a generic recommendation ("SHOULD") to perform a 301 redirect from HTTP to HTTPS (which hardly needs an ID callout, since it's _de_facto_ standard anyway). The ID does make reference to a possible "HSTS Pre-Loaded List", i.e. a list of sites that a browser would know _a_priori_ to implement HSTS, but there is no automated mechanism defined to publish/distribute that list, other than a vague suggestion (Section 12.3) that site owners and browser implementors get together to bake the list into the software "at the factory". - Kevin From i.grok@comcast.net Mon Nov 19 06:05:48 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AA021F862B for ; Mon, 19 Nov 2012 06:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGj67KSWsVcq for ; Mon, 19 Nov 2012 06:05:47 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id C42D121F8608 for ; Mon, 19 Nov 2012 06:05:46 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta05.westchester.pa.mail.comcast.net with comcast id RR6x1k0041uE5Es55S5m81; Mon, 19 Nov 2012 14:05:46 +0000 Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta16.westchester.pa.mail.comcast.net with comcast id RS5l1k00a2Ekl483cS5lrh; Mon, 19 Nov 2012 14:05:46 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.5) with ESMTP id qAJE5hah028244 for ; Mon, 19 Nov 2012 09:05:43 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id qAJE5hLi028243 for dnsop@ietf.org; Mon, 19 Nov 2012 09:05:43 -0500 Date: Mon, 19 Nov 2012 09:05:43 -0500 From: Scott Schmit To: dnsop@ietf.org Message-ID: <20121119140543.GB28040@odin.ulthar.us> Mail-Followup-To: dnsop@ietf.org References: <20121119101834.GA23238@nic.fr> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: <20121119101834.GA23238@nic.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [DNSOP] Declaring HTTPS mandatory in the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 14:05:48 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 19, 2012 at 11:18:34AM +0100, Stephane Bortzmeyer wrote: > I vaguely remember that there was an Internet-Draft about declaring, > in the DNS, that a HTTP server MUST be accessed only by HTTPS. But I > cannot find it, either with the Datatracker or with Google. Any > pointer? Perhaps you're thinking of this expired draft: draft-hoffman-server-has-tls? --=20 Scott Schmit --J2SCkAp4GZ/dPZZf Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQBAYJKoZIhvcNAQcCoIIP9TCCD/ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DTUwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBvkwggXhoAMCAQICAwR4CjANBgkqhkiG 9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDcwNDEz NTc1MVoXDTEzMDcwNTA1MjcyNlowQDEbMBkGA1UEAwwSaS5ncm9rQGNvbWNhc3QubmV0MSEw HwYJKoZIhvcNAQkBFhJpLmdyb2tAY29tY2FzdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCxn+QJTgdUJ1RAOi6JbFsDfl21ZX/OPx/ttuXWQP1vWwBZybHU+4/+bRXH 5ONhjbc5ikZvz/E406iQLy2xMT5PI/hx4uIZQQYpkjxd4rCbbvLNACz5L+cFaGj4WfGwAXDv bw4nx8Mh3WjbR5yjBCWYqadiv7HWAWmhaJmuaTp/e+mO2EEOOdoNQ8b2mxMyN43TlElx6Zos t7g/eQUcLWgTB5apPhowCCGnFU6uHK053QsPmsmZ67gg8acpb5ic0+P+X1j+IgD3jcsDzjrF TPlrvU4ZuBYQJISqngbc2ua/uutx75Xs4iFXWNRlnYfZMFJy96USzrhIBRqcORrjbyGXAgMB AAGjggOtMIIDqTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwHQYDVR0OBBYEFAxkdHPHW3mhf+gXJjezdazgoDRuMB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB0GA1UdEQQWMBSBEmkuZ3Jva0Bjb21jYXN0Lm5ldDCC AiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3 YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVt ZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i bGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBT ZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9h aWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBACJi0f4m 0bSVq+pq4AHeC2Rj4S8rciW+Uce6LC69UlyVMijKv/pZNFM08vqRXEI9WpKQhKXacJ+rK9az DBmnxq1scqKhn7991V6Yt2t0tEY8vUX7q330GybUB/rQLNrh66GFXaEWU/S692pGzvUXeV+w zz48snMpoMHQdxkHHW5sQkpo99SF/vOA5/sqvFmJ+ai1iDRjtKcChjkmAtFmCKv/dNrXnvew 5+QnLlnE/TsW4Sdv3bcLdlthD4eavS3BdgXfX7dfj0ykel53J2Us3CikNbyuCsJpwMH+gX1j LcXZOYIDLzZXCFEOFajhgsAZ5JQrW0fFRxjGIp8Rs+rxdFwxggKXMIICkwIBATCBlDCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEeAowCQYFKw4DAhoFAKCB2DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMTkxNDA1NDNaMCMG CSqGSIb3DQEJBDEWBBQTGk7x9GUBIzpLJVA4cmh4AC9iRzB5BgkqhkiG9w0BCQ8xbDBqMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq hkiG9w0BAQEFAASCAQBHUKnLqKMfFxlJvV9kFy9DlOhw5YiuOGWXQk5GNrjiCFgDe3lOkUGU UA1N1WtuLR2ck88FvUobKGdLuFBj4Zqhq9xdPFmn5kgGyxhIRCFOQNq1Om+63CzWvRvJcu9H RaU0YXGdfrXtNuNcQnMRoXSWgxtPYiP5glouHTiXlgHl7Ys3d7FSfGhnLQdTt605Zp6X/kvZ 3FdgGApqGrcCoKi+VVDD3cVsbYVUy+eeRgNb3ZunwTlqbwfdeVWN17y5Slth9VLiQQ3/d6tH 8BtqDeXMreou59Aw7gMx9HE4EXHdzRdBLc7rBw9qgbVfXooBO3/uYhzlsNJgqt/YGldOdGLQ --J2SCkAp4GZ/dPZZf-- From bortzmeyer@nic.fr Mon Nov 19 06:42:39 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C327D21F8639 for ; Mon, 19 Nov 2012 06:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.212 X-Spam-Level: X-Spam-Status: No, score=-101.212 tagged_above=-999 required=5 tests=[AWL=1.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo8lMTFF3EZD for ; Mon, 19 Nov 2012 06:42:39 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 653C221F85E7 for ; Mon, 19 Nov 2012 06:42:35 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id B8447280151 for ; Mon, 19 Nov 2012 15:42:02 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id B494E28013E for ; Mon, 19 Nov 2012 15:42:02 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay2.nic.fr (Postfix) with ESMTP id A928BB38004 for ; Mon, 19 Nov 2012 15:41:32 +0100 (CET) Date: Mon, 19 Nov 2012 15:41:32 +0100 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20121119144132.GB3753@nic.fr> References: <20121119101834.GA23238@nic.fr> <20121119140543.GB28040@odin.ulthar.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121119140543.GB28040@odin.ulthar.us> X-Operating-System: Debian GNU/Linux wheezy/sid X-Kernel: Linux 3.2.0-3-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [DNSOP] Declaring HTTPS mandatory in the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 14:42:39 -0000 On Mon, Nov 19, 2012 at 09:05:43AM -0500, Scott Schmit wrote a message of 119 lines which said: > Perhaps you're thinking of this expired draft: draft-hoffman-server-has-tls? Exactly! Thanks. This I-D is not HTTPS-specific, which may explain why I did not find it. Someone also suggested this proposal (not an I-D): http://www.circleid.com/posts/20090105_problem_with_https_ssl_md5/ From kcd@chrysler.com Mon Nov 19 07:08:29 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE6B21F8557 for ; Mon, 19 Nov 2012 07:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHQq0yqcVjxC for ; Mon, 19 Nov 2012 07:08:27 -0800 (PST) Received: from shbmap01.extra.chrysler.com (shbmap01.out.extra.chrysler.com [129.9.168.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7E521F84E6 for ; Mon, 19 Nov 2012 07:08:27 -0800 (PST) Received: from odbmap04.oddc.chrysler.com (Unknown_Domain [53.28.32.58]) by shbmap01.extra.chrysler.com (Symantec Messaging Gateway) with SMTP id 6B.7F.02915.A6B4AA05; Mon, 19 Nov 2012 10:08:26 -0500 (EST) X-AuditID: 8109a822-b7f566d000000b63-b9-50aa4b6a1f6b Received: from shmsp070.shdc.chrysler.com (shmsp070.shdc.chrysler.com [53.231.161.247]) by odbmap04.oddc.chrysler.com (Symantec Messaging Gateway) with SMTP id 04.84.02648.A6B4AA05; Mon, 19 Nov 2012 10:08:26 -0500 (EST) Received: from [10.143.0.242] (CITMNCNU1410TPT.cg.chrysler.com [10.143.0.242]) by shmsp070.shdc.chrysler.com (8.13.8+Sun/8.13.8/chrysler-relay-1.4-kcd) with ESMTP id qAJF8Qae014799 for ; Mon, 19 Nov 2012 10:08:26 -0500 (EST) Message-ID: <50AA4B65.2060001@chrysler.com> Date: Mon, 19 Nov 2012 10:08:21 -0500 From: Kevin Darcy User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: dnsop@ietf.org References: <20121119101834.GA23238@nic.fr> <20121119140543.GB28040@odin.ulthar.us> <20121119144132.GB3753@nic.fr> In-Reply-To: <20121119144132.GB3753@nic.fr> Content-Type: multipart/alternative; boundary="------------020105060502050408090200" X-Brightmail-Tracker: H4sIAAAAAAAAA12Tf2wLYRjH87bVXmsv1+vWvet+mGP7w2JMLDHzcySMRM4kyIjt1p221nXN XcsWf5iwmApGhK0WRjArYkRiRjJqmW1+bcQwIYL4LYuxIf7gfftjrv577vN97vk+z/dylJLp oUyUzeESRAdvZ9U6VWZC8szJG5b6uKmPzqfMeP75oWoeWHzixC8FB/J1s4oFu22jIE6ZU6iz Nno9aqd/Uvn36hWV4DjrAVoK0dNRZetBRbA2op4X59UeoKMY+j5Ag/s+jQo31Q82a4LCc4DO XGxXBB++A3Rl6CwgXZBOQwf2PwnUKjoF/ax/ryS1mp6IWvsbNaSOofOR/8INTbBfj7rq3qhI HU0zaOhpe8DNQGehtpM/8BoUNhDRB5+WYC0e33+zO9CupFeiO50do8gOiD6lQb2/3yprgN4r G+uV9XnxKCWdjYavikE8Dl3+Uq8M1mnIt/uuQs4bgNoH4iVrUSnvnJqRLpS7RD7dbBUrJLsg ppvLSi8CnPtW7Wm2BXR5oR+UUAo2Bq6a7+OYMUVlxRVWXrIWiG67ILHR8E4uxnAEF7ntJawJ rlmMqWGEOoRNeLgLf1U2CcYdO80xsSOa5JacNrOtzC0VuEW7H8RTKjYW/j66lmNoC+8SSgTB KYhBPz/YRFEsgrlL8Hi9KFiE8vU2uyss4/deEmNargQ2SoQ1s7BglAuypcbDiYNNHGOSy//v paC0fmChovDNycQeSk6+VLJZQtYGmENoVJgGbOPgBBIPE4Yyy0SYT3IwhqVIu25QYYqFZjKR Jh1Wt2PkSpMRdq5q5JixMoG4mRJgL+ExMv7P0JQMbxM1TqZGegb+tnfHfnwEZgrge7ID9+B/ 8d+RDITkntEhGLgRQR1h+hCTnZgAHcvJPiEl0u0jzlKBs+zjGkmWLt4lzxKQzxEVpqEsh782 kSxDMCLLP0QyhqVIJ1MlyHtWYPDNPbelJ9P6athTveBtSzPXcLg3dXvOnG83ta2vr7am60u5 1EdHGnY0v/TsSq1y7s0sLryXV1D7LuHhzmzgWF1VfVvxRrNl86tlmQPTOixN0zJyLvW3HG9b l3ft5KE9tQdS+ttmb53NL4y/nhN9pjvp1sBYX53jQdaix30z+ga2sSrJymdMUooS/xdjehr9 4wQAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsVi+nzhd90s71UBBpsuilrcfXOZxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGctndbEVHNKq+NIR3MC4SKmLkZNDQsBEYs6nDewQtpjEhXvr 2boYuTiEBO4ySqzedIQJwvnCKLHz6xpGkCpeAW2JKZNugNksAqoSP+a8YAax2QRUJHbdWg42 SVQgSuLQxoPsEPWCEidnPmEBsUUEhCS+3jzCCmILC1hK7F/6HWgbB9CCIomXqzhBwpxA428d PgVWziwQJnHmxDHWCYx8s5BMmoUkNQuom1nAWuLb7iKIsLzE9rdzmCFsbYlVvWeZkMUXMLKt YpTKT0nKTSwwMNHLT0lJ1kvOKKoszkkt0kvOz93ECApQGQXLHYxzb8gfYhTgYFTi4Q23WBUg xJpYVlyZe4hRkoNJSZQ33BEoxJeUn1KZkVicEV9UmpNafIhRgoNZSYT3lRJQjjclsbIqtSgf JiXNwaIkzitksTRASCA9sSQ1OzW1ILUIJivDwaEkwXvFE6hRsCg1PbUiLTOnBCHNxMEJMpwH aLiCF8jw4oLE3OLMdIj8KUZFKXFeHZCEAEgiozQPrheWQF4xigO9Isx7CGQFDzD5wHW/AhrM BDT4WsBykMEliQgpqQZGQ80f7CxyXRdVDNYnOoW9W38kRz98qWpuzfJVfjF/xVZ90OwM0b3G KboudxZb9O1/XB+s1gVPn1n+/fGL+g1pXiVR4o6y8QWBL5U/z3vI3SubWK656zzjoUmPA740 23Lv/LHRd9lErvqEgo3iB6NcWHK+FU94xhs4e2HKllyT7kef+TsOmDgrsRRnJBpqMRcVJwIA EFG3TvsCAAA= Subject: Re: [DNSOP] Declaring HTTPS mandatory in the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 15:08:29 -0000 This is a multi-part message in MIME format. --------------020105060502050408090200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/19/2012 9:41 AM, Stephane Bortzmeyer wrote: > On Mon, Nov 19, 2012 at 09:05:43AM -0500, > Scott Schmit wrote > a message of 119 lines which said: > >> Perhaps you're thinking of this expired draft: draft-hoffman-server-has-tls? > Exactly! Thanks. This I-D is not HTTPS-specific, which may explain why > I did not find it. > > Someone also suggested this proposal (not an I-D): > > http://www.circleid.com/posts/20090105_problem_with_https_ssl_md5/ > It should be noted that the section of the original article recommending a custom DNS record be "quickly" standardized through the IETF process, and adopted, was actually struck out after feedback by Robert Graham: As Robert Graham, co-founder and CEO of Erratasec pointed out, I have the implementation process backwards because implementation has always come before standardization on the Internet. I must have been asleep writing that last paragraph because I should already know better. */Robert Graham:/*/What made the Internet different from all the other competing internetworks of the 1980s was that people would implement something first, then standardize it. OSI failed because standards led implementations./ Either Microsoft or Mozilla should just implement something, and document the DNS format that they will accept. Standards bodies can catch up later. I think this is probably wise advice, although there is nothing wrong with getting Microsoft, Mozilla and/or Google involved early in the standardization process... - Kevin --------------020105060502050408090200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 11/19/2012 9:41 AM, Stephane Bortzmeyer wrote:
On Mon, Nov 19, 2012 at 09:05:43AM -0500,
 Scott Schmit <i.grok@comcast.net> wrote 
 a message of 119 lines which said:


Perhaps you're thinking of this expired draft: draft-hoffman-server-has-tls?

Exactly! Thanks. This I-D is not HTTPS-specific, which may explain why
I did not find it.

Someone also suggested this proposal (not an I-D):

http://www.circleid.com/posts/20090105_problem_with_https_ssl_md5/
It should be noted that the section of the original article recommending a custom DNS record be "quickly" standardized through the IETF process, and adopted, was actually struck out after feedback by Robert Graham:

As Robert Graham, co-founder and CEO of Erratasec pointed out, I have the implementation process backwards because implementation has always come before standardization on the Internet. I must have been asleep writing that last paragraph because I should already know better.

Robert Graham: What made the Internet different from all the other competing internetworks of the 1980s was that people would implement something first, then standardize it. OSI failed because standards led implementations.

Either Microsoft or Mozilla should just implement something, and document the DNS format that they will accept. Standards bodies can catch up later.

I think this is probably wise advice, although there is nothing wrong with getting Microsoft, Mozilla and/or Google involved early in the standardization process...

                                                                                                                                                                                - Kevin

--------------020105060502050408090200-- From paul.hoffman@vpnc.org Mon Nov 19 07:36:20 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366D521F86A3 for ; Mon, 19 Nov 2012 07:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M9qKxaqT97C for ; Mon, 19 Nov 2012 07:36:19 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AF47B21F84D0 for ; Mon, 19 Nov 2012 07:36:19 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAJFaH8E050802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Nov 2012 08:36:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <20121119144132.GB3753@nic.fr> Date: Mon, 19 Nov 2012 07:36:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121119101834.GA23238@nic.fr> <20121119140543.GB28040@odin.ulthar.us> <20121119144132.GB3753@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1499) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Declaring HTTPS mandatory in the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 15:36:20 -0000 On Nov 19, 2012, at 6:41 AM, Stephane Bortzmeyer = wrote: > On Mon, Nov 19, 2012 at 09:05:43AM -0500, > Scott Schmit wrote=20 > a message of 119 lines which said: >=20 >> Perhaps you're thinking of this expired draft: = draft-hoffman-server-has-tls? >=20 > Exactly! Thanks. This I-D is not HTTPS-specific, which may explain why > I did not find it. Y'all forget that think that security is valuable for things other than = the web. :-) The draft has expired because there was little interest in it, and it = causes weird interactions with HSTS from the websec WG. --Paul Hoffman From paul@cypherpunks.ca Mon Nov 19 10:47:48 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A266721F86D0 for ; Mon, 19 Nov 2012 10:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnfyJvPL5wTr for ; Mon, 19 Nov 2012 10:47:48 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1616321F86C4 for ; Mon, 19 Nov 2012 10:47:47 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id E18D282B75; Mon, 19 Nov 2012 13:47:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D9EDE804AA; Mon, 19 Nov 2012 13:47:00 -0500 (EST) Date: Mon, 19 Nov 2012 13:47:00 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul Hoffman In-Reply-To: Message-ID: References: <20121119101834.GA23238@nic.fr> <20121119140543.GB28040@odin.ulthar.us> <20121119144132.GB3753@nic.fr> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsop Subject: Re: [DNSOP] Declaring HTTPS mandatory in the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 18:47:48 -0000 On Mon, 19 Nov 2012, Paul Hoffman wrote: >>> Perhaps you're thinking of this expired draft: draft-hoffman-server-has-tls? >> >> Exactly! Thanks. This I-D is not HTTPS-specific, which may explain why >> I did not find it. > > Y'all forget that think that security is valuable for things other than the web. :-) > > The draft has expired because there was little interest in it, and it causes weird interactions with HSTS from the websec WG. That will probably lead to people using the TLSA record as a pointer to "do not connect without TLS". Which I believe people who wanted HASTLS did not like? (as HSTS does not protect you from attacks from sites you've never visited before from a trusted network) Paul From fanf2@hermes.cam.ac.uk Wed Nov 21 06:01:01 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E0121F8235 for ; Wed, 21 Nov 2012 06:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.762 X-Spam-Level: X-Spam-Status: No, score=-5.762 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnKvdh4aP-it for ; Wed, 21 Nov 2012 06:01:00 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8713C21F8203 for ; Wed, 21 Nov 2012 06:01:00 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:34276) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1TbArI-0008PQ-Qe (Exim 4.72) (return-path ); Wed, 21 Nov 2012 14:00:56 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TbArI-0001dj-7Y (Exim 4.72) (return-path ); Wed, 21 Nov 2012 14:00:56 +0000 Date: Wed, 21 Nov 2012 14:00:56 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Paul Wouters In-Reply-To: Message-ID: References: <20121119101834.GA23238@nic.fr> <20121119140543.GB28040@odin.ulthar.us> <20121119144132.GB3753@nic.fr> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsop , Paul Hoffman Subject: Re: [DNSOP] Declaring HTTPS mandatory in the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 14:01:01 -0000 Paul Wouters wrote: > > That will probably lead to people using the TLSA record as a pointer to > "do not connect without TLS". I wrote that requirement into my DANE for email drafts. http://tools.ietf.org/html/draft-fanf-dane-smtp-04#section-3.2 http://tools.ietf.org/html/draft-fanf-dane-mua-00#section-3 Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From lee@asgard.org Wed Nov 21 07:01:26 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56FC21F860F for ; Wed, 21 Nov 2012 07:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.627 X-Spam-Level: X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEb0LHZI33C1 for ; Wed, 21 Nov 2012 07:01:26 -0800 (PST) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9E621F871F for ; Wed, 21 Nov 2012 07:01:25 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qALF1OnP028991 for ; Wed, 21 Nov 2012 10:01:24 -0500 Received: (qmail 7487 invoked by uid 0); 21 Nov 2012 15:01:24 -0000 Received: from unknown (HELO HDC00042402) (lee@asgard.org@204.235.115.167) by 0 with ESMTPA; 21 Nov 2012 15:01:24 -0000 From: "Lee Howard" To: Date: Wed, 21 Nov 2012 10:01:23 -0500 Message-ID: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3H9cQTileaQJNVSOS61nc5vAtpTw== Content-Language: en-us Subject: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 15:01:26 -0000 You may remember this draft from a couple of years ago. People keep asking me what a residential ISP should do for IPv6 PTR records, and I keep repeating what's in the draft. The intent is to document existing solutions, since prepopulating PTRs like we did in IPv4 doesn't work. Last time I brought it to DNSOP, there was interest, but not necessarily as a working group document. Since it's been a while, and the operator community is still asking for guidance, I've updated it, and would like a renewed review of it as an individual submission (unless this WG or v6ops wants it). Filename: draft-howard-isp-ip6rdns Revision: 05 Title: Reverse DNS in IPv6 for Internet Service Providers Creation date: 2012-11-20 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-05.txt Status: http://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns Htmlized: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-05 Abstract: In IPv4, Internet Service Providers (ISPs) commonly provide IN- ADDR.ARPA. information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches for ISPs to manage the ip6.arpa zone for IPv6 address space assigned to many customers. Thanks, Lee From Ted.Lemon@nominum.com Wed Nov 21 08:44:32 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FD121F87B5 for ; Wed, 21 Nov 2012 08:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.282 X-Spam-Level: X-Spam-Status: No, score=-106.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ua5bwcdBvkl for ; Wed, 21 Nov 2012 08:44:31 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id E758821F8446 for ; Wed, 21 Nov 2012 08:44:30 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUK0E7ue0mQA8JcUcCZM+aZF5O24/IXCI@postini.com; Wed, 21 Nov 2012 08:44:31 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 Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EBACD1B819F for ; Wed, 21 Nov 2012 08:44:29 -0800 (PST) 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 Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E2100190043; Wed, 21 Nov 2012 08:44:29 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 21 Nov 2012 08:44:29 -0800 From: Ted Lemon To: Lee Howard Thread-Topic: [DNSOP] new version of IPv6 rDNS for ISPs Thread-Index: Ac3H9cQTileaQJNVSOS61nc5vAtpTwAVMNuA Date: Wed, 21 Nov 2012 16:44:29 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074740E503@mbx-01.win.nominum.com> References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> In-Reply-To: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <97497959955E9542A43D6FA29E649DD3@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 16:44:32 -0000 On Nov 21, 2012, at 10:01 AM, Lee Howard wrote: > Since it's been > a while, and the operator community is still asking for guidance, I've > updated it, and would like a renewed review of it as an individual > submission (unless this WG or v6ops wants it). The document looks pretty good to me, except that the motivation section is= likely to be controversial (as I'm sure you are aware). The reasons you = state are not reasons that I personally find motivational; I want a working= reverse tree because it's a way to publish information about an address, b= oth for debugging purposes and for operational purposes (e.g., DANE). I could make some suggestions about this section, but I think it might be b= etter to just take it out. I would just ditch the text in the introductio= n starting with "Some of the most..." and the three bullet items that follo= w it. Aside from this quibble, I think the document is useful and should be publi= shed. From paul@redbarn.org Wed Nov 21 10:07:33 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5849321F862C for ; Wed, 21 Nov 2012 10:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KKBJRmszL6R for ; Wed, 21 Nov 2012 10:07:32 -0800 (PST) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id D498721F85B8 for ; Wed, 21 Nov 2012 10:07:32 -0800 (PST) Received: from [IPv6:2001:559:8000:cb:1d59:b060:6481:6a84] (unknown [IPv6:2001:559:8000:cb:1d59:b060:6481:6a84]) by ss.vix.com (Postfix) with ESMTP id 18C0DEBCE9; Wed, 21 Nov 2012 18:07:29 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <50AD185B.1090707@redbarn.org> Date: Wed, 21 Nov 2012 18:07:23 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Ted Lemon References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> <8D23D4052ABE7A4490E77B1A012B63074740E503@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074740E503@mbx-01.win.nominum.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Lee Howard , "" Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 18:07:33 -0000 On 2012-11-21 4:44 PM, Ted Lemon wrote: > ... Aside from this quibble, I think the document is useful and should > be published. my quibble is different. ipv6 is bringing some tough love to the consumer-facing edge. the fact that ISP's auto-populated the IPv4 PTR tree made it impossible for mail server operators to distinguish between consumer grade and business grade internet connections. since consumer grade connectees should really not be connecting to SMTP servers on other networks, there's been a great deal of work to find all of the common auto-populated PTR naming patterns in use anywhere in the world, in order to reject off-net e-mail from consumer grade connections. this work is inefficient, ineffective, painful even when correct, and often wrong. there are some excellent reasons not to use PTR RR records for this purpose, starting with good security practices and continuing through good engineering practices. nevertheless this is a pre-existing property of the existing server plant, and even if server operators were willing to give it up, the tail would be very long. i'm going to treat this as an unavoidable universal mistake that all of us will have to live with, forever, period. network operators should provide PTR RR's for specific addresses which have real names. the inability due to IPv6's richness of address space to provide auto-naming for PTR's does not to me, a problem statement make. paul -- "It seems like the rules for automagic completion of incomplete names typed into browsers are going to start to look like those for the game of fizbin." --rick jones From jim@rfc1035.com Wed Nov 21 10:28:03 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B7E21F84C7 for ; Wed, 21 Nov 2012 10:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SeZGyXitdNQ for ; Wed, 21 Nov 2012 10:28:03 -0800 (PST) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) by ietfa.amsl.com (Postfix) with ESMTP id 10EAE21F8479 for ; Wed, 21 Nov 2012 10:28:03 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id 122F0CBC41D; Wed, 21 Nov 2012 18:28:01 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jim Reid In-Reply-To: <50AD185B.1090707@redbarn.org> Date: Wed, 21 Nov 2012 18:28:00 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> <8D23D4052ABE7A4490E77B1A012B63074740E503@mbx-01.win.nominum.com> <50AD185B.1090707@redbarn.org> To: Paul Vixie X-Mailer: Apple Mail (2.1499) Cc: "" , Lee Howard , Ted Lemon Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 18:28:03 -0000 On 21 Nov 2012, at 18:07, Paul Vixie wrote: > network operators should provide PTR RR's for specific addresses which > have real names. the inability due to IPv6's richness of address space > to provide auto-naming for PTR's does not to me, a problem statement make. +1 From ajs@anvilwalrusden.com Wed Nov 21 10:44:15 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA3721F8819 for ; Wed, 21 Nov 2012 10:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HvQg-qA+z4g for ; Wed, 21 Nov 2012 10:44:15 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4829D21F87EF for ; Wed, 21 Nov 2012 10:44:15 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id EC00E8A031 for ; Wed, 21 Nov 2012 18:44:12 +0000 (UTC) Date: Wed, 21 Nov 2012 13:44:11 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20121121184410.GM94160@mx1.yitter.info> References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> <8D23D4052ABE7A4490E77B1A012B63074740E503@mbx-01.win.nominum.com> <50AD185B.1090707@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50AD185B.1090707@redbarn.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 18:44:15 -0000 On Wed, Nov 21, 2012 at 06:07:23PM +0000, Paul Vixie wrote: > consumer grade and business grade internet connections. since consumer > grade connectees should really not be connecting to SMTP servers on > other networks I do not accept this premise, and I don't see any argument in favour of it. What evidence does "willing to pay more for the same lousy service" provide with respect to "is not sending outbound crap"? > to give it up, the tail would be very long. i'm going to treat this as > an unavoidable universal mistake that all of us will have to live with, > forever, period. There, we agree. > network operators should provide PTR RR's for specific addresses which > have real names. Also here. A -- Andrew Sullivan ajs@anvilwalrusden.com From paul@redbarn.org Wed Nov 21 11:15:00 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6CF21F8872 for ; Wed, 21 Nov 2012 11:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwr0JtWYk3jH for ; Wed, 21 Nov 2012 11:14:59 -0800 (PST) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8131921F8809 for ; Wed, 21 Nov 2012 11:14:59 -0800 (PST) Received: from [IPv6:2001:559:8000:cb:1d59:b060:6481:6a84] (unknown [IPv6:2001:559:8000:cb:1d59:b060:6481:6a84]) by ss.vix.com (Postfix) with ESMTP id 35731EBC88; Wed, 21 Nov 2012 19:14:51 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <50AD2825.4050302@redbarn.org> Date: Wed, 21 Nov 2012 19:14:45 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andrew Sullivan References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> <8D23D4052ABE7A4490E77B1A012B63074740E503@mbx-01.win.nominum.com> <50AD185B.1090707@redbarn.org> <20121121184410.GM94160@mx1.yitter.info> In-Reply-To: <20121121184410.GM94160@mx1.yitter.info> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dnsop@ietf.org Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 19:15:00 -0000 On 2012-11-21 6:44 PM, Andrew Sullivan wrote: > On Wed, Nov 21, 2012 at 06:07:23PM +0000, Paul Vixie wrote: >> consumer grade and business grade internet connections. since consumer >> grade connectees should really not be connecting to SMTP servers on >> other networks > I do not accept this premise, and I don't see any argument in favour > of it. What evidence does "willing to pay more for the same lousy > service" provide with respect to "is not sending outbound crap"? that's not a dns question, and we seem to agree on the problem statement mechanics, so i'm not going to answer this here beyond saying "if you aren't willing to pay extra for a PTR RR on your end, then i don't want you talking to my SMTP servers". in other words this is a personal policy matter for me, and though i know a couple ten-million others feel the same way, i'm not going to try to enshrine it in IETF's work, in any way. From chris_griffiths@cable.comcast.com Thu Nov 22 08:55:54 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A2C21F86A4 for ; Thu, 22 Nov 2012 08:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.75 X-Spam-Level: X-Spam-Status: No, score=-103.75 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2n2AUaisHt0 for ; Thu, 22 Nov 2012 08:55:54 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 027F221F86B2 for ; Thu, 22 Nov 2012 08:55:53 -0800 (PST) Received: from ([24.40.56.116]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.42984538; Thu, 22 Nov 2012 09:30:30 -0700 Received: from PACDCEXMB14.cable.comcast.com ([169.254.1.48]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Thu, 22 Nov 2012 11:55:51 -0500 From: "Griffiths, Chris" Thread-Topic: [DNSOP] new version of IPv6 rDNS for ISPs Thread-Index: Ac3H9cQTileaQJNVSOS61nc5vAtpTwAVMNuAACxnf4A= Date: Thu, 22 Nov 2012 16:55:49 +0000 Message-ID: References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> <8D23D4052ABE7A4490E77B1A012B63074740E503@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074740E503@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <7584F241E14BF84DB80D6375F874BA9D@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Ted Lemon Cc: Lee Howard , "" Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 16:55:54 -0000 On Nov 21, 2012, at 11:44 AM, Ted Lemon wrote: > On Nov 21, 2012, at 10:01 AM, Lee Howard > wrote: >> Since it's been >> a while, and the operator community is still asking for guidance, I've >> updated it, and would like a renewed review of it as an individual >> submission (unless this WG or v6ops wants it). >=20 > The document looks pretty good to me, except that the motivation section = is likely to be controversial (as I'm sure you are aware). The reasons yo= u state are not reasons that I personally find motivational; I want a worki= ng reverse tree because it's a way to publish information about an address,= both for debugging purposes and for operational purposes (e.g., DANE). >=20 > I could make some suggestions about this section, but I think it might be= better to just take it out. I would just ditch the text in the introduct= ion starting with "Some of the most..." and the three bullet items that fol= low it. >=20 > Aside from this quibble, I think the document is useful and should be pub= lished. Ted, I agree with this assessment, and perhaps it does make sense to update or r= emove as needed in a follow-up version. I support this document being publ= ished, in order to provide the options that operators can take as they depl= oy IPv6 and support it in their DNS platforms. From geier@geier.ne.tz Thu Nov 22 01:30:32 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC0A21F87DA for ; Thu, 22 Nov 2012 01:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJikbBRR4tQP for ; Thu, 22 Nov 2012 01:30:31 -0800 (PST) Received: from tih.co.tz (unknown [217.172.181.156]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8FB21F87CB for ; Thu, 22 Nov 2012 01:30:29 -0800 (PST) Received: from [127.0.0.1] ([::ffff:41.188.137.16]) (AUTH: LOGIN geier@geier.ne.tz, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by tih.co.tz with esmtp; Thu, 22 Nov 2012 10:30:27 +0100 id 002C804D.50ADF0B4.00002080 Message-ID: <50ADF0B1.80300@geier.ne.tz> Date: Thu, 22 Nov 2012 12:30:25 +0300 From: Frank Habicht User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: dnsop@ietf.org References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> <8D23D4052ABE7A4490E77B1A012B63074740E503@mbx-01.win.nominum.com> <50AD185B.1090707@redbarn.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 22 Nov 2012 10:50:23 -0800 Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 09:30:32 -0000 Hi, On 11/21/2012 9:28 PM, Jim Reid wrote: > > On 21 Nov 2012, at 18:07, Paul Vixie wrote: > >> network operators should provide PTR RR's for specific addresses which >> have real names. the inability due to IPv6's richness of address space >> to provide auto-naming for PTR's does not to me, a problem statement make. > > +1 +1 not pre-populating rDNS here. feel that absence of rDNS is a useful indicator for "don't accept spam from here". 1.1 s/2.0.192.IN-ADDR-ARPA/2.0.192.IN-ADDR.ARPA/g while I consider 1.1 correct. I doubt whether that's a "good" situation. 2.1 sounds a bit like it's bad to receive an NXDOMAIN. Is it bad? is "successful lookup" one that gets a response, or one that has ANSWER: >0 ? Under recommendations I personally would like the negative response to be given more consideration. Maybe as a default behavior for residential connections as long as end users have not chosen any of the other options (as/if provided by the ISP)...? Frank From joe.abley@icann.org Thu Nov 22 11:07:58 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CE521F85E4 for ; Thu, 22 Nov 2012 11:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmm772Q-jnOu for ; Thu, 22 Nov 2012 11:07:57 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 64A9621F863B for ; Thu, 22 Nov 2012 11:07:56 -0800 (PST) Received: from [199.212.90.44] (199.212.90.44) by smtpx.exc.icann.org (64.78.22.244) with Microsoft SMTP Server (TLS) id 8.3.245.1; Thu, 22 Nov 2012 11:07:55 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> Date: Thu, 22 Nov 2012 14:07:53 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> To: Lee Howard X-Mailer: Apple Mail (2.1499) Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 19:07:58 -0000 Hi Lee, Some comments below, based on a fairly cursory skim through (so, I may = well have missed and/or understood things). 2.2 Wildcard match There is no mention of the issue of uniqueness. What do you do when you = have five thousand different customers who all attempt secure dynamic = updates with the name "macbook"? Or, what to do when you have two Nest = thermostats in the same house (on the same network) both of which think = their name is "nest"? If there was a possible solution where a customer device could = auto-register a name using dynamic DNS, how would it know what = nameservers to send the UPDATE messages to? Extract the MNAME from the = closest-enclosing SOA? How do you find the closest-enclosing SOA, = bearing in mind that the address concerned might previously have been = used by someone else, and hence the blah.blah.ip6.arpa owner name might = already exist? 2.3.1 Dynamic DNS from individual hosts I think it should be mentioned that this is a niche scenario, and that = the vast majority of customers today don't connect a single host = directly to their DSL/cable/whatever modem. And alongside that, some = study should be cited that has come to that conclusion based on actual = measurements, rather than my speculation :-) 2.3.2 Dynamic DNS through Residential Gateways I think this section makes an assumption that the place to send your = UPDATEs to is the same DNS server that is handed out (e.g. via DHCP = option) for use as a recursive server. If that's really a requirement, = that ought to be spelled out (because I think in general it's unusual). = Most ISPs hand out at least two such addresses. Can either one be used? = If not, which one? 2.3.3 Dynamic DNS Delegations This approach would leave a single nameserver responsible for a = delegation, which is contrary to general best practice. Quite possibly = that's a reasonable trade-off in this case (poor link quality affecting = DNS resolution would also affect the ability of the customer to use the = network) but the trade-off should be mentioned. The conclusion that this is not an option for residential ISPs assumes = sysadmin requirements on the part of the user, incidentally. If this = convention was widely deployed in home gateways, users wouldn't need to = care. 2.5 Dynamically Generate PTR When Queried ("On the Fly") The DNSSEC commentary is a bit weird. Keys are associated with zones, = not with RRSets. Keys would not need to be generated on the fly; I think = you're talking about signatures. 4.3 Considerations for Other Uses of the DNS I don't understand this section at all. What does it mean? General I don't feel that in its current form this draft provides much practical = advice to an ISP who is trying to find an analogue to "pre-populate all = my IN-ADDR zones containing customer addresses" as is commonly (whatever = you think about it) done in IPv4. I don't think that's generally a fault = of the draft; I think this is just an operational consideration that was = not well-explored during the development of IPv6. There are potentially = additional requirements for hosts, routers, DHCPv6 and RADIUS in here. Perhaps a more useful approach (if there is consensus that more work is = required in this area) would be to work on a requirements document for = the solution space. If the goal is rather to figure out practical advice which ISPs can use = today to provide PTR records for their customers, then I think this = draft needs to provide some more concrete advice. Joe On 2012-11-21, at 10:01, Lee Howard wrote: > You may remember this draft from a couple of years ago. People keep = asking > me what a residential ISP should do for IPv6 PTR records, and I keep > repeating what's in the draft. > The intent is to document existing solutions, since prepopulating PTRs = like > we did in IPv4 doesn't work. Last time I brought it to DNSOP, there = was > interest, but not necessarily as a working group document. Since it's = been > a while, and the operator community is still asking for guidance, I've > updated it, and would like a renewed review of it as an individual > submission (unless this WG or v6ops wants it). >=20 > Filename: draft-howard-isp-ip6rdns > Revision: 05 > Title: Reverse DNS in IPv6 for Internet Service = Providers > Creation date: 2012-11-20 > WG ID: Individual Submission > Number of pages: 13 > URL: > http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-05.txt > Status: = http://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns > Htmlized: = http://tools.ietf.org/html/draft-howard-isp-ip6rdns-05 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-howard-isp-ip6rdns-05 >=20 > Abstract: > In IPv4, Internet Service Providers (ISPs) commonly provide IN- > ADDR.ARPA. information for their customers by prepopulating the zone > with one PTR record for every available address. This practice does > not scale in IPv6. This document analyzes different approaches for > ISPs to manage the ip6.arpa zone for IPv6 address space assigned to > many customers. >=20 > Thanks, >=20 > Lee >=20 >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From Ted.Lemon@nominum.com Thu Nov 22 12:24:28 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84AC21F8971 for ; Thu, 22 Nov 2012 12:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdS4bjeFGi1f for ; Thu, 22 Nov 2012 12:24:27 -0800 (PST) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFAB21F874C for ; Thu, 22 Nov 2012 12:24:27 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUK6J+ssrIry5NHKdfQkHux51UQBifj2b@postini.com; Thu, 22 Nov 2012 12:24:27 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 Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 406311B81A8 for ; Thu, 22 Nov 2012 12:24:26 -0800 (PST) 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 Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2E813190043; Thu, 22 Nov 2012 12:24:26 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 22 Nov 2012 12:24:26 -0800 From: Ted Lemon To: Joe Abley Thread-Topic: [DNSOP] new version of IPv6 rDNS for ISPs Thread-Index: Ac3H9cQTileaQJNVSOS61nc5vAtpTwBMfY6AAAKsHAA= Date: Thu, 22 Nov 2012 20:24:25 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074740F8AA@mbx-01.win.nominum.com> References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Lee Howard , "dnsop@ietf.org" Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 20:24:28 -0000 On Nov 22, 2012, at 2:07 PM, Joe Abley wrote: > This approach would leave a single nameserver responsible for a delegatio= n, which is contrary to general best practice. Quite possibly that's a reas= onable trade-off in this case (poor link quality affecting DNS resolution w= ould also affect the ability of the customer to use the network) but the tr= ade-off should be mentioned. >=20 > The conclusion that this is not an option for residential ISPs assumes sy= sadmin requirements on the part of the user, incidentally. If this conventi= on was widely deployed in home gateways, users wouldn't need to care. The mechanism for specifying how the delegation happens should allow the zo= ne to be delegated to more than one name server=97presumably the primary wo= uld be the CPE device, but someone who really cares about the reliability o= f the reverse zone, if there is such a person, would want to set up a secon= dary elsewhere and keep it up to date with zone transfers or the like. From marka@isc.org Thu Nov 22 15:10:47 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2150A21F8446 for ; Thu, 22 Nov 2012 15:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[AWL=-1.162, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_44=0.6, SARE_BAYES_5x7=0.6, SARE_BAYES_6x7=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLV-k9uYb4QP for ; Thu, 22 Nov 2012 15:10:42 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 6B36121F84CA for ; Thu, 22 Nov 2012 15:10:29 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id D3EA3C9562; Thu, 22 Nov 2012 23:10:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:ec08:e2f2:4aea:54e4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 69B6B216C3D; Thu, 22 Nov 2012 23:10:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id E8C622C0E45E; Fri, 23 Nov 2012 10:10:11 +1100 (EST) To: Joe Abley From: Mark Andrews References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> In-reply-to: Your message of "Thu, 22 Nov 2012 14:07:53 CDT." Date: Fri, 23 Nov 2012 10:10:11 +1100 Message-Id: <20121122231011.E8C622C0E45E@drugs.dv.isc.org> Cc: Lee Howard , "dnsop@ietf.org" Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 23:10:47 -0000 In message , Joe Abley writes: > Hi Lee, > > Some comments below, based on a fairly cursory skim through (so, I may well h > ave missed and/or understood things). > > 2.2 Wildcard match > > There is no mention of the issue of uniqueness. What do you do when you have > five thousand different customers who all attempt secure dynamic updates with > the name "macbook"? Or, what to do when you have two Nest thermostats in the > same house (on the same network) both of which think their name is "nest"? > > If there was a possible solution where a customer device could auto-register > a name using dynamic DNS, how would it know what nameservers to send the UPDA > TE messages to? Extract the MNAME from the closest-enclosing SOA? How do you > find the closest-enclosing SOA, bearing in mind that the address concerned mi > ght previously have been used by someone else, and hence the blah.blah.ip6.ar > pa owner name might already exist? > > 2.3.1 Dynamic DNS from individual hosts > > I think it should be mentioned that this is a niche scenario, and that the va > st majority of customers today don't connect a single host directly to their > DSL/cable/whatever modem. And alongside that, some study should be cited that > has come to that conclusion based on actual measurements, rather than my spe > culation :-) Individual hosts should be doing dynamic DNS. Where that update is sent to may change but all machines should be doing it and should support TSIG as a minimum. They should also expect to see DNAME and CNAME records. i.e. the update may be to a name other than that produced by the address to IP6.ARPA (and IN-ADDR.ARPA) mapping. Individual hosts should be able to work out where to send the updates by querying the DNS to find the nameservers of the containing zone after processing and DNAME/CNAME mappings. We shipped code sans DNAME/CNAME remapping a decade ago that did this. Darwin and Windows already support sending dynamic updates though I don't believe they handle the presence of DNAME or CNAME. > 2.3.2 Dynamic DNS through Residential Gateways > > I think this section makes an assumption that the place to send your UPDATEs > to is the same DNS server that is handed out (e.g. via DHCP option) for use a > s a recursive server. If that's really a requirement, that ought to be spelle > d out (because I think in general it's unusual). Most ISPs hand out at least > two such addresses. Can either one be used? If not, which one? > > 2.3.3 Dynamic DNS Delegations > > This approach would leave a single nameserver responsible for a delegation, w > hich is contrary to general best practice. Quite possibly that's a reasonable > trade-off in this case (poor link quality affecting DNS resolution would als > o affect the ability of the customer to use the network) but the trade-off sh > ould be mentioned. Firstly there are multiple ways to do a "delegation". * Use a DNAME to a namespace that is already delegated. a.b.c.d.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.IP6.ARPA DNAME IP6.EXAMPLE.NET * The traditional method using NS records. > The conclusion that this is not an option for residential ISPs assumes sysadm > in requirements on the part of the user, incidentally. If this convention was > widely deployed in home gateways, users wouldn't need to care. And with IPv6 I would expect most homes *will* get dynamic forward zones. IPv6 *is* a game changer and people are still rooted in IPv4 think. > 2.5 Dynamically Generate PTR When Queried ("On the Fly") > > The DNSSEC commentary is a bit weird. Keys are associated with zones, not wit > h RRSets. Keys would not need to be generated on the fly; I think you're talk > ing about signatures. > > 4.3 Considerations for Other Uses of the DNS > > I don't understand this section at all. What does it mean? > > General > > I don't feel that in its current form this draft provides much practical advi > ce to an ISP who is trying to find an analogue to "pre-populate all my IN-ADD > R zones containing customer addresses" as is commonly (whatever you think abo > ut it) done in IPv4. I don't think that's generally a fault of the draft; I t > hink this is just an operational consideration that was not well-explored dur > ing the development of IPv6. There are potentially additional requirements fo > r hosts, routers, DHCPv6 and RADIUS in here. > > Perhaps a more useful approach (if there is consensus that more work is requi > red in this area) would be to work on a requirements document for the solutio > n space. > > If the goal is rather to figure out practical advice which ISPs can use today > to provide PTR records for their customers, then I think this draft needs to > provide some more concrete advice. > > > Joe > > On 2012-11-21, at 10:01, Lee Howard wrote: > > > You may remember this draft from a couple of years ago. People keep asking > > me what a residential ISP should do for IPv6 PTR records, and I keep > > repeating what's in the draft. > > The intent is to document existing solutions, since prepopulating PTRs like > > we did in IPv4 doesn't work. Last time I brought it to DNSOP, there was > > interest, but not necessarily as a working group document. Since it's been > > a while, and the operator community is still asking for guidance, I've > > updated it, and would like a renewed review of it as an individual > > submission (unless this WG or v6ops wants it). > > > > Filename: draft-howard-isp-ip6rdns > > Revision: 05 > > Title: Reverse DNS in IPv6 for Internet Service Providers > > Creation date: 2012-11-20 > > WG ID: Individual Submission > > Number of pages: 13 > > URL: > > http://www.ietf.org/internet-drafts/draft-howard-isp-ip6rdns-05.txt > > Status: http://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns > > Htmlized: http://tools.ietf.org/html/draft-howard-isp-ip6rdns-05 > > Diff: > > http://www.ietf.org/rfcdiff?url2=draft-howard-isp-ip6rdns-05 > > > > Abstract: > > In IPv4, Internet Service Providers (ISPs) commonly provide IN- > > ADDR.ARPA. information for their customers by prepopulating the zone > > with one PTR record for every available address. This practice does > > not scale in IPv6. This document analyzes different approaches for > > ISPs to manage the ip6.arpa zone for IPv6 address space assigned to > > many customers. > > > > Thanks, > > > > Lee > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From joe.abley@icann.org Thu Nov 22 16:11:29 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B7821F86C6 for ; Thu, 22 Nov 2012 16:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x7=0.6, SARE_BAYES_6x7=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2TifY6bBEkH for ; Thu, 22 Nov 2012 16:11:22 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id EB9D521F86A4 for ; Thu, 22 Nov 2012 16:11:21 -0800 (PST) Received: from [199.212.90.44] (199.212.90.44) by smtpx.exc.icann.org (64.78.22.244) with Microsoft SMTP Server (TLS) id 8.3.245.1; Thu, 22 Nov 2012 16:11:17 -0800 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: <20121122231011.E8C622C0E45E@drugs.dv.isc.org> Date: Thu, 22 Nov 2012 19:11:14 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <30776E96-C575-4FDE-899C-FDC8441C5735@icann.org> References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> <20121122231011.E8C622C0E45E@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1499) Cc: Lee Howard , "dnsop@ietf.org" Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 00:11:29 -0000 On 2012-11-22, at 18:10, Mark Andrews wrote: > Individual hosts should be doing dynamic DNS. Where that update > is sent to may change but all machines should be doing it and should > support TSIG as a minimum. The missing pieces here include: - what sane ISP/campus/home network/hotspot operator gives credentials = to customers or even random users to complete dynamic updates to one of = their master servers? - how can a TSIG key be shared between a network operator and a client = that potentially don't know each other? - what name should a user be allowed to specify in their PTR RDATA? - what stops user A from sending authentically TSIG-signed UPDATEs to a = nameserver and changing (or removing) user B's PTR? - what consumer systems do this by default? (I think it's none, but I = thought I'd ask) > Individual hosts should be able to work out where to send the updates > by querying the DNS to find the nameservers of the containing zone > after processing and DNAME/CNAME mappings. I think you skipped a step -- you need to find the zone cut before you = can find the nameservers responsible for the zone. I guess I do that by = asking for blah.ip6.arpa/IN/SOA and checking the authority section, but = what if the authority section is empty because of software choices in = some nameserver? I guess then I need to [krill:~]% ifconfig en0 | grep inet6 | grep -vi fe80:: inet6 2001:4900:1042:100:7ed1:c3ff:fee8:102f prefixlen 64 = autoconf=20 [krill:~]%=20 [krill:~]% dig = 7.7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. = IN SOA +short [krill:~]% dig = 7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. = IN SOA +short=20 [krill:~]% dig = 2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN = SOA +short=20 [krill:~]% dig = 6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN = SOA +short=20 [krill:~]% dig = 4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = +short=20 [krill:~]% dig = f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = +short=20 [krill:~]% dig = d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = +short=20 [krill:~]% dig = 8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = +short =20 [krill:~]% dig e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. = IN SOA +short =20 [krill:~]% dig 7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. = IN SOA +short =20 [krill:~]% dig 2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN = SOA +short =20 [krill:~]% dig a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN = SOA +short=20 [krill:~]% dig e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = +short=20 [krill:~]% dig 4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = +short=20 [krill:~]% dig 8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = +short=20 [krill:~]% dig 5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20= [krill:~]% dig 0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20= [krill:~]% dig 0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20 [krill:~]% dig 1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20 [krill:~]% dig 0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20 [krill:~]% dig 2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20 . jabley.hopcount.ca. 2011032174 10800 3600 604800 86400 [krill:~]%=20 Ah, there it is. There's no MNAME specified (I rudely called it ".") but = let's pretend I didn't do that. Now I need to know: what is my name? how do I know the name is unique within this network? what TSIG key should I use? Let's suspend disbelief and suppose that I am capable of knowing a = reasonable name that represents a reasonable, valid FQDN, that I know = it's unique, and that I have somehow discovered a TSIG secret for the = local network that is still a secret, and isn't shared knowledge amongst = 300,000 other customers. Once I've answered those questions, I send a TSIG-signed UPDATE to the = MNAME-specified server and update: = 7.7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. = IN PTR krill.hopcount.ca. Presumably we're encouraging PTR records to make sense, in which case I = also want to update: krill.hopcount.ca. AAAA 2001:4900:1042:100:584e:a27e:8df4:6277 Since hopcount.ca is my own domain, and I run the server referenced in = the MNAME (assuming again I change it from "." to something sensible), = there is some chance I could make this work. What if the domain is = hosted elsewhere? What if it's the ISP's domain I've decided to use? = What if I have no reasonable parent domain configured, and the local = hostname is "Joe's Computer"? I need to repeat this for every v6 address I have (I have five right = now, apparently, not counting the link-local) and also handle deletion = of AAAAs and PTRs that might already be there, accommodating the full = range of abrupt disconnects that phones and networks enjoy six hundred = times per day. Even without harping on about the many unanswerable questions in the = travelogue above, this whole procedure seems filled with fail. > Darwin and Windows already support sending dynamic updates though > I don't believe they handle the presence of DNAME or CNAME. I believe these days none of (Windows, Mac OS X, iOS, Android) do this = by default. Windows and Mac OS X can be made to do this kind of thing = with specific configuration ("wide-area bonjour", "Active Directory"), = which is usually only ever done in an enterprise context. I think current tools for this suck, and current protocols are going to = need extensions to be defined before the situation gets any better. = Happy to be proven wrong, though. If there's a good way to do this (enforce a naming scheme that = guarantees uniqueness, use SIG(0), whatever) then I think this draft = needs to spell it out in a way that people can actually implement, both = as vendors of consumer operating systems and as v6-capable ISPs. Simply = saying "this has been easy for a decade" doesn't really get us anywhere.=20= Joe= From marka@isc.org Thu Nov 22 17:16:54 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CFC21F84E9 for ; Thu, 22 Nov 2012 17:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=-0.434, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, SARE_BAYES_5x7=0.6, SARE_BAYES_6x7=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgeRTW686MXN for ; Thu, 22 Nov 2012 17:16:47 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFC121F847C for ; Thu, 22 Nov 2012 17:16:47 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 4BC29C96E0; Fri, 23 Nov 2012 01:16:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:ec08:e2f2:4aea:54e4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D3D5B216C3D; Fri, 23 Nov 2012 01:16:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 85BCB2C11223; Fri, 23 Nov 2012 12:16:32 +1100 (EST) To: Joe Abley From: Mark Andrews References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> <20121122231011.E8C622C0E45E@drugs.dv.isc.org> <30776E96-C575-4FDE-899C-FDC8441C5735@icann.org> In-reply-to: Your message of "Thu, 22 Nov 2012 19:11:14 CDT." <30776E96-C575-4FDE-899C-FDC8441C5735@icann.org> Date: Fri, 23 Nov 2012 12:16:32 +1100 Message-Id: <20121123011632.85BCB2C11223@drugs.dv.isc.org> Cc: Lee Howard , "dnsop@ietf.org" Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 01:16:54 -0000 In message <30776E96-C575-4FDE-899C-FDC8441C5735@icann.org>, Joe Abley writes: > > On 2012-11-22, at 18:10, Mark Andrews wrote: > > > Individual hosts should be doing dynamic DNS. Where that update > > is sent to may change but all machines should be doing it and should > > support TSIG as a minimum. > > The missing pieces here include: > > - what sane ISP/campus/home network/hotspot operator gives credentials = > to customers or even random users to complete dynamic updates to one of = > their master servers? ISP's have a contractual relationship often with shared secrets (username / password) for updating all sorts of information via a web interface. TSIG is just a username / password pair operated over DNS instead of HTTP / HTTPS. You can still do all the sanity checking you want on the names if you want. Named has the hooks to do this today. What it doesn't have yet is a external TSIG database but that is realitively easy to add. > - how can a TSIG key be shared between a network operator and a client = > that potentially don't know each other? Use a DH TKEY exchange with packets sourced from the address you want to be updated. You then have a TSIG that is bound to a address. You only allow that TSIG to update the associated reverse name. > - what name should a user be allowed to specify in their PTR RDATA? Any legal multi label hostname. You can do checks on the name for obsenties if you want. > - what stops user A from sending authentically TSIG-signed UPDATEs to a = > nameserver and changing (or removing) user B's PTR? See above. > - what consumer systems do this by default? (I think it's none, but I = > thought I'd ask) We are designing for the FUTURE. The consumer systems WILL do this if the operators add support. This is all existing protocols being bolted together. > > Individual hosts should be able to work out where to send the updates > > by querying the DNS to find the nameservers of the containing zone > > after processing and DNAME/CNAME mappings. > > I think you skipped a step -- you need to find the zone cut before you = > can find the nameservers responsible for the zone. I guess I do that by = > asking for blah.ip6.arpa/IN/SOA and checking the authority section, but = > what if the authority section is empty because of software choices in = > some nameserver? I guess then I need to We shipped code to do this back before the turn of the millenium with BIND 8 as it was needed for nsupdate. > [krill:~]% ifconfig en0 | grep inet6 | grep -vi fe80:: > inet6 2001:4900:1042:100:7ed1:c3ff:fee8:102f prefixlen 64 = > autoconf=20 > [krill:~]%=20 > [krill:~]% dig = > 7.7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. = > IN SOA +short > [krill:~]% dig = > 7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. = > IN SOA +short=20 > [krill:~]% dig = > 2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN = > SOA +short=20 > [krill:~]% dig = > 6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN = > SOA +short=20 > [krill:~]% dig = > 4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = > +short=20 > [krill:~]% dig = > f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = > +short=20 > [krill:~]% dig = > d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = > +short=20 > [krill:~]% dig = > 8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = > +short =20 > [krill:~]% dig e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. = > IN SOA +short =20 > [krill:~]% dig 7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. = > IN SOA +short =20 > [krill:~]% dig 2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN = > SOA +short =20 > [krill:~]% dig a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN = > SOA +short=20 > [krill:~]% dig e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = > +short=20 > [krill:~]% dig 4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = > +short=20 > [krill:~]% dig 8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA = > +short=20 > [krill:~]% dig 5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20= > > [krill:~]% dig 0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20= > > [krill:~]% dig 0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20 > [krill:~]% dig 1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20 > [krill:~]% dig 0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20 > [krill:~]% dig 2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA +short=20 > . jabley.hopcount.ca. 2011032174 10800 3600 604800 86400 > [krill:~]%=20 % nsupdate -dd > update add e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. 0 in ptr dummy.example.net. > send Reply from SOA query: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5017 ;; flags: qr rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. IN SOA ;; AUTHORITY SECTION: 2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. 0 IN SOA . jabley.hopcount.ca. 2011032174 10800 3600 604800 86400 Found zone name: 2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa The master is: . couldn't get address for '.': not found % > Ah, there it is. There's no MNAME specified (I rudely called it ".") but = > let's pretend I didn't do that. > > Now I need to know: > > what is my name? Names don't depend apon where you are in the network. You give a machine a name when you configure it for the first time. > how do I know the name is unique within this network? The name is fully qualified. There is no "unique within this network" to worry about. It's globally unique. > what TSIG key should I use? The one you negotiate with the nameserver. > Let's suspend disbelief and suppose that I am capable of knowing a = > reasonable name that represents a reasonable, valid FQDN, that I know = > it's unique, and that I have somehow discovered a TSIG secret for the = > local network that is still a secret, and isn't shared knowledge amongst = > 300,000 other customers. > > Once I've answered those questions, I send a TSIG-signed UPDATE to the = > MNAME-specified server and update: > > = > 7.7.2.6.4.f.d.8.e.7.2.a.e.4.8.5.0.0.1.0.2.4.0.1.0.0.9.4.1.0.0.2.ip6.arpa. = > IN PTR krill.hopcount.ca. > > Presumably we're encouraging PTR records to make sense, in which case I = > also want to update: > > krill.hopcount.ca. AAAA 2001:4900:1042:100:584e:a27e:8df4:6277 > > Since hopcount.ca is my own domain, and I run the server referenced in = > the MNAME (assuming again I change it from "." to something sensible), = > there is some chance I could make this work. What if the domain is = > hosted elsewhere? What if it's the ISP's domain I've decided to use? = > What if I have no reasonable parent domain configured, and the local = > hostname is "Joe's Computer"? Well you host your zone on a server that does dynamic updates. > I need to repeat this for every v6 address I have (I have five right = > now, apparently, not counting the link-local) and also handle deletion = > of AAAAs and PTRs that might already be there, accommodating the full = > range of abrupt disconnects that phones and networks enjoy six hundred = > times per day. Well you would send one update for the forward with all your addresses. > Even without harping on about the many unanswerable questions in the = > travelogue above, this whole procedure seems filled with fail. > > > Darwin and Windows already support sending dynamic updates though > > I don't believe they handle the presence of DNAME or CNAME. > > I believe these days none of (Windows, Mac OS X, iOS, Android) do this = > by default. Windows and Mac OS X can be made to do this kind of thing = > with specific configuration ("wide-area bonjour", "Active Directory"), = > which is usually only ever done in an enterprise context. > > I think current tools for this suck, and current protocols are going to = > need extensions to be defined before the situation gets any better. = > Happy to be proven wrong, though. Tools become better as every starts to support it. > If there's a good way to do this (enforce a naming scheme that = > guarantees uniqueness, use SIG(0), whatever) then I think this draft = > needs to spell it out in a way that people can actually implement, both = > as vendors of consumer operating systems and as v6-capable ISPs. Simply = > saying "this has been easy for a decade" doesn't really get us anywhere.=20= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@iecc.com Thu Nov 22 17:47:09 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3E221F8648 for ; Thu, 22 Nov 2012 17:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.324 X-Spam-Level: X-Spam-Status: No, score=-106.324 tagged_above=-999 required=5 tests=[AWL=-3.725, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-gApR21n3z9 for ; Thu, 22 Nov 2012 17:47:08 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 22E6A21F8647 for ; Thu, 22 Nov 2012 17:47:07 -0800 (PST) Received: (qmail 42285 invoked from network); 23 Nov 2012 01:47:05 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Nov 2012 01:47:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50aed598.xn--btvx9d.k1211; i=johnl@user.iecc.com; bh=qqfuL18f5CWgMnuWwI6j/oj5SfSM+DsFbRJdXmvrNtM=; b=dCeXAnu8uS8eWA7oMz9dfdZ8FsyIzm7QONIsrMi3BqclLRgcP9RvTVvLoitKbvLGPbA7P7bAEqdXL8PxfLkLd+Y+FlZPqqOqRjkIe2TzfiJM082DCMTqg/rDrLOyRzeG45ed7A4dtHF7rMRdZayC2EZT/7eaMdGXYerXCBTdRKE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50aed598.xn--btvx9d.k1211; olt=johnl@user.iecc.com; bh=qqfuL18f5CWgMnuWwI6j/oj5SfSM+DsFbRJdXmvrNtM=; b=dnEhuuYtGAld+bbUmQ4EF8A5sCWgxr5mMWB7U1nCa4g4tiahCpgmaAzBabIrl54r8dcadf0Ux3iDCJTjmXRkMYyQRsHA+Kzu8fkpFn+sJ0TXvRkuuu7gsYu8nwpjjtjMJRhT6nmUVjoZ6xa2g/Ug/BGufBhLl9wQ3MijTt3Qsak= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 23 Nov 2012 01:46:42 -0000 Message-ID: <20121123014642.23974.qmail@joyce.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: <20121122231011.E8C622C0E45E@drugs.dv.isc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 01:47:09 -0000 >And with IPv6 I would expect most homes *will* get dynamic forward zones. More likely no forward zones, since they serve no useful purpose. >IPv6 *is* a game changer and people are still rooted in IPv4 think. Agreed. Why do you think that a host that is not a server and will never be contacted by (non-malicious) other hosts needs a name? R's, John PS: If you were planning to say that with the magic of IPv6, everyone will be able to run servers on their home cable connection, don't bother. From marka@isc.org Thu Nov 22 17:57:00 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE65521F844C for ; Thu, 22 Nov 2012 17:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wI7ojPpXv+pd for ; Thu, 22 Nov 2012 17:56:58 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B155821F8445 for ; Thu, 22 Nov 2012 17:56:58 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id DDCB2C97A4; Fri, 23 Nov 2012 01:56:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 9F532216C3D; Fri, 23 Nov 2012 01:56:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6DCC42C1291F; Fri, 23 Nov 2012 12:56:51 +1100 (EST) To: "John Levine" From: Mark Andrews References: <20121123014642.23974.qmail@joyce.lan> In-reply-to: Your message of "23 Nov 2012 01:46:42 -0000." <20121123014642.23974.qmail@joyce.lan> Date: Fri, 23 Nov 2012 12:56:51 +1100 Message-Id: <20121123015651.6DCC42C1291F@drugs.dv.isc.org> Cc: dnsop@ietf.org Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 01:57:00 -0000 In message <20121123014642.23974.qmail@joyce.lan>, "John Levine" writes: > >And with IPv6 I would expect most homes *will* get dynamic forward zones. > > More likely no forward zones, since they serve no useful purpose. > > >IPv6 *is* a game changer and people are still rooted in IPv4 think. > > Agreed. Why do you think that a host that is not a server and will > never be contacted by (non-malicious) other hosts needs a name? Because servers out there won't allowing it access without a name. I know this is stupid but they exist. > R's, > John > > PS: If you were planning to say that with the magic of IPv6, everyone will > be able to run servers on their home cable connection, don't bother. I expect to have fibre to the home within 5 years as part of the NBN rollout here in Aus. With that there is no good reason discourage running servers at home as there are with asymetric access technologies like cable and aDSL. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From johnl@iecc.com Thu Nov 22 18:14:12 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F8F21F8969 for ; Thu, 22 Nov 2012 18:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.186 X-Spam-Level: X-Spam-Status: No, score=-106.186 tagged_above=-999 required=5 tests=[AWL=-3.587, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdpTEISer+NB for ; Thu, 22 Nov 2012 18:14:06 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4C67921F87BB for ; Thu, 22 Nov 2012 18:14:06 -0800 (PST) Received: (qmail 46809 invoked from network); 23 Nov 2012 02:14:03 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Nov 2012 02:14:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50aedbeb.xn--i8sz2z.k1211; i=johnl@user.iecc.com; bh=BG7X4+mVKZk6lr6dNBUwnG0Mp5MMhODCTs5YgLbDH1w=; b=TEtMZ+xGS6FA9oEboDz3Zrid3YcU8Do7942ZHWFqMrFko3soNaOFfW0fh3cw+uNBUu17XeMmOO6pXWdC+FcCPD69kROLmeLSa96Oo/0qOVVZTkd1Rb8jRU0LdzoSSY6c+0zbeTavYc8jVQWt8y/fsKsqsHLfBuFt0kpz64QyEeY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50aedbeb.xn--i8sz2z.k1211; olt=johnl@user.iecc.com; bh=BG7X4+mVKZk6lr6dNBUwnG0Mp5MMhODCTs5YgLbDH1w=; b=Wn2ydpT1NZTkzFN5OF/pKWodOzl75b1wERIkxfo/kWGCD1qlHq76LZTh5fZIL7bCIMUAxJYXyCkaIiRTuqPHdEHx791OCRNUjHaNxfJKMFV120LozjuKZ7Majj76D08SehkoxTxg6VxehMXQ4XpOUp5b4awRH54NRmIpZywF4Pk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 23 Nov 2012 02:13:41 -0000 Message-ID: <20121123021341.2672.qmail@joyce.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: <20121123015651.6DCC42C1291F@drugs.dv.isc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 02:14:12 -0000 >> Agreed. Why do you think that a host that is not a server and will >> never be contacted by (non-malicious) other hosts needs a name? > >Because servers out there won't allowing it access without a name. >I know this is stupid but they exist. Given a choice between rolling out complex and fragile rDNS systems, and telling people with such servers that the IPv6 world is different, I know what I'd do. >> PS: If you were planning to say that with the magic of IPv6, everyone will >> be able to run servers on their home cable connection, don't bother. > >I expect to have fibre to the home within 5 years as part of the >NBN rollout here in Aus. With that there is no good reason discourage >running servers at home as there are with asymetric access technologies >like cable and aDSL. Nothing personal, but if you think that upload speed has anything to do with the rules against servers on consumer broadband, you don't understand the internet access business very well. (Hint: ADSL uptream bandwidth is unshared to the DSLAM.) R's, John From marka@isc.org Thu Nov 22 18:22:47 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB1521F8536 for ; Thu, 22 Nov 2012 18:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARbOMfn7I+2c for ; Thu, 22 Nov 2012 18:22:47 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id E7CC221F851F for ; Thu, 22 Nov 2012 18:22:46 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 3721A5F9BA2; Fri, 23 Nov 2012 02:22:36 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 5F2E0216C80; Fri, 23 Nov 2012 02:22:35 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D5D1B2C14DF6; Fri, 23 Nov 2012 13:22:32 +1100 (EST) To: "John Levine" From: Mark Andrews References: <20121123021341.2672.qmail@joyce.lan> In-reply-to: Your message of "23 Nov 2012 02:13:41 -0000." <20121123021341.2672.qmail@joyce.lan> Date: Fri, 23 Nov 2012 13:22:32 +1100 Message-Id: <20121123022232.D5D1B2C14DF6@drugs.dv.isc.org> Cc: dnsop@ietf.org Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 02:22:47 -0000 In message <20121123021341.2672.qmail@joyce.lan>, "John Levine" writes: > >> Agreed. Why do you think that a host that is not a server and will > >> never be contacted by (non-malicious) other hosts needs a name? > > > >Because servers out there won't allowing it access without a name. > >I know this is stupid but they exist. > > Given a choice between rolling out complex and fragile rDNS systems, > and telling people with such servers that the IPv6 world is different, > I know what I'd do. > > >> PS: If you were planning to say that with the magic of IPv6, everyone will > >> be able to run servers on their home cable connection, don't bother. > > > >I expect to have fibre to the home within 5 years as part of the > >NBN rollout here in Aus. With that there is no good reason discourage > >running servers at home as there are with asymetric access technologies > >like cable and aDSL. > > Nothing personal, but if you think that upload speed has anything to > do with the rules against servers on consumer broadband, you don't > understand the internet access business very well. (Hint: ADSL > uptream bandwidth is unshared to the DSLAM.) There are lots of reasons. Most of which don't make any sense at all if you examine them critically. If you are paying for bits to be moved it should matter where they are being moved from. > R's, > John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ted.Lemon@nominum.com Thu Nov 22 19:18:26 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A914321F8675 for ; Thu, 22 Nov 2012 19:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.575 X-Spam-Level: X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6e5UOK2d1Do for ; Thu, 22 Nov 2012 19:18:22 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 780F021F896E for ; Thu, 22 Nov 2012 19:18:22 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUK7q/RvrpcvSb2EDzfuYmFXYuKWAKMiJ@postini.com; Thu, 22 Nov 2012 19:18:22 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 Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7FEE91B81A6 for ; Thu, 22 Nov 2012 19:18:21 -0800 (PST) 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 Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 75FE2190043; Thu, 22 Nov 2012 19:18:21 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 22 Nov 2012 19:18:09 -0800 From: Ted Lemon To: John Levine Thread-Topic: [DNSOP] new version of IPv6 rDNS for ISPs Thread-Index: AQHNyQaFileaQJNVSOS61nc5vAtpT5f3LNUAgAAZioA= Date: Fri, 23 Nov 2012 03:18:09 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074740FB7B@mbx-01.win.nominum.com> References: <20121123014642.23974.qmail@joyce.lan> In-Reply-To: <20121123014642.23974.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 03:18:26 -0000 On Nov 22, 2012, at 8:46 PM, John Levine wrote: > PS: If you were planning to say that with the magic of IPv6, everyone wil= l > be able to run servers on their home cable connection, don't bother. Why not? From ggm@algebras.org Thu Nov 22 19:37:14 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56A321F87BA for ; Thu, 22 Nov 2012 19:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYOvJik5627c for ; Thu, 22 Nov 2012 19:37:14 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF4B21F87B8 for ; Thu, 22 Nov 2012 19:37:13 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so983571dae.31 for ; Thu, 22 Nov 2012 19:37:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=h3PZk/Qm6sYspaYj56blGVIG4vSCkJHffa2DSxuzEZ0=; b=DmCNAhqbzpEby+4Rwa55tR9shUZg73Wvo42O8odaDRNCEIJPBMijCivkedIx2t7ZWE V9aFOTBngD/QOd6zT3sdVF1U2YPbemcrvs4RtG/W2PDob96reIvPz5wyBp2lExBdOTt5 lfnEfVfQXSyye1gZWAmbC0sY1mTxau0gzTiVym6PDcth86PxRIkycVvvIwYSwVhZxKw9 NL3o0JhCQ5KMy/DCgOKMJpV++05TCBuizEcLRgTxFIRlS1C0N6shbPpc5OOiRKs9GDs3 XNRjoPEMWvmaiEqr6nWr9TlZOeBz+4p2OVM+YGxaY+1x8XssggCqggHjfJJN6QmxQyfb lEaw== Received: by 10.68.189.102 with SMTP id gh6mr10568348pbc.37.1353641833655; Thu, 22 Nov 2012 19:37:13 -0800 (PST) Received: from ?IPv6:2001:dc0:a000:4:485d:d4b8:10b0:2251? ([2001:dc0:a000:4:485d:d4b8:10b0:2251]) by mx.google.com with ESMTPS id g1sm2919332pax.21.2012.11.22.19.37.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Nov 2012 19:37:13 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: George Michaelson In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074740FB7B@mbx-01.win.nominum.com> Date: Fri, 23 Nov 2012 13:37:08 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <9BF71945-F4FA-466D-B475-083E21B812E1@algebras.org> References: <20121123014642.23974.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B63074740FB7B@mbx-01.win.nominum.com> To: dnsop@ietf.org X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlKnzoEXwioqw55iccD7bEawyOds59WOBBWf0PRLTBWPHgpJ0u3SWowouKqD0LR0IqdlhKr Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 03:37:14 -0000 On 23/11/2012, at 1:18 PM, Ted Lemon wrote: > On Nov 22, 2012, at 8:46 PM, John Levine wrote: >> PS: If you were planning to say that with the magic of IPv6, everyone = will >> be able to run servers on their home cable connection, don't bother. >=20 > Why not? > =20 Because the lack of public IPv4 was only an *excuse* for blocking this = functionality: ISPs in the main don't want you to equalise traffic = coming from their CAN network out to the world, they didn't build with = that model in mind. One can even invert the sentence a bit: they made assumptions about the = traffic asymmetries in the world and built to take advantage of them. OTOH, if you want to say "with the magic of IPv6, servers in the home = are now at least possibly simpler" I am there. I know, because I've used = some, to great effect. (I hated setting up NAT inbound rules to one, and only one internal IP. = with IPv6, I have to open an ACL inbound, but having said I want port 22 = SSH to work, I can now get to all my home nodes. Internode IPv6 native = on ADSL2+) Of course, you still hit ISP level ACLs. there are a bunch of simplistic = portblocks they do, on the basis that it felt right at the time, and if = it was good enough then, it must still be good now. Port 25 for = instance, inbound, to their CAN numbered space can be "hard" -G From Ted.Lemon@nominum.com Thu Nov 22 19:51:31 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2801521F8463 for ; Thu, 22 Nov 2012 19:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PP5YXkm930y for ; Thu, 22 Nov 2012 19:51:27 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2717021F847C for ; Thu, 22 Nov 2012 19:51:26 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUK7yvumPKvSm/joSTFQvFVS+lEpPQZo5@postini.com; Thu, 22 Nov 2012 19:51:27 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 Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 3FDE11B81A6 for ; Thu, 22 Nov 2012 19:51:26 -0800 (PST) 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 Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3479B190043; Thu, 22 Nov 2012 19:51:26 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 22 Nov 2012 19:51:20 -0800 From: Ted Lemon To: George Michaelson Thread-Topic: [DNSOP] new version of IPv6 rDNS for ISPs Thread-Index: AQHNyQaFileaQJNVSOS61nc5vAtpT5f3LNUAgAAZioCAAAVQAIAAA/YA Date: Fri, 23 Nov 2012 03:51:19 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074740FC76@mbx-01.win.nominum.com> References: <20121123014642.23974.qmail@joyce.lan> <8D23D4052ABE7A4490E77B1A012B63074740FB7B@mbx-01.win.nominum.com> <9BF71945-F4FA-466D-B475-083E21B812E1@algebras.org> In-Reply-To: <9BF71945-F4FA-466D-B475-083E21B812E1@algebras.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <093BE275C9945F4EB228237AA7461DB0@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 03:51:31 -0000 On Nov 22, 2012, at 10:37 PM, George Michaelson wrote: > On 23/11/2012, at 1:18 PM, Ted Lemon wrote: >=20 >> On Nov 22, 2012, at 8:46 PM, John Levine wrote: >>> PS: If you were planning to say that with the magic of IPv6, everyone w= ill >>> be able to run servers on their home cable connection, don't bother. >>=20 >> Why not? >>=20 >=20 > Because the lack of public IPv4 was only an *excuse* for blocking this fu= nctionality: ISPs in the main don't want you to equalise traffic coming fro= m their CAN network out to the world, they didn't build with that model in = mind. I hear you, but this isn't really a meaningful rejoinder, because this equa= lization you are talking about isn't a prerequisite for selling devices tha= t will want to publish services from the home. You can't have a network that only lets traffic go in one direction. IPv4= +NAT makes it hard for traffic to go in both directions, and yet still we h= ave bittorrent, Skype, limited VoIP, and lots of back-to-my-pc solutions. = We have dyndns.org, which wouldn't have needed to exist if people weren't = setting up home servers. So really, while it may be true that ISPs will resist certain kinds of home= servers being set up, and I don't people to be running web servers targete= d to the general public on home network connections, it's entirely reasonab= le to think that low-use home servers will be a reality in the near future.= We know that ISPs are talking about serious, high-reliability M2M applic= ations. So external reachability is going to be a reality. It's easy to dismiss this (which I don't think you were doing=97I'm really = referring back to what John Levine said) by putting down home servers as a = "hobbyist" sort of thing, which ISPs won't feel market pressure to support,= but I think that this attitude is actually what's unrealistic. There is = a *huge* untapped market in peer-to-peer applications.=20 We can think now about how to make sure that this market has the tools it n= eeds to grow, or we can ignore it until it becomes big, at which point it w= ill be too late. From dgq2011@gmail.com Thu Nov 22 19:53:48 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143E521F85C1 for ; Thu, 22 Nov 2012 19:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZLMTp14aAIl for ; Thu, 22 Nov 2012 19:53:44 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 216B621F85BC for ; Thu, 22 Nov 2012 19:53:44 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so6171600pbc.31 for ; Thu, 22 Nov 2012 19:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:references:x-priority:x-has-attach:x-mailer :mime-version:message-id:content-type; bh=NDd1ofkDBjBlA9D6tgaJ70wBZ9qbRt3BbGzuzQtPdsI=; b=i0DbCSxIWmczrVUFb0oG2IpO47xLM2eaxbm412lEA7zYVQf1aAVIEx9vOBn/sUzIYC G/sQCEKyGHLzGdlm6alUAJ4QI/gzl+DThfSd9ejNfawCUhQkDxJvxmim8jufglrfzvUo hp4DoaLFgkC7AOVv6vl6+Bu3bwlfbZCWIfz1Ux10veeFQ+CnnXVYDmzrPQ/HwxEW7LpE mU+Sqr2XPvot8MqaiW1vwIjWrF/TpF81YtE8m2ZqI1qpzy2dxFgb2OJ0wh9K6AYzvfXQ gz45GRCyVt3y1zzzPgP096FpgMDRGhGRGNLDetyNLufQed8CaJIeR/+2QHg+Qyw1fCfw KTmA== Received: by 10.66.79.168 with SMTP id k8mr7047005pax.12.1353642823942; Thu, 22 Nov 2012 19:53:43 -0800 (PST) Received: from user-THINK ([218.241.103.7]) by mx.google.com with ESMTPS id oi3sm3081552pbb.1.2012.11.22.19.53.41 (version=SSLv3 cipher=OTHER); Thu, 22 Nov 2012 19:53:43 -0800 (PST) Date: Fri, 23 Nov 2012 11:53:39 +0800 From: dgq2011 To: dnsop References: <20121119101834.GA23238@nic.fr> <20121119140543.GB28040@odin.ulthar.us> <20121119144132.GB3753@nic.fr> , X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201211231153370557979@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart874284040575_=----" Subject: Re: [DNSOP] Declaring HTTPS mandatory in the DNS X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 03:53:48 -0000 This is a multi-part message in MIME format. ------=_001_NextPart874284040575_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QmFzaWNhbGx5LCB0aGUgZHJhZnQgKGRyYWZ0LWhvZmZtYW4tc2VydmVyLWhhcy10bHMpIHByb3Zp ZGVzIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIHRoZSBzZXJ2ZXIgdGVsbHMgdGhlIGNsaWVudCB3aGlj aCBpcyBpbnNlY3VyZS9zZWN1cmUgcG9ydC4gQW4gaWRlYSBzdWRkZW5seSBjb21pbmcgaW50byBt eSBtaW5kIGlzIHdoeSBub3QgaW50ZWdyYXRlIHN1Y2ggbWVjaGFuaXNtIHdpdGggU1JWIFtSRkMy NzgyXT8gVGhlIGZvcm1hdCBvZiB0aGUgU1JWIFJSIGlzIGxpa2UgdGhpczogX1NlcnZpY2UuX1By b3RvLk5hbWUgVFRMIENsYXNzIFNSViBQcmlvcml0eSBXZWlnaHQgUG9ydCBUYXJnZXQuIEp1c3Qg YWRkIG9uZSBmaWVsZCB0byBpbmRpY2F0ZSB0aGUgc2VjdXJpdHkgcHJvcGVydHkgb2YgdGhlIHBv cnQgKG5hbWVseSB0byBpbmRpY2F0ZSB3aGV0aGVyIHRoZSBwb3J0IGlzIHNlY3VyZSBvciBub3Qp IGFuZCB0aGVuIG1vc3Qgb2YgdGhlIHdvcmsgaXMgZG9uZS4gRm9yZ2l2ZSBtZSBpZiBzb21ldGhp bmcgb2J2aW91cyBpcyBtaXNzZWQhDQoNCg0KDQoNCkd1YW5ncWluZyBEZW5nDQoNCkZyb206IFBh dWwgV291dGVycw0KRGF0ZTogMjAxMi0xMS0yMCAwMjo0Nw0KVG86IFBhdWwgSG9mZm1hbg0KQ0M6 IGRuc29wDQpTdWJqZWN0OiBSZTogW0ROU09QXSBEZWNsYXJpbmcgSFRUUFMgbWFuZGF0b3J5IGlu IHRoZSBETlMNCk9uIE1vbiwgMTkgTm92IDIwMTIsIFBhdWwgSG9mZm1hbiB3cm90ZToNCg0KPj4+ IFBlcmhhcHMgeW91J3JlIHRoaW5raW5nIG9mIHRoaXMgZXhwaXJlZCBkcmFmdDogZHJhZnQtaG9m Zm1hbi1zZXJ2ZXItaGFzLXRscz8NCj4+DQo+PiBFeGFjdGx5ISBUaGFua3MuIFRoaXMgSS1EIGlz IG5vdCBIVFRQUy1zcGVjaWZpYywgd2hpY2ggbWF5IGV4cGxhaW4gd2h5DQo+PiBJIGRpZCBub3Qg ZmluZCBpdC4NCj4NCj4gWSdhbGwgZm9yZ2V0IHRoYXQgdGhpbmsgdGhhdCBzZWN1cml0eSBpcyB2 YWx1YWJsZSBmb3IgdGhpbmdzIG90aGVyIHRoYW4gdGhlIHdlYi4gOi0pDQo+DQo+IFRoZSBkcmFm dCBoYXMgZXhwaXJlZCBiZWNhdXNlIHRoZXJlIHdhcyBsaXR0bGUgaW50ZXJlc3QgaW4gaXQsIGFu ZCBpdCBjYXVzZXMgd2VpcmQgaW50ZXJhY3Rpb25zIHdpdGggSFNUUyBmcm9tIHRoZSB3ZWJzZWMg V0cuDQoNClRoYXQgd2lsbCBwcm9iYWJseSBsZWFkIHRvIHBlb3BsZSB1c2luZyB0aGUgVExTQSBy ZWNvcmQgYXMgYSBwb2ludGVyIHRvDQoiZG8gbm90IGNvbm5lY3Qgd2l0aG91dCBUTFMiLiBXaGlj aCBJIGJlbGlldmUgcGVvcGxlIHdobyB3YW50ZWQgSEFTVExTDQpkaWQgbm90IGxpa2U/DQoNCihh cyBIU1RTIGRvZXMgbm90IHByb3RlY3QgeW91IGZyb20gYXR0YWNrcyBmcm9tIHNpdGVzIHlvdSd2 ZSBuZXZlcg0KICB2aXNpdGVkIGJlZm9yZSBmcm9tIGEgdHJ1c3RlZCBuZXR3b3JrKQ0KDQpQYXVs DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRE5TT1Ag bWFpbGluZyBsaXN0DQpETlNPUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9kbnNvcA== ------=_001_NextPart874284040575_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Basically, the draft (draft-hoffman-server-has-tl= s)=20 provides a mechanism by which the server tells the client which is=20 insecure/secure port. An idea suddenly coming into my mind is why not inte= grate=20 such mechanism with SRV [RFC2782]? The format of the SRV RR is like this:=20 _Service._Proto.Name TTL Class SRV Priority Weight Port Target. Just add o= ne field to indicate the security property of the port (namely to indicate wh= ether=20 the port is secure or not) and then most of the work is done. Forgive me i= f=20 something obvious is missed!

 
Guangqing Deng
 
Date: 2012-11-20 02:47
CC: dnsop
Subject: Re: [DNSOP] Declaring HTTPS mandatory in the=20 DNS
On Mon, 19 Nov 2012, Paul Hoffman = wrote:
 
>>> Perhaps you're thinking of this=  expired draft: draft-hoffman-server-has-tls?
>>
>> Exactly! Thanks. This I-D is n= ot HTTPS-specific, which may explain why
>> I did not find it.
>
> Y'all forget that think that secur= ity is valuable for things other than t= he web. :-)
>
> The draft has expired because ther= e was little interest in it, and it&nbs= p;causes weird interactions with HSTS from t= he websec WG.
 
That will probably lead to people using=  the TLSA record as a pointer to
"do not connect without TLS". Which I&n= bsp;believe people who wanted HASTLS
did not like?
 
(as HSTS does not protect you from = ;attacks from sites you've never
  visited before from a trusted ne= twork)
 
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
------=_001_NextPart874284040575_=------ From fanf2@hermes.cam.ac.uk Fri Nov 23 03:17:32 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4F721F84D6 for ; Fri, 23 Nov 2012 03:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.813 X-Spam-Level: X-Spam-Status: No, score=-5.813 tagged_above=-999 required=5 tests=[AWL=0.786, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwDOXDZ3aRGX for ; Fri, 23 Nov 2012 03:17:27 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id E5E9F21F84D2 for ; Fri, 23 Nov 2012 03:17:26 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:45562) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1TbrG7-0004rG-Xl (Exim 4.72) (return-path ); Fri, 23 Nov 2012 11:17:23 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TbrG7-0000JB-EG (Exim 4.72) (return-path ); Fri, 23 Nov 2012 11:17:23 +0000 Date: Fri, 23 Nov 2012 11:17:23 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Joe Abley In-Reply-To: Message-ID: References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Lee Howard , "dnsop@ietf.org" Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 11:17:32 -0000 Joe Abley wrote: > > If there was a possible solution where a customer device could > auto-register a name using dynamic DNS, how would it know what > nameservers to send the UPDATE messages to? Extract the MNAME from the > closest-enclosing SOA? How do you find the closest-enclosing SOA, > bearing in mind that the address concerned might previously have been > used by someone else, and hence the blah.blah.ip6.arpa owner name might > already exist? Just query for the SOA at the full RDNS name, and the name server will return the zone apex name and SOA record in the authority section of its reply (or possibly in the answer section though that's unlikely). http://tools.ietf.org/html/draft-andrews-dnsext-soa-discovery Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From fanf2@hermes.cam.ac.uk Fri Nov 23 03:28:49 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1181621F844D for ; Fri, 23 Nov 2012 03:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.885 X-Spam-Level: X-Spam-Status: No, score=-3.885 tagged_above=-999 required=5 tests=[AWL=-1.286, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmFG2Kn5IWSX for ; Fri, 23 Nov 2012 03:28:43 -0800 (PST) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) by ietfa.amsl.com (Postfix) with ESMTP id 72A7621F844C for ; Fri, 23 Nov 2012 03:28:43 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59189) by ppsw-43.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1TbrQo-0001sD-p5 (Exim 4.72) (return-path ); Fri, 23 Nov 2012 11:28:26 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TbrQo-0001qu-QN (Exim 4.72) (return-path ); Fri, 23 Nov 2012 11:28:26 +0000 Date: Fri, 23 Nov 2012 11:28:26 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Joe Abley In-Reply-To: <30776E96-C575-4FDE-899C-FDC8441C5735@icann.org> Message-ID: References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> <20121122231011.E8C622C0E45E@drugs.dv.isc.org> <30776E96-C575-4FDE-899C-FDC8441C5735@icann.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Lee Howard , "dnsop@ietf.org" Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 11:28:49 -0000 Joe Abley wrote: > > I think you skipped a step -- you need to find the zone cut before you > can find the nameservers responsible for the zone. I guess I do that by > asking for blah.ip6.arpa/IN/SOA and checking the authority section, but > what if the authority section is empty because of software choices in > some nameserver? Are name servers allowed to leave out the SOA record? It would break negative cacheing. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From fanf2@hermes.cam.ac.uk Fri Nov 23 03:36:10 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3388721F851F for ; Fri, 23 Nov 2012 03:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.777 X-Spam-Level: X-Spam-Status: No, score=-5.777 tagged_above=-999 required=5 tests=[AWL=0.822, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-IEnbCcgzWq for ; Fri, 23 Nov 2012 03:36:06 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id E38B521F842F for ; Fri, 23 Nov 2012 03:36:05 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:52541) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1TbrYC-0003qq-qi (Exim 4.72) (return-path ); Fri, 23 Nov 2012 11:36:04 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TbrYC-0002tq-Ab (Exim 4.72) (return-path ); Fri, 23 Nov 2012 11:36:04 +0000 Date: Fri, 23 Nov 2012 11:36:04 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: John Levine In-Reply-To: <20121123014642.23974.qmail@joyce.lan> Message-ID: References: <20121123014642.23974.qmail@joyce.lan> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: dnsop@ietf.org Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 11:36:10 -0000 John Levine wrote: > > Why do you think that a host that is not a server and will > never be contacted by (non-malicious) other hosts needs a name? Is there such a thing as a host that is not a server? Multicast DNS and DNS-SD exist so that you can discover devices and services on your lan. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From joe.abley@icann.org Fri Nov 23 03:39:10 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B8821F853B for ; Fri, 23 Nov 2012 03:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VafsUclbaxoN for ; Fri, 23 Nov 2012 03:39:06 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0F22F21F850B for ; Fri, 23 Nov 2012 03:39:06 -0800 (PST) Received: from [199.212.90.44] (199.212.90.44) by smtpx.exc.icann.org (64.78.22.244) with Microsoft SMTP Server (TLS) id 8.3.245.1; Fri, 23 Nov 2012 03:39:04 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: Date: Fri, 23 Nov 2012 06:39:02 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <80308469-1DE6-42E1-BD4F-F65696764C99@icann.org> References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> <20121122231011.E8C622C0E45E@drugs.dv.isc.org> <30776E96-C575-4FDE-899C-FDC8441C5735@icann.org> To: Tony Finch X-Mailer: Apple Mail (2.1499) Cc: Lee Howard , "dnsop@ietf.org" Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 11:39:10 -0000 On 2012-11-23, at 06:28, Tony Finch wrote: > Joe Abley wrote: >=20 >> I think you skipped a step -- you need to find the zone cut before = you >> can find the nameservers responsible for the zone. I guess I do that = by >> asking for blah.ip6.arpa/IN/SOA and checking the authority section, = but >> what if the authority section is empty because of software choices in >> some nameserver? >=20 > Are name servers allowed to leave out the SOA record? It would break > negative cacheing. I was being pessimistic. If that authority-section SOA was frequently = missing (e.g. for devices behind home gateways) would anything break = from the perspective of stub resolvers? I can't think of anything; hence = I assume it's broken. Joe= From jim@rfc1035.com Fri Nov 23 03:42:27 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D8B21F84D1 for ; Fri, 23 Nov 2012 03:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POlu+mt+Yd5X for ; Fri, 23 Nov 2012 03:42:22 -0800 (PST) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) by ietfa.amsl.com (Postfix) with ESMTP id C4E8821F854F for ; Fri, 23 Nov 2012 03:42:20 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id 76F84CBC41D; Fri, 23 Nov 2012 11:42:17 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jim Reid In-Reply-To: Date: Fri, 23 Nov 2012 11:42:16 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> To: Tony Finch X-Mailer: Apple Mail (2.1499) Cc: dnsop@ietf.org, Lawrence Conroy Subject: [DNSOP] finding the closest delegation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 11:42:27 -0000 On 23 Nov 2012, at 11:17, Tony Finch wrote: > Just query for the SOA at the full RDNS name, and the name server will > return the zone apex name and SOA record in the authority section of = its > reply (or possibly in the answer section though that's unlikely). >=20 > http://tools.ietf.org/html/draft-andrews-dnsext-soa-discovery We have been here before. The ENUM name space has comparable properties to ip6.arpa: lots of = labels, "irregular" delegation points and sparse population. Some ENUM = applications and use cases had a need to find the closest encloser too. = So a long time ago, I helped write up something similar for the ENUM WG = -- http://tools.ietf.org/html/draft-ietf-enum-void-02 -- and was told I = was a naughty boy. It was apparently a Very Bad Thing to treat data from = the Authority Section as an answer from the DNS: resolving servers could = do this, but nothing else apparently. I suspect Mark's draft may have = been killed because of that too. FWIW there were other religious issues which meant that ENUM draft ended = up going nowhere. From jim@rfc1035.com Fri Nov 23 03:52:12 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F77321F8588 for ; Fri, 23 Nov 2012 03:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bna0U4kXTazC for ; Fri, 23 Nov 2012 03:52:11 -0800 (PST) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) by ietfa.amsl.com (Postfix) with ESMTP id B65F721F8587 for ; Fri, 23 Nov 2012 03:52:11 -0800 (PST) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) by shaun.rfc1035.com (Postfix) with ESMTP id 99E88CBC41D; Fri, 23 Nov 2012 11:52:10 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jim Reid In-Reply-To: Date: Fri, 23 Nov 2012 11:52:10 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <70069DB2-E6ED-492C-A900-83AA6C5112CF@rfc1035.com> References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> <20121122231011.E8C622C0E45E@drugs.dv.isc.org> <30776E96-C575-4FDE-899C-FDC8441C5735@icann.org> To: Tony Finch X-Mailer: Apple Mail (2.1499) Cc: dnsop@ietf.org Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 11:52:12 -0000 On 23 Nov 2012, at 11:28, Tony Finch wrote: > Are name servers allowed to leave out the SOA record? Yes. Though it depends on what the question was, which server you ask = and what data it has. RFC2308 lists some examples of valid = NXDOMAIN/NODATA responses containing no SOA record. > It would break negative cacheing. So what? It's not compulsory to implement or support that. Which would of course = be a Bad Idea. From marka@isc.org Fri Nov 23 06:35:03 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6E121F85B8 for ; Fri, 23 Nov 2012 06:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kB2uVQ5Q3DK for ; Fri, 23 Nov 2012 06:34:58 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 7C49121F85AD for ; Fri, 23 Nov 2012 06:34:53 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id C771F5F9A54; Fri, 23 Nov 2012 14:34:39 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 22D4D216C3D; Fri, 23 Nov 2012 14:34:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id D7F4A2C17DC9; Sat, 24 Nov 2012 01:34:22 +1100 (EST) To: Jim Reid From: Mark Andrews References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> In-reply-to: Your message of "Fri, 23 Nov 2012 11:42:16 -0000." Date: Sat, 24 Nov 2012 01:34:22 +1100 Message-Id: <20121123143422.D7F4A2C17DC9@drugs.dv.isc.org> Cc: Tony Finch , dnsop@ietf.org, Lawrence Conroy Subject: Re: [DNSOP] finding the closest delegation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 14:35:03 -0000 In message , Jim Reid writes: > On 23 Nov 2012, at 11:17, Tony Finch wrote: > > > Just query for the SOA at the full RDNS name, and the name server will > > return the zone apex name and SOA record in the authority section of its > > reply (or possibly in the answer section though that's unlikely). > > > > http://tools.ietf.org/html/draft-andrews-dnsext-soa-discovery > > We have been here before. > > The ENUM name space has comparable properties to ip6.arpa: lots of labels, "i > rregular" delegation points and sparse population. Some ENUM applications and > use cases had a need to find the closest encloser too. So a long time ago, I > helped write up something similar for the ENUM WG -- http://tools.ietf.org/h > tml/draft-ietf-enum-void-02 -- and was told I was a naughty boy. It was appar > ently a Very Bad Thing to treat data from the Authority Section as an answer > from the DNS: resolving servers could do this, but nothing else apparently. I > suspect Mark's draft may have been killed because of that too. No, it just needed some more work so that whether the zeroing of the -ve TTL on the SOA query was not done unconditionally. Named now has a per zone flag to control this. There is nothing wrong with using the SOA record from the -ve response. Named has been doing it for about 15 years in nslookup. If it is not there it falls back to stripping a label at a time until it gets the SOA record. > FWIW there were other religious issues which meant that ENUM draft ended up g > oing nowhere. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ogud@ogud.com Fri Nov 23 09:22:33 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247B321F84C5 for ; Fri, 23 Nov 2012 09:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.692 X-Spam-Level: X-Spam-Status: No, score=-103.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUw8BhhgB16D for ; Fri, 23 Nov 2012 09:22:32 -0800 (PST) Received: from smtp135.iad.emailsrvr.com (smtp135.iad.emailsrvr.com [207.97.245.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2399821F8447 for ; Fri, 23 Nov 2012 09:22:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp33.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id E5DC4305D9 for ; Fri, 23 Nov 2012 12:22:24 -0500 (EST) X-Virus-Scanned: OK Received: by smtp33.relay.iad1a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id CCC54305AF for ; Fri, 23 Nov 2012 12:22:24 -0500 (EST) Message-ID: <50AFB0D0.3020908@ogud.com> Date: Fri, 23 Nov 2012 12:22:24 -0500 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: dnsop@ietf.org References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [DNSOP] finding the closest delegation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 17:22:33 -0000 Just use DNSSEC, the RRSIG records tell you the apex of the zone :-) Olafur On 23/11/2012 06:42, Jim Reid wrote: > On 23 Nov 2012, at 11:17, Tony Finch wrote: > >> Just query for the SOA at the full RDNS name, and the name server will >> return the zone apex name and SOA record in the authority section of its >> reply (or possibly in the answer section though that's unlikely). >> >> http://tools.ietf.org/html/draft-andrews-dnsext-soa-discovery > > We have been here before. > > The ENUM name space has comparable properties to ip6.arpa: lots of labels, "irregular" delegation points and sparse population. Some ENUM applications and use cases had a need to find the closest encloser too. So a long time ago, I helped write up something similar for the ENUM WG -- http://tools.ietf.org/html/draft-ietf-enum-void-02 -- and was told I was a naughty boy. It was apparently a Very Bad Thing to treat data from the Authority Section as an answer from the DNS: resolving servers could do this, but nothing else apparently. I suspect Mark's draft may have been killed because of that too. > > FWIW there were other religious issues which meant that ENUM draft ended up going nowhere. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From daryl.tanner@blueyonder.co.uk Fri Nov 23 17:32:11 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF02821F85AA for ; Fri, 23 Nov 2012 17:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnUIOD3f2BJD for ; Fri, 23 Nov 2012 17:32:11 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 64EA021F8583 for ; Fri, 23 Nov 2012 17:32:11 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so10227225oag.31 for ; Fri, 23 Nov 2012 17:32:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=I1bjCpQeV1QvIekjxR5TCYsDp4MuEoqimTW2Bt/q0OQ=; b=mGf15tADN9lX/4MBx5/vwIj9ohf3fPZzFJIpA9iYe7BRVFYa/zVyOuCOg8icQhaE+O Sw4q9+tGbsbDq+JZ1O2mjjfTZIeoxgSd434j8KbL3NIPiCagkcceQNVPVbmcdR0j53xM DUGElXXT/mjtEJU5ZXFNDUiyPulEQxM6PY5vJwX016EUnYKEWcznwKTHLkj3WxedrdTC 6rmVeKynk4W1Rb5JbUNc//A3SmqwOBcIRRC+7OoWzkgNbRcwU4mF4N4l7yEmesztOexV vLZIRJTxkP/vP+b4g2JeNN+vD/kiScUbcJvjWdorkMb/g3v7ngQHkhYQ9JJ/cM6uiv79 vs2Q== MIME-Version: 1.0 Received: by 10.60.24.7 with SMTP id q7mr4110088oef.108.1353720730799; Fri, 23 Nov 2012 17:32:10 -0800 (PST) Received: by 10.60.168.169 with HTTP; Fri, 23 Nov 2012 17:32:10 -0800 (PST) X-Originating-IP: [77.100.84.76] In-Reply-To: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> Date: Sat, 24 Nov 2012 01:32:10 +0000 Message-ID: From: Daryl Tanner To: Lee Howard Content-Type: multipart/alternative; boundary=e89a8ff1c4e648d06104cf33abaa X-Gm-Message-State: ALoCoQmpUc1ABETG6byexyiEYdfRulxB9tpAD1cMCT3C1O1U2l0VztbKR/1z1RBFnfEfgFTZ0PMK Cc: dnsop@ietf.org Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 01:32:12 -0000 --e89a8ff1c4e648d06104cf33abaa Content-Type: text/plain; charset=ISO-8859-1 On 21 November 2012 15:01, Lee Howard wrote: > You may remember this draft from a couple of years ago. People keep asking > me what a residential ISP should do for IPv6 PTR records, and I keep > repeating what's in the draft. > The intent is to document existing solutions, since prepopulating PTRs like > we did in IPv4 doesn't work. Last time I brought it to DNSOP, there was > interest, but not necessarily as a working group document. Since it's been > a while, and the operator community is still asking for guidance, I've > updated it, and would like a renewed review of it as an individual > submission (unless this WG or v6ops wants it). > I'm in support of this document being published. One observation is that the delegation to CPE routers (home gateways) is contradictory to RFC6092: REC-8 By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server. Not suggesting delegation to CPE shouldn't happen, but would it would negate this requirement. Regards Daryl --e89a8ff1c4e648d06104cf33abaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 21 November 2012 15:01, Lee Howard <lee= @asgard.org> wrote:
You may remember this draft from a couple of years ago. =A0People keep aski= ng
me what a residential ISP should do for IPv6 PTR records, and I keep
repeating what's in the draft.
The intent is to document existing solutions, since prepopulating PTRs like=
we did in IPv4 doesn't work. =A0Last time I brought it to DNSOP, there = was
interest, but not necessarily as a working group document. =A0Since it'= s been
a while, and the operator community is still asking for guidance, I've<= br> updated it, and would like a renewed review of it as an individual
submission (unless this WG or v6ops wants it).
=A0
I'm in support of this document being published.

One obs= ervation is that the delegation to CPE routers (home gateways) is contradic= tory to RFC6092:

=A0REC-8=A0=A0 By DEFAULT, inbound DNS queries received on exterior
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 interfaces MUST NOT be processed by any inte= grated DNS
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 resolving server.

Not s= uggesting delegation to CPE shouldn't happen, but would it would negate= this requirement.

Regards
Daryl
--e89a8ff1c4e648d06104cf33abaa-- From paul@redbarn.org Fri Nov 23 18:17:05 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B4821F8566 for ; Fri, 23 Nov 2012 18:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Br8j1Wtt8L0N for ; Fri, 23 Nov 2012 18:17:04 -0800 (PST) Received: from ss.vix.com (ss.vix.com [IPv6:2001:559:8000:cb::2]) by ietfa.amsl.com (Postfix) with ESMTP id 79DC121F854B for ; Fri, 23 Nov 2012 18:17:04 -0800 (PST) Received: from [IPv6:2001:559:8000:cb:58f5:fc48:da3b:ac54] (unknown [IPv6:2001:559:8000:cb:58f5:fc48:da3b:ac54]) by ss.vix.com (Postfix) with ESMTP id 91D71EBCE9; Sat, 24 Nov 2012 02:17:03 +0000 (UTC) (envelope-from paul@redbarn.org) Message-ID: <50B02E1A.6000602@redbarn.org> Date: Sat, 24 Nov 2012 02:16:58 +0000 From: Paul Vixie User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Mark Andrews References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> <20121123143422.D7F4A2C17DC9@drugs.dv.isc.org> In-Reply-To: <20121123143422.D7F4A2C17DC9@drugs.dv.isc.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tony Finch , Lawrence Conroy , dnsop@ietf.org Subject: Re: [DNSOP] finding the closest delegation X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 02:17:05 -0000 On 2012-11-23 2:34 PM, Mark Andrews wrote: > ... > There is nothing wrong with using the SOA record from the -ve > response. Named has been doing it for about 15 years in nslookup. > If it is not there it falls back to stripping a label at a time > until it gets the SOA record. indeed not. i think mark means nsupdate here. the history of this is, i wrote for late model bind8 a function called res_findzonecut(), which was part of integrating a contributed implementation of RFC 2136, which i'd been the editor and main author of. the comments at the top of lib/res/res_findzonecut.c are shown below. there's nothing untoward, or spec-violating, or even spec-bending going on here. /* * int * res_findzonecut(res, dname, class, zname, zsize, addrs, naddrs) * find enclosing zone for a , and some server addresses * parameters: * res - resolver context to work within (is modified) * dname - domain name whose enclosing zone is desired * class - class of dname (and its enclosing zone) * zname - found zone name * zsize - allocated size of zname * addrs - found server addresses * naddrs - max number of addrs * return values: * < 0 - an error occurred (check errno) * = 0 - zname is now valid, but addrs[] wasn't changed * > 0 - zname is now valid, and return value is number of addrs[] found * notes: * this function calls res_nsend() which means it depends on correctly * functioning recursive nameservers (usually defined in /etc/resolv.conf * or its local equivilent). * * we start by asking for an SOA. if we get one as an * answer, that just means is a zone top, which is fine. * more than likely we'll be told to go pound sand, in the form of a * negative answer. * * note that we are not prepared to deal with referrals since that would * only come from authority servers and our correctly functioning local * recursive server would have followed the referral and got us something * more definite. * * if the authority section contains an SOA, this SOA should also be the * closest enclosing zone, since any intermediary zone cuts would've been * returned as referrals and dealt with by our correctly functioning local * recursive name server. but an SOA in the authority section should NOT * match our dname (since that would have been returned in the answer * section). an authority section SOA has to be "above" our dname. * * however, since authority section SOA's were once optional, it's * possible that we'll have to go hunting for the enclosing SOA by * ripping labels off the front of our dname -- this is known as "doing * it the hard way." * * ultimately we want some server addresses, which are ideally the ones * pertaining to the SOA.MNAME, but only if there is a matching NS RR. * so the second phase (after we find an SOA) is to go looking for the * NS RRset for that SOA's zone. * * no answer section processed by this code is allowed to contain CNAME * or DNAME RR's. for the SOA query this means we strip a label and * keep going. for the NS and A queries this means we just give up. */ paul From sthaug@nethelp.no Sat Nov 24 00:17:41 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BFC21F8695 for ; Sat, 24 Nov 2012 00:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wP7U3mzWN+Fs for ; Sat, 24 Nov 2012 00:17:40 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 9BDAB21F868E for ; Sat, 24 Nov 2012 00:17:39 -0800 (PST) Received: (qmail 44293 invoked from network); 24 Nov 2012 08:17:34 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 24 Nov 2012 08:17:34 -0000 Date: Sat, 24 Nov 2012 09:17:34 +0100 (CET) Message-Id: <20121124.091734.74705846.sthaug@nethelp.no> To: daryl.tanner@blueyonder.co.uk From: sthaug@nethelp.no In-Reply-To: References: <00ac01cdc7f9$12e2f3e0$38a8dba0$@asgard.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: lee@asgard.org, dnsop@ietf.org Subject: Re: [DNSOP] new version of IPv6 rDNS for ISPs X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 08:17:41 -0000 > One observation is that the delegation to CPE routers (home gateways) is > contradictory to RFC6092: > > REC-8 By DEFAULT, inbound DNS queries received on exterior > interfaces MUST NOT be processed by any integrated DNS > resolving server. > > Not suggesting delegation to CPE shouldn't happen, but would it would > negate this requirement. DNS amplification attacks caused, at least partly, by DNS proxies in CPEs is a significant problem. Note that this is often due to the CPEs being open to *recursive* queries. A delegation would only need replies to zones the CPE was authoritative for - however, I'm afraid such a distinction would be lost on many CPE manufacturers. There are also ISPs that block outgoing DNS queries to (residential) CPEs, precisely because of DNS amplification attacks by these CPEs. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From lee@asgard.org Wed Nov 28 12:51:57 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4359221F843A for ; Wed, 28 Nov 2012 12:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FENSARyzCGX for ; Wed, 28 Nov 2012 12:51:55 -0800 (PST) Received: from atl4mhob10.myregisteredsite.com (atl4mhob10.myregisteredsite.com [209.17.115.48]) by ietfa.amsl.com (Postfix) with ESMTP id E47E421F84D0 for ; Wed, 28 Nov 2012 12:51:51 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob10.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qASKpnB6029507 for ; Wed, 28 Nov 2012 15:51:49 -0500 Received: (qmail 8604 invoked by uid 0); 28 Nov 2012 20:51:47 -0000 Received: from unknown (HELO HDC00042402) (lee@asgard.org@204.235.115.165) by 0 with ESMTPA; 28 Nov 2012 20:51:47 -0000 From: "Lee Howard" To: Date: Wed, 28 Nov 2012 15:51:47 -0500 Message-ID: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3NnlzD9U0y1HktRqKW+jid0GWOTg== Content-Language: en-us Subject: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 20:51:57 -0000 Thanks for the lively discussion! Here's what I heard, in addition to several useful, non-controversial text suggestions: 1. Uses for reverse DNS a. Several people think it's unnecessary to require PTRs. A few even think a lack of PTRs might be a good thing (in the case of mail servers rejecting connections). b. A few people think they are useful, because their servers can put the PTR response in logs and they have some idea where a connection came from. Others point out that WHOIS is a better source, with debate about the usefulness and utility of WHOIS. In my opinion, the need should be filled as close as possible to those who need it: don't rely on ISPs to develop infrastructure for your convenience, without any benefit to them. c. I did not see anyone say that PTRs are required. Some people have asked me to take a position, in this or another document, that PTRs are not required (for residential Internet users). Someone else may submit that document. 2. Delegation: Several people support delegating to the home gateway. a. There is no mechanism to tell a home gateway that it is now authoritative for "12345.customer.example.net." Or is there? Without that, it also wouldn't know what FQDN to put in PTR RRs. b. Violates RFC6092 REQ-8. c. Delegating to a single auth nameserver may or may not be acceptable. d. (from v6ops) ISP should slave from customer CPE 3. Dynamic DNS a. Several people like dDNS, but it isn't clear that there's an existing mechanism for telling hosts to whom to send their dDNS updates. b. dDNS does help the case of privacy or other temporary addresses Of ~13 people commenting, I heard three people explicitly say, "Please publish this document" and one say, "This doesn't provide enough practical advice about how to do in IPv6 what we did in IPv4; maybe write a requirements doc instead." One approach to finding consensus then: 1. Update the document to reflect the points in #1 above. 2. Support someone else writing a draft called "PTRs unnecessary" or whatever. I have someone in mind. 3. Document the problems with #2(a) and #3(a) above. Since there is currently no mechanism, no requirements document, and no charter to change these limitations, this provides the best information available at this time. 4. Write a requirements document to fill gaps in #2 and #3. This may coincidentally fall into work spinning off from 6renum. I would very much like co-authors for this, since I will not be able to give it my full attention. As I make responsive changes, I will also try to change the tone a bit, from a survey of possible mechanisms, to guidance for operators ("Here's what operators should do; here are other possible mechanisms, and why they aren't worth bothering about.") Thanks again for the very useful feedback and discussion. I hope this message will reflect rough consensus, or at least clearer detail of where I've missed the point. Lee From Ted.Lemon@nominum.com Wed Nov 28 13:23:31 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8279521F85D2 for ; Wed, 28 Nov 2012 13:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRhhCzxsu08H for ; Wed, 28 Nov 2012 13:23:31 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id AA35721F86E7 for ; Wed, 28 Nov 2012 13:23:30 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKULaA0u+Ddjhke4ZxpSor4dHbeUYwEO7c@postini.com; Wed, 28 Nov 2012 13:23:30 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 Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B22251B819F for ; Wed, 28 Nov 2012 13:23:29 -0800 (PST) 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 Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id A7D5D190043; Wed, 28 Nov 2012 13:23:29 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 28 Nov 2012 13:23:29 -0800 From: Ted Lemon To: Lee Howard Thread-Topic: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) Thread-Index: Ac3NnlzD9U0y1HktRqKW+jid0GWOTgAU0xCA Date: Wed, 28 Nov 2012 21:23:28 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474169F9@mbx-01.win.nominum.com> References: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> In-Reply-To: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 21:23:31 -0000 On Nov 28, 2012, at 3:51 PM, Lee Howard wrote: > 2. Delegation: Several people support delegating to the home gateway. > a. There is no mechanism to tell a home gateway that it is now > authoritative for "12345.customer.example.net." Or is there? Without th= at, > it also wouldn't know what FQDN to put in PTR RRs. > b. Violates RFC6092 REQ-8. > c. Delegating to a single auth nameserver may or may not be acceptable. > d. (from v6ops) ISP should slave from customer CPE The really good point that you almost made here is that the CPE device does= n't necessarily have an FQDN zone to update, and if it is delegated the PTR= zone and doesn't have anything to stuff into it, it might stuff something = harmful into it. So it would be good to advise against that. Then the question of what forward zone to publish is interesting; I'd assum= ed that the ISP would never be involved in this. I suppose some ISPs migh= t want to offer this as a service, so it would be worth documenting how the= y ought to do it. There is a draft that documents how the reverse zone could be set up (as pa= rt of the DHCP PD process). If we think there's a real use case for the I= SP offering the customer a zone, we should define a way for the ISP to do t= his (I'd suggest a DHCP option, since we're presumably doing DHCP PD to del= egate a prefix). > 2. Support someone else writing a draft called "PTRs unnecessary" or > whatever. I have someone in mind. This is a waste of time=97it will never get consensus. We've wasted time = in this working group trying to do this in the past. > 3. Document the problems with #2(a) and #3(a) above. Since there is > currently no mechanism, no requirements document, and no charter to chang= e > these limitations, this provides the best information available at this > time. =20 > 4. Write a requirements document to fill gaps in #2 and #3. This may > coincidentally fall into work spinning off from 6renum. I would very muc= h > like co-authors for this, since I will not be able to give it my full > attention. I have some interest in this topic and would be willing to write some docs,= although you might not agree with the docs I would write. From lee@asgard.org Wed Nov 28 14:10:31 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E818221F8937 for ; Wed, 28 Nov 2012 14:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SykS4mDhmM1m for ; Wed, 28 Nov 2012 14:10:31 -0800 (PST) Received: from atl4mhob08.myregisteredsite.com (atl4mhob08.myregisteredsite.com [209.17.115.46]) by ietfa.amsl.com (Postfix) with ESMTP id 089AC21F892F for ; Wed, 28 Nov 2012 14:10:30 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob08.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qASMATS5028374 for ; Wed, 28 Nov 2012 17:10:29 -0500 Received: (qmail 18350 invoked by uid 0); 28 Nov 2012 22:10:29 -0000 Received: from unknown (HELO HDC00042402) (lee@asgard.org@204.235.115.165) by 0 with ESMTPA; 28 Nov 2012 22:10:29 -0000 From: "Lee Howard" To: "'Ted Lemon'" References: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> <8D23D4052ABE7A4490E77B1A012B6307474169F9@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307474169F9@mbx-01.win.nominum.com> Date: Wed, 28 Nov 2012 17:10:28 -0500 Message-ID: <009401cdcdb5$2d13f630$873be290$@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHF3Sb6bGLrppEyzIq+55USZMJZegJTFB1wl/0UC8A= Content-Language: en-us Cc: dnsop@ietf.org Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:10:32 -0000 > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Wednesday, November 28, 2012 4:23 PM > To: Lee Howard > Cc: > Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) > > On Nov 28, 2012, at 3:51 PM, Lee Howard wrote: > > 2. Delegation: Several people support delegating to the home gateway. > > a. There is no mechanism to tell a home gateway that it is now > > authoritative for "12345.customer.example.net." Or is there? Without > > that, it also wouldn't know what FQDN to put in PTR RRs. > > b. Violates RFC6092 REQ-8. > > c. Delegating to a single auth nameserver may or may not be acceptable. > > d. (from v6ops) ISP should slave from customer CPE > > The really good point that you almost made here is that the CPE device doesn't necessarily > have an FQDN zone to update, and if it is delegated the PTR zone and doesn't have anything > to stuff into it, it might stuff something harmful into it. So it would be good to advise > against that. > > Then the question of what forward zone to publish is interesting; I'd assumed that the ISP > would never be involved in this. I suppose some ISPs might want to offer this as a service, > so it would be worth documenting how they ought to do it. Without explicit caution, the CPE might populate .local for FQDN. Yes, I assumed that everyone knew that residential users rarely have their own domain name, and would have to get it from their ISP. I don't think ISPs especially want to provide this--there's no gain and lots of potential pain. > > There is a draft that documents how the reverse zone could be set up (as part of the DHCP > PD process). If we think there's a real use case for the ISP offering the customer a zone, we > should define a way for the ISP to do this (I'd suggest a DHCP option, since we're > presumably doing DHCP PD to delegate a prefix). We might want to check with some ISPs and see if they would be interested in consuming such a spec. I doubt many would--it's something to troubleshoot that offers little value to the residential user. > > 3. Document the problems with #2(a) and #3(a) above. Since there is > > currently no mechanism, no requirements document, and no charter to > > change these limitations, this provides the best information available > > at this time. > > 4. Write a requirements document to fill gaps in #2 and #3. This may > > coincidentally fall into work spinning off from 6renum. I would very > > much like co-authors for this, since I will not be able to give it my > > full attention. > > I have some interest in this topic and would be willing to write some docs, although you > might not agree with the docs I would write. Then it would be healthy for us to collaborate! Maybe we can drive compromise positions before making the WG(s) thrash. Lee From Ted.Lemon@nominum.com Wed Nov 28 14:35:27 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8E321F8961 for ; Wed, 28 Nov 2012 14:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAG5DvXOZo8P for ; Wed, 28 Nov 2012 14:35:27 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id ED52F21F8960 for ; Wed, 28 Nov 2012 14:35:26 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKULaRrot2RW8I8sNJIHVMk87+l2Q9AJ1x@postini.com; Wed, 28 Nov 2012 14:35:27 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 Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 373731B81A6 for ; Wed, 28 Nov 2012 14:35:26 -0800 (PST) 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 Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 2D179190043; Wed, 28 Nov 2012 14:35:26 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 28 Nov 2012 14:35:26 -0800 From: Ted Lemon To: Lee Howard Thread-Topic: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) Thread-Index: Ac3NnlzD9U0y1HktRqKW+jid0GWOTgAU0xCAAAGkXAAAAN7sAA== Date: Wed, 28 Nov 2012 22:35:24 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747416B59@mbx-01.win.nominum.com> References: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> <8D23D4052ABE7A4490E77B1A012B6307474169F9@mbx-01.win.nominum.com> <009401cdcdb5$2d13f630$873be290$@asgard.org> In-Reply-To: <009401cdcdb5$2d13f630$873be290$@asgard.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:35:27 -0000 On Nov 28, 2012, at 5:10 PM, Lee Howard wrote: > Without explicit caution, the CPE might populate .local for FQDN. Yes, I > assumed that > everyone knew that residential users rarely have their own domain name, a= nd > would have > to get it from their ISP. I don't think ISPs especially want to provide > this--there's no gain > and lots of potential pain. I think that there's minimal potential pain if it's done right, and it's so= mething they could charge extra for, but that's pretty much the only scenar= io in which I expect ISPs to do this. OTOH, it seems like a pretty obviou= s market for a third party. > We might want to check with some ISPs and see if they would be interested= in > consuming > such a spec. I doubt many would--it's something to troubleshoot that off= ers > little value to > the residential user.=20 Actually I'd have to disagree with this. It offers significant value to t= he residential user in that their site can now have a globally-unique name,= which is a problem we've discussed at some length in homenet, and which re= mains an unsolved problem. > Then it would be healthy for us to collaborate! Maybe we can drive > compromise > positions before making the WG(s) thrash. Sure! :) From fanf2@hermes.cam.ac.uk Thu Nov 29 03:06:23 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A343121F89DF for ; Thu, 29 Nov 2012 03:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MTs5WFloFJp for ; Thu, 29 Nov 2012 03:06:23 -0800 (PST) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) by ietfa.amsl.com (Postfix) with ESMTP id C19D321F89DE for ; Thu, 29 Nov 2012 03:06:22 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:34685) by ppsw-43.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Te1wh-0001St-mP (Exim 4.72) (return-path ); Thu, 29 Nov 2012 11:06:19 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Te1wg-0000jS-Ve (Exim 4.72) (return-path ); Thu, 29 Nov 2012 11:06:18 +0000 Date: Thu, 29 Nov 2012 11:06:18 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Ted Lemon In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747416B59@mbx-01.win.nominum.com> Message-ID: References: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> <8D23D4052ABE7A4490E77B1A012B6307474169F9@mbx-01.win.nominum.com> <009401cdcdb5$2d13f630$873be290$@asgard.org> <8D23D4052ABE7A4490E77B1A012B630747416B59@mbx-01.win.nominum.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Lee Howard , "" Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 11:06:23 -0000 Ted Lemon wrote: > On Nov 28, 2012, at 5:10 PM, Lee Howard wrote: > > Yes, I assumed that everyone knew that residential users rarely have > > their own domain name, and would have to get it from their ISP. I > > don't think ISPs especially want to provide this--there's no gain and > > lots of potential pain. > > I think that there's minimal potential pain if it's done right, and it's > something they could charge extra for, but that's pretty much the only > scenario in which I expect ISPs to do this. OTOH, it seems like a > pretty obvious market for a third party. It ought to be part of the basic package. (Like Demon Internet in the mid-1990s.) > > We might want to check with some ISPs and see if they would be > > interested in consuming such a spec. I doubt many would--it's > > something to troubleshoot that offers little value to the residential > > user. > > Actually I'd have to disagree with this. It offers significant value to > the residential user in that their site can now have a globally-unique > name, which is a problem we've discussed at some length in homenet, and > which remains an unsolved problem. If every site has a domain name then it becomes easy to support wide-area service discovery, so people can still make use of what they have at home when they are away. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From lee@asgard.org Thu Nov 29 06:17:05 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8B421F89B5 for ; Thu, 29 Nov 2012 06:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8l0qKr0pmoX for ; Thu, 29 Nov 2012 06:17:05 -0800 (PST) Received: from atl4mhob07.myregisteredsite.com (atl4mhob07.myregisteredsite.com [209.17.115.45]) by ietfa.amsl.com (Postfix) with ESMTP id E2ED921F887F for ; Thu, 29 Nov 2012 06:17:04 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qATEH1h3023142 for ; Thu, 29 Nov 2012 09:17:01 -0500 Received: (qmail 7473 invoked by uid 0); 29 Nov 2012 14:17:01 -0000 Received: from unknown (HELO HDC00042402) (lee@asgard.org@204.235.115.165) by 0 with ESMTPA; 29 Nov 2012 14:17:01 -0000 From: "Lee Howard" To: "'Tony Finch'" , "'Ted Lemon'" References: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> <8D23D4052ABE7A4490E77B1A012B6307474169F9@mbx-01.win.nominum.com> <009401cdcdb5$2d13f630$873be290$@asgard.org> <8D23D4052ABE7A4490E77B1A012B630747416B59@mbx-01.win.nominum.com> In-Reply-To: Date: Thu, 29 Nov 2012 09:17:01 -0500 Message-ID: <009d01cdce3c$3355e800$9a01b800$@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHF3Sb6bGLrppEyzIq+55USZMJZegJTFB1wAWS5G+oCOdVxiAF6s3jJl9VYmyA= Content-Language: en-us Cc: dnsop@ietf.org Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 14:17:06 -0000 > -----Original Message----- > From: Tony Finch [mailto:fanf2@hermes.cam.ac.uk] On Behalf Of Tony Finch > Sent: Thursday, November 29, 2012 6:06 AM > To: Ted Lemon > Cc: Lee Howard; > Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) > > Ted Lemon wrote: > > > On Nov 28, 2012, at 5:10 PM, Lee Howard wrote: > > > > Yes, I assumed that everyone knew that residential users rarely have > > > their own domain name, and would have to get it from their ISP. I > > > don't think ISPs especially want to provide this--there's no gain > > > and lots of potential pain. > > > > I think that there's minimal potential pain if it's done right, and > > it's something they could charge extra for, but that's pretty much the > > only scenario in which I expect ISPs to do this. OTOH, it seems like > > a pretty obvious market for a third party. > > It ought to be part of the basic package. (Like Demon Internet in the > mid-1990s.) Show me a business case. For the residential ISP, all I see is troubleshooting and time spent explaining DNS to customers. In exchange, expensive upstream wavelengths get used. > > > We might want to check with some ISPs and see if they would be > > > interested in consuming such a spec. I doubt many would--it's > > > something to troubleshoot that offers little value to the > > > residential user. > > > > Actually I'd have to disagree with this. It offers significant value > > to the residential user in that their site can now have a > > globally-unique name, which is a problem we've discussed at some > > length in homenet, and which remains an unsolved problem. > > If every site has a domain name then it becomes easy to support wide-area service discovery, > so people can still make use of what they have at home when they are away. The question I think we should ask is, "If we develop a mechanism, will anyone deploy it?" The answer is not, "The mechanism enables other things." I don't want to waste my time, and the working group's time, on dustbin-destined technologies. Lee From warren@kumari.net Thu Nov 29 06:41:41 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA52E21F89DB for ; Thu, 29 Nov 2012 06:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqD8yqJx-X1s for ; Thu, 29 Nov 2012 06:41:39 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E3421F8821 for ; Thu, 29 Nov 2012 06:41:39 -0800 (PST) Received: from [192.168.1.142] (unknown [66.84.81.119]) by vimes.kumari.net (Postfix) with ESMTPSA id CB2871B405C8; Thu, 29 Nov 2012 09:41:38 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630747416B59@mbx-01.win.nominum.com> Date: Thu, 29 Nov 2012 09:41:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> <8D23D4052ABE7A4490E77B1A012B6307474169F9@mbx-01.win.nominum.com> <009401cdcdb5$2d13f630$873be290$@asgard.org> <8D23D4052ABE7A4490E77B1A012B630747416B59@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1499) Cc: Lee Howard , "" Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 14:41:41 -0000 On Nov 28, 2012, at 5:35 PM, Ted Lemon wrote: > On Nov 28, 2012, at 5:10 PM, Lee Howard wrote: >> Without explicit caution, the CPE might populate .local for FQDN. = Yes, I >> assumed that >> everyone knew that residential users rarely have their own domain = name, and >> would have >> to get it from their ISP. I don't think ISPs especially want to = provide >> this--there's no gain >> and lots of potential pain. >=20 > I think that there's minimal potential pain if it's done right, and = it's something they could charge extra for, but that's pretty much the = only scenario in which I expect ISPs to do this. OTOH, it seems like a = pretty obvious market for a third party. You mean like DynDNS for example? >=20 >> We might want to check with some ISPs and see if they would be = interested in >> consuming >> such a spec. I doubt many would--it's something to troubleshoot that = offers >> little value to >> the residential user.=20 >=20 > Actually I'd have to disagree with this. It offers significant value = to the residential user in that their site can now have a = globally-unique name, which is a problem we've discussed at some length = in homenet, and which remains an unsolved problem. Points at Dyn and afraid.org and 3322.org^w^w and no-ip=85 W >=20 >> Then it would be healthy for us to collaborate! Maybe we can drive >> compromise >> positions before making the WG(s) thrash. >=20 > Sure! :) >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >=20 --=20 A. No Q. Is it sensible to top-post? From Ted.Lemon@nominum.com Thu Nov 29 07:45:53 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEF321F8AC0 for ; Thu, 29 Nov 2012 07:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rB2BPGLcjvoK for ; Thu, 29 Nov 2012 07:45:52 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 92A9321F8604 for ; Thu, 29 Nov 2012 07:45:52 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKULeDMJ216j6kE3KN5kVUYe5nM13TAVQQ@postini.com; Thu, 29 Nov 2012 07:45:52 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 Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E14741B81A6 for ; Thu, 29 Nov 2012 07:45:51 -0800 (PST) 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 Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id DB428190052; Thu, 29 Nov 2012 07:45:51 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 29 Nov 2012 07:45:45 -0800 From: Ted Lemon To: Warren Kumari Thread-Topic: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) Thread-Index: Ac3NnlzD9U0y1HktRqKW+jid0GWOTgAU0xCAAAGkXAAAAN7sAAAhvs0AAAI9GQA= Date: Thu, 29 Nov 2012 15:45:45 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63074741752D@mbx-01.win.nominum.com> References: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> <8D23D4052ABE7A4490E77B1A012B6307474169F9@mbx-01.win.nominum.com> <009401cdcdb5$2d13f630$873be290$@asgard.org> <8D23D4052ABE7A4490E77B1A012B630747416B59@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5B7DA625D6C561458922775C91D4CD68@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Lee Howard , "" Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 15:45:53 -0000 On Nov 29, 2012, at 9:41 AM, Warren Kumari wrote: > You mean like DynDNS for example? Exactly. And DynDNS is a great example of why we need a standard. From lee@asgard.org Thu Nov 29 13:42:53 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E1321F8C6C for ; Thu, 29 Nov 2012 13:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twsXpu+xYmRU for ; Thu, 29 Nov 2012 13:42:52 -0800 (PST) Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8887521F8C6B for ; Thu, 29 Nov 2012 13:42:52 -0800 (PST) Received: from mailpod.hostingplatform.com (mail.networksolutionsemail.com [205.178.146.50]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qATLgpH6032310 for ; Thu, 29 Nov 2012 16:42:51 -0500 Received: (qmail 14048 invoked by uid 0); 29 Nov 2012 21:42:50 -0000 Received: from unknown (HELO HDC00042402) (lee@asgard.org@204.235.115.165) by 0 with ESMTPA; 29 Nov 2012 21:42:50 -0000 From: "Lee Howard" To: "'Ted Lemon'" , "'Warren Kumari'" References: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> <8D23D4052ABE7A4490E77B1A012B6307474169F9@mbx-01.win.nominum.com> <009401cdcdb5$2d13f630$873be290$@asgard.org> <8D23D4052ABE7A4490E77B1A012B630747416B59@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074741752D@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63074741752D@mbx-01.win.nominum.com> Date: Thu, 29 Nov 2012 16:42:48 -0500 Message-ID: <00bf01cdce7a$7af8f380$70eada80$@asgard.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHF3Sb6bGLrppEyzIq+55USZMJZegJTFB1wAWS5G+oCOdVxiAKROOOxAvrljm6XtUtrwA== Content-Language: en-us Cc: dnsop@ietf.org Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 21:42:53 -0000 > -----Original Message----- > From: dnsop-bounces@ietf.org [mailto:dnsop-bounces@ietf.org] On Behalf Of Ted Lemon > Sent: Thursday, November 29, 2012 10:46 AM > To: Warren Kumari > Cc: Lee Howard; > Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) > > On Nov 29, 2012, at 9:41 AM, Warren Kumari wrote: > > You mean like DynDNS for example? > > Exactly. And DynDNS is a great example of why we need a standard. Can you list the functional requirements? Lee From marka@isc.org Thu Nov 29 16:27:12 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03EB21F8B06 for ; Thu, 29 Nov 2012 16:27:12 -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=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhY4W3FihGyD for ; Thu, 29 Nov 2012 16:27:12 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 509C021F8B04 for ; Thu, 29 Nov 2012 16:27:12 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id F27FF5F99DF; Fri, 30 Nov 2012 00:26:59 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 03D70216C3D; Fri, 30 Nov 2012 00:26:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1EAC32C61831; Fri, 30 Nov 2012 11:26:51 +1100 (EST) To: "Lee Howard" From: Mark Andrews References: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> <8D23D4052ABE7A4490E77B1A012B6307474169F9@mbx-01.win.nominum.com> <009401cdcdb5$2d13f630$873be290$@asgard.org> <8D23D4052ABE7A4490E77B1A012B630747416B59@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074741752D@mbx-01.win.nominum.com> <00bf01cdce7a$7af8f380$70eada80$@asgard.org> In-reply-to: Your message of "Thu, 29 Nov 2012 16:42:48 CDT." <00bf01cdce7a$7af8f380$70eada80$@asgard.org> Date: Fri, 30 Nov 2012 11:26:50 +1100 Message-Id: <20121130002651.1EAC32C61831@drugs.dv.isc.org> Cc: dnsop@ietf.org, 'Ted Lemon' Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 00:27:13 -0000 In message <00bf01cdce7a$7af8f380$70eada80$@asgard.org>, "Lee Howard" writes: > > -----Original Message----- > > From: dnsop-bounces@ietf.org [mailto:dnsop-bounces@ietf.org] On Behalf Of > Ted Lemon > > Sent: Thursday, November 29, 2012 10:46 AM > > To: Warren Kumari > > Cc: Lee Howard; > > Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) > > > > On Nov 29, 2012, at 9:41 AM, Warren Kumari wrote: > > > You mean like DynDNS for example? > > > > Exactly. And DynDNS is a great example of why we need a standard. > > Can you list the functional requirements? > > Lee We have a standard for dynamic DNS updating. And standards for securing it. There are even products from different companies that interoperate. http://dyn.com/support/bonjour-and-dns-discovery/ Now while that page has a SRV record _dns-update._udp in the zone to find the server to send the update to the Mac will send the request to the nameservers for the zone if it is not there. Bog standard named has supported this since before the TSIG RFC was finalised in 2000. And if the client doesn't do it the DHCP server can. It would not suprise me to find someone running our DHCPv6 server updating a zone hosted by dyn.com using UPDATE+TSIG. Thats three vendors all interoperating with UPDATE+TSIG. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ted.Lemon@nominum.com Thu Nov 29 18:16:07 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE46F21F89D0 for ; Thu, 29 Nov 2012 18:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.285 X-Spam-Level: X-Spam-Status: No, score=-106.285 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0O9gyDjaXG5q for ; Thu, 29 Nov 2012 18:16:07 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id EA37621F89A1 for ; Thu, 29 Nov 2012 18:16:06 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKULgW5uVqy+gwcARK/QUkQuHwxQXHs3Dh@postini.com; Thu, 29 Nov 2012 18:16:07 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 Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0411C1B80AD for ; Thu, 29 Nov 2012 18:16:06 -0800 (PST) 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 Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id ECAF7190052; Thu, 29 Nov 2012 18:16:05 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 29 Nov 2012 18:16:06 -0800 From: Ted Lemon To: Mark Andrews Thread-Topic: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) Thread-Index: AQHNzpF1my/Ip8fB9UmJP6UPy6AvxpgCKkaA Date: Fri, 30 Nov 2012 02:16:05 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307474183B3@mbx-01.win.nominum.com> References: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> <8D23D4052ABE7A4490E77B1A012B6307474169F9@mbx-01.win.nominum.com> <009401cdcdb5$2d13f630$873be290$@asgard.org> <8D23D4052ABE7A4490E77B1A012B630747416B59@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074741752D@mbx-01.win.nominum.com> <00bf01cdce7a$7af8f380$70eada80$@asgard.org> <20121130002651.1EAC32C61831@drugs.dv.isc.org> In-Reply-To: <20121130002651.1EAC32C61831@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Lee Howard , "" Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 02:16:07 -0000 On Nov 29, 2012, at 7:26 PM, Mark Andrews wrote: > Thats three vendors all interoperating with UPDATE+TSIG. DynDNS.org does DNS updates? I was under the impression that it was all d= one with web fu. From marka@isc.org Thu Nov 29 21:38:10 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E9A21F886A for ; Thu, 29 Nov 2012 21:38:10 -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=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3vWv13tjCtD for ; Thu, 29 Nov 2012 21:38:09 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B71A521F87AC for ; Thu, 29 Nov 2012 21:38:09 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id A8424C980D; Fri, 30 Nov 2012 05:38:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Fri, 30 Nov 2012 05:38:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 71ACA216C3D; Fri, 30 Nov 2012 05:38:01 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 3E6C92C695E8; Fri, 30 Nov 2012 16:37:53 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> <8D23D4052ABE7A4490E77B1A012B6307474169F9@mbx-01.win.nominum.com> <009401cdcdb5$2d13f630$873be290$@asgard.org> <8D23D4052ABE7A4490E77B1A012B630747416B59@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074741752D@mbx-01.win.nominum.com> <00bf01cdce7a$7af8f380$70eada80$@asgard.org> <20121130002651.1EAC32C61831@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B6307474183B3@mbx-01.win.nominum.com> In-reply-to: Your message of "Fri, 30 Nov 2012 02:16:05 -0000." <8D23D4052ABE7A4490E77B1A012B6307474183B3@mbx-01.win.nominum.com> Date: Fri, 30 Nov 2012 16:37:52 +1100 Message-Id: <20121130053753.3E6C92C695E8@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org 1102; Body=4 Fuz1=4 Fuz2=4 Cc: Lee Howard , "" Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 05:38:10 -0000 In message <8D23D4052ABE7A4490E77B1A012B6307474183B3@mbx-01.win.nominum.com>, T ed Lemon writes: > On Nov 29, 2012, at 7:26 PM, Mark Andrews > wrote: > > Thats three vendors all interoperating with UPDATE+TSIG. > > DynDNS.org does DNS updates? I was under the impression that it was all d= > one with web fu. Yes. They do TSIG signed DNS updates. They do direct them to a update server using a in zone SRV record rather than the nameservers that are serving answers to the world but otherwise it is bog standard UPDATE + TSIG. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Thu Nov 29 22:02:05 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B185721F89BE for ; Thu, 29 Nov 2012 22:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vVD3OqLtZ8S for ; Thu, 29 Nov 2012 22:02:05 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9B521F89BB for ; Thu, 29 Nov 2012 22:02:05 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 6CF808A031 for ; Fri, 30 Nov 2012 06:01:57 +0000 (UTC) Date: Fri, 30 Nov 2012 01:01:54 -0500 From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20121130060154.GD7792@mx1.yitter.info> References: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> <8D23D4052ABE7A4490E77B1A012B6307474169F9@mbx-01.win.nominum.com> <009401cdcdb5$2d13f630$873be290$@asgard.org> <8D23D4052ABE7A4490E77B1A012B630747416B59@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074741752D@mbx-01.win.nominum.com> <00bf01cdce7a$7af8f380$70eada80$@asgard.org> <20121130002651.1EAC32C61831@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B6307474183B3@mbx-01.win.nominum.com> <20121130053753.3E6C92C695E8@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121130053753.3E6C92C695E8@drugs.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 06:02:05 -0000 On Fri, Nov 30, 2012 at 04:37:52PM +1100, Mark Andrews wrote: > Yes. They do TSIG signed DNS updates. They do direct them to a > update server using a in zone SRV record rather than the nameservers > that are serving answers to the world but otherwise it is bog > standard UPDATE + TSIG. Well, yes, but the plain fact is that if you want all Dyn's features, you have to use the webby API. Also, not every customer has access to UPDATE + TSIG. Full disclosure: Dyn gives me money, and I give them some of my feeble brain. A -- Andrew Sullivan ajs@anvilwalrusden.com From Ted.Lemon@nominum.com Fri Nov 30 06:09:12 2012 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF9321F89A9 for ; Fri, 30 Nov 2012 06:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToxSuivoX+h6 for ; Fri, 30 Nov 2012 06:09:11 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 996F921F84CE for ; Fri, 30 Nov 2012 06:09:11 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKULi+Bw83V1OssT0hRXyELSIGgVOPdc2j@postini.com; Fri, 30 Nov 2012 06:09:11 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 Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id EF8C21B81F5 for ; Fri, 30 Nov 2012 06:09:10 -0800 (PST) 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 Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E8309190052; Fri, 30 Nov 2012 06:09:10 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 30 Nov 2012 06:09:10 -0800 From: Ted Lemon To: Mark Andrews Thread-Topic: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) Thread-Index: AQHNzpF1my/Ip8fB9UmJP6UPy6AvxpgCKkaA//+yXN+AARTfgA== Date: Fri, 30 Nov 2012 14:09:10 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630747418F6D@mbx-01.win.nominum.com> References: <008d01cdcdaa$2ebbdad0$8c339070$@asgard.org> <8D23D4052ABE7A4490E77B1A012B6307474169F9@mbx-01.win.nominum.com> <009401cdcdb5$2d13f630$873be290$@asgard.org> <8D23D4052ABE7A4490E77B1A012B630747416B59@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B63074741752D@mbx-01.win.nominum.com> <00bf01cdce7a$7af8f380$70eada80$@asgard.org> <20121130002651.1EAC32C61831@drugs.dv.isc.org> <8D23D4052ABE7A4490E77B1A012B6307474183B3@mbx-01.win.nominum.com> <20121130053753.3E6C92C695E8@drugs.dv.isc.org> In-Reply-To: <20121130053753.3E6C92C695E8@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <043DFA831B3CEC4CB1455C396C447EF1@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Lee Howard , "" Subject: Re: [DNSOP] summary (was: RE: new version of IPv6 rDNS for ISPs) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 14:09:12 -0000 On Nov 30, 2012, at 12:37 AM, Mark Andrews wrote: > Yes. They do TSIG signed DNS updates. They do direct them to a > update server using a in zone SRV record rather than the nameservers > that are serving answers to the world but otherwise it is bog > standard UPDATE + TSIG. So it's OpenWRT that's missing the feature of using this update mechanism.