From weiler@tislabs.com Thu Aug 4 06:52:31 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F8B21F8B4B for ; Thu, 4 Aug 2011 06:52:31 -0700 (PDT) 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 GUEvgsSGeyOV for ; Thu, 4 Aug 2011 06:52:30 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 950FF21F8B3D for ; Thu, 4 Aug 2011 06:52:30 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 3FEE728B0042 for ; Thu, 4 Aug 2011 09:52:45 -0400 (EDT) Received: from nova.tislabs.com (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id 2003E1F8033 for ; Thu, 4 Aug 2011 09:52:45 -0400 (EDT) Date: Thu, 4 Aug 2011 09:52:45 -0400 (EDT) From: weiler@tislabs.com To: dnsext@ietf.org Message-ID: User-Agent: Alpine 2.00 (LRH 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [dnsext] dnssec-bis-updates and the CD bit (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 13:52:31 -0000 [I sent this to namedroppers by mistake, having just hit "reply all" and not checked the headers closely enough. Some of you will see it as a duplicate.] On Mon, 1 Nov 2010, Florian Weimer wrote: > Anyway, I have no problems with the text as-is (in -11, don't know if > that's current). Note however that the more or less explicit > recommendation to set CD by default has security implications: you no > longer profit from more stringent validation at an upstream validator. > This should be mentioned in the Security Considerations. I missed this when preparing -13. I'm submitting a new version now that incorporates this suggestion. > I think this is a very minor issue because even with the CD fixes, the > protocol more or less requires that your forwarder has a superset of > your own trust anchors. Therefore, the situation that the forwarders > perform more stringent checks is not a relevant scenario. I don't understond why a forwarder must have "a superset of your own trust anchors", but I don't think that understanding is key to the point in the first paragraph I quoted above. -- Sam From Ray.Bellis@nominet.org.uk Fri Aug 5 06:55:09 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1EF21F8B2C for ; Fri, 5 Aug 2011 06:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.341 X-Spam-Level: X-Spam-Status: No, score=-9.341 tagged_above=-999 required=5 tests=[AWL=1.258, 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 5ZISK5IJeozZ for ; Fri, 5 Aug 2011 06:55:08 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1DF21F8661 for ; Fri, 5 Aug 2011 06:55:08 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=ugiEHYYHdAJhTJAc2g4HdFkYUnExpzIySwsPCQl36FKz9YHtqGmv/MZc Yej2SmGRCw8hAST5uanTLLpQNgnjwknO/izYYCevizyWiXuyWIXcsXYOn +bo7PVwyyoBD1+g; 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=1312552526; x=1344088526; 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:=20dnssec-bis-updates=20-=20EDNS=20buffer=20size =20in=20responses|Date:=20Fri,=205=20Aug=202011=2013:55:2 4=20+0000|Message-ID:=20<98B08575-2259-40DD-864A-BA57F498 BEEE@nominet.org.uk>|To:=20"dnsext@ietf.org"=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20 quoted-printable|Content-ID:=20<3f5201f8-ecb2-422c-8b90-8 f0c76f6e694>; bh=A7oRqJXq8NtFp6/TrSP0nLJiLWE/H7Lv5kVWihHgCmc=; b=LpMIdnXhzMX0d3O+KVsAryDsIEJLN7TOa9qW2+MZ8qAkJD2LHubHGV4g 8WEElX7YaVOZDlRH/7wdLJR4p8k9tOvlp9tFX5fvDMpvCPY5WJ+mRnUr6 0lwHTjDWdSliJwA; X-IronPort-AV: E=Sophos;i="4.67,323,1309734000"; d="scan'208";a="27701668" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 05 Aug 2011 14:55:25 +0100 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%19]) with mapi; Fri, 5 Aug 2011 14:55:24 +0100 From: Ray Bellis To: "dnsext@ietf.org" Thread-Topic: dnssec-bis-updates - EDNS buffer size in responses Thread-Index: AQHMU3dS85wNtbv6HkGaMF+icZtZGg== Date: Fri, 5 Aug 2011 13:55:24 +0000 Message-ID: <98B08575-2259-40DD-864A-BA57F498BEEE@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3f5201f8-ecb2-422c-8b90-8f0c76f6e694> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dnsext] dnssec-bis-updates - EDNS buffer size in responses X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 13:55:09 -0000 I'm bouncing this here at Peter Koch's request, following discussion on the= DNSSEC Deployment List that was prompted by the observation that the respo= nses from Google's recursive service contain an EDNS buffer size indication= of 512 bytes. Currently, RFC 4035, =A73 says: " A security-aware name server MUST support the EDNS0 ([RFC2671]) message size extension, MUST support a message size of at least 1220 octets, and SHOULD support a message size of 4000 octets." However the response buffer size indicates the receive buffer size of the _= server_, i.e. how big a _query_ it can receive. There's no need for the EDNS buffer size supplied in the _response_ to adhe= re to this recommended minimum. So far as I can see DNSSEC makes no difference to the size of requests, exc= ept for the overhead of the OPT RR itself, and that's moot since without th= at RR there's no buffer size indication anyway. Ray From Ed.Lewis@neustar.biz Fri Aug 5 07:25:12 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3274921F8B3C for ; Fri, 5 Aug 2011 07:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.076 X-Spam-Level: X-Spam-Status: No, score=-106.076 tagged_above=-999 required=5 tests=[AWL=-0.873, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 vt6nYm+7xGMx for ; Fri, 5 Aug 2011 07:25:11 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACFD21F8B2A for ; Fri, 5 Aug 2011 07:25:11 -0700 (PDT) Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p75EPPuh095692; Fri, 5 Aug 2011 10:25:26 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.203.185] by Work-Laptop-2.local (PGP Universal service); Fri, 05 Aug 2011 10:25:26 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 05 Aug 2011 10:25:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <98B08575-2259-40DD-864A-BA57F498BEEE@nominet.org.uk> References: <98B08575-2259-40DD-864A-BA57F498BEEE@nominet.org.uk> Date: Fri, 5 Aug 2011 10:25:22 -0400 To: "dnsext@ietf.org" From: Edward Lewis Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.71 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: Re: [dnsext] dnssec-bis-updates - EDNS buffer size in responses X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 14:25:12 -0000 1) OPT RR is not unique to DNSSEC. (I'm just stating the obvious.) 2) *MUST support* a message size of X doesn't=20 mean it has to say that (X) in the EDNS0 buffer=20 size. The word "support" is way too fuzzy to be=20 included in a requirement. I'm not sure that=20 specifying a value less than 1220 is a violation=20 if the server could do 1220 "if it wanted to". 3) Does the 512 value in the Google server=20 response cause a demonstrable operational=20 problem? (I.e., or is the issue just that this=20 situation seems to be a violation of the written=20 specification?) At 13:55 +0000 8/5/11, Ray Bellis wrote: >I'm bouncing this here at Peter Koch's request,=20 >following discussion on the DNSSEC Deployment=20 >List that was prompted by the observation that=20 >the responses from Google's recursive service=20 >contain an EDNS buffer size indication of 512=20 >bytes. > >Currently, RFC 4035, =A73 says: > >" A security-aware name server MUST support the EDNS0 ([RFC2671]) > message size extension, MUST support a message size of at least 1220 > octets, and SHOULD support a message size of 4000 octets." > >However the response buffer size indicates the=20 >receive buffer size of the _server_, i.e. how=20 >big a _query_ it can receive. > >There's no need for the EDNS buffer size=20 >supplied in the _response_ to adhere to this=20 >recommended minimum. > >So far as I can see DNSSEC makes no difference=20 >to the size of requests, except for the overhead=20 >of the OPT RR itself, and that's moot since=20 >without that RR there's no buffer size=20 >indication anyway. > >Ray > >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext -- -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From marka@isc.org Fri Aug 5 07:42:23 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C899721F8C44 for ; Fri, 5 Aug 2011 07:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 iHJ02SN+CxGT for ; Fri, 5 Aug 2011 07:42:23 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 1D42121F8C33 for ; Fri, 5 Aug 2011 07:42:23 -0700 (PDT) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 74D2C5F98EC; Fri, 5 Aug 2011 14:42:26 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (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 DC845216C80; Fri, 5 Aug 2011 14:42:22 +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 A2FBB1283B6E; Sat, 6 Aug 2011 00:42:20 +1000 (EST) To: Ray Bellis From: Mark Andrews References: <98B08575-2259-40DD-864A-BA57F498BEEE@nominet.org.uk> In-reply-to: Your message of "Fri, 05 Aug 2011 13:55:24 GMT." <98B08575-2259-40DD-864A-BA57F498BEEE@nominet.org.uk> Date: Sat, 06 Aug 2011 00:42:20 +1000 Message-Id: <20110805144220.A2FBB1283B6E@drugs.dv.isc.org> Cc: "dnsext@ietf.org" Subject: Re: [dnsext] dnssec-bis-updates - EDNS buffer size in responses X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 14:42:23 -0000 In message <98B08575-2259-40DD-864A-BA57F498BEEE@nominet.org.uk>, Ray Bellis wr ites: > I'm bouncing this here at Peter Koch's request, following discussion on the > DNSSEC Deployment List that was prompted by the observation that the respo > nses from Google's recursive service contain an EDNS buffer size indication > of 512 bytes. > > Currently, RFC 4035, =A73 says: > > " A security-aware name server MUST support the EDNS0 ([RFC2671]) > message size extension, MUST support a message size of at least 1220 > octets, and SHOULD support a message size of 4000 octets." > > However the response buffer size indicates the receive buffer size of the _ > server_, i.e. how big a _query_ it can receive. > > There's no need for the EDNS buffer size supplied in the _response_ to adhe > re to this recommended minimum. > > So far as I can see DNSSEC makes no difference to the size of requests, exc > ept for the overhead of the OPT RR itself, and that's moot since without th > at RR there's no buffer size indication anyway. > > Ray Just because you see a value less than 1220, it doesn't mean that you are not 100% compliant with this code. In the thread this came from there was evidence that the nameservers in question *do* support EDNS at the required size. "support" does not mean "will always emit". These is no MUST NOT emit EDNS queries/responses with a EDNS UDP size less that 1220. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ray.Bellis@nominet.org.uk Fri Aug 5 09:34:00 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4258721F8B86 for ; Fri, 5 Aug 2011 09:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.425 X-Spam-Level: X-Spam-Status: No, score=-7.425 tagged_above=-999 required=5 tests=[AWL=-0.826, 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 pF7BNfVmgONp for ; Fri, 5 Aug 2011 09:33:59 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id 51E5721F8B7E for ; Fri, 5 Aug 2011 09:33:59 -0700 (PDT) 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-Transfer-Encoding:MIME-Version; b=eLEWL8LZfrG0ZJAsyhr7giDQJZ48uedpY5HZ4STktOYoEZECLVGVYyJi 1J+whufT+nfNMtLapJRLZzhZHqzx3gd8VzMOgmLFNHmYZz9tDU7jUand2 DOfvbeioEczLVVN; 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=1312562057; x=1344098057; 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[dnsext]=20dnssec-bis-updates=20-=20EDN S=20buffer=20size=20in=20responses|Date:=20Fri,=205=20Aug =202011=2016:34:15=20+0000|Message-ID:=20<8B7F972437853B4 0865000D86857B1D118D3C61A@wds-exc1.okna.nominet.org.uk> |To:=20Edward=20Lewis=20|CC:=20"dns ext@ietf.org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |In-Reply-To:=20 |References:=20<98B08575-2259-40DD-864A-BA57F498BEEE@nomi net.org.uk>,; bh=Bil8kO6WmJiQZytFr/83MDsyldyd76y8Uz/UWch+stA=; b=xcB0GNdhlw1nhIKlrfsD3B5int7l0N48zRQIx3ljCLrqIBakZHOrSRni sl5h8tcalP7nayZd6nkSS2GpDaqcHpRaVvEI/zGL07ST30JTbGd1PcLqQ XtmOcR0JP+eXob1; X-IronPort-AV: E=Sophos;i="4.67,324,1309734000"; d="scan'208";a="34565270" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 05 Aug 2011 17:34:16 +0100 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%19]) with mapi; Fri, 5 Aug 2011 17:34:16 +0100 From: Ray Bellis To: Edward Lewis Thread-Topic: [dnsext] dnssec-bis-updates - EDNS buffer size in responses Thread-Index: AQHMU3ucGpBbPbOUJUu1X/dRyHTPpZUOcRoq Date: Fri, 5 Aug 2011 16:34:15 +0000 Message-ID: <8B7F972437853B40865000D86857B1D118D3C61A@wds-exc1.okna.nominet.org.uk> References: <98B08575-2259-40DD-864A-BA57F498BEEE@nominet.org.uk>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] dnssec-bis-updates - EDNS buffer size in responses X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 16:34:00 -0000 > The word "support" is way too fuzzy to be=0A= > included in a requirement. =0A= =0A= [see below]=0A= =0A= > I'm not sure that=0A= > specifying a value less than 1220 is a violation=0A= > if the server could do 1220 "if it wanted to".=0A= =0A= I don't think I want to go there.=0A= =0A= > 3) Does the 512 value in the Google server=0A= > response cause a demonstrable operational=0A= > problem? (I.e., or is the issue just that this=0A= > situation seems to be a violation of the written=0A= > specification?)=0A= =0A= The latter. It was suggested (not by me) that _responding_ with a value of= 512 was "dodgy" because it violates the 1220 value from RFC 4035.=0A= =0A= My argument is that this value is mostly irrelevant in responses, in so muc= h as it relates to the server's _inbound_ buffer size for UDP requests.=0A= =0A= PK suggested that the wording might be clarified in dnssec-bis-updates.=0A= =0A= I'd suggest that "support" is actually fine in context - it's just that it'= s being interpreted too widely to apply both to responses and requests. 26= 71-bis is relatively clear on the difference.=0A= =0A= Ray=0A= =0A= From peter@denic.de Mon Aug 8 04:37:18 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3D821F85CA for ; Mon, 8 Aug 2011 04:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V2jD89qnzj0 for ; Mon, 8 Aug 2011 04:37:17 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id C39EB21F8520 for ; Mon, 8 Aug 2011 04:37:10 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QqO9E-0008JB-0V; Mon, 08 Aug 2011 13:37:32 +0200 Received: from localhost by x27.adm.denic.de with local id 1QqO9D-0003NN-Sy; Mon, 08 Aug 2011 13:37:31 +0200 Date: Mon, 8 Aug 2011 13:37:31 +0200 From: Peter Koch To: IETF DNSEXT WG Message-ID: <20110808113731.GI30809@x27.adm.denic.de> References: <98B08575-2259-40DD-864A-BA57F498BEEE@nominet.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch X-Mailman-Approved-At: Mon, 08 Aug 2011 05:34:13 -0700 Subject: Re: [dnsext] dnssec-bis-updates - EDNS buffer size in responses X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 11:37:18 -0000 On Fri, Aug 05, 2011 at 10:25:22AM -0400, Edward Lewis wrote: > 2) *MUST support* a message size of X doesn't > mean it has to say that (X) in the EDNS0 buffer > size. > > The word "support" is way too fuzzy to be > included in a requirement. I'm not sure that > specifying a value less than 1220 is a violation > if the server could do 1220 "if it wanted to". this comes close to the point that lead to the suggestion to continue the discussion in this venue. "support" isn't clear enough about the direction and there's little benefit yet if an authoritative server or a recursive server on the client facing side would be able to handle larger packets than 512 payload. The DNSSEC specification demands that a DO be sent back in the response, thus an EDNS OPT RR has to be present and therefore a payload size value must be chosen anyway. There's little point in understatement here, either. So, the potential clarification would emphasize that "support" means 'generating or handling responses' in section 3 of RFC 4035. > 3) Does the 512 value in the Google server > response cause a demonstrable operational > problem? (I.e., or is the issue just that this > situation seems to be a violation of the written > specification?) Probably not in this case, but DNS Dynamic Update messages might change the picture. -Peter From evnikita2@gmail.com Sat Aug 13 01:53:05 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0996221F85F2 for ; Sat, 13 Aug 2011 01:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.37 X-Spam-Level: X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhtcdex3Tvvl for ; Sat, 13 Aug 2011 01:53:04 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A8A4321F85EE for ; Sat, 13 Aug 2011 01:53:03 -0700 (PDT) Received: by fxe6 with SMTP id 6so3047473fxe.31 for ; Sat, 13 Aug 2011 01:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=pOdM07CSxnpptKUkUKYu67Pnf9INUgKHUYU1+QnAlOA=; b=L98B/Tj8HiIiNEPomY33jgW8SWidDHX9JtYkM5jKNwYwU6YM3K9ytWGBnf8SNcUFmO +B/EjCs+YsBgAezorF1IupmHB7Q8WqiC+fa1s2NpbNKEdyzgxe+TlKLQWvuSVaGuCK1I 5bUIIk+DeCIcaRhmuFAHGtbj3C6OqTy+GJ+EY= Received: by 10.223.56.80 with SMTP id x16mr2528003fag.36.1313225622513; Sat, 13 Aug 2011 01:53:42 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id c5sm2148281fah.30.2011.08.13.01.53.40 (version=SSLv3 cipher=OTHER); Sat, 13 Aug 2011 01:53:41 -0700 (PDT) Message-ID: <4E463BBA.3090001@gmail.com> Date: Sat, 13 Aug 2011 11:54:18 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: dnsext@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [dnsext] RFC 6195, IANA and HINFO DNS RRs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 08:53:05 -0000 Hello all, Looking through IANA MOA (http://www.iana.org/protocols/), I've noticed two interesting registries: "Machine Names" and "OS Names". For the first, no reference was defined, neither was the assignment policy. The second listed RFC 952 as reference and FCFS (see RFC 5226) as assignment policy spelled out there, even though RFC 952 says nothing about assigning OS names and pointed to RFC 943, "Assigned Numbers". These two registries were grandfathered from this series of RFCs called "Assigned Numbers"; however, I've recalled that there is HINFO DNS RR which seemed to use similar parameters. Having looked through RFC 6195, "DNS IANA Considerations", I found absolutely nothing which would clarify the situation with these two parameters. Section 3.3.2 of RFC 1035, though, says: > 3.3.2. HINFO RDATA format > > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > / CPU / > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > / OS / > +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ > > where: > > CPU A which specifies the CPU type. > > OS A which specifies the operating > system type. > > Standard values for CPU and OS can be found in [RFC-1010]. > > HINFO records are used to acquire general information about a host. The > main use is for protocols such as FTP that can use special procedures > when talking between machines or operating systems of the same type. RFC 1010 actually contained the list of then-assigned parameters, pointing to RFC 810 (which had been updated by RFC 952 and also used these two parameters). These two registries are still being quite obscure, you may see; so what I propose is to formalize the procedures for assigning the 2 identifiers in context of DNS HINFO resource records, writing the document updating RFC 6195 and 952. So any thoughts on this? Mykyta Yevstifeyev From jim@rfc1035.com Sat Aug 13 03:27:03 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9918821F84F3 for ; Sat, 13 Aug 2011 03:27:03 -0700 (PDT) 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_61=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW8tDbTD7rIE for ; Sat, 13 Aug 2011 03:27:03 -0700 (PDT) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by ietfa.amsl.com (Postfix) with ESMTP id CE48921F84EB for ; Sat, 13 Aug 2011 03:27:02 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 2739415420A1; Sat, 13 Aug 2011 11:27:28 +0100 (BST) Message-Id: <933B6B65-A2BF-4592-9D1F-D310862C3660@rfc1035.com> From: Jim Reid To: Mykyta Yevstifeyev In-Reply-To: <4E463BBA.3090001@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 13 Aug 2011 11:27:27 +0100 References: <4E463BBA.3090001@gmail.com> X-Mailer: Apple Mail (2.936) Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC 6195, IANA and HINFO DNS RRs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 10:27:03 -0000 On 13 Aug 2011, at 09:54, Mykyta Yevstifeyev wrote: > These two registries are still being quite obscure, you may see; so > what I propose is to formalize the procedures for assigning the 2 > identifiers in context of DNS HINFO resource records, writing the > document updating RFC 6195 and 952. So any thoughts on this? Don't bother. HINFO is essentially dead. Pretty much nothing uses it. I doubt any software queries for HINFO records. Few zones, if any, publish them. A couple of s form the RDATA for HINFO. These strings don't need or deserve a registry. It simply doesn't matter what goes into these strings provided they comply with the wire protocol. I am struggling to see why such a registry could be needed or why some application would want to care enough to check the result of an HINFO lookup against a list of formally registered strings. RFC1700 was the last reference to a list of names for HINFO records. [Interestingly, it imposes limitations on character set and length of the names that do not apply to DNS s.] That 17 year old list contains a remarkable list of long-dead platforms: Gould, Pyramid, DEC, Tops-10, SunOS, Multics, etc. I suppose that graveyard might have some historical curiosity. Bringing it up to date and maintaining it seems pointless though. What's the use case that's provoked your interest in DNS archeology? From peter@denic.de Sat Aug 13 03:40:46 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F8721F8781 for ; Sat, 13 Aug 2011 03:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcNDw0M+M9aE for ; Sat, 13 Aug 2011 03:40:46 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6F121F8764 for ; Sat, 13 Aug 2011 03:40:46 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QsBec-0006mI-E8; Sat, 13 Aug 2011 12:41:22 +0200 Received: from localhost by x27.adm.denic.de with local id 1QsBec-0001GO-6R; Sat, 13 Aug 2011 12:41:22 +0200 Date: Sat, 13 Aug 2011 12:41:22 +0200 From: Peter Koch To: dnsext@ietf.org Message-ID: <20110813104122.GI11178@x27.adm.denic.de> References: <4E463BBA.3090001@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E463BBA.3090001@gmail.com> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dnsext] RFC 6195, IANA and HINFO DNS RRs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 10:40:46 -0000 Mykyta, > These two registries are still being quite obscure, you may see; so what > I propose is to formalize the procedures for assigning the 2 identifiers > in context of DNS HINFO resource records, writing the document updating > RFC 6195 and 952. So any thoughts on this? there is no value, operational or otherwise, in "repairing" HINFO. The use that was once envisioned for, say, FTP, didn't take up and there is no documented or known use case. Even where used, people have entered free form text in both of the HINFO fields for various reasons and purposes. Just for the record, while essentially free of usable semantics, I do not think HINFO should be declared "Historic". In any case, the registries you mentioned would not be "owned" by dnsext. -Peter From evnikita2@gmail.com Sat Aug 13 03:46:04 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87E121F8876 for ; Sat, 13 Aug 2011 03:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.072 X-Spam-Level: X-Spam-Status: No, score=-3.072 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20tx+MyNm9Nc for ; Sat, 13 Aug 2011 03:46:04 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id D92D021F880C for ; Sat, 13 Aug 2011 03:45:45 -0700 (PDT) Received: by fxe6 with SMTP id 6so3078712fxe.31 for ; Sat, 13 Aug 2011 03:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=V1YRSbnQCgbvnwfJ9dp1IA1d8FEJHRUft26qdyxUojI=; b=fFss7GOTiqIEcSivpGWM/HcD5kozua87hrgILjgGjh41HPYIK9kMGe8hppcqfhkjQF 8VmnnORi29aiOXE10+macO/zNawZmdDlJMfU6Ngu5vER/nZN+OSNC3jHPp1Ut2mICMZw ZhutKv4/fToxcVmf02hfETLnv3fDsoL/HBDOg= Received: by 10.223.60.65 with SMTP id o1mr2633456fah.58.1313232384969; Sat, 13 Aug 2011 03:46:24 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id e8sm1111922fah.34.2011.08.13.03.46.21 (version=SSLv3 cipher=OTHER); Sat, 13 Aug 2011 03:46:21 -0700 (PDT) Message-ID: <4E465623.2010205@gmail.com> Date: Sat, 13 Aug 2011 13:46:59 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Jim Reid References: <4E463BBA.3090001@gmail.com> <933B6B65-A2BF-4592-9D1F-D310862C3660@rfc1035.com> In-Reply-To: <933B6B65-A2BF-4592-9D1F-D310862C3660@rfc1035.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC 6195, IANA and HINFO DNS RRs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 10:46:04 -0000 13.08.2011 13:27, Jim Reid wrote: > On 13 Aug 2011, at 09:54, Mykyta Yevstifeyev wrote: > >> These two registries are still being quite obscure, you may see; so >> what I propose is to formalize the procedures for assigning the 2 >> identifiers in context of DNS HINFO resource records, writing the >> document updating RFC 6195 and 952. So any thoughts on this? > > Don't bother. HINFO is essentially dead. Pretty much nothing uses it. > I doubt any software queries for HINFO records. Few zones, if any, > publish them. > > A couple of s form the RDATA for HINFO. These > strings don't need or deserve a registry. It simply doesn't matter > what goes into these strings provided they comply with the wire > protocol. I am struggling to see why such a registry could be needed > or why some application would want to care enough to check the result > of an HINFO lookup against a list of formally registered strings. > > RFC1700 was the last reference to a list of names for HINFO records. > [Interestingly, it imposes limitations on character set and length of > the names that do not apply to DNS s.] That 17 year > old list contains a remarkable list of long-dead platforms: Gould, > Pyramid, DEC, Tops-10, SunOS, Multics, etc. I suppose that graveyard > might have some historical curiosity. Bringing it up to date and > maintaining it seems pointless though. Well, this is quite reasonable for Machine Names (even though RFC 1700 was published in 1994 but the registry was last updated in 2001). OS Names registry is quite alive (well, if one may say like this); I see Windows NT 6.1 (aka Windows 7) there, and the last-updated date is 2010. Some entries, of course, are actually really outdated and dead, as eg. RiscOS or what you've mentioned. As I've already mentioned, with respect to the Machine/CPU names, I just have nothing to object, really :-) I guess the limitations of RFC 1700 were drown from RFCs 810/952, but I'm not sure. > > What's the use case that's provoked your interest in DNS archeology? Frankly speaking, my motivations was "this exists". Maybe liquidating the Machine Names registry may be an option (I still think OS Names is a useful thing)? Mykyta > From evnikita2@gmail.com Sat Aug 13 03:52:31 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88FE21F8922 for ; Sat, 13 Aug 2011 03:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.371 X-Spam-Level: X-Spam-Status: No, score=-3.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAqvtf+Gc2Pf for ; Sat, 13 Aug 2011 03:52:31 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2BD21F88D9 for ; Sat, 13 Aug 2011 03:52:31 -0700 (PDT) Received: by fxe6 with SMTP id 6so3080557fxe.31 for ; Sat, 13 Aug 2011 03:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kbEhuWFxuG21W+bUGBBDTTL9/Adz73n3413P69mlMvE=; b=ERuxdracXYN1yWUiUMffWuQ1cF1RTakhOcTjyLTTWm8Xf5MNSFSwHhN1Ta2zl4vf8V njjyhCybR2t9sZNr1/mj3rwPODmed3u+5q6K/wyfeTeuXWfE6Rhl9nwIpXAtrQwowPXo l4ZyxhkRtoroTH6KYtMEpLaXiXOf0uARN0ImQ= Received: by 10.223.55.205 with SMTP id v13mr2632011fag.88.1313232790270; Sat, 13 Aug 2011 03:53:10 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id d1sm3182966fai.28.2011.08.13.03.53.08 (version=SSLv3 cipher=OTHER); Sat, 13 Aug 2011 03:53:09 -0700 (PDT) Message-ID: <4E4657BB.5060902@gmail.com> Date: Sat, 13 Aug 2011 13:53:47 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Patrik Faltstrom (pfaltstr)" References: <4E463BBA.3090001@gmail.com> <933B6B65-A2BF-4592-9D1F-D310862C3660@rfc1035.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] RFC 6195, IANA and HINFO DNS RRs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 10:52:32 -0000 13.08.2011 13:48, Patrik Faltstrom (pfaltstr) wrote: > On 13 aug 2011, at 12:27, "Jim Reid" wrote: > >> Don't bother. HINFO is essentially dead. Pretty much nothing uses it. I doubt any software queries for HINFO records. Few zones, if any, publish them. > Instead, if new such things really are needed, use more modern mechanisms like NAPTR or URI rr types Patrik, I guess you refer to URI RR, which is registered as follows: > URI 256 URI [Faltstrom] So you are indeed a right person to ask: where can I find the documentation for this RR? Mykyta > (together with definition of the service you are after). > > Patrik > > From pfaltstr@cisco.com Sat Aug 13 03:49:05 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D0521F8A7E for ; Sat, 13 Aug 2011 03:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.836 X-Spam-Level: X-Spam-Status: No, score=-6.836 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jAzJ5oBlUVN for ; Sat, 13 Aug 2011 03:49:05 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D28BC21F8922 for ; Sat, 13 Aug 2011 03:49:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pfaltstr@cisco.com; l=405; q=dns/txt; s=iport; t=1313232585; x=1314442185; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=dhZclyvR5vdF+R1J/jsEm/32JdcMB0UcDTG9kteSmlo=; b=bRaldXOhpNMYdJo+zKZMoGhM82sj8D0RDzdoz0uc9FLehHRaP3SL3COB I3UQV/VPKyrTadPFRYus95FomGopwqN+WB84KSEzqZ4sBdC2PyeljaHVx L9g6iv5XgcAQ4YG2dvEZI+44tvAqBcOboUSRgWPXmlUGNmC/RRDrcVURL Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMIAHhWRk6Q/khL/2dsb2JhbABBiRCeAGYCd4FAAQEBAQIBEgEnPwULAgEIRlcBAQQTIodOmVkBnkCFaF8EkxKFFYti X-IronPort-AV: E=Sophos;i="4.67,366,1309737600"; d="scan'208";a="50325744" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 13 Aug 2011 10:49:23 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7DAnNAI016639; Sat, 13 Aug 2011 10:49:23 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 13 Aug 2011 12:49:22 +0200 Received: from 72.163.62.137 ([72.163.62.137]) by XMB-AMS-106.cisco.com ([144.254.74.81]) with Microsoft Exchange Server HTTP-DAV ; Sat, 13 Aug 2011 10:49:21 +0000 References: <4E463BBA.3090001@gmail.com> <933B6B65-A2BF-4592-9D1F-D310862C3660@rfc1035.com> Content-Transfer-Encoding: quoted-printable From: "Patrik Faltstrom (pfaltstr)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: <933B6B65-A2BF-4592-9D1F-D310862C3660@rfc1035.com> Message-ID: thread-topic: [dnsext] RFC 6195, IANA and HINFO DNS RRs thread-index: AcxZpqgIEsp9SNwOQtmcpedBkDxxsA== Date: Sat, 13 Aug 2011 12:48:14 +0200 To: "Jim Reid" MIME-Version: 1.0 (iPhone Mail 8L1) X-OriginalArrivalTime: 13 Aug 2011 10:49:22.0951 (UTC) FILETIME=[A9774170:01CC59A6] X-Mailman-Approved-At: Sat, 13 Aug 2011 06:22:26 -0700 Cc: Mykyta Yevstifeyev , dnsext@ietf.org Subject: Re: [dnsext] RFC 6195, IANA and HINFO DNS RRs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 10:49:05 -0000 On 13 aug 2011, at 12:27, "Jim Reid" wrote: > Don't bother. HINFO is essentially dead. Pretty much nothing uses it. I do= ubt any software queries for HINFO records. Few zones, if any, publish them.= Instead, if new such things really are needed, use more modern mechanisms li= ke NAPTR or URI rr types (together with definition of the service you are af= ter). Patrik From cet1@hermes.cam.ac.uk Mon Aug 15 05:58:45 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A81121F8B6D for ; Mon, 15 Aug 2011 05:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXfdnyoPGTeX for ; Mon, 15 Aug 2011 05:58:44 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 688E221F8B87 for ; Mon, 15 Aug 2011 05:58:44 -0700 (PDT) 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-2.csi.cam.ac.uk ([131.111.8.54]:40529) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:cet1) id 1QswlN-0001IU-EH (Exim 4.72) (return-path ); Mon, 15 Aug 2011 13:59:29 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1QswlN-0005jK-D5 (Exim 4.67) (return-path ); Mon, 15 Aug 2011 13:59:29 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.4); 15 Aug 2011 13:59:29 +0100 Date: 15 Aug 2011 13:59:29 +0100 From: Chris Thompson To: dnsext@ietf.org Message-ID: In-Reply-To: <933B6B65-A2BF-4592-9D1F-D310862C3660@rfc1035.com> References: <4E463BBA.3090001@gmail.com> <933B6B65-A2BF-4592-9D1F-D310862C3660@rfc1035.com> X-Mailer: Prayer v1.3.4 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Cc: Mykyta Yevstifeyev Subject: Re: [dnsext] RFC 6195, IANA and HINFO DNS RRs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 12:58:45 -0000 On Aug 13 2011, Jim Reid wrote: >On 13 Aug 2011, at 09:54, Mykyta Yevstifeyev wrote: > >> These two registries are still being quite obscure, you may see; so >> what I propose is to formalize the procedures for assigning the 2 >> identifiers in context of DNS HINFO resource records, writing the >> document updating RFC 6195 and 952. So any thoughts on this? > >Don't bother. HINFO is essentially dead. Pretty much nothing uses it. >I doubt any software queries for HINFO records. Few zones, if any, >publish them. Some zone administrators do still publish them. Locally I found e.g. $ dig +short hinfo {axon,moose,navier,roof,zzz}.damtp.cam.ac.uk "Sun4u" "Solaris2" "PC" "WinXP" "PC" "Win7" "Mac" "MacOS" "PC" "Linux/x86" (just a sample). But I suspect more people have found useful ways of maltreating the poor old thing. E.g. in our own zones we have an apex HINFO record as a version indicator, used as a prereq in dynamic updates: $ dig +short hinfo cam.ac.uk "V1" "2011-08-15 11:59:01 UTC" I chose HINFO because (a) it wasn't TXT (b) it displays nicely & (c) even 21st-century-ignorant nameserver software can cope with it. -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom. From evnikita2@gmail.com Mon Aug 15 09:04:49 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9C321F8C17 for ; Mon, 15 Aug 2011 09:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.404 X-Spam-Level: X-Spam-Status: No, score=-3.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o45RgHjYgty3 for ; Mon, 15 Aug 2011 09:04:48 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58E0D21F8BF8 for ; Mon, 15 Aug 2011 09:04:48 -0700 (PDT) Received: by fxe6 with SMTP id 6so4053779fxe.31 for ; Mon, 15 Aug 2011 09:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=ue50S/gOF/IyeEcyaSRowNj11lY/xZ0RVGbjUyvdiZQ=; b=hSjJ+ejqGOtA52Oyghuy+iVbIUikgw74IYR8G7wLjl5hpqi/1VNLAHT2oWRP/5zEYx rnR1fEpgZVL7WGONrRPqFasNdo5JY2fa4efoqLRXvmT/KRAXU5yA9ge1iMH+rGtBrL3N zC1lnqqH4Vk9h5ea7pjdgRbb9VTWTa00jCLmo= Received: by 10.223.75.25 with SMTP id w25mr5680795faj.140.1313424333646; Mon, 15 Aug 2011 09:05:33 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id i16sm5111714faa.45.2011.08.15.09.05.31 (version=SSLv3 cipher=OTHER); Mon, 15 Aug 2011 09:05:32 -0700 (PDT) Message-ID: <4E4943F1.8020301@gmail.com> Date: Mon, 15 Aug 2011 19:06:09 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: dnsext@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [dnsext] draft-cheshire-dnsext-special-names-01 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 16:04:49 -0000 Hello all, I understand that draft-cheshire-dnsext-special-names isn't a WG item, however it is associated with it, so I think this list is an appropriate place to ask the following question. This draft has been in IESG Evaluation state for already near 180 days; I did ask the editors of this document whether something is going to happen with respect to it, but received no answer. Maybe somebody on the list knows something on this question; in such case could you please tell me? Mykyta Yevstifeyev From snwells82@gmail.com Mon Aug 15 15:31:34 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EECB11E80D2 for ; Mon, 15 Aug 2011 15:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.661 X-Spam-Level: X-Spam-Status: No, score=-3.661 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91hSJQahFxV9 for ; Mon, 15 Aug 2011 15:31:34 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id E154E11E8086 for ; Mon, 15 Aug 2011 15:31:33 -0700 (PDT) Received: by pzk33 with SMTP id 33so6034877pzk.18 for ; Mon, 15 Aug 2011 15:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=m3WFIhdB+2US6tPHt5f0YV6zWj41fvhihfv9dytCDrU=; b=QcLGGuuFOhpdYoDeo+R+c4LK7QcyeM9ajfVxjlxoL4gX5v3yaSgEkKRU9MlUZ0Umnb 9BOY4YPRdPaslSsAoOnpUDx5sxfA/UU5idrghYNaTxAguxx9jK1NGIdDtHFDYqCr75A0 IcVPEj2tlmKtxfmZ38aYtz+sSssvi2LAmMHpI= MIME-Version: 1.0 Received: by 10.142.69.8 with SMTP id r8mr2109115wfa.353.1313447540174; Mon, 15 Aug 2011 15:32:20 -0700 (PDT) Received: by 10.68.62.231 with HTTP; Mon, 15 Aug 2011 15:32:20 -0700 (PDT) Date: Mon, 15 Aug 2011 15:32:20 -0700 Message-ID: From: Sean Wells To: "" Content-Type: multipart/alternative; boundary=001636e0ab4f102f2e04aa92d6a3 Subject: [dnsext] Missing DNSKEY record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 22:31:34 -0000 --001636e0ab4f102f2e04aa92d6a3 Content-Type: text/plain; charset=ISO-8859-1 Hi, As part of the DNSSEC validation, you lookup the DNSKEY record. If the DNSKEY record is missing in the response and you receive a NSEC, you can't do much because to validate NSEC, you need the key again. You can detect this and abort i.e if you don't have a DNSKEY, abort the validation process without processing the NSEC. Obviously, this could be part of an attack. But aborting is still better than asking for keys again and again. I don't see any text in RFC 4035 regarding this. Perhaps, dnssec-bis implementation can mention this case ? thanks Sean --001636e0ab4f102f2e04aa92d6a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

As part of the DNSSEC validation, you lookup the DNS= KEY record. If the DNSKEY record is missing in the response and you receive= a NSEC, you can't do much because to validate NSEC, you need the key a= gain. You can detect this and abort i.e if you don't have a DNSKEY, abo= rt the validation process without processing the NSEC. Obviously, this coul= d be part of an attack. But aborting is still better than asking for keys a= gain and again. I don't see any text in RFC 4035 regarding this. Perhap= s, dnssec-bis implementation can mention this case ?

thanks
Sean
--001636e0ab4f102f2e04aa92d6a3-- From ajs@anvilwalrusden.com Mon Aug 15 19:43:15 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CFD21F8C1B for ; Mon, 15 Aug 2011 19:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTkylgCqjVdj for ; Mon, 15 Aug 2011 19:43:15 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id E6CF121F8C09 for ; Mon, 15 Aug 2011 19:43:14 -0700 (PDT) Received: from shinkuro.com (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 mail.yitter.info (Postfix) with ESMTPSA id 836801ECB41C for ; Tue, 16 Aug 2011 02:44:02 +0000 (UTC) Date: Mon, 15 Aug 2011 22:43:59 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110816024359.GF12951@shinkuro.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Missing DNSKEY record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 02:43:15 -0000 On Mon, Aug 15, 2011 at 03:32:20PM -0700, Sean Wells wrote: > do much because to validate NSEC, you need the key again. You can detect > this and abort i.e if you don't have a DNSKEY, abort the validation process > without processing the NSEC. Obviously, this could be part of an attack. But > aborting is still better than asking for keys again and again. I don't see > any text in RFC 4035 regarding this. Perhaps, dnssec-bis implementation can > mention this case ? What would you have it say? "If you are unable to validate a response because you don't have adequate information, then . . ."? I think the right answer is surely, "Bogus, return SERVFAIL", no? A -- Andrew Sullivan ajs@anvilwalrusden.com From rdroms.ietf@gmail.com Mon Aug 15 21:44:06 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B24221F8B1C; Mon, 15 Aug 2011 21:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.559 X-Spam-Level: X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OkQByq-aQkO; Mon, 15 Aug 2011 21:44:05 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 5D28C21F8ADC; Mon, 15 Aug 2011 21:44:05 -0700 (PDT) Received: by qyk35 with SMTP id 35so3134517qyk.10 for ; Mon, 15 Aug 2011 21:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer; bh=1XeYdudLkL2J//T1L/qY/iUieTIchTucuw8OPNcibEw=; b=h6lwymYxcDHtqtGrSr0n6QihxprlpRjZB0HNJHE21LF+fA9NzSkFbHg/IlAkt3nJC3 es7c01dXwI/zkQ3uM7I4RcvmlePr4fQpXKImsKlG9emFgP2+U2juW+n7nha4JCiiWq7M 9uZ8ttcmebOr9JbNp/HDYyzBCV3YvyB+rQ0dA= Received: by 10.224.30.211 with SMTP id v19mr3121716qac.136.1313469892499; Mon, 15 Aug 2011 21:44:52 -0700 (PDT) Received: from bxb-rdroms-8714.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id k14sm4652986qct.45.2011.08.15.21.44.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Aug 2011 21:44:51 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Aug 2011 00:44:48 -0400 To: "dnsext@ietf.org" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 04:44:06 -0000 There has been a discussion on the 6man mailing list about moving A6 = records to Historic. I'd like to get input from dnsext about the = re-designation. ipv6@ietf.org is bcc:ed; please reply to dnsext. Thanks - Ralph From snwells82@gmail.com Mon Aug 15 21:56:14 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2D711E8086 for ; Mon, 15 Aug 2011 21:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.655 X-Spam-Level: X-Spam-Status: No, score=-3.655 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCvqASGcxdr5 for ; Mon, 15 Aug 2011 21:56:13 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 581EA11E8085 for ; Mon, 15 Aug 2011 21:56:13 -0700 (PDT) Received: by vws12 with SMTP id 12so5530893vws.31 for ; Mon, 15 Aug 2011 21:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I6IxlYw2wQ+/SCUdPoifm/ZwZanMIpt1Zjz3rot6ZL0=; b=QQNgN8cUZWufuyl7o+xxT3x8YG6aLLZc1WNF+Z/G+UFijZZ7gAeyrnYrvvjoY2VLIm Ul3NKUuNuh3LKzloIPmOYu2DkppbS/ZchDjvjI+3Kw9wzEN1d4VRL30qjo+OC7DSbHLv JK/iblPCN3Dw/EaxqJ+O6tS1niUmCKV+vprGs= MIME-Version: 1.0 Received: by 10.220.184.77 with SMTP id cj13mr1182255vcb.263.1313470618865; Mon, 15 Aug 2011 21:56:58 -0700 (PDT) Received: by 10.220.199.8 with HTTP; Mon, 15 Aug 2011 21:56:58 -0700 (PDT) In-Reply-To: <20110816024359.GF12951@shinkuro.com> References: <20110816024359.GF12951@shinkuro.com> Date: Mon, 15 Aug 2011 21:56:58 -0700 Message-ID: From: Sean Wells To: Andrew Sullivan Content-Type: multipart/alternative; boundary=90e6ba53a562a90fb404aa983531 Cc: dnsext@ietf.org Subject: Re: [dnsext] Missing DNSKEY record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 04:56:14 -0000 --90e6ba53a562a90fb404aa983531 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 15, 2011 at 7:43 PM, Andrew Sullivan wrote: > On Mon, Aug 15, 2011 at 03:32:20PM -0700, Sean Wells wrote: > > > do much because to validate NSEC, you need the key again. You can detect > > this and abort i.e if you don't have a DNSKEY, abort the validation > process > > without processing the NSEC. Obviously, this could be part of an attack. > But > > aborting is still better than asking for keys again and again. I don't > see > > any text in RFC 4035 regarding this. Perhaps, dnssec-bis implementation > can > > mention this case ? > > What would you have it say? "If you are unable to validate a response > because you don't have adequate information, then . . ."? > > In the validation process, it looks like handling a NSEC for DNSKEY is the only odd one out. NSEC response for DS is well understood. I don't know what implementations do when RRSIGs are missing. I would just mention the odd case instead of generalizing: "If you are unable to validate a response because you are not able to fetch DNSKEY records, the validation process should be aborted". I think the right answer is surely, "Bogus, return SERVFAIL", no? > > Sure. But do implementations return SERVFAIL today ? How do resolvers handle this case ? -Sean > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext --90e6ba53a562a90fb404aa983531 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 15, 2011 at 7:43 PM, Andrew = Sullivan <aj= s@anvilwalrusden.com> wrote:
On Mon, Aug 15, 2011 at 03:32:20PM -0700, Sean Wells wrot= e:

> do much because to validate NSEC, you need the key again. You can dete= ct
> this and abort i.e if you don't have a DNSKEY, abort the validatio= n process
> without processing the NSEC. Obviously, this could be part of an attac= k. But
> aborting is still better than asking for keys again and again. I don&#= 39;t see
> any text in RFC 4035 regarding this. Perhaps, dnssec-bis implementatio= n can
> mention this case ?

What would you have it say? =A0"If you are unable to validate a = response
because you don't have adequate information, then . . ."?

In the validation process, it looks like handling a N= SEC for DNSKEY is the only odd one out. NSEC response for DS is well unders= tood. I don't know what implementations do when RRSIGs are missing.

I would just mention the odd case instead of generalizi= ng: "If you are unable to validate a response because you are not able= to fetch DNSKEY records, the validation process should be aborted".

I think the right answer is surely, "Bogus, return SERVFAIL", no?=

Sure. But do implementations return SERVFAIL today ? = How do resolvers handle this case ?

=A0-Sean
=
A

--
Andrew Sullivan
ajs@anvilwalrusden.com
_______________________________________________
dnsext mailing list
dnsext@ietf.org
= https://www.ietf.org/mailman/listinfo/dnsext
--90e6ba53a562a90fb404aa983531-- From mgraff@isc.org Tue Aug 16 00:09:22 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A225621F88B6 for ; Tue, 16 Aug 2011 00:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvjNxmak5gF0 for ; Tue, 16 Aug 2011 00:09:22 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 0513921F86EE for ; Tue, 16 Aug 2011 00:09:21 -0700 (PDT) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 56E6F5F984C; Tue, 16 Aug 2011 07:09:43 +0000 (UTC) (envelope-from mgraff@isc.org) Received: from [184.48.56.119] (dhcp184-48-56-119.ssb.sjc.wayport.net [184.48.56.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id CF628216C80; Tue, 16 Aug 2011 07:09:41 +0000 (UTC) (envelope-from mgraff@isc.org) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <12636ACC-FCCB-4A0F-ADF2-3F3A05AF70E4@isc.org> X-Mailer: iPhone Mail (8L1) From: Michael Graff Date: Tue, 16 Aug 2011 00:09:35 -0700 To: Ralph Droms Cc: "dnsext@ietf.org" Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 07:09:22 -0000 Please move it to historic.=20 --Michael (from an iPhone) On Aug 15, 2011, at 21:44, Ralph Droms wrote: > There has been a discussion on the 6man mailing list about moving A6 recor= ds to Historic. I'd like to get input from dnsext about the re-designation.= >=20 > ipv6@ietf.org is bcc:ed; please reply to dnsext. >=20 > Thanks >=20 > - Ralph >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From bert.hubert@netherlabs.nl Tue Aug 16 00:37:49 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7646021F8802 for ; Tue, 16 Aug 2011 00:37:49 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam_report: ...that system for details.\n \n Content previ[...] X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4shkOiJ3erq for ; Tue, 16 Aug 2011 00:37:49 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [IPv6:2001:888:2000:1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id E8A8021F87E2 for ; Tue, 16 Aug 2011 00:37:47 -0700 (PDT) Received: from mail-fx0-f44.google.com ([209.85.161.44]) by xs.powerdns.com with esmtpsa (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1QtEEH-00031V-JD for dnsext@ietf.org; Tue, 16 Aug 2011 09:38:31 +0200 Received: by fxe6 with SMTP id 6so4468103fxe.31 for ; Tue, 16 Aug 2011 00:38:24 -0700 (PDT) Received: by 10.223.57.78 with SMTP id b14mr6776929fah.83.1313480304080; Tue, 16 Aug 2011 00:38:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.88.84 with HTTP; Tue, 16 Aug 2011 00:38:04 -0700 (PDT) In-Reply-To: References: From: bert hubert Date: Tue, 16 Aug 2011 09:38:04 +0200 Message-ID: To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam_report: Spam detection software, running on the system "xs.powerdns.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Tue, Aug 16, 2011 at 6:44 AM, Ralph Droms wrote: > There has been a discussion on the 6man mailing list about moving A6 records to Historic. I'd like to get input from dnsext about the re-designation. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: "dnsext@ietf.org" Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 07:37:49 -0000 On Tue, Aug 16, 2011 at 6:44 AM, Ralph Droms wrote: > There has been a discussion on the 6man mailing list about moving A6 reco= rds to Historic. =A0I'd like to get input from dnsext about the re-designat= ion. Please move to historic - there is still some lingering confusion out there if A6 is for real or not, and it would be good to put that discussion to bed. Bert From peter@denic.de Tue Aug 16 00:41:48 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF0E21F8B9F for ; Tue, 16 Aug 2011 00:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXuKtL4i3aPi for ; Tue, 16 Aug 2011 00:41:47 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 819CE21F8B9E for ; Tue, 16 Aug 2011 00:41:47 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QtEIE-0004zJ-C7; Tue, 16 Aug 2011 09:42:34 +0200 Received: from localhost by x27.adm.denic.de with local id 1QtEIE-0007Be-8n; Tue, 16 Aug 2011 09:42:34 +0200 Date: Tue, 16 Aug 2011 09:42:34 +0200 From: Peter Koch To: IETF DNSEXT WG Message-ID: <20110816074234.GV11178@x27.adm.denic.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 07:41:48 -0000 On Tue, Aug 16, 2011 at 12:44:48AM -0400, Ralph Droms wrote: > There has been a discussion on the 6man mailing list about moving A6 records to Historic. I'd like to get input from dnsext about the re-designation. i have reviewed the thread starting at . While i do not think A6 has any particular value, I wonder where the alleged confusion would originate from. RFCs 3363 and 3364 should send a clear message, even though the status of "Experimental" was a political compromise back then. Then again, these RFCs might not be read by the potentially confused, but there's reasonable doubt that that audience would interpret "Historic" as intended. However, A6 was defined in RFC 2874 together with "bitstring labels" and while their use might be arguable as well, they'd either have to share fate or be preserved in a separate document since the status applies to a whole RFC, not just parts. Operationally, I'd rather not see authoritative server implementations lose the ability to recognize A6 presentation format ('cause you never know). -Peter From jiangsheng@huawei.com Tue Aug 16 00:48:48 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BDD21F8B85 for ; Tue, 16 Aug 2011 00:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lsft9oaXMaA6 for ; Tue, 16 Aug 2011 00:48:48 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D5F2821F8B5D for ; Tue, 16 Aug 2011 00:48:47 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ000M7PGCMK8@szxga05-in.huawei.com> for dnsext@ietf.org; Tue, 16 Aug 2011 15:48:22 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ000LYDGBOFH@szxga05-in.huawei.com> for dnsext@ietf.org; Tue, 16 Aug 2011 15:48:22 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml208-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADE60457; Tue, 16 Aug 2011 15:48:21 +0800 (CST) Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 16 Aug 2011 15:48:17 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.66]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Tue, 16 Aug 2011 15:48:21 +0800 Date: Tue, 16 Aug 2011 07:48:19 +0000 From: Sheng Jiang In-reply-to: X-Originating-IP: [10.110.98.152] To: Ralph Droms , "dnsext@ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B920123583F@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [dnsext] A6 to Historic Thread-index: AQHMW89DzETflTc61EiAwAeNAQW9AZUfGG5g X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 07:48:48 -0000 +1 When we did 6renum current practise analysis, we found A6 record is helpful in renumbering cases. However, we then found it has many issues, which has been documented in RFC 3363 and RFC 3364. If A6 stays experimental status, it is really misleading. We should avoid this confusion by moving it to Historic. However, some current data shows A6 is actually in use. Based on this, moving A6 to historic is much more complex than an IESG decision. We may need more investigation on how these A6 records are current used. We also need to investigate what impact may have if A6 is abolish. Another important question is whether there are A6-only client. It looks a lot investigation and analysis work, which is definitely worth a draft, before we can make the decision to moving A6 into history or start a phase out plan. Sheng > -----Original Message----- > From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On > Behalf Of Ralph Droms > Sent: Tuesday, August 16, 2011 12:45 PM > To: dnsext@ietf.org > Subject: [dnsext] A6 to Historic > > There has been a discussion on the 6man mailing list about moving A6 > records to Historic. I'd like to get input from dnsext about the re- > designation. > > ipv6@ietf.org is bcc:ed; please reply to dnsext. > > Thanks > > - Ralph > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From roy@nominet.org.uk Tue Aug 16 01:06:21 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC6421F8BAE for ; Tue, 16 Aug 2011 01:06:21 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOZyXgmaAuNO for ; Tue, 16 Aug 2011 01:06:20 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id 065C921F8C07 for ; Tue, 16 Aug 2011 01:06:19 -0700 (PDT) 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=oQdp747LPLyf/3jtB0MKEN0aDQbOs5aYcswwmRISeODGydYQR34K1EIx ykTdbpMJomy/FM2eF+BU4BoeR5D/C/KaM/Mi8XdBTtwTIMEQB4C6akZ/Y BO5hjAtFDnmYCGU; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1313482028; x=1345018028; 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:=20Roy=20Arends=20|Subject:=20R e:=20[dnsext]=20A6=20to=20Historic|Date:=20Tue,=2016=20Au g=202011=2008:07:27=20+0000|Message-ID:=20|To:=20Ralph=20Drom s=20|CC:=20"dnsext@ietf.org"=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<398854a6-9f15-4258-894b-ffc9273ec776> |In-Reply-To:=20|References:=20; bh=46Czzro1/wIs6XDNYg868BiNojO/d27AbG7A33fVGm8=; b=yovVCGNNK3x1Q5QR7/34t16Dlsos4TXt8WvCZ+Y2Vl8HMa8xF4Obi+aS oZ5sjTuiu4/4ZHWWQ6sCxmNHPDssGJBONK8v/jzUkFsJ3LjCQB4TwJUGl kDQCHpxPkXVXRnJ; X-IronPort-AV: E=Sophos;i="4.67,379,1309734000"; d="scan'208";a="34755478" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 16 Aug 2011 09:07:06 +0100 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%19]) with mapi; Tue, 16 Aug 2011 09:07:06 +0100 From: Roy Arends To: Ralph Droms Thread-Topic: [dnsext] A6 to Historic Thread-Index: AQHMW89JFEZ8d46euUadWTBLBbshC5UfDrCA Date: Tue, 16 Aug 2011 08:07:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <398854a6-9f15-4258-894b-ffc9273ec776> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 08:06:21 -0000 Hi Ralph, I'm all for moving A6 from experimental to historic, though I'd l= ike to understand what the motivator behind it is (cleanup?). Additionally,= A6 (RFC2874) depends on Binary Labels (or bit string labels) (RFC2673). Sh= ould that be moved to historic as well, or should that be left as is? I am = not aware of any other uses for binary labels (outside of A6). At Nominet, we still see about 2.5m queries a day for type A6 queries, thou= gh a representative sample taken of the QNAMEs in the query shows a 0% depl= oyment of A6 records in the UK namespace. To explain: we see those queries = at our authoritative servers, and we subsequently send either a delegation = or an rcode3 (NXDOMAIN) back. The representative sample is taken from the d= elegated namespace. If this is moved to historic, I would like to see some text on how to deal = with A6 records in the future. If they are to be treated as 'unknown record= s' (RFC3597), it might lead to some interoperability issues, as resolvers t= hat supported A6 in the past were required to do additional section process= ing for these records on the wire. Additionally, we need to understand how = to deal with an A6 record in presentation format. With near zero deployment= and a very large installed base that won't be changed overnight, moving so= mething from experimental to historic for the purpose of 'cleaning up' or '= avoiding confusion' makes sense. It does come at a cost for those who have = implemented it and consider their implementation as a reference implementat= ion.=20 Kind regards, Roy Arends Nominet UK On Aug 16, 2011, at 5:44 AM, Ralph Droms wrote: > There has been a discussion on the 6man mailing list about moving A6 reco= rds to Historic. I'd like to get input from dnsext about the re-designatio= n. >=20 > ipv6@ietf.org is bcc:ed; please reply to dnsext. >=20 > Thanks >=20 > - Ralph >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From shane@isc.org Tue Aug 16 01:25:56 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3605221F8B78 for ; Tue, 16 Aug 2011 01:25:56 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXz16nVNnOhF for ; Tue, 16 Aug 2011 01:25:55 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 6270921F8A7A for ; Tue, 16 Aug 2011 01:25:55 -0700 (PDT) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 78B325F98B6; Tue, 16 Aug 2011 08:26:29 +0000 (UTC) (envelope-from shane@isc.org) Received: from [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00] (unknown [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 07E96216C7B; Tue, 16 Aug 2011 08:26:26 +0000 (UTC) (envelope-from shane@isc.org) From: Shane Kerr To: Peter Koch Date: Tue, 16 Aug 2011 10:26:23 +0200 In-Reply-To: <20110816074234.GV11178@x27.adm.denic.de> References: <20110816074234.GV11178@x27.adm.denic.de> Organization: ISC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.2 (3.0.2-3.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1313483187.2065.31.camel@shane-desktop> Mime-Version: 1.0 Cc: IETF DNSEXT WG Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 08:25:56 -0000 Peter, On Tue, 2011-08-16 at 09:42 +0200, Peter Koch wrote: > On Tue, Aug 16, 2011 at 12:44:48AM -0400, Ralph Droms wrote: > > There has been a discussion on the 6man mailing list about moving A6 records to Historic. I'd like to get input from dnsext about the re-designation. > > i have reviewed the thread starting at > . > > While i do not think A6 has any particular value, I wonder where > the alleged confusion would originate from. RFCs 3363 and 3364 > should send a clear message, even though the status of "Experimental" > was a political compromise back then. Then again, these RFCs > might not be read by the potentially confused, but there's > reasonable doubt that that audience would interpret "Historic" > as intended. I was recently at the IANA page that lists registered RR types: http://www.iana.org/assignments/dns-parameters It's not clear from this list what RR types are more important, which are less important, which may have special-case uses, and which are basically worthless. (I love the recent trend to list the "Value and meaning" as identical to the identifier!) Moving A6 to historic may have the benefit of being able to change the label from: A6 38 A6 (Experimental) [RFC3226][RFC2874] to: A6 38 A6 (Obsolete - use AAAA) [RFC3226][RFC2874][RFCxxxx] This isn't a huge help, but it is something! -- Shane From fweimer@bfk.de Tue Aug 16 01:29:24 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6906D21F8BD5 for ; Tue, 16 Aug 2011 01:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN0l2tKH-TGJ for ; Tue, 16 Aug 2011 01:29:23 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D73A21F8BC3 for ; Tue, 16 Aug 2011 01:29:18 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QtF2D-00013x-8J; Tue, 16 Aug 2011 08:30:05 +0000 Received: by bfk.de with local id 1QtF2D-0001A1-4q; Tue, 16 Aug 2011 08:30:05 +0000 From: Florian Weimer To: Peter Koch References: <20110816074234.GV11178@x27.adm.denic.de> Date: Tue, 16 Aug 2011 08:30:05 +0000 In-Reply-To: <20110816074234.GV11178@x27.adm.denic.de> (Peter Koch's message of "Tue, 16 Aug 2011 09:42:34 +0200") Message-ID: <82hb5hzrle.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF DNSEXT WG Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 08:29:24 -0000 * Peter Koch: > However, A6 was defined in RFC 2874 together with "bitstring labels" > and while their use might be arguable as well, they'd either have to > share fate or be preserved in a separate document since the > status applies to a whole RFC, not just parts. EDNS0bis will disallow extended label types, matching current implementation practice. Extended label types require a different mechanism for discovering zone delegation in resolvers, and it appears that this has never been implemented anywhere. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From roy@nominet.org.uk Tue Aug 16 01:44:07 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E96C21F8B31 for ; Tue, 16 Aug 2011 01:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8aFcyfCPx5t for ; Tue, 16 Aug 2011 01:44:06 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6315B21F8B25 for ; Tue, 16 Aug 2011 01:44:05 -0700 (PDT) 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=svftWpy5x7pQ0HPfSXcg4egP1U6f0iVB9ktPmt45vznu77bz2vD2iieV j8KnjdFcEtPNBPrBYxG5dXWqPghjgP3DxZmeoOIGn6xOhVnHRdh/vQrou ysi81DeB/failBX; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1313484294; x=1345020294; 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:=20Roy=20Arends=20|Subject:=20R e:=20[dnsext]=20A6=20to=20Historic|Date:=20Tue,=2016=20Au g=202011=2008:45:12=20+0000|Message-ID:=20|To:=20Florian=20We imer=20|CC:=20Peter=20Koch=20,=20IETF=20DNSEXT=20WG=20|MIME-Version: =201.0|Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20 |In-Reply-To:=20<82hb5hzrle.fsf@mid.bfk.de>|References: =20=0D=0A =20<20110816074234.GV11178@x27.adm.denic.de>=20<82hb5hzrl e.fsf@mid.bfk.de>; bh=yRJgqxtDpxLCzeideI5tmu3RPveaumt1iM252WNmQVM=; b=x1FRX4iJZXNHmd0m3V4E53bP34m6HKn36S4uQ4d5WGca+APxPcryhY2E 1VXA4Iv0Wa7wxHCE3bU6rkrtLr9xo2RAcPak3JfoInsNXQ9FMoWTQw0vz vzVxf37M75ALge+; X-IronPort-AV: E=Sophos;i="4.67,379,1309734000"; d="scan'208";a="34755803" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 16 Aug 2011 09:44:52 +0100 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%19]) with mapi; Tue, 16 Aug 2011 09:44:51 +0100 From: Roy Arends To: Florian Weimer Thread-Topic: [dnsext] A6 to Historic Thread-Index: AQHMW+6yFEZ8d46euUadWTBLBbshC5UfGP4A Date: Tue, 16 Aug 2011 08:45:12 +0000 Message-ID: References: <20110816074234.GV11178@x27.adm.denic.de> <82hb5hzrle.fsf@mid.bfk.de> In-Reply-To: <82hb5hzrle.fsf@mid.bfk.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Peter Koch , IETF DNSEXT WG Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 08:44:07 -0000 On Aug 16, 2011, at 9:30 AM, Florian Weimer wrote: > * Peter Koch: >=20 >> However, A6 was defined in RFC 2874 together with "bitstring labels" >> and while their use might be arguable as well, they'd either have to >> share fate or be preserved in a separate document since the >> status applies to a whole RFC, not just parts. >=20 > EDNS0bis will disallow extended label types, matching current > implementation practice. Extended label types require a different > mechanism for discovering zone delegation in resolvers, and it appears > that this has never been implemented anywhere. Hi Florian, I dispute that extended label types have never been implemented. Up until B= IND-9.3.1, bit string labels (using ELT 000001) were supported. However, th= e text in draft-ietf-dnsext-rfc2671bis-edns0 already moves bit string label= s to historic (explicitly), so that deals with at least that concern. By im= plication, it makes A6 useless, hence lets move that to historic as well. Kind regards, Roy Arends Nominet UK From peter@denic.de Tue Aug 16 01:49:27 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056BE21F8B28 for ; Tue, 16 Aug 2011 01:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZxDeJ+EL+27 for ; Tue, 16 Aug 2011 01:49:26 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 703C521F8ABC for ; Tue, 16 Aug 2011 01:49:26 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QtFLh-0005fx-Lm; Tue, 16 Aug 2011 10:50:13 +0200 Received: from localhost by x27.adm.denic.de with local id 1QtFLh-0008Jj-Hq; Tue, 16 Aug 2011 10:50:13 +0200 Date: Tue, 16 Aug 2011 10:50:13 +0200 From: Peter Koch To: IETF DNSEXT WG Message-ID: <20110816085013.GX11178@x27.adm.denic.de> References: <20110816074234.GV11178@x27.adm.denic.de> <1313483187.2065.31.camel@shane-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1313483187.2065.31.camel@shane-desktop> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: [dnsext] Communicating RR Type "requirement levels" [Re: A6 to Historic] X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 08:49:27 -0000 On Tue, Aug 16, 2011 at 10:26:23AM +0200, Shane Kerr wrote: > Moving A6 to historic may have the benefit of being able to change the > label from: > > A6 38 A6 (Experimental) [RFC3226][RFC2874] > > to: > > A6 38 A6 (Obsolete - use AAAA) [RFC3226][RFC2874][RFCxxxx] > > This isn't a huge help, but it is something! yes, it's a mistake. The current list is neither complete nor consistent. and while one might argue that the registry MAY contain comments, it is unclear how they would be entered or maintained. For the status of specification (Hist, Exp, Informational or any Standards Track maturity level) the housekeeping is traditionally done by the RFC Editor, not IANA. "Obsolete" has unclear meaning, at least doesn't exist in RFC 2026 (other than as a loose equivalent to Historic). What comes closest is section 3.3 of RFC 2026, but again not an IANA task. And finally, for those specifications not opriginating from within the IETF, there's no authoritative source for the status. The IANA registry is a registry of code points with pointers to specification. It should not be overloaded with additional information. There's clearly a need for such a 'wiki style' repository, but that definitely needs a different approach. In an ideal world, the IETF had a marketing/education wing that would deal with these navigation and accessibility issues (and several more). In the real world, ISOC would be a good starting point for these tasks. -Peter From fweimer@bfk.de Tue Aug 16 01:51:09 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA1321F8B75 for ; Tue, 16 Aug 2011 01:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uxgs3ke7gR7 for ; Tue, 16 Aug 2011 01:51:08 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 72D8321F8B74 for ; Tue, 16 Aug 2011 01:51:08 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1QtFNL-00049R-8S; Tue, 16 Aug 2011 08:51:55 +0000 Received: by bfk.de with local id 1QtFNL-0004wl-5b; Tue, 16 Aug 2011 08:51:55 +0000 From: Florian Weimer To: Roy Arends References: <20110816074234.GV11178@x27.adm.denic.de> <82hb5hzrle.fsf@mid.bfk.de> Date: Tue, 16 Aug 2011 08:51:55 +0000 In-Reply-To: (Roy Arends's message of "Tue, 16 Aug 2011 08:45:12 +0000") Message-ID: <828vqtzql0.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Peter Koch , IETF DNSEXT WG Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 08:51:09 -0000 * Roy Arends: > On Aug 16, 2011, at 9:30 AM, Florian Weimer wrote: > >> * Peter Koch: >>=20 >>> However, A6 was defined in RFC 2874 together with "bitstring labels" >>> and while their use might be arguable as well, they'd either have to >>> share fate or be preserved in a separate document since the >>> status applies to a whole RFC, not just parts. >>=20 >> EDNS0bis will disallow extended label types, matching current >> implementation practice. Extended label types require a different >> mechanism for discovering zone delegation in resolvers, and it appears >> that this has never been implemented anywhere. > > Hi Florian, > > I dispute that extended label types have never been implemented. Up > until BIND-9.3.1, bit string labels (using ELT 000001) were > supported. However, the text in draft-ietf-dnsext-rfc2671bis-edns0 > already moves bit string labels to historic (explicitly), so that > deals with at least that concern. By implication, it makes A6 useless, > hence lets move that to historic as well. The proper resolver behavior was never implemented. BIND's resolver assumed that the parent was upgraded to support extended label types before they were used in a child zone. To my knowledge, the root never fully implemented extended label types, so this protocol extension never took off. The issue is that a resolver sends the full QNAME to parent servers. If the name includes an extended label type and the parent lacks support, the parent will respond with an error. An alternative implementation would incrementally add labels until the delegation is discovered, so that the parent never sees non-material labels. This has other benefits, such as not sending partial call data records around the world if you use the public ENUM tree under e164.arpa, but I don't think it has been implemented. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From roy@nominet.org.uk Tue Aug 16 02:16:00 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BA621F8BDB for ; Tue, 16 Aug 2011 02:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.449 X-Spam-Level: X-Spam-Status: No, score=-8.449 tagged_above=-999 required=5 tests=[AWL=2.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ne82yKc0qM1 for ; Tue, 16 Aug 2011 02:16:00 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id D02D521F8BA9 for ; Tue, 16 Aug 2011 02:15:59 -0700 (PDT) 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=ThhPJpc87Ve9ftSSPZPvgnFGZ2YwGPzMCgLffGQJqgQ1041zOu6dOnuO jNfd7yz4Z0Qpvn1Lvjv9O33fJNvMSCCfe1AvfLyHUdgs70E+aA+zD3bwa Vjeg6G1WIXe54Cy; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1313486208; x=1345022208; 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:=20Roy=20Arends=20|Subject:=20R e:=20[dnsext]=20A6=20to=20Historic|Date:=20Tue,=2016=20Au g=202011=2009:17:07=20+0000|Message-ID:=20|To:=20Florian=20We imer=20|CC:=20Peter=20Koch=20,=20IETF=20DNSEXT=20WG=20|MIME-Version: =201.0|Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<9d478dfb-3996-454d-a60e-de564bcaaba2> |In-Reply-To:=20<828vqtzql0.fsf@mid.bfk.de>|References: =20=0D=0A =20<20110816074234.GV11178@x27.adm.denic.de>=20<82hb5hzrl e.fsf@mid.bfk.de>=0D=0A=20=0D=0A=20<828vqtzql0.fsf@mid.bfk.de >; bh=XtDpOGKxZl/4lydEiJ3VZCVwmhM1hoioLaqMh9r2EKM=; b=NIK5fH51nGyshNTtLKUE0wh83lwgofWL/U60O6HX9iABW1d+mF0yvT2e ZtKNO0vxKXrUe/uL7rp8cG6f0OIyDK3aTohxI/33BR8N5Ss7Z4oQnF1XM 4aGx/K5F5p/YKCT; X-IronPort-AV: E=Sophos;i="4.67,379,1309734000"; d="scan'208";a="27872248" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 16 Aug 2011 10:16:46 +0100 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%19]) with mapi; Tue, 16 Aug 2011 10:16:46 +0100 From: Roy Arends To: Florian Weimer Thread-Topic: [dnsext] A6 to Historic Thread-Index: AQHMW/G/FEZ8d46euUadWTBLBbshC5UfIeOA Date: Tue, 16 Aug 2011 09:17:07 +0000 Message-ID: References: <20110816074234.GV11178@x27.adm.denic.de> <82hb5hzrle.fsf@mid.bfk.de> <828vqtzql0.fsf@mid.bfk.de> In-Reply-To: <828vqtzql0.fsf@mid.bfk.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9d478dfb-3996-454d-a60e-de564bcaaba2> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Peter Koch , IETF DNSEXT WG Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 09:16:00 -0000 On Aug 16, 2011, at 9:51 AM, Florian Weimer wrote: > * Roy Arends: >=20 >> On Aug 16, 2011, at 9:30 AM, Florian Weimer wrote: >>> Extended label types require a different >>> mechanism for discovering zone delegation in resolvers, and it appears >>> that this has never been implemented anywhere. >>=20 >> Hi Florian, >>=20 >> I dispute that extended label types have never been implemented. >=20 > The proper resolver behavior was never implemented. =20 Hi Florian,=20 My apologies, I jumped to conclusion after having misread your response. Yo= u are right of course. Kind regards, Roy Arends Nominet UK= From marka@isc.org Tue Aug 16 04:42:11 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B9721F8781 for ; Tue, 16 Aug 2011 04:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.145 X-Spam-Level: X-Spam-Status: No, score=-1.145 tagged_above=-999 required=5 tests=[AWL=-1.446, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MANGLED_TEXT=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMwfMKqEpR7P for ; Tue, 16 Aug 2011 04:42:11 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 44DD521F875E for ; Tue, 16 Aug 2011 04:42:10 -0700 (PDT) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 6B877C9428; Tue, 16 Aug 2011 11:42:48 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (dhcp184-48-56-208.ssb.sjc.wayport.net [184.48.56.208]) (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 1FF3D216C80; Tue, 16 Aug 2011 11:42:48 +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 77F1312DBA8C; Tue, 16 Aug 2011 21:42:46 +1000 (EST) To: Roy Arends From: Mark Andrews References: <20110816074234.GV11178@x27.adm.denic.de> <82hb5hzrle.fsf@mid.bfk.de> In-reply-to: Your message of "Tue, 16 Aug 2011 08:45:12 GMT." Date: Tue, 16 Aug 2011 21:42:46 +1000 Message-Id: <20110816114246.77F1312DBA8C@drugs.dv.isc.org> Cc: Peter Koch , IETF DNSEXT WG Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 11:42:11 -0000 In message , Roy Arends wr ites: > On Aug 16, 2011, at 9:30 AM, Florian Weimer wrote: > > > * Peter Koch: > > > >> However, A6 was defined in RFC 2874 together with "bitstring labels" > >> and while their use might be arguable as well, they'd either have to > >> share fate or be preserved in a separate document since the > >> status applies to a whole RFC, not just parts. > > > > EDNS0bis will disallow extended label types, matching current > > implementation practice. Extended label types require a different > > mechanism for discovering zone delegation in resolvers, and it appears > > that this has never been implemented anywhere. > > Hi Florian, > > I dispute that extended label types have never been implemented. Up until BIN > D-9.3.1, bit string labels (using ELT 000001) were supported. However, the te > xt in draft-ietf-dnsext-rfc2671bis-edns0 already moves bit string labels to h > istoric (explicitly), so that deals with at least that concern. By implicatio > n, it makes A6 useless, hence lets move that to historic as well. A6 is completely independent of bit-string labels. The case for declaring A6 historic has to stand / fall on its own merits. > Kind regards, > > Roy Arends > Nominet UK > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Tue Aug 16 05:06:10 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E3D21F8A6F for ; Tue, 16 Aug 2011 05:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Tlr+QKw1tW2 for ; Tue, 16 Aug 2011 05:06:10 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE3821F8A7A for ; Tue, 16 Aug 2011 05:06:10 -0700 (PDT) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 5DA61C9425; Tue, 16 Aug 2011 12:06:47 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (dhcp184-48-56-208.ssb.sjc.wayport.net [184.48.56.208]) (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 06962216C7B; Tue, 16 Aug 2011 12:06:47 +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 DA27912DBDA0; Tue, 16 Aug 2011 22:06:45 +1000 (EST) To: Sean Wells From: Mark Andrews References: <20110816024359.GF12951@shinkuro.com> In-reply-to: Your message of "Mon, 15 Aug 2011 21:56:58 MST." Date: Tue, 16 Aug 2011 22:06:45 +1000 Message-Id: <20110816120645.DA27912DBDA0@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] Missing DNSKEY record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 12:06:10 -0000 In message , Sean Wells writes: > > On Mon, Aug 15, 2011 at 7:43 PM, Andrew Sullivan wrot > e: > > > On Mon, Aug 15, 2011 at 03:32:20PM -0700, Sean Wells wrote: > > > > > do much because to validate NSEC, you need the key again. You can detect > > > this and abort i.e if you don't have a DNSKEY, abort the validation > > process > > > without processing the NSEC. Obviously, this could be part of an attack. > > But > > > aborting is still better than asking for keys again and again. I don't > > see > > > any text in RFC 4035 regarding this. Perhaps, dnssec-bis implementation > > can > > > mention this case ? > > > > What would you have it say? "If you are unable to validate a response > > because you don't have adequate information, then . . ."? > > > > In the validation process, it looks like handling a NSEC for DNSKEY is the > only odd one out. NSEC response for DS is well understood. I don't know what > implementations do when RRSIGs are missing. > > I would just mention the odd case instead of generalizing: "If you are > unable to validate a response because you are not able to fetch DNSKEY > records, the validation process should be aborted". Actually it isn't a immediate fail. It's only a fail if the zone is supposed to be treated as secure by the validator. If the zone is insecure as far as the validator is concerned then the answer is legitmate. > I think the right answer is surely, "Bogus, return SERVFAIL", no? > > > > Sure. But do implementations return SERVFAIL today ? How do resolvers > handle this case ? > > -Sean > > > A > > > > -- > > Andrew Sullivan > > ajs@anvilwalrusden.com > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From rdroms.ietf@gmail.com Tue Aug 16 07:50:31 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15EE21F8B53 for ; Tue, 16 Aug 2011 07:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.564 X-Spam-Level: X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQDWwVYexOnA for ; Tue, 16 Aug 2011 07:50:31 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 15CE221F8B5D for ; Tue, 16 Aug 2011 07:50:31 -0700 (PDT) Received: by vws12 with SMTP id 12so5960635vws.31 for ; Tue, 16 Aug 2011 07:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=JxK1yq6Z5ehE3E/psWvqOr8G3hKuGG2fNOAqdZm6NIY=; b=xaIHT7CvYrf9hLBXJnznsZ/KPsg5pjdOi7nTZFVCVMg7xQnGU61xwtSRLEgOdOPAqm TfKMKSKiwWxYUlMyxJj9F/KJGMEAF3m/Xiv98li1WD95ivbDQAdhizkfNQUB99K+QK9J S0THE1H8Z1OFGIXcWymUKO7D1WQJJG2k1Wg/M= Received: by 10.52.188.68 with SMTP id fy4mr5031635vdc.91.1313506279444; Tue, 16 Aug 2011 07:51:19 -0700 (PDT) Received: from bxb-rdroms-8714.cisco.com (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id cg6sm129287vdc.17.2011.08.16.07.51.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 16 Aug 2011 07:51:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <4e4a5da0.410dcc0a.0f19.6b20SMTPIN_ADDED@mx.google.com> Date: Tue, 16 Aug 2011 10:51:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <86AD8857-3E07-4A01-8AB0-02E832270C21@gmail.com> References: <4e4a5da0.410dcc0a.0f19.6b20SMTPIN_ADDED@mx.google.com> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 14:50:31 -0000 Brian Carpenter kicked off the discussion on the 6man mailing list with: What do 6man people think about moving RFC 2874 (the A6 record) from Experimental to Historic status? It's pretty clear that it doesn't have any real value, and it can still create confusion for newcomers. I agree with Brian and am inclined to move A6 to Historic. - Ralph On Aug 16, 2011, at 8:07 AM 8/16/11, bmanning@vacation.karoshi.com = wrote: >=20 > is the rational for moving this to historic due to the removal of A6 = code from one of=20 > the popular reference implementations back when it was made = experimetal or is there some > practical reason to change its status? >=20 > /bill >=20 > -leave it at experimental please- >=20 >=20 > On Tue, Aug 16, 2011 at 12:44:48AM -0400, Ralph Droms wrote: >> There has been a discussion on the 6man mailing list about moving A6 = records to Historic. I'd like to get input from dnsext about the = re-designation. >>=20 >> ipv6@ietf.org is bcc:ed; please reply to dnsext. >>=20 >> Thanks >>=20 >> - Ralph >>=20 >> _______________________________________________ >> dnsext mailing list >> dnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsext From paul.hoffman@vpnc.org Tue Aug 16 07:56:39 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B45221F8B6F for ; Tue, 16 Aug 2011 07:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1RYE8xuDir3 for ; Tue, 16 Aug 2011 07:56:38 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B48F921F8B6A for ; Tue, 16 Aug 2011 07:56:38 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7GEurCs046706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Aug 2011 07:56:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 16 Aug 2011 07:57:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <76F02EB1-308A-477D-9B4C-0B963FC5A66A@vpnc.org> References: To: Roy Arends X-Mailer: Apple Mail (2.1244.3) Cc: Ralph Droms , "dnsext@ietf.org" Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 14:56:39 -0000 On Aug 16, 2011, at 1:07 AM, Roy Arends wrote: > If this is moved to historic, I would like to see some text on how to = deal with A6 records in the future. +1. Historically in the IETF, moving something to "historic" has caused = confusion for developers because of lack of information (including the = lack of good definition of what "historic" means). This has lead to = *less* interoperability as different developers interpret "historic" in = different ways. If we are going to take this step, we should be clear what we mean, even = though that takes a bit more writing work. --Paul Hoffman From snwells82@gmail.com Tue Aug 16 09:12:42 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CC811E80A5 for ; Tue, 16 Aug 2011 09:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.65 X-Spam-Level: X-Spam-Status: No, score=-3.65 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OP66VEMl+olH for ; Tue, 16 Aug 2011 09:12:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E906721F8BB7 for ; Tue, 16 Aug 2011 09:12:41 -0700 (PDT) Received: by vxi29 with SMTP id 29so59443vxi.31 for ; Tue, 16 Aug 2011 09:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8yk4dVSCflk/sC83VEFkNd/FP9kWdxvfT6ZQfMRGzkk=; b=XCy9iHzytAqCx07aYbvFFrHpVSva4gAlwealZDGit2XEtwyAKrKtSF4GlgkbxqK+yI BSuwkjOgrX9eIV7ccjfdcYO/QaHvwM3w7xikyst3Xa9lurrzCYhy4pw4670cDXer4KUS DTfM6IKjb/nPB4HfMcTqJuIklFV3gfSG32l/Q= MIME-Version: 1.0 Received: by 10.220.215.1 with SMTP id hc1mr1365359vcb.193.1313511210377; Tue, 16 Aug 2011 09:13:30 -0700 (PDT) Received: by 10.220.199.8 with HTTP; Tue, 16 Aug 2011 09:13:30 -0700 (PDT) In-Reply-To: <20110816120645.DA27912DBDA0@drugs.dv.isc.org> References: <20110816024359.GF12951@shinkuro.com> <20110816120645.DA27912DBDA0@drugs.dv.isc.org> Date: Tue, 16 Aug 2011 09:13:30 -0700 Message-ID: From: Sean Wells To: Mark Andrews Content-Type: multipart/alternative; boundary=bcaec54fbbaa1a609604aaa1a9e1 Cc: dnsext@ietf.org Subject: Re: [dnsext] Missing DNSKEY record X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 16:12:43 -0000 --bcaec54fbbaa1a609604aaa1a9e1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 16, 2011 at 5:06 AM, Mark Andrews wrote: > > In message RLX1PutFESg6qKf9M0REputw@mail.gmail.com> > , Sean Wells writes: > > > > On Mon, Aug 15, 2011 at 7:43 PM, Andrew Sullivan >wrot > > e: > > > > > On Mon, Aug 15, 2011 at 03:32:20PM -0700, Sean Wells wrote: > > > > > > > do much because to validate NSEC, you need the key again. You can > detect > > > > this and abort i.e if you don't have a DNSKEY, abort the validation > > > process > > > > without processing the NSEC. Obviously, this could be part of an > attack. > > > But > > > > aborting is still better than asking for keys again and again. I > don't > > > see > > > > any text in RFC 4035 regarding this. Perhaps, dnssec-bis > implementation > > > can > > > > mention this case ? > > > > > > What would you have it say? "If you are unable to validate a response > > > because you don't have adequate information, then . . ."? > > > > > > In the validation process, it looks like handling a NSEC for DNSKEY is > the > > only odd one out. NSEC response for DS is well understood. I don't know > what > > implementations do when RRSIGs are missing. > > > > I would just mention the odd case instead of generalizing: "If you are > > unable to validate a response because you are not able to fetch DNSKEY > > records, the validation process should be aborted". > > Actually it isn't a immediate fail. It's only a fail if the zone is > supposed > to be treated as secure by the validator. If the zone is insecure as far > as > the validator is concerned then the answer is legitmate. > > The issue is not the legitimacy of the response itself. What should the validator do if it can't lookup the DNSKEY record and it receives a NSEC in response to it ? Could you clarify as to what you mean by "it isn't a immediate fail" ? > > I think the right answer is surely, "Bogus, return SERVFAIL", no? > > > > > > Sure. But do implementations return SERVFAIL today ? How do resolvers > > handle this case ? > > > > -Sean > > > > > A > > > > > > -- > > > Andrew Sullivan > > > ajs@anvilwalrusden.com > > > _______________________________________________ > > > dnsext mailing list > > > dnsext@ietf.org > > > https://www.ietf.org/mailman/listinfo/dnsext > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > -- Sean --bcaec54fbbaa1a609604aaa1a9e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 16, 2011 at 5:06 AM, Mark An= drews <marka@isc.org<= /a>> wrote:

In message <CANokk3Lfh4LU9scedpimbPqHV=3DRLX1PutFESg6qKf9M0REputw@mail.gmail.com>=
, Sean Wells writes:
>
> On Mon, Aug 15, 2011 at 7:43 PM, Andrew Sullivan <ajs@anvilwalrusden.com>wrot
> e:
>
> > On Mon, Aug 15, 2011 at 03:32:20PM -0700, Sean Wells wrote:
> >
> > > do much because to validate NSEC, you need the key again. Yo= u can detect
> > > this and abort i.e if you don't have a DNSKEY, abort the= validation
> > process
> > > without processing the NSEC. Obviously, this could be part o= f an attack.
> > But
> > > aborting is still better than asking for keys again and agai= n. I don't
> > see
> > > any text in RFC 4035 regarding this. Perhaps, dnssec-bis imp= lementation
> > can
> > > mention this case ?
> >
> > What would you have it say? =A0"If you are unable to validat= e a response
> > because you don't have adequate information, then . . ."= ?
> >
> > In the validation process, it looks like handling a NSEC for DNSK= EY is the
> only odd one out. NSEC response for DS is well understood. I don't= know what
> implementations do when RRSIGs are missing.
>
> I would just mention the odd case instead of generalizing: "If yo= u are
> unable to validate a response because you are not able to fetch DNSKEY=
> records, the validation process should be aborted".

Actually it isn't a immediate fail. =A0It's only a fail if th= e zone is supposed
to be treated as secure by the validator. =A0If the zone is insecure as far= as
the validator is concerned then the answer is legitmate.


The issue is not the legitimacy of the response itself. What should= the validator do if it can't lookup the DNSKEY record and it receives = a NSEC in response to it ? =A0Could you clarify as to what you mean by &quo= t;it isn't a immediate fail" ?

=A0
> I think the right answer is surely, "Bogus, return SERVFAIL"= , no?
> >
> > Sure. But do implementations return SERVFAIL today ? How do resol= vers
> handle this case ?
>
> =A0-Sean
>
> > A
> >
> > --
> > Andrew Sullivan
> > ajs@anvilwalrusden.com<= /a>
> > _______________________________________________
> > dnsext mailing list
> > dnsext@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsext
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@isc.org



--
Sean<= br> --bcaec54fbbaa1a609604aaa1a9e1-- From drc@virtualized.org Tue Aug 16 09:42:58 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397A221F89BE for ; Tue, 16 Aug 2011 09:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZL1uMwGvrPfY for ; Tue, 16 Aug 2011 09:42:57 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6059021F85F2 for ; Tue, 16 Aug 2011 09:42:57 -0700 (PDT) Received: from [10.0.1.9] (cpe-66-91-109-17.hawaii.res.rr.com [66.91.109.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 869EB1703F; Tue, 16 Aug 2011 16:43:44 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <76F02EB1-308A-477D-9B4C-0B963FC5A66A@vpnc.org> Date: Tue, 16 Aug 2011 06:43:42 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <76F02EB1-308A-477D-9B4C-0B963FC5A66A@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1244.3) Cc: dnsext@ietf.org Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 16:42:58 -0000 On Aug 16, 2011, at 4:57 AM, Paul Hoffman wrote: > On Aug 16, 2011, at 1:07 AM, Roy Arends wrote: >> If this is moved to historic, I would like to see some text on how to = deal with A6 records in the future. I'm confused. Why should A6 be treated any differently than any other = un-understood RRtype? > If we are going to take this step, we should be clear what we mean, = even though that takes a bit more writing work. Perhaps we should move it to "Don't Waste Your Time"? To be clear, I'm all for moving A6 to "Historic". I think spending any = further time on it would fall under = http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality. Regards, -drc From roy@nominet.org.uk Tue Aug 16 15:01:01 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6739E21F8AEA for ; Tue, 16 Aug 2011 15:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.166 X-Spam-Level: X-Spam-Status: No, score=-7.166 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vb9FTACiblzY for ; Tue, 16 Aug 2011 15:01:00 -0700 (PDT) Received: from mx1.knowthenet.org.uk (mx1.knowthenet.org.uk [213.248.199.2]) by ietfa.amsl.com (Postfix) with ESMTP id 58D3F21F8AD3 for ; Tue, 16 Aug 2011 15:01:00 -0700 (PDT) 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: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=K+p10Db3bjrHlFymLr9iyX0qtZrsRMiF1ZIPKETsXeb7/n0xuIB/QECv xlCMIbiLwfZs7qO4KLSPDz8cwUSMHYRnqmj7w+Dg0jftndocesGcUXV8a GGd5e6r1OJpUaDc; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=roy@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1313532110; x=1345068110; 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:=20Roy=20Arends=20|Subject:=20R e:=20[dnsext]=20A6=20to=20Historic|Date:=20Tue,=2016=20Au g=202011=2022:01:44=20+0000|Message-ID:=20|To:=20David=20Conrad=20,=20Paul=20Hoffman=20|CC: =20"dnsext@ietf.org"=20|MIME-Version:=20 1.0|Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<95b73d62-1bd6-4f28-8c04-36d97b077d18> |In-Reply-To:=20; bh=JsXIDfLoPjDxfhiwIM+11teEC7y/5g1G7VL3H3yIBds=; b=Ffl6ZRTSssjSsjpXKKagQAZVoEC6Ug8ifw3bM3dB6aCPxAW1RU+7jc3w a5SpOGbVZC91wmCi/aaj2eyWbKbqrsJDgjPmNtMnz8+nIZQZItZTun4BU gOWFtgrFgi1cSld; X-IronPort-AV: E=Sophos;i="4.68,236,1312153200"; d="scan'208";a="34770538" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 16 Aug 2011 23:01:48 +0100 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%19]) with mapi; Tue, 16 Aug 2011 23:01:48 +0100 From: Roy Arends To: David Conrad , Paul Hoffman Thread-Topic: [dnsext] A6 to Historic Thread-Index: AQHMW89JFEZ8d46euUadWTBLBbshC5UfDrCAgABygoCAAB28AIAAaZ8A Date: Tue, 16 Aug 2011 22:01:44 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <95b73d62-1bd6-4f28-8c04-36d97b077d18> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 22:01:01 -0000 On 8/16/11 5:43 PM, "David Conrad" wrote: >On Aug 16, 2011, at 4:57 AM, Paul Hoffman wrote: >> On Aug 16, 2011, at 1:07 AM, Roy Arends wrote: >>> If this is moved to historic, I would like to see some text on how to >>>deal with A6 records in the future. > > >I'm confused. Why should A6 be treated any differently than any other >un-understood RRtype? A6 should indeed be treated the same as any other un-understood RRtype..... But we should say that somewhere... That's the point. > >> If we are going to take this step, we should be clear what we mean, >>even though that takes a bit more writing work. > > >Perhaps we should move it to "Don't Waste Your Time"? > >To be clear, I'm all for moving A6 to "Historic". I think spending any >further time on it would fall under >http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality. Cute. If, in ten years time, folks want to know why we moved A6 to historic, and what to do when encountering it, they could use a point of reference. Not documenting doesn't help. Something very similar to RFC3425. Roy =20 From jiangsheng@huawei.com Tue Aug 16 18:18:12 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8BC21F8AFA for ; Tue, 16 Aug 2011 18:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2uHzy5w54S5 for ; Tue, 16 Aug 2011 18:18:11 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id A11BD21F8AF9 for ; Tue, 16 Aug 2011 18:18:11 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ100B8NSWQUK@szxga05-in.huawei.com> for dnsext@ietf.org; Wed, 17 Aug 2011 09:17:14 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ100I92SWHT2@szxga05-in.huawei.com> for dnsext@ietf.org; Wed, 17 Aug 2011 09:17:14 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADF86919; Wed, 17 Aug 2011 09:17:12 +0800 (CST) Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 17 Aug 2011 09:17:07 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.66]) by szxeml408-hub.china.huawei.com ([169.254.27.188]) with mapi id 14.01.0270.001; Wed, 17 Aug 2011 09:17:12 +0800 Date: Wed, 17 Aug 2011 01:17:10 +0000 From: Sheng Jiang In-reply-to: <76F02EB1-308A-477D-9B4C-0B963FC5A66A@vpnc.org> X-Originating-IP: [10.110.98.152] To: Paul Hoffman , Roy Arends Message-id: <5D36713D8A4E7348A7E10DF7437A4B92012360A1@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [dnsext] A6 to Historic Thread-index: AQHMW89DzETflTc61EiAwAeNAQW9AZUemViAgABygYCAATJpIA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <76F02EB1-308A-477D-9B4C-0B963FC5A66A@vpnc.org> Cc: Ralph Droms , "dnsext@ietf.org" Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 01:18:12 -0000 I can work on this. But I need a co-author who can investigate the status of the current A6 usage. Any volunteer? Sheng > -----Original Message----- > From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On > Behalf Of Paul Hoffman > Sent: Tuesday, August 16, 2011 10:57 PM > To: Roy Arends > Cc: Ralph Droms; dnsext@ietf.org > Subject: Re: [dnsext] A6 to Historic > > On Aug 16, 2011, at 1:07 AM, Roy Arends wrote: > > > If this is moved to historic, I would like to see some text on how to > deal with A6 records in the future. > > +1. Historically in the IETF, moving something to "historic" has caused > confusion for developers because of lack of information (including the > lack of good definition of what "historic" means). This has lead to > *less* interoperability as different developers interpret "historic" in > different ways. > > If we are going to take this step, we should be clear what we mean, > even though that takes a bit more writing work. > > --Paul Hoffman > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From bmanning@karoshi.com Tue Aug 16 21:56:21 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4424521F8997 for ; Tue, 16 Aug 2011 21:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.386 X-Spam-Level: X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0toeVNuazyKx for ; Tue, 16 Aug 2011 21:56:20 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8370321F8888 for ; Tue, 16 Aug 2011 21:56:20 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7GMnUCD017448; Tue, 16 Aug 2011 22:49:30 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7GMnU6j017447; Tue, 16 Aug 2011 22:49:30 GMT Date: Tue, 16 Aug 2011 22:49:30 +0000 From: bmanning@vacation.karoshi.com To: Ralph Droms Message-ID: <20110816224930.GC14894@vacation.karoshi.com.> References: <4e4a5da0.410dcc0a.0f19.6b20SMTPIN_ADDED@mx.google.com> <86AD8857-3E07-4A01-8AB0-02E832270C21@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86AD8857-3E07-4A01-8AB0-02E832270C21@gmail.com> User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, dnsext@ietf.org Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 04:56:21 -0000 well, as others have pointed out, there is a reasonable, if small use of A6 in the wild and just because one sector (6man) is easily confused, does not mean the rest of us are (dnsext). it may not have any real value to some, but it apparently does to a statistically visiable community. which in my mind is a reason to leave it alone. but as an actual user of the code point, I fully expect to be overridded by folks who don't use it and therefore see no reason to keep things around that don't fit their view of the world. Thanks for the heads up that you are going to depricate A6. /bill On Tue, Aug 16, 2011 at 10:51:15AM -0400, Ralph Droms wrote: > Brian Carpenter kicked off the discussion on the 6man mailing list with: > > What do 6man people think about moving RFC 2874 (the A6 record) > from Experimental to Historic status? > > It's pretty clear that it doesn't have any real value, and > it can still create confusion for newcomers. > > I agree with Brian and am inclined to move A6 to Historic. > > - Ralph > > On Aug 16, 2011, at 8:07 AM 8/16/11, bmanning@vacation.karoshi.com wrote: > > > > > is the rational for moving this to historic due to the removal of A6 code from one of > > the popular reference implementations back when it was made experimetal or is there some > > practical reason to change its status? > > > > /bill > > > > -leave it at experimental please- > > > > > > On Tue, Aug 16, 2011 at 12:44:48AM -0400, Ralph Droms wrote: > >> There has been a discussion on the 6man mailing list about moving A6 records to Historic. I'd like to get input from dnsext about the re-designation. > >> > >> ipv6@ietf.org is bcc:ed; please reply to dnsext. > >> > >> Thanks > >> > >> - Ralph > >> > >> _______________________________________________ > >> dnsext mailing list > >> dnsext@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsext > From bmanning@karoshi.com Tue Aug 16 22:01:22 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884B621F8A95 for ; Tue, 16 Aug 2011 22:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80ypQ4FAJLG5 for ; Tue, 16 Aug 2011 22:01:22 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0123921F8A80 for ; Tue, 16 Aug 2011 22:01:21 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7GC7rCD016368; Tue, 16 Aug 2011 12:07:54 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7GC7q41016367; Tue, 16 Aug 2011 12:07:52 GMT Date: Tue, 16 Aug 2011 12:07:52 +0000 From: bmanning@vacation.karoshi.com To: Ralph Droms Message-ID: <20110816120752.GA14894@vacation.karoshi.com.> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "dnsext@ietf.org" Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 05:01:22 -0000 is the rational for moving this to historic due to the removal of A6 code from one of the popular reference implementations back when it was made experimetal or is there some practical reason to change its status? /bill -leave it at experimental please- On Tue, Aug 16, 2011 at 12:44:48AM -0400, Ralph Droms wrote: > There has been a discussion on the 6man mailing list about moving A6 records to Historic. I'd like to get input from dnsext about the re-designation. > > ipv6@ietf.org is bcc:ed; please reply to dnsext. > > Thanks > > - Ralph > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From jiangsheng@huawei.com Tue Aug 16 23:13:34 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C35421F8A35 for ; Tue, 16 Aug 2011 23:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.28 X-Spam-Level: X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuUjoKujKgGA for ; Tue, 16 Aug 2011 23:13:33 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 90C9921F88B6 for ; Tue, 16 Aug 2011 23:13:33 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ200GTC6NMWB@szxga03-in.huawei.com> for dnsext@ietf.org; Wed, 17 Aug 2011 14:14:11 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ200HJQ6MJIN@szxga03-in.huawei.com> for dnsext@ietf.org; Wed, 17 Aug 2011 14:14:10 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADG09327; Wed, 17 Aug 2011 14:14:10 +0800 (CST) Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 17 Aug 2011 14:14:05 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.66]) by szxeml403-hub.china.huawei.com ([169.254.173.75]) with mapi id 14.01.0270.001; Wed, 17 Aug 2011 14:14:10 +0800 Date: Wed, 17 Aug 2011 06:14:09 +0000 From: Sheng Jiang In-reply-to: <20110816120752.GA14894@vacation.karoshi.com> X-Originating-IP: [10.110.98.152] To: "bmanning@vacation.karoshi.com" , Ralph Droms Message-id: <5D36713D8A4E7348A7E10DF7437A4B92012362F8@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [dnsext] A6 to Historic Thread-index: AQHMW89DzETflTc61EiAwAeNAQW9AZUe3IQAgAG0xFA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110816120752.GA14894@vacation.karoshi.com> Cc: "dnsext@ietf.org" Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 06:13:34 -0000 It was RFC 3363, " Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", moved A6 from "proposed standard" to "experimental" status. Also see RFC 3364, "Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)", for some issues A6 has. Sheng > -----Original Message----- > From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On > Behalf Of bmanning@vacation.karoshi.com > Sent: Tuesday, August 16, 2011 8:08 PM > To: Ralph Droms > Cc: dnsext@ietf.org > Subject: Re: [dnsext] A6 to Historic > > > is the rational for moving this to historic due to the removal of A6 > code from one of > the popular reference implementations back when it was made experimetal > or is there some > practical reason to change its status? > > /bill > > -leave it at experimental please- > > > On Tue, Aug 16, 2011 at 12:44:48AM -0400, Ralph Droms wrote: > > There has been a discussion on the 6man mailing list about moving A6 > records to Historic. I'd like to get input from dnsext about the re- > designation. > > > > ipv6@ietf.org is bcc:ed; please reply to dnsext. > > > > Thanks > > > > - Ralph > > > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From gson@araneus.fi Wed Aug 17 00:54:35 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9952D21F8B39 for ; Wed, 17 Aug 2011 00:54:35 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n39tvzqfpg-i for ; Wed, 17 Aug 2011 00:54:35 -0700 (PDT) Received: from gunk.araneus.fi (gunk.araneus.fi [166.84.6.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0845C21F8B38 for ; Wed, 17 Aug 2011 00:54:34 -0700 (PDT) Received: from guava.gson.org (guava.gson.org [10.0.11.2]) by gunk.araneus.fi (Postfix) with ESMTP id 4FECD1D0CE3; Wed, 17 Aug 2011 07:51:17 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 0CB4175E8F; Wed, 17 Aug 2011 10:55:22 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20043.29672.301202.173099@guava.gson.org> Date: Wed, 17 Aug 2011 10:55:20 +0300 To: Sheng Jiang , "dnsext@ietf.org" In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B920123583F@SZXEML506-MBS.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B920123583F@SZXEML506-MBS.china.huawei.com> X-Mailer: VM 8.0.14 under 21.4.1 (i386--netbsdelf) From: Andreas Gustafsson Cc: Ralph Droms Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 07:54:35 -0000 Sheng Jiang wrote: > However, some current data shows A6 is actually in use. Could you please provide a reference to this data? Does it show that A6 records are actually published on authoritative servers, or just that there is type A6 query traffic? That there is A6 query traffic does not mean that A6 is actually in use; it probably just means that there are still some recursive servers in operation that issue internally-generated type A6 queries when trying to look up missing name server addresses, in addition to issuing such queries for A and AAAA. +1 for moving A6 to Historic. -- Andreas Gustafsson, gson@araneus.fi From jiangsheng@huawei.com Wed Aug 17 01:19:32 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60DD21F856C for ; Wed, 17 Aug 2011 01:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.286 X-Spam-Level: X-Spam-Status: No, score=-6.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPGSjfP0m0t0 for ; Wed, 17 Aug 2011 01:19:31 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 607F021F856D for ; Wed, 17 Aug 2011 01:19:13 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ200C40CGIJK@szxga03-in.huawei.com> for dnsext@ietf.org; Wed, 17 Aug 2011 16:19:30 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ200F9TCFQJW@szxga03-in.huawei.com> for dnsext@ietf.org; Wed, 17 Aug 2011 16:19:30 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADG22565; Wed, 17 Aug 2011 16:19:29 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 17 Aug 2011 16:19:22 +0800 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.66]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Wed, 17 Aug 2011 16:19:28 +0800 Date: Wed, 17 Aug 2011 08:19:28 +0000 From: Sheng Jiang In-reply-to: <20043.29672.301202.173099@guava.gson.org> X-Originating-IP: [10.110.98.152] To: Andreas Gustafsson , "dnsext@ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B92012363BC@SZXEML506-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [dnsext] A6 to Historic Thread-index: AQHMW89DzETflTc61EiAwAeNAQW9AZUfGG5ggAEP3ACAAIxW8A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5D36713D8A4E7348A7E10DF7437A4B920123583F@SZXEML506-MBS.china.huawei.com> <20043.29672.301202.173099@guava.gson.org> Cc: Ralph Droms Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 08:19:32 -0000 > > However, some current data shows A6 is actually in use. > > Could you please provide a reference to this data? Does it show that > A6 records are actually published on authoritative servers, or just > that there is type A6 query traffic? The root servers are getting 100's of A6 q/s (~20:1 AAAA:A6 ). > That there is A6 query traffic does not mean that A6 is actually in > use; it probably just means that there are still some recursive > servers in operation that issue internally-generated type A6 queries > when trying to look up missing name server addresses, in addition to > issuing such queries for A and AAAA. That's right. That's what we need to investigate further. Sheng > +1 for moving A6 to Historic. > -- > Andreas Gustafsson, gson@araneus.fi From fanf2@hermes.cam.ac.uk Wed Aug 17 03:31:03 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1008721F8B15 for ; Wed, 17 Aug 2011 03:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EADTgJTPJ6p5 for ; Wed, 17 Aug 2011 03:31:02 -0700 (PDT) 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 2DE6521F8B13 for ; Wed, 17 Aug 2011 03:31:02 -0700 (PDT) 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-2.csi.cam.ac.uk ([131.111.8.54]:35209) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1QtdPb-0003Mu-Qs (Exim 4.72) (return-path ); Wed, 17 Aug 2011 11:31:51 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QtdPb-0000tE-4r (Exim 4.67) (return-path ); Wed, 17 Aug 2011 11:31:51 +0100 Date: Wed, 17 Aug 2011 11:31:51 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: bmanning@vacation.karoshi.com In-Reply-To: <20110816224930.GC14894@vacation.karoshi.com.> Message-ID: References: <4e4a5da0.410dcc0a.0f19.6b20SMTPIN_ADDED@mx.google.com> <86AD8857-3E07-4A01-8AB0-02E832270C21@gmail.com> <20110816224930.GC14894@vacation.karoshi.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: Ralph Droms , dnsext@ietf.org Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 10:31:03 -0000 bmanning@vacation.karoshi.com wrote: > > well, as others have pointed out, there is a reasonable, if small use of A6 in the > wild Isn't that entirely due to obsolete software that queries for A6 instead of AAAA? Note the A6 queries will never get a positive answer. How does the rate of ip6.int queries compare? Tony. -- f.anthony.n.finch http://dotat.at/ Humber: Northwest, veering northeast 3 or 4, occasionally 5 at first. Slight. Showers. Good. From jim@rfc1035.com Wed Aug 17 05:28:30 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A2021F8B4F for ; Wed, 17 Aug 2011 05:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbQvm55zV2sf for ; Wed, 17 Aug 2011 05:28:30 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 3779F21F8B4A for ; Wed, 17 Aug 2011 05:28:30 -0700 (PDT) Received: from [127.0.0.1] (shaun.rfc1035.com [93.186.33.42]) by shaun.rfc1035.com (Postfix) with ESMTP id 6B519CBC44C; Wed, 17 Aug 2011 13:29:18 +0100 (BST) Message-Id: <4C8E59A2-28A2-408D-96CC-E084ED37D96F@rfc1035.com> From: Jim Reid To: Andreas Gustafsson In-Reply-To: <20043.29672.301202.173099@guava.gson.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 17 Aug 2011 13:29:18 +0100 References: <5D36713D8A4E7348A7E10DF7437A4B920123583F@SZXEML506-MBS.china.huawei.com> <20043.29672.301202.173099@guava.gson.org> X-Mailer: Apple Mail (2.936) Cc: Ralph Droms , "dnsext@ietf.org" Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 12:28:30 -0000 On 17 Aug 2011, at 08:55, Andreas Gustafsson wrote: > > That there is A6 query traffic does not mean that A6 is actually in > use; it probably just means that there are still some recursive > servers in operation that issue internally-generated type A6 queries > when trying to look up missing name server addresses, in addition to > issuing such queries for A and AAAA. Yeah. ISTR A6 lookups found their way into some Linux/glibc implementations of gethostbyname() 8-10 years ago. These may well have not been replaced or upgraded yet. > +1 for moving A6 to Historic. Me too! From Ed.Lewis@neustar.biz Wed Aug 17 06:19:58 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFFC21F8B7E for ; Wed, 17 Aug 2011 06:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.465 X-Spam-Level: X-Spam-Status: No, score=-106.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeLDNlpVmTUm for ; Wed, 17 Aug 2011 06:19:57 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 24D6B21F8B4E for ; Wed, 17 Aug 2011 06:19:56 -0700 (PDT) Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p7HDKh1E007845; Wed, 17 Aug 2011 09:20:44 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.108] by work-laptop-2 (PGP Universal service); Wed, 17 Aug 2011 09:20:44 -0400 X-PGP-Universal: processed; by work-laptop-2 on Wed, 17 Aug 2011 09:20:44 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4C8E59A2-28A2-408D-96CC-E084ED37D96F@rfc1035.com> References: <5D36713D8A4E7348A7E10DF7437A4B920123583F@SZXEML506-MBS.china.huawei.com> <20043.29672.301202.173099@guava.gson.org> <4C8E59A2-28A2-408D-96CC-E084ED37D96F@rfc1035.com> Date: Wed, 17 Aug 2011 09:18:08 -0400 To: "dnsext@ietf.org" , Ralph Droms From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.71 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [dnsext] brief personal opinion on A6 status X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 13:19:58 -0000 A6, as with a handful of other lame duck types, should be marked historic with the meaning being "here's the definition of the syntax and semantics but it is not required for general purpose implementations and is considered to be obsolete." Other dead-on-arrival types include SINK which lives on in the IANA registry and in harder-to-find expired drafts. As far as A6, saying "it's in use" is a weak excuse. Many old, old versions of BIND asked for it and some active name servers have not been upgraded for a long time. I'm all for moving A6 to historic because it can be dangerous to the protocol. When A6 was moved to experimental following the London IETF meeting in summer 2001, I had two negative thoughts about A6 despite originally thinking it was a really cool answer to renumbering problems. One, no one was able to ever "white board" a scenario showing the concept working in front of a small crowd without making a mistake. That it, it did not pass a sniff test of being a simple enough to explain or operate mechanism. Two, it could be a denial of service attack vector by inducing a resolver into a long-lived "loop" trying to find all of the fragments of the address needed to assemble the 128 bits. Fragments weren't guaranteed to line up, so a resolver might find conflicting portions of the address. Even if it seemed it was ultimately guaranteed to find an address, the work to get there (including the needed network queries) could be considerable. The lesson learned from the A6 experiment was that the data model of DNS had to stick to simple records to preserve the speed feature of DNS. The lesson also applied to DNSSEC, affirming[*] that simplifying the default authorization model (the signer domain name in the RRSIG ought to be the zone) was a right step. Ever since then we have been trying to make sure the resolver's work is minimized. [*] I'm not saying this led to RFC 3008, as RFC 3008 was published nearly a year earlier. But it made the restriction more significant. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From sthaug@nethelp.no Wed Aug 17 08:33:49 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C07A21F8B5D for ; Wed, 17 Aug 2011 08:33:49 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDTcSRKHfKAd for ; Wed, 17 Aug 2011 08:33:48 -0700 (PDT) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 0802621F8B6D for ; Wed, 17 Aug 2011 08:33:47 -0700 (PDT) Received: (qmail 69380 invoked from network); 17 Aug 2011 15:34:37 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 17 Aug 2011 15:34:37 -0000 Date: Wed, 17 Aug 2011 17:34:37 +0200 (CEST) Message-Id: <20110817.173437.74690346.sthaug@nethelp.no> To: Ed.Lewis@neustar.biz From: sthaug@nethelp.no In-Reply-To: References: <20043.29672.301202.173099@guava.gson.org> <4C8E59A2-28A2-408D-96CC-E084ED37D96F@rfc1035.com> 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: dnsext@ietf.org, rdroms.ietf@gmail.com Subject: Re: [dnsext] brief personal opinion on A6 status X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 15:33:49 -0000 > One, no one was able to ever "white board" a scenario showing the > concept working in front of a small crowd without making a mistake. > That it, it did not pass a sniff test of being a simple enough to > explain or operate mechanism. Does DNSSEC pass this test? Steinar Haug, Nethelp consulting, sthaug@nethelp.no From Ed.Lewis@neustar.biz Wed Aug 17 08:41:11 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FF921F8BA6 for ; Wed, 17 Aug 2011 08:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.476 X-Spam-Level: X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y18mol5Bdrp for ; Wed, 17 Aug 2011 08:41:10 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 519B321F8B9A for ; Wed, 17 Aug 2011 08:41:09 -0700 (PDT) Received: from work-laptop-2 (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p7HFft0m008919; Wed, 17 Aug 2011 11:41:56 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.108] by work-laptop-2 (PGP Universal service); Wed, 17 Aug 2011 11:41:57 -0400 X-PGP-Universal: processed; by work-laptop-2 on Wed, 17 Aug 2011 11:41:57 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20110817.173437.74690346.sthaug@nethelp.no> References: <20043.29672.301202.173099@guava.gson.org> <4C8E59A2-28A2-408D-96CC-E084ED37D96F@rfc1035.com> <20110817.173437.74690346.sthaug@nethelp.no> Date: Wed, 17 Aug 2011 11:41:51 -0400 To: From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.71 on 10.20.30.4 Cc: Ed.Lewis@neustar.biz, dnsext@ietf.org, rdroms.ietf@gmail.com Subject: Re: [dnsext] brief personal opinion on A6 status X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 15:41:11 -0000 At 17:34 +0200 8/17/11, wrote: >> One, no one was able to ever "white board" a scenario showing the >> concept working in front of a small crowd without making a mistake. >> That it, it did not pass a sniff test of being a simple enough to >> explain or operate mechanism. > >Does DNSSEC pass this test? Yeah. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From drc@virtualized.org Wed Aug 17 15:54:34 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B765321F8C21 for ; Wed, 17 Aug 2011 15:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifYECxnRJ7YW for ; Wed, 17 Aug 2011 15:54:17 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8080421F8B2E for ; Wed, 17 Aug 2011 15:54:17 -0700 (PDT) Received: from [10.0.1.9] (cpe-66-91-109-17.hawaii.res.rr.com [66.91.109.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id C94F71703F; Wed, 17 Aug 2011 22:55:08 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20110816224930.GC14894@vacation.karoshi.com.> Date: Wed, 17 Aug 2011 12:55:06 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <6D7DCFB3-FD79-456C-ADE6-18966EBBF52E@virtualized.org> References: <4e4a5da0.410dcc0a.0f19.6b20SMTPIN_ADDED@mx.google.com> <86AD8857-3E07-4A01-8AB0-02E832270C21@gmail.com> <20110816224930.GC14894@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: dnsext@ietf.org Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 22:54:34 -0000 On Aug 16, 2011, at 12:49 PM, bmanning@vacation.karoshi.com wrote: > it may not have any real value to some, but it apparently does to a = statistically visiable community. =20 The fact that root servers are receiving A6 queries does not necessarily = imply A6 has value. > but as an actual user of the code point, How are you using it? Regards, -drc From johnl@iecc.com Wed Aug 17 20:21:58 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFC45E8003 for ; Wed, 17 Aug 2011 20:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_13=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd0pVlv25cUG for ; Wed, 17 Aug 2011 20:21:57 -0700 (PDT) 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 1C7575E8002 for ; Wed, 17 Aug 2011 20:21:56 -0700 (PDT) Received: (qmail 16603 invoked from network); 18 Aug 2011 03:22:47 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 18 Aug 2011 03:22:47 -0000 Received: (qmail 70816 invoked from network); 18 Aug 2011 03:22:46 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Aug 2011 03:22:46 -0000 Date: 18 Aug 2011 03:22:24 -0000 Message-ID: <20110818032224.45073.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [dnsext] An RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 03:21:58 -0000 I was pondering why it's such a pain to deploy a new RRTYPE. First, you have to change the code in the authoritative servers (BIND, Maradns, whatever) to parse the new RR. Nearly everyone uses some sort of provisioning system with a web front end or the like to manage the zone files, so you need to make code changes to the provisioning system, to handle new RRTYPEs, too. But most RRTYPEs (not all, but most) are syntactically pretty simple. How hard would it be to define an RRTYPE definition language for DNS software that could handle most new RRTYPEs? If we did that, and systems had a conventional place to put the definitions, analogous to /etc/ports, then for new RRTYPEs that don't require either exotic syntax or semantic changes to the DNS, you add a line or two to the definition file, and you're done. So I went through the list of all the RRTYPEs to see what sort of fields they include. Disregarding the exotic one-off types like the longitude and latitude in signed milliseconds in LOC records, it's nearly all names, strings, and integers of various sizes. Some of the integers have named values, or are decoded into named bitmask fields, but it's still pretty simple. So if we were adding the KX records from RFC 2230, it'd be something like this: KX:36 I2 N Its name is KX, its RRTYPE is 36, and it has two fields, a two-byte integer and a domain name. It'd also need some sort of flag to note that the server should include additional section info for the N field, which is typical for N fields. For SSHFP records from RFC 4255: SSHFP:44 I1 I1 X The name is SSHFP, type is 44, record contains two one-byte numbers followed by a hex string. For the CERT record in RFC 4398 which has named codes, something like this: CERT:27 I2<1:PKIX,2:SPKI,3:PGP,4:IPKIX,5:ISPKI,6:IPGP,7:ACPKIX,\ 8:IACPKIX,253:URI,254:OID> I2 \ I1<1:RSA/MD5,2:Diffie-Hellman,3:DSA/SHA-1,4:Elliptic,5:RSA/SHA-1> B The CERT record is three numbers followed by a base64 field. The first and third numbers can also be written as mnemonic values. (Feel free to adjust the syntax to be less ugly.) Again, this isn't supposed to handle every possible new RRTYPE, but I think it'll handle enough to make it a lot easier to add the sorts of types that are now punted to TXT records with prefixed names. R's, John ---------------------------------------------------------------------- field types ? field is optional, must be at the end field has named flag bits field has named code values A 32 bit IPv4 address as n.n.n.n AAAA 128 bit IPv6 address as h:h::h N uncompressed domain name CN compressed domain name MN domain name interpreted as a mailbox CMN compressed domain name interpreted as a mailbox S counted string MS one or more counted strings LS long string, multiple strings logically concatenated B string written as base64 I1 one-octet integer I2 two-octet integer I4 four-octet integer T Unix timestamp written as YYYYMMDDHHMMSS X uncounted string of hex digits TYPE Value and meaning Reference ----------- --------------------------------------------- --------- A 1 a host address [RFC1035] val A NS 2 an authoritative name server [RFC1035] val CN MD 3 a mail destination (Obsolete - use MX) [RFC1035] val CN MF 4 a mail forwarder (Obsolete - use MX) [RFC1035] val CN CNAME 5 the canonical name for an alias [RFC1035] val CN SOA 6 marks the start of a zone of authority [RFC1035] val CN CMN I4 I4 I4 I4 MB 7 a mailbox domain name (EXPERIMENTAL) [RFC1035] val CN MG 8 a mail group member (EXPERIMENTAL) [RFC1035] val CN MR 9 a mail rename domain name (EXPERIMENTAL) [RFC1035] val CN NULL 10 a null RR (EXPERIMENTAL) [RFC1035] value is ignored WKS 11 a well known service description [RFC1035] val A I1 PTR 12 a domain name pointer [RFC1035] val CN HINFO 13 host information [RFC1035] val S S MINFO 14 mailbox or mail list information [RFC1035] val CN CN MX 15 mail exchange [RFC1035] val I2 CN TXT 16 text strings [RFC1035] val MS RP 17 for Responsible Person [RFC1183] val MN N AFSDB 18 for AFS Data Base location [RFC1183][RFC5864] val I2 N (maybe CN) X25 19 for X.25 PSDN address [RFC1183] val S ISDN 20 for ISDN address [RFC1183] val S S? RT 21 for Route Through [RFC1183] val I2 N NSAP 22 for NSAP address, NSAP style A record [RFC1706] val S S NSAP-PTR 23 for domain name pointer, NSAP style [RFC1348] val N SIG 24 for security signature [RFC4034][RFC3755][RFC2535] val I2 I1 I1 I4 T T I2 CN B KEY 25 for security key [RFC4034][RFC3755][RFC2535] val I2 I1 I1 B PX 26 X.400 mail mapping information [RFC2163] val I2 N N GPOS 27 Geographical Position [RFC1712] val S S S AAAA 28 IP6 Address [RFC3596] val AAAA LOC 29 Location Information [RFC1876] val NXT 30 Next Domain - OBSOLETE [RFC3755][RFC2535] val CN EID 31 Endpoint Identifier [Patton] NIMLOC 32 Nimrod Locator [Patton] SRV 33 Server Selection [RFC2782] val I2 I2 I2 N ATMA 34 ATM Address [ATMDOC] val I1 S NAPTR 35 Naming Authority Pointer [RFC2915][RFC2168][RFC3403] val I2 I2 I2 S S N KX 36 Key Exchanger [RFC2230] val I2 N CERT 37 CERT [RFC4398] val I2 I2 I1 B A6 38 A6 (Experimental) [RFC3226][RFC2874] val I1
? N? DNAME 39 DNAME [RFC2672] val N SINK 40 SINK [Eastlake] OPT 41 OPT [RFC2671] val I2 I2 APL 42 APL [RFC3123] val I2 I1 <7 bit length> DS 43 Delegation Signer [RFC4034][RFC3658] val I2 I1 I1 X SSHFP 44 SSH Key Fingerprint [RFC4255] val I1 I1 X IPSECKEY 45 IPSECKEY [RFC4025] val I1 I1 I1 B RRSIG 46 RRSIG [RFC4034][RFC3755] val I2 I1 I1 I4 T T I2 N B NSEC 47 NSEC [RFC4034][RFC3755] val N DNSKEY 48 DNSKEY [RFC4034][RFC3755] val I2 I1 I1 B DHCID 49 DHCID [RFC4701] val B NSEC3 50 NSEC3 [RFC5155] val I1 I1 I2 NSEC3PARAM 51 NSEC3PARAM [RFC5155] val I1 I1 I2 Unassigned 52-54 HIP 55 Host Identity Protocol [RFC5205] val NINFO 56 NINFO [Reid] RKEY 57 RKEY [Reid] TALINK 58 Trust Anchor LINK [Wijngaards] CDS 59 Child DS [Barwood] Unassigned 60-98 SPF 99 [RFC4408] val LS UINFO 100 [IANA-Reserved] UID 101 [IANA-Reserved] GID 102 [IANA-Reserved] UNSPEC 103 [IANA-Reserved] Unassigned 104-248 TKEY 249 Transaction Key [RFC2930] TSIG 250 Transaction Signature [RFC2845] ??? next four are qtypes, not rrtypes IXFR 251 incremental transfer [RFC1995] AXFR 252 transfer of an entire zone [RFC1035][RFC5936] MAILB 253 mailbox-related RRs (MB, MG or MR) [RFC1035] MAILA 254 mail agent RRs (Obsolete - see MX) [RFC1035] * 255 A request for all records [RFC1035] URI 256 URI [Faltstrom] CAA 257 Certification Authority Authorization [Hallam-Baker] Unassigned 258-32767 TA 32768 DNSSEC Trust Authorities [Weiler] 2005-12-13 DLV 32769 DNSSEC Lookaside Validation [RFC4431] val I2 I1 I1 X From bmanning@karoshi.com Wed Aug 17 21:46:07 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C1A21F8B12 for ; Wed, 17 Aug 2011 21:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.366 X-Spam-Level: X-Spam-Status: No, score=-5.366 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vh-JvRGG2sTu for ; Wed, 17 Aug 2011 21:46:07 -0700 (PDT) Received: from vacation.karoshi.com (unknown [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id CC09021F8B11 for ; Wed, 17 Aug 2011 21:45:55 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7H5JPCD018680; Wed, 17 Aug 2011 05:19:26 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7H5JPN2018679; Wed, 17 Aug 2011 05:19:25 GMT Date: Wed, 17 Aug 2011 05:19:25 +0000 From: bmanning@vacation.karoshi.com To: Roy Arends Message-ID: <20110817051925.GC17498@vacation.karoshi.com.> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "dnsext@ietf.org" , Paul Hoffman Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 04:46:07 -0000 actually, Ralph has provided the rational for moving to historic. "Brian Carpenter was confused." and for those of us who use A6, I guess we will continue to support it even if -in its move to historic- unless the IANA choses to revolk its code point, which is something I don't think they have ever done for any RR type that was defined. Of course there is always a first time. /bill On Tue, Aug 16, 2011 at 10:01:44PM +0000, Roy Arends wrote: > > > On 8/16/11 5:43 PM, "David Conrad" wrote: > > >On Aug 16, 2011, at 4:57 AM, Paul Hoffman wrote: > >> On Aug 16, 2011, at 1:07 AM, Roy Arends wrote: > >>> If this is moved to historic, I would like to see some text on how to > >>>deal with A6 records in the future. > > > > > >I'm confused. Why should A6 be treated any differently than any other > >un-understood RRtype? > > A6 should indeed be treated the same as any other un-understood > RRtype..... But we should say that somewhere... That's the point. > > > > >> If we are going to take this step, we should be clear what we mean, > >>even though that takes a bit more writing work. > > > > > >Perhaps we should move it to "Don't Waste Your Time"? > > > >To be clear, I'm all for moving A6 to "Historic". I think spending any > >further time on it would fall under > >http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality. > > Cute. > > If, in ten years time, folks want to know why we moved A6 to historic, and > what to do when encountering it, they could use a point of reference. Not > documenting doesn't help. Something very similar to RFC3425. > > Roy > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From drc@virtualized.org Wed Aug 17 22:01:54 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BE011E8091 for ; Wed, 17 Aug 2011 22:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWAVTij4eI9x for ; Wed, 17 Aug 2011 22:01:54 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6796F11E808F for ; Wed, 17 Aug 2011 22:01:54 -0700 (PDT) Received: from [10.0.1.9] (cpe-66-91-109-17.hawaii.res.rr.com [66.91.109.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id B74B21703F; Thu, 18 Aug 2011 05:02:46 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20110818033644.GF19852@vacation.karoshi.com.> Date: Wed, 17 Aug 2011 19:02:45 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <0B4CF9B3-F42F-4E26-8087-B85C9E6B68F4@virtualized.org> References: <4e4a5da0.410dcc0a.0f19.6b20SMTPIN_ADDED@mx.google.com> <86AD8857-3E07-4A01-8AB0-02E832270C21@gmail.com> <20110816224930.GC14894@vacation.karoshi.com.> <6D7DCFB3-FD79-456C-ADE6-18966EBBF52E@virtualized.org> <20110818033644.GF19852@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: dnsext@ietf.org Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 05:01:54 -0000 Bill, On Aug 17, 2011, at 5:36 PM, bmanning@vacation.karoshi.com wrote: >>> it may not have any real value to some, but it apparently does to a = statistically visiable community. =20 >> The fact that root servers are receiving A6 queries does not = necessarily imply A6 has value. > certainly not to the roots. =20 Sorry, which "statistically visible community" are you talking about = then? >> How are you using it? > for doing IPv6 prefix renumbering. Which part of RFC 3364's analysis of A6's issues do you disagree with? > I had to put the code back into BIND when > ISC stripped it out, then had to fix DHCPv6 to work as DHCP was = designed to ... > so I have DDNS working when nodes are mobile and move between policy = domains. Other than your hacked BIND, is there any other implementation? Regards, -drc From peter@denic.de Thu Aug 18 01:55:19 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985AA21F89A1 for ; Thu, 18 Aug 2011 01:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuJszYFd0JfS for ; Thu, 18 Aug 2011 01:55:19 -0700 (PDT) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0FC21F874F for ; Thu, 18 Aug 2011 01:55:18 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1QtyOY-0007xR-AL; Thu, 18 Aug 2011 10:56:10 +0200 Received: from localhost by x27.adm.denic.de with local id 1QtyOY-0001VP-3E; Thu, 18 Aug 2011 10:56:10 +0200 Date: Thu, 18 Aug 2011 10:56:10 +0200 From: Peter Koch To: IETF DNSEXT WG Message-ID: <20110818085610.GJ25053@x27.adm.denic.de> References: <20110817051925.GC17498@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110817051925.GC17498@vacation.karoshi.com.> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 08:55:19 -0000 On Wed, Aug 17, 2011 at 05:19:25AM +0000, bmanning@vacation.karoshi.com wrote: > even if -in its move to historic- unless the IANA choses to revolk its code point, > which is something I don't think they have ever done for any RR type that was > defined. Of course there is always a first time. which part of RFC 6195 or which other document did i miss that would put this decision in IANA's hands or would define code point revocation in the first place? -Peter From paul@xelerance.com Thu Aug 18 06:27:34 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FCA21F888A for ; Thu, 18 Aug 2011 06:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ApG431JC4hU for ; Thu, 18 Aug 2011 06:27:33 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 864DB21F86A9 for ; Thu, 18 Aug 2011 06:27:33 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 85273C671; Thu, 18 Aug 2011 09:30:28 -0400 (EDT) Date: Thu, 18 Aug 2011 09:30:28 -0400 (EDT) From: Paul Wouters To: John Levine In-Reply-To: <20110818032224.45073.qmail@joyce.lan> Message-ID: References: <20110818032224.45073.qmail@joyce.lan> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] An RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 13:27:34 -0000 On Wed, 18 Aug 2011, John Levine wrote: > Subject: [dnsext] An RRTYPE extension language > > I was pondering why it's such a pain to deploy a new RRTYPE. People just think it is. It is not. > First, you have to change the code in the authoritative servers (BIND, That's rare. Like for DNSSEC that was needed, but for most RRTYPEs that's not true. > Maradns, whatever) to parse the new RR. Nearly everyone uses some > sort of provisioning system with a web front end or the like to manage > the zone files, so you need to make code changes to the provisioning system, > to handle new RRTYPEs, too. This is why the unknown record type was invented. http://tools.ietf.org/html/rfc3597 I'm playing with DANE and I can just specify a new RRTYPE without hacking either bind or nsd or unbound. I just put in the zone: _443._tcp.www.xelerance.com. IN TYPE65468 \# 34 010130102FA54AE5CD5852D0CFAF1FE5F467C547D766A13410079BB2B01319B702B9 34 is the two bytes for the dane subtype plus 32 bytes for the SHA1 length, telling the parser who long the rrdate is. You could express your other examples in this syntax. It might not be the nicest syntax, but it works. Paul From johnl@iecc.com Thu Aug 18 06:44:30 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B852021F8AC9 for ; Thu, 18 Aug 2011 06:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKBjY17TAzbA for ; Thu, 18 Aug 2011 06:44:30 -0700 (PDT) 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 E087921F8A6F for ; Thu, 18 Aug 2011 06:44:29 -0700 (PDT) Received: (qmail 21181 invoked from network); 18 Aug 2011 13:45:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=52bc.4e4d1772.k1108; bh=hE/BqSV5EgUlaMR9dW6V/vdjeYfxNW9rKF/gjTu/H38=; b=rHOTtWhzP9QJd2RGOo7+uOz+cRF+BThEU6778oKkwvsY6h2QTfbjyDAcJ9t2gm1ExQit3z57UpGjVk/CImw63RC57KSm4uArg2XDHwu1jkJK87l+LfT/KZhq0pz5cvwCVzKKYDqXm1RSyMUYQDuYzE72wjLJkIwurMP9NfTm218= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Aug 2011 13:44:59 -0000 Date: 18 Aug 2011 09:45:21 -0400 Message-ID: From: "John R. Levine" To: "Paul Wouters" In-Reply-To: References: <20110818032224.45073.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] An RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 13:44:30 -0000 >> I was pondering why it's such a pain to deploy a new RRTYPE. > People just think it is. It is not. Sigh. > _443._tcp.www.xelerance.com. IN TYPE65468 \# 34 > 010130102FA54AE5CD5852D0CFAF1FE5F467C547D766A13410079BB2B01319B702B9 Perhaps "deploy" means something other than what you think it does. Yes, most DNS servers have an escape syntax that lets you specify arbitrary record types in hex or octal. I've added kludges to my provisioning software to translate a syntax for AAAA recors into octal escapes that tinydns can handle. But are you volunteering to take the support calls from all my users to explain to them how to translate everything into hex when they want to add new records into my provisioning system? If you expect people who are not DNS weenies to use new RRTYPEs, they have to be able to provision them in terms they can understand. DANE is relatively tough, since a useful provisioning system will need not just the RR syntax but some way to describe the certs. But most RRs are easier than that, hence this proposal. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From Ed.Lewis@neustar.biz Thu Aug 18 06:59:29 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F9921F8B1B for ; Thu, 18 Aug 2011 06:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eohkaxHM1Zg for ; Thu, 18 Aug 2011 06:59:29 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id CAF2021F85AC for ; Thu, 18 Aug 2011 06:59:28 -0700 (PDT) Received: from jsew-lt500.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p7IE0I7x016330; Thu, 18 Aug 2011 10:00:19 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.104] by jsew-lt500.cis.neustar.com (PGP Universal service); Thu, 18 Aug 2011 10:00:19 -0400 X-PGP-Universal: processed; by jsew-lt500.cis.neustar.com on Thu, 18 Aug 2011 10:00:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20110818032224.45073.qmail@joyce.lan> Date: Thu, 18 Aug 2011 10:00:13 -0400 To: "John R. Levine" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.71 on 10.20.30.4 Cc: dnsext@ietf.org Subject: Re: [dnsext] An RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 13:59:30 -0000 At 9:45 -0400 8/18/11, John R. Levine wrote: >But are you volunteering to take the support calls from all my users to >explain to them how to translate everything into hex when they want to add new >records into my provisioning system? If you expect people who are not DNS >weenies to use new RRTYPEs, they have to be able to provision them in >terms they can understand. A point was missed. The unknown record type RFC describes how the DNS passes back and forth data it doesn't understand and doesn't need to. (The DNS needs to know what's in an SOA, NS, A, AAAA, dnssec, MX, CNAME, DNAME and a few others, it doesn't need to know about NAPTR, SRV, TXT, and others.) The "UI" around this can do whatever it wants. "Your provisioning system" is free to present to the user what ever data presentation you want. It can be in French, Hindi, pictograms or even in Hex. You just need to, behind the scenes, translate it to the wire format (or in the printed wire format if you are shoe horning this onto something like "a" BIND that needs text file input). And then to present to the user, parse the wire back to pretty format. Applications can put what ever gunk they want into the DNS. There are even type codes reserved that don't need to be documented publicly or reserved specially. All that needs to know how to handle it are the ends of the transfer. The painful part is getting people to switch from the type code used in testing to the type code eventually allocated once the paperwork is done. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From johnl@iecc.com Thu Aug 18 07:28:32 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEF921F8B6C for ; Thu, 18 Aug 2011 07:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SQpAcND8uEu for ; Thu, 18 Aug 2011 07:28:31 -0700 (PDT) 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 7B37221F8B5A for ; Thu, 18 Aug 2011 07:28:31 -0700 (PDT) Received: (qmail 21433 invoked from network); 18 Aug 2011 14:29:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=53b8.4e4d21c5.k1108; bh=KdRNhwQVZPcDhj+FjEGzOWceVf6zI9HM+Fhi/6yw5TE=; b=UNy9y1Qw2j4gC2DqPjXcOrGYDBsZSx59METgIpEUeCS4hiIcafuyzHcUwtC4TZpykc3CPG7O/wbhFQc9/wxp6QBADNeaMaOcz2CrsP0u0M2iEFUrH6a2KOe3thrh7JVeOMbs5fcELZmckixFslABUn62PeIiZFcLtNQ9F9xrUVw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Aug 2011 14:29:03 -0000 Date: 18 Aug 2011 10:29:24 -0400 Message-ID: From: "John R. Levine" To: "Edward Lewis" In-Reply-To: References: <20110818032224.45073.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] An RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 14:28:32 -0000 > "Your provisioning system" is free to present to the user what ever data > presentation you want. It can be in French, Hindi, pictograms or even in > Hex. You just need to, behind the scenes, translate it to the wire format > (or in the printed wire format if you are shoe horning this onto something > like "a" BIND that needs text file input). And then to present to the user, > parse the wire back to pretty format. Right. But my point is that without a working provisioning system, it is in practice impossible to use an RR other than for the 0.0001% of people who are DNS weenies like us. Hence my desire to make it easier to update them to do so. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From paul@xelerance.com Thu Aug 18 07:34:58 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207D821F8B22 for ; Thu, 18 Aug 2011 07:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgT1ACCin3pq for ; Thu, 18 Aug 2011 07:34:57 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1C01021F8B29 for ; Thu, 18 Aug 2011 07:34:57 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 76657C671; Thu, 18 Aug 2011 10:37:52 -0400 (EDT) Date: Thu, 18 Aug 2011 10:37:52 -0400 (EDT) From: Paul Wouters To: "John R. Levine" In-Reply-To: Message-ID: References: <20110818032224.45073.qmail@joyce.lan> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] An RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 14:34:58 -0000 On Thu, 18 Aug 2011, John R. Levine wrote: >> "Your provisioning system" is free to present to the user what ever data >> presentation you want. It can be in French, Hindi, pictograms or even in >> Hex. You just need to, behind the scenes, translate it to the wire format >> (or in the printed wire format if you are shoe horning this onto something >> like "a" BIND that needs text file input). And then to present to the >> user, parse the wire back to pretty format. > > Right. But my point is that without a working provisioning system, it is in > practice impossible to use an RR other than for the 0.0001% of people who are > DNS weenies like us. Hence my desire to make it easier to update them to do > so. Someone needs to translate. Its either your provisioning system, or the user. In the dane example, I would let the user select "TLSA" and "cert type" and a hostname, and I'd have the provisioning system to the dane.py call to probe the TLS and covert it to zonefile digestable syntax. Perhaps let the user verify it before commiting. Paul From johnl@iecc.com Thu Aug 18 07:41:30 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758E821F8B7F for ; Thu, 18 Aug 2011 07:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgDsrM-zdtjN for ; Thu, 18 Aug 2011 07:41:29 -0700 (PDT) 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 C299421F8B7E for ; Thu, 18 Aug 2011 07:41:29 -0700 (PDT) Received: (qmail 21518 invoked from network); 18 Aug 2011 14:42:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=540d.4e4d24cf.k1108; bh=20VoSGblzOAbF9C9XFDCXqrDnCDA3U7eMjHTLo2HrZ8=; b=DwRHASPygdfINQGaxl/MZV6YFUvFmD6Hoih9U7mGMHdGIWQBE8qT1Cqt7j0y5wwq8oeC8sVFaEjRwRcxr1KZuMnslpDpvoy3GjxLJuXIFFqSfxgDE7a3RGMWas6TT4ITV/LAML/MxzocIESsacOgnWSp22nRJCIlfNyjCJV5hmo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Aug 2011 14:42:01 -0000 Date: 18 Aug 2011 10:42:23 -0400 Message-ID: From: "John R. Levine" To: "Paul Wouters" In-Reply-To: References: <20110818032224.45073.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] An RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 14:41:30 -0000 > Someone needs to translate. Its either your provisioning system, or the user. > In the dane example, I would let the user select "TLSA" and "cert type" and > a hostname, and I'd have the provisioning system to the dane.py call to > probe the TLS and covert it to zonefile digestable syntax. Perhaps let the > user verify it before commiting. It appears we agree that a new RR such as DANE is not in practice usable until there is support for it in provisioning systems. So would it be a good idea to automate adding support to provisioning systems where possible? R's, John From jim@rfc1035.com Thu Aug 18 07:46:12 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DA821F8B9B for ; Thu, 18 Aug 2011 07:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axs4Tj4DhTkS for ; Thu, 18 Aug 2011 07:46:11 -0700 (PDT) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD8821F8B92 for ; Thu, 18 Aug 2011 07:46:11 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id DF4F115420A1; Thu, 18 Aug 2011 15:46:55 +0100 (BST) Message-Id: <02B1DC14-4969-4BA3-8364-4F584A1E8369@rfc1035.com> From: Jim Reid To: "John R. Levine" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 18 Aug 2011 15:46:55 +0100 References: <20110818032224.45073.qmail@joyce.lan> X-Mailer: Apple Mail (2.936) Cc: dnsext@ietf.org Subject: Re: [dnsext] An RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 14:46:12 -0000 On 18 Aug 2011, at 15:29, John R. Levine wrote: > But my point is that without a working provisioning system, ... For some unspecified definition of "working". > Hence my desire to make it easier to update them to do so. I don't see the point quite frankly. I doubt anyone will use such a beast if it existed because the control panels and what have you that are in use today are unlikely to ever be replaced or dragged out of the Stone Age. [The week before last one of them told me an IPv6 address in colon notation was not an IP address!] In general these provisioning systems are so tightly coupled to existing business processes, CRM systems and back-end databases that they are just too difficult to change. And there are other things that those programmer hours could be spent on. Anyhow, further discussion of these provisioning systems isn't needed IMO. Just write up an I-D on your proposed extension language (or gather a set of requirements). A proper document is the obvious starting point for a meaningful discussion. From Ed.Lewis@neustar.biz Thu Aug 18 07:49:34 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6922E21F8B98 for ; Thu, 18 Aug 2011 07:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CULUe19gsVwA for ; Thu, 18 Aug 2011 07:49:34 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDD021F8B92 for ; Thu, 18 Aug 2011 07:49:33 -0700 (PDT) Received: from jsew-lt500.cis.neustar.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p7IEoNoS016695; Thu, 18 Aug 2011 10:50:23 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.104] by jsew-lt500.cis.neustar.com (PGP Universal service); Thu, 18 Aug 2011 10:50:24 -0400 X-PGP-Universal: processed; by jsew-lt500.cis.neustar.com on Thu, 18 Aug 2011 10:50:24 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20110818032224.45073.qmail@joyce.lan> Date: Thu, 18 Aug 2011 10:50:18 -0400 To: "John R. Levine" From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.71 on 10.20.30.4 Cc: Edward Lewis , dnsext@ietf.org Subject: Re: [dnsext] An RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 14:49:34 -0000 At 10:29 -0400 8/18/11, John R. Levine wrote: >Right. But my point is that without a working provisioning system, it is >in practice impossible to use an RR other than for the 0.0001% of people >who are DNS weenies like us. Hence my desire to make it easier to update >them to do so. That (your point) is true for any technology. Usually the place to solve this is in the provisioning interface (the UI) and not the guts of the system. In this case, the DNS already has the guts - unknown record type rules - and it is up to "you" to decide what to enter and what to extract from the type you want. It's always been all about the user interface, perhaps the user user interface tells an application and the application uses an application interface - the same but with a level of indirection. OTOH, maybe you want to dig up the old SINK RR history (never made it to RFC but has a type code reserved) - http://tools.ietf.org/html/draft-ietf-dnsind-kitchen-sink-02 . I'm not raising that to be funny, maybe I and at least Paul are assuming more about the problem then you intend. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 I'm overly entertained. From ondrej.sury@nic.cz Thu Aug 18 08:52:47 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49E621F8B33 for ; Thu, 18 Aug 2011 08:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MzF9ykoGhpZ for ; Thu, 18 Aug 2011 08:52:47 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF2D21F8B29 for ; Thu, 18 Aug 2011 08:52:42 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:1d67:4023:e239:bd47] (unknown [IPv6:2001:1488:ac14:1400:1d67:4023:e239:bd47]) by mail.nic.cz (Postfix) with ESMTPSA id 82EC02A2C10; Thu, 18 Aug 2011 17:53:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1313682813; bh=aBcs8ZnCv/tqj5RG0Dhy9Vh1MDFU+NUrCtOAOv7xvp4=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=QmpiLndcGSlYhl1aZo0znnMo5doO/Vcuhy58N1KHMn0j32metzWxXN7yDXi5uOEH/ LRnGHAdkapx1QmjRotnOacIPC+EOOyIBgrlKhb9NIyM57MEG5RQrdidrP8qQYhpGCH ozAD2YakzyXLu/MQ9JcfnkIMOTsedTBIWWvpQDfM= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4E000B93.3030306@necom830.hpcl.titech.ac.jp> Date: Thu, 18 Aug 2011 17:53:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A34D894-4323-4948-811E-6568C838A503@nic.cz> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 15:52:47 -0000 On 21. 6. 2011, at 5:10, Masataka Ohta wrote: > Shane Kerr wrote: >=20 >> The reason this came up is that two operators (Ondrej and me) both >> encountered the problem in the real world and it adversely affected >> our operations. >=20 > Are your examples essentially different from Brian Dickson's? Much simpler. The DNSSEC signed zone is huge and with anycasts = scattered around the world downloading the zone from hidden master(s) I just don't want the AXFR happen if it can be prevented. So if I had a knob which would turn the AXFR fallback off I could easily setup an infrastructure which will buzz me if the IXFR cannot be done = because something has happened on the master and I could f.e. allow to sync one = slave at the time (or few of them). And there's a lot of stuff which can = happen on the master to forget the differences. The problem is that the 500MB zone * number of anycast slaves (25ish) is 10 GB of data to transfer. Sure, I can just buy a really fat pipe, but I am no friend of "throw more money" there solutions when we can have simple protocol solution. The IXFR-only is not a mechanism which would be used by small DNS = operators, but it can make a difference for huge zone owners like the average = DNSSEC signed TLDs. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From drc@virtualized.org Thu Aug 18 10:20:50 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6EC21F856C for ; Thu, 18 Aug 2011 10:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LN577SbHAG44 for ; Thu, 18 Aug 2011 10:20:49 -0700 (PDT) Received: from trantor.virtualized.org (trantor.virtualized.org [199.48.134.42]) by ietfa.amsl.com (Postfix) with ESMTP id B718221F8B6C for ; Thu, 18 Aug 2011 10:20:49 -0700 (PDT) Received: from [172.16.42.3] (cpe-66-91-109-17.hawaii.res.rr.com [66.91.109.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc) by trantor.virtualized.org (Postfix) with ESMTPSA id 3F8E11703F; Thu, 18 Aug 2011 17:21:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20110818112522.GB22163@vacation.karoshi.com.> Date: Thu, 18 Aug 2011 07:21:36 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4e4a5da0.410dcc0a.0f19.6b20SMTPIN_ADDED@mx.google.com> <86AD8857-3E07-4A01-8AB0-02E832270C21@gmail.com> <20110816224930.GC14894@vacation.karoshi.com.> <6D7DCFB3-FD79-456C-ADE6-18966EBBF52E@virtualized.org> <20110818033644.GF19852@vacation.karoshi.com.> <0B4CF9B3-F42F-4E26-8087-B85C9E6B68F4@virtualized.org> <20110818112522.GB22163@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: dnsext@ietf.org Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:20:50 -0000 Bill, On Aug 18, 2011, at 1:25 AM, bmanning@vacation.karoshi.com wrote: > On Wed, Aug 17, 2011 at 07:02:45PM -1000, David Conrad wrote: >>> I had to put the code back into BIND when >>> ISC stripped it out, then had to fix DHCPv6 to work as DHCP was = designed to ... >>> so I have DDNS working when nodes are mobile and move between policy = domains. >> Other than your hacked BIND, is there any other implementation? > all versions of bind are hacked to some degree or other. I was making the distinction between what was = implemented/supported/promulgated by ISC and what was done outside of = ISC. > and not being a DNS server librarian, I have no idea what other > folks are using/doing - other than what gets seen on the wire. I'm trying to understand if there is a valid reason to keep A6 as = experimental or whether it should the experiment be declared over by = moving A6 to historic. As we figured out when the first A6 = implementation was being developed, yes, A6 can be made to work but it = introduces a tremendous number of potential nuclear land mines that = would make the DNS far more brittle than it already is (I'll admit I = still have a bit of bitterness about how all of this was handled). =20 As documented in 3364, A6 has many implications. If the work that you've = done contradicts those findings, that would be useful to know. If others = are working on A6 in a non-trivial fashion, that would also be of = interest.=20 Regards, -drc From johnl@iecc.com Thu Aug 18 11:05:31 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD47F21F8A7D for ; Thu, 18 Aug 2011 11:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epZZv1CL9QPN for ; Thu, 18 Aug 2011 11:05:31 -0700 (PDT) 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 0D5AD21F8A7A for ; Thu, 18 Aug 2011 11:05:21 -0700 (PDT) Received: (qmail 22844 invoked from network); 18 Aug 2011 18:06:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=593b.4e4d5497.k1108; bh=OVrVM725UKjYPQfvy71F9nQRCJiZNnrr73oV2ritwSI=; b=KgJ5lhiadlIPVPccS02/u4RvGN896ZajPxGZ0os1YLv+ibXwhaVDrcB/qmJoTwML2luj/GrWvhgfW2EFkNl+GA85LtFfzVIiaVEHZl4nmmpPoRShhk3jUe/uF6hF/eqGArUoJmVeqs4wcO34Bqj4fbjERxLUylH/QNbLIyPKQ0M= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Aug 2011 18:05:53 -0000 Date: 18 Aug 2011 14:06:15 -0400 Message-ID: From: "John R. Levine" To: "Jim Reid" In-Reply-To: <02B1DC14-4969-4BA3-8364-4F584A1E8369@rfc1035.com> References: <20110818032224.45073.qmail@joyce.lan> <02B1DC14-4969-4BA3-8364-4F584A1E8369@rfc1035.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] An RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 18:05:32 -0000 >> Hence my desire to make it easier to update them to do so. > > I don't see the point quite frankly. I doubt anyone will use such a beast if > it existed because the control panels and what have you that are in use today > are unlikely to ever be replaced or dragged out of the Stone Age. You many be right, but that doesn't seem like a reason not to offer a path to make them relatively future-resistant, rather than patching each time there's a new RR. > Anyhow, further discussion of these provisioning systems isn't needed IMO. > Just write up an I-D on your proposed extension language (or gather a set of > requirements). A proper document is the obvious starting point for a > meaningful discussion. I'm happy to do that, but there's not much point if people will just insist that either provisioning isn't a problem, or it's too grubby for DNSEXT to think about. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From ajs@anvilwalrusden.com Thu Aug 18 11:33:12 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB7821F8BAA for ; Thu, 18 Aug 2011 11:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dgD65NG7vTs for ; Thu, 18 Aug 2011 11:33:11 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7961F21F8BA2 for ; Thu, 18 Aug 2011 11:33:11 -0700 (PDT) Received: from shinkuro.com (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 mail.yitter.info (Postfix) with ESMTPSA id 789FB1ECB41C for ; Thu, 18 Aug 2011 18:34:06 +0000 (UTC) Date: Thu, 18 Aug 2011 14:34:14 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110818183413.GA29289@shinkuro.com> References: <20110818032224.45073.qmail@joyce.lan> <02B1DC14-4969-4BA3-8364-4F584A1E8369@rfc1035.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] An RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 18:33:12 -0000 On Thu, Aug 18, 2011 at 02:06:15PM -0400, John R. Levine wrote: > I'm happy to do that, but there's not much point if people will just > insist that either provisioning isn't a problem, or it's too grubby > for DNSEXT to think about. Speaking personally, I think it _is_ a problem and I am willing to review such a draft. Speaking as a co-chair but without having conferred with Olafur, I'm not totally sure this is something that would fit correctly in DNSEXT's charter, since this is in support of wire changes instead of a protocol issue _per se_. This might actually be DNSOP fodder instead. We can have a jurisdiction fight after there's a draft, however. A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Thu Aug 18 11:48:05 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCA921F8B42 for ; Thu, 18 Aug 2011 11:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.899 X-Spam-Level: X-Spam-Status: No, score=-110.899 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuiOhPqC59tL for ; Thu, 18 Aug 2011 11:48:05 -0700 (PDT) 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 5887F21F8B34 for ; Thu, 18 Aug 2011 11:48:05 -0700 (PDT) Received: (qmail 23193 invoked from network); 18 Aug 2011 18:48:59 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 18 Aug 2011 18:48:59 -0000 Received: (qmail 18531 invoked from network); 18 Aug 2011 18:48:59 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Aug 2011 18:48:59 -0000 Date: 18 Aug 2011 18:48:36 -0000 Message-ID: <20110818184836.39866.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: <20110818183413.GA29289@shinkuro.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dnsext] An RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 18:48:06 -0000 In article <20110818183413.GA29289@shinkuro.com> you write: >On Thu, Aug 18, 2011 at 02:06:15PM -0400, John R. Levine wrote: >> I'm happy to do that, but there's not much point if people will just >> insist that either provisioning isn't a problem, or it's too grubby >> for DNSEXT to think about. > >Speaking personally, I think it _is_ a problem and I am willing to >review such a draft. Oh, good. I'll go write something, with luck by the end of next week. R's, John From msk@cloudmark.com Thu Aug 18 12:18:05 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F6311E80A3 for ; Thu, 18 Aug 2011 12:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.557 X-Spam-Level: X-Spam-Status: No, score=-103.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LO2reakKOrO2 for ; Thu, 18 Aug 2011 12:18:04 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9355211E808C for ; Thu, 18 Aug 2011 12:18:04 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 18 Aug 2011 12:18:59 -0700 From: "Murray S. Kucherawy" To: Andrew Sullivan , "dnsext@ietf.org" Date: Thu, 18 Aug 2011 12:18:58 -0700 Thread-Topic: [dnsext] An RRTYPE extension language Thread-Index: Acxd1W+bnM0fK+A7TVGvcEZFashqFwABjRRg Message-ID: References: <20110818032224.45073.qmail@joyce.lan> <02B1DC14-4969-4BA3-8364-4F584A1E8369@rfc1035.com> <20110818183413.GA29289@shinkuro.com> In-Reply-To: <20110818183413.GA29289@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dnsext] An RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 19:18:05 -0000 > -----Original Message----- > From: dnsext-bounces@ietf.org [mailto:dnsext-bounces@ietf.org] On Behalf = Of Andrew Sullivan > Sent: Thursday, August 18, 2011 11:34 AM > To: dnsext@ietf.org > Subject: Re: [dnsext] An RRTYPE extension language >=20 > > I'm happy to do that, but there's not much point if people will just > > insist that either provisioning isn't a problem, or it's too grubby > > for DNSEXT to think about. >=20 > Speaking personally, I think it _is_ a problem and I am willing to > review such a draft. Ditto. -MSK From bmanning@karoshi.com Thu Aug 18 13:21:23 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F84921F8ABB for ; Thu, 18 Aug 2011 13:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.335 X-Spam-Level: X-Spam-Status: No, score=-5.335 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI7uu26jr-SS for ; Thu, 18 Aug 2011 13:21:22 -0700 (PDT) Received: from vacation.karoshi.com (unknown [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id B554521F85F2 for ; Thu, 18 Aug 2011 13:21:21 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7IHbeCD022967; Thu, 18 Aug 2011 17:37:40 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7IHbd7O022966; Thu, 18 Aug 2011 17:37:39 GMT Date: Thu, 18 Aug 2011 17:37:38 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Message-ID: <20110818173738.GD22163@vacation.karoshi.com.> References: <4e4a5da0.410dcc0a.0f19.6b20SMTPIN_ADDED@mx.google.com> <86AD8857-3E07-4A01-8AB0-02E832270C21@gmail.com> <20110816224930.GC14894@vacation.karoshi.com.> <6D7DCFB3-FD79-456C-ADE6-18966EBBF52E@virtualized.org> <20110818033644.GF19852@vacation.karoshi.com.> <0B4CF9B3-F42F-4E26-8087-B85C9E6B68F4@virtualized.org> <20110818112522.GB22163@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, dnsext@ietf.org Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 20:21:23 -0000 On Thu, Aug 18, 2011 at 07:21:36AM -1000, David Conrad wrote: > Bill, > > On Aug 18, 2011, at 1:25 AM, bmanning@vacation.karoshi.com wrote: > > On Wed, Aug 17, 2011 at 07:02:45PM -1000, David Conrad wrote: > >>> I had to put the code back into BIND when > >>> ISC stripped it out, then had to fix DHCPv6 to work as DHCP was designed to ... > >>> so I have DDNS working when nodes are mobile and move between policy domains. > >> Other than your hacked BIND, is there any other implementation? > > all versions of bind are hacked to some degree or other. > > I was making the distinction between what was implemented/supported/promulgated by ISC and what was done outside of ISC. fair enough. in my thinking, BIND stopped being BIND when it left Berkeley ... there is the ISC varient. :) > > and not being a DNS server librarian, I have no idea what other > > folks are using/doing - other than what gets seen on the wire. > > I'm trying to understand if there is a valid reason to keep A6 as experimental or whether it should the experiment be declared over by moving A6 to historic. As we figured out when the first A6 implementation was being developed, yes, A6 can be made to work but it introduces a tremendous number of potential nuclear land mines that would make the DNS far more brittle than it already is (I'll admit I still have a bit of bitterness about how all of this was handled). well, bitstrings was a kewl idea that was -very- (too) hard to wrap an operational practice around - a blunt force way to "fix" bitwise delegation in the reverse tree. A6, done properly, would have been the ideal way to support renumbering. > As documented in 3364, A6 has many implications. If the work that you've done contradicts those findings, that would be useful to know. If others are working on A6 in a non-trivial fashion, that would also be of interest. I think Ed has clarified a defenseable arguement for moving to historic... the latency of nested lookups (sort of like chasing validation) is reason enough to move to historic ... UNLESS we can practically move to a situation where there is a full IMR instead of a stub in each endsystem. Then a cohesive arguement can be made to revisit the base assumptions of 3364 /bill > > Regards, > -drc > From bmanning@karoshi.com Thu Aug 18 13:21:23 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF48E21F8ABB for ; Thu, 18 Aug 2011 13:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.306 X-Spam-Level: X-Spam-Status: No, score=-5.306 tagged_above=-999 required=5 tests=[AWL=-0.811, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH-3wxHFYFtj for ; Thu, 18 Aug 2011 13:21:23 -0700 (PDT) Received: from vacation.karoshi.com (unknown [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id B7F5921F8A7D for ; Thu, 18 Aug 2011 13:21:22 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7IBMYCD022369; Thu, 18 Aug 2011 11:22:34 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7IBMTOO022368; Thu, 18 Aug 2011 11:22:29 GMT Date: Thu, 18 Aug 2011 11:22:29 +0000 From: bmanning@vacation.karoshi.com To: Edward Lewis Message-ID: <20110818112229.GA22163@vacation.karoshi.com.> References: <5D36713D8A4E7348A7E10DF7437A4B920123583F@SZXEML506-MBS.china.huawei.com> <20043.29672.301202.173099@guava.gson.org> <4C8E59A2-28A2-408D-96CC-E084ED37D96F@rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "dnsext@ietf.org" , Ralph Droms Subject: Re: [dnsext] brief personal opinion on A6 status X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 20:21:24 -0000 Ed, This "lesson learned" is a credible reason to move the RR to historic. If this is the rational Ralph wants to use - then I can back its move. If its just "some people are confused" then thats not good enough for me. Thanks for the cogent arguement. /bill On Wed, Aug 17, 2011 at 09:18:08AM -0400, Edward Lewis wrote: > A6, as with a handful of other lame duck types, should be marked > historic with the meaning being "here's the definition of the syntax > and semantics but it is not required for general purpose > implementations and is considered to be obsolete." Other > dead-on-arrival types include SINK which lives on in the IANA > registry and in harder-to-find expired drafts. > > As far as A6, saying "it's in use" is a weak excuse. Many old, old > versions of BIND asked for it and some active name servers have not > been upgraded for a long time. I'm all for moving A6 to historic > because it can be dangerous to the protocol. > > When A6 was moved to experimental following the London IETF meeting > in summer 2001, I had two negative thoughts about A6 despite > originally thinking it was a really cool answer to renumbering > problems. > > One, no one was able to ever "white board" a scenario showing the > concept working in front of a small crowd without making a mistake. > That it, it did not pass a sniff test of being a simple enough to > explain or operate mechanism. > > Two, it could be a denial of service attack vector by inducing a > resolver into a long-lived "loop" trying to find all of the fragments > of the address needed to assemble the 128 bits. Fragments weren't > guaranteed to line up, so a resolver might find conflicting portions > of the address. Even if it seemed it was ultimately guaranteed to > find an address, the work to get there (including the needed network > queries) could be considerable. > > The lesson learned from the A6 experiment was that the data model of > DNS had to stick to simple records to preserve the speed feature of > DNS. The lesson also applied to DNSSEC, affirming[*] that > simplifying the default authorization model (the signer domain name > in the RRSIG ought to be the zone) was a right step. Ever since then > we have been trying to make sure the resolver's work is minimized. > > [*] I'm not saying this led to RFC 3008, as RFC 3008 was published > nearly a year earlier. But it made the restriction more significant. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > I'm overly entertained. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From bmanning@karoshi.com Thu Aug 18 13:21:24 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE70A21F8A7D for ; Thu, 18 Aug 2011 13:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.279 X-Spam-Level: X-Spam-Status: No, score=-5.279 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QixKZvBu4ZLr for ; Thu, 18 Aug 2011 13:21:23 -0700 (PDT) Received: from vacation.karoshi.com (unknown [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 31CCC21F8A97 for ; Thu, 18 Aug 2011 13:21:23 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7IBPNCD022377; Thu, 18 Aug 2011 11:25:23 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7IBPMoE022376; Thu, 18 Aug 2011 11:25:22 GMT Date: Thu, 18 Aug 2011 11:25:22 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Message-ID: <20110818112522.GB22163@vacation.karoshi.com.> References: <4e4a5da0.410dcc0a.0f19.6b20SMTPIN_ADDED@mx.google.com> <86AD8857-3E07-4A01-8AB0-02E832270C21@gmail.com> <20110816224930.GC14894@vacation.karoshi.com.> <6D7DCFB3-FD79-456C-ADE6-18966EBBF52E@virtualized.org> <20110818033644.GF19852@vacation.karoshi.com.> <0B4CF9B3-F42F-4E26-8087-B85C9E6B68F4@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0B4CF9B3-F42F-4E26-8087-B85C9E6B68F4@virtualized.org> User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, dnsext@ietf.org Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 20:21:24 -0000 On Wed, Aug 17, 2011 at 07:02:45PM -1000, David Conrad wrote: > Bill, > > > > I had to put the code back into BIND when > > ISC stripped it out, then had to fix DHCPv6 to work as DHCP was designed to ... > > so I have DDNS working when nodes are mobile and move between policy domains. > > Other than your hacked BIND, is there any other implementation? all versions of bind are hacked to some degree or other. i just put back in the code that ISC had in there in the first place. its not (yet) a bespoke DNS authoritative server. and not being a DNS server librarian, I have no idea what other folks are using/doing - other than what gets seen on the wire. /bill > > Regards, > -drc > From bmanning@karoshi.com Thu Aug 18 13:25:59 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE14421F8AE6 for ; Thu, 18 Aug 2011 13:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.254 X-Spam-Level: X-Spam-Status: No, score=-5.254 tagged_above=-999 required=5 tests=[AWL=-0.759, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkI9mt5CIr5d for ; Thu, 18 Aug 2011 13:25:59 -0700 (PDT) Received: from vacation.karoshi.com (unknown [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7908E21F8591 for ; Thu, 18 Aug 2011 13:25:57 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7I3akCD021070; Thu, 18 Aug 2011 03:36:47 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7I3aiAD021069; Thu, 18 Aug 2011 03:36:44 GMT Date: Thu, 18 Aug 2011 03:36:44 +0000 From: bmanning@vacation.karoshi.com To: David Conrad Message-ID: <20110818033644.GF19852@vacation.karoshi.com.> References: <4e4a5da0.410dcc0a.0f19.6b20SMTPIN_ADDED@mx.google.com> <86AD8857-3E07-4A01-8AB0-02E832270C21@gmail.com> <20110816224930.GC14894@vacation.karoshi.com.> <6D7DCFB3-FD79-456C-ADE6-18966EBBF52E@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6D7DCFB3-FD79-456C-ADE6-18966EBBF52E@virtualized.org> User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com, dnsext@ietf.org Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 20:25:59 -0000 On Wed, Aug 17, 2011 at 12:55:06PM -1000, David Conrad wrote: > On Aug 16, 2011, at 12:49 PM, bmanning@vacation.karoshi.com wrote: > > it may not have any real value to some, but it apparently does to a statistically visiable community. > > > The fact that root servers are receiving A6 queries does not necessarily imply A6 has value. certainly not to the roots. but they have to field all kinds of stray/orphaned queries. properly considered, roots should not get A queries either. > > but as an actual user of the code point, > > How are you using it? for doing IPv6 prefix renumbering. I had to put the code back into BIND when ISC stripped it out, then had to fix DHCPv6 to work as DHCP was designed to ... so I have DDNS working when nodes are mobile and move between policy domains. /bill > > Regards, > -drc > From mohta@necom830.hpcl.titech.ac.jp Thu Aug 18 14:05:34 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7ED721F8B8A for ; Thu, 18 Aug 2011 14:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.069 X-Spam-Level: X-Spam-Status: No, score=0.069 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-qk2nMibjRJ for ; Thu, 18 Aug 2011 14:05:34 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id D610A21F8B89 for ; Thu, 18 Aug 2011 14:05:33 -0700 (PDT) Received: (qmail 29992 invoked from network); 18 Aug 2011 21:07:45 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 18 Aug 2011 21:07:45 -0000 Message-ID: <4E4D7E7E.1070700@necom830.hpcl.titech.ac.jp> Date: Fri, 19 Aug 2011 06:05:02 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <8A34D894-4323-4948-811E-6568C838A503@nic.cz> In-Reply-To: <8A34D894-4323-4948-811E-6568C838A503@nic.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 21:05:34 -0000 Ondej Sur wrote: >> Are your examples essentially different from Brian Dickson's? > Much simpler. The DNSSEC signed zone is huge and with anycasts scattered > around the world downloading the zone from hidden master(s) I just don't > want the AXFR happen if it can be prevented. You fail to explain why the AXFR happens. > And there's a lot of stuff which can happen > on the master to forget the differences. I can see none. > The problem is that the 500MB zone * number of anycast slaves (25ish) is > 10 GB of data to transfer. Sure, I can just buy a really fat pipe, but > I am no friend of "throw more money" there solutions when we can have > simple protocol solution. The simplest solution is not to forget the differences. Masataka Ohta From johnl@iecc.com Thu Aug 18 22:04:08 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F54B21F862F for ; Thu, 18 Aug 2011 22:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.999 X-Spam-Level: X-Spam-Status: No, score=-110.999 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Md17kE7FOiUT for ; Thu, 18 Aug 2011 22:04:08 -0700 (PDT) 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 BF05A21F8620 for ; Thu, 18 Aug 2011 22:04:07 -0700 (PDT) Received: (qmail 26991 invoked from network); 19 Aug 2011 05:05:02 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 19 Aug 2011 05:05:02 -0000 Received: (qmail 674 invoked from network); 19 Aug 2011 05:05:02 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Aug 2011 05:05:02 -0000 Date: 19 Aug 2011 05:04:40 -0000 Message-ID: <20110819050440.21024.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 05:04:08 -0000 I was supposed to be doing something else tonight, so I wrote up a draft of my extension language thing instead. See http://www.ietf.org/id/draft-levine-dnsextlang-00.txt R's, John From ggm+ietf@apnic.net Thu Aug 18 22:10:21 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB7021F8514 for ; Thu, 18 Aug 2011 22:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdEiIW2vtbcg for ; Thu, 18 Aug 2011 22:10:20 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 72B6D21F86AA for ; Thu, 18 Aug 2011 22:10:20 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:9575:ffe5:641b:8b2b] (unknown [IPv6:2001:dc0:a000:4:9575:ffe5:641b:8b2b]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D79C4B67ED; Fri, 19 Aug 2011 01:11:11 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: <20110819050440.21024.qmail@joyce.lan> Date: Fri, 19 Aug 2011 15:11:11 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110819050440.21024.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1244.3) Cc: dnsext@ietf.org Subject: Re: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 05:10:21 -0000 On 19/08/2011, at 3:04 PM, John Levine wrote: > I was supposed to be doing something else tonight, so I wrote > up a draft of my extension language thing instead. See >=20 > http://www.ietf.org/id/draft-levine-dnsextlang-00.txt >=20 I think this is interesting. I think the main interest I have is that = its a formalism to describe the new RR, which could be done many ways: C = struct, ASN.1, (E)BNF. I think this is no worse than other ways, and it doesn't proscriptively = limit the SEMANTIC meaning of the new RR. I wonder if its going to be sufficiently extensible for forseeable = requirements. SRV for instance encodes structures like regex() which is = 'powerful' (ie complicated) But that aside, I found the draft readable, and interesting. I think this is worth discussion. -George From johnl@iecc.com Thu Aug 18 22:26:05 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E024611E8090 for ; Thu, 18 Aug 2011 22:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6p2T+iFOcwP8 for ; Thu, 18 Aug 2011 22:26:05 -0700 (PDT) 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 13C9E11E8082 for ; Thu, 18 Aug 2011 22:26:04 -0700 (PDT) Received: (qmail 27159 invoked from network); 19 Aug 2011 05:26:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=6a16.4e4df423.k1108; bh=L9bmiH+XKuJyqNSyThBEbZvrAyEHHx3Xe1FQOpe5AI8=; b=D9AoFcV4mKy8WXsqiNLad1AMhc6D7nVX0J8jK5QH4/hui2LHZx52pUaM6NQbehKDmN9zNck8oPAbqf/csOGaEGfq8pF4/PqNVPKZ+bPXOBS4lvEV7rkzAmcelmZLMD3RQM6lBm6gO53KZJxBoOAFcdBiLzezMEtY2cj8lxqIGEk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Aug 2011 05:26:36 -0000 Date: 19 Aug 2011 01:26:58 -0400 Message-ID: From: "John R. Levine" To: "George Michaelson" In-Reply-To: References: <20110819050440.21024.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 05:26:06 -0000 > I wonder if its going to be sufficiently extensible for forseeable requirements. SRV for instance encodes structures like regex() which is 'powerful' (ie complicated) SRV is three integers and a domain name. Do you mean NAPTR? It includes a regex, but the regex isn't interpreted within the DNS, only by clients, so as far as the DNS is concerned, it's just a string. NAPTR:35 I2 I2 S S S N[A] I should probably emphasize that this isn't supposed to be the FUSRP*. Some RRs require that the DNS server do something new, so if for example we added a BNAME record, it'd be easy enough to describe the syntax, but that wouldn't tell the DNS server about all the new synthesis rules. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly * - Final Ultimate Solution to the RRTYPE Problem From ggm+ietf@apnic.net Thu Aug 18 22:30:04 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B5711E8090 for ; Thu, 18 Aug 2011 22:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.733 X-Spam-Level: X-Spam-Status: No, score=-101.733 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aKL5UiCw+G1 for ; Thu, 18 Aug 2011 22:30:04 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 31A5B11E8082 for ; Thu, 18 Aug 2011 22:30:04 -0700 (PDT) Received: from dynamic161.apnic.net (dynamic161.apnic.net [203.119.42.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A9FC0B675C; Fri, 19 Aug 2011 01:30:59 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: George Michaelson In-Reply-To: Date: Fri, 19 Aug 2011 15:30:59 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <19EAC368-BB0B-4171-9747-1BBD7C7C86F8@apnic.net> References: <20110819050440.21024.qmail@joyce.lan> To: John R. Levine X-Mailer: Apple Mail (2.1244.3) Cc: dnsext@ietf.org Subject: Re: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 05:30:04 -0000 On 19/08/2011, at 3:26 PM, John R. Levine wrote: >> I wonder if its going to be sufficiently extensible for forseeable = requirements. SRV for instance encodes structures like regex() which is = 'powerful' (ie complicated) >=20 > SRV is three integers and a domain name. Do you mean NAPTR? It = includes a regex, but the regex isn't interpreted within the DNS, only = by clients, so as far as the DNS is concerned, it's just a string. >=20 > NAPTR:35 I2 I2 S S S N[A] >=20 Yes I meant NAPTR. And, as you say... > I should probably emphasize that this isn't supposed to be the FUSRP*. = Some RRs require that the DNS server do something new, so if for example = we added a BNAME record, it'd be easy enough to describe the syntax, but = that wouldn't tell the DNS server about all the new synthesis rules. its descriptive only, in a structural Octet-level-encoding sense.=20 >=20 > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for = Dummies", > Please consider the environment before reading this e-mail. = http://jl.ly >=20 > * - Final Ultimate Solution to the RRTYPE Problem I really hate use of the words Final and Solution in one sentence. we've = both just aquired a huge amount of Baysian for Godwin filters. -G From ondrej.sury@nic.cz Fri Aug 19 00:28:35 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D80721F86B6 for ; Fri, 19 Aug 2011 00:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.025 X-Spam-Level: X-Spam-Status: No, score=-1.025 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiP6LLdeDOXz for ; Fri, 19 Aug 2011 00:28:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3436421F86AC for ; Fri, 19 Aug 2011 00:28:22 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:d03d:a0:8f9b:2ed1] (unknown [IPv6:2001:1488:ac14:1400:d03d:a0:8f9b:2ed1]) by mail.nic.cz (Postfix) with ESMTPSA id AA1542A2CC3; Fri, 19 Aug 2011 09:28:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1313738936; bh=rwGOtJO7Vzk/px0TbY78vW16M8GOPt4+mGXksU+9Y6Y=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=J189nFUD3hx6At2aC8xEbBtFN5b3e4xtViGd8Cqw0mXZ12M/v+gnx0pVrGnUaYmbS OPh3gCx6FNI0/OjfJzR2WDnQYaYijhK7oDPsPzgYgjB52gy4mhBs5P91DgymSo/Qr6 4Y03sGHRCk/Z+oVa2lrZyxw+1Yu/IDhDBAnRvIKc= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4E4D7E7E.1070700@necom830.hpcl.titech.ac.jp> Date: Fri, 19 Aug 2011 09:28:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <8A34D894-4323-4948-811E-6568C838A503@nic.cz> <4E4D7E7E.1070700@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 07:28:35 -0000 On 18. 8. 2011, at 23:05, Masataka Ohta wrote: > Ondej Sur wrote: >=20 >>> Are your examples essentially different from Brian Dickson's? >=20 >> Much simpler. The DNSSEC signed zone is huge and with anycasts = scattered >> around the world downloading the zone from hidden master(s) I just = don't >> want the AXFR happen if it can be prevented. >=20 > You fail to explain why the AXFR happens. >> And there's a lot of stuff which can happen >> on the master to forget the differences. >=20 > I can see none. =46rom an operational experience, I see a lot. You can run out of = memory, out of disk space, on disk journal can get corrupt (yes this happens), DNS software can (and will) have other bugs, people can make mistakes. Yes, all of this happens in the real world. >> The problem is that the 500MB zone * number of anycast slaves (25ish) = is >> 10 GB of data to transfer. Sure, I can just buy a really fat pipe, = but >> I am no friend of "throw more money" there solutions when we can have >> simple protocol solution. >=20 > The simplest solution is not to forget the differences. =46rom the pure theoretical view point, yes. =46rom the operational = view, I cannot agree with you. You seem to operate on the grounds that the run environment is perfect, the software is bug free, the people don't make mistakes. The operational experience don't concur with that view. Simply put, I see this as an design flaw in the original IXFR. The decision on whether to do an AXFR-style IXFR or not should be the decision of the slave (the client) and not the master server. It should not be the decision of the server whether to send a few megabytes of differences (IXFR) or hundreds of megabytes (AXFR-style). The IXFR-only is a simple solution to remedy this problem. It is backwards compatible with existing servers and clients, nobody is forced to use it, yet you are strongly opposed claiming that it's not needed. Even though at least mine and Shane's experience with the operations of big-to-huge zones differ. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From mohta@necom830.hpcl.titech.ac.jp Fri Aug 19 00:49:08 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE4221F8742 for ; Fri, 19 Aug 2011 00:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.074 X-Spam-Level: X-Spam-Status: No, score=0.074 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76c-PntvaQ5p for ; Fri, 19 Aug 2011 00:49:07 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 52EAC21F8922 for ; Fri, 19 Aug 2011 00:49:05 -0700 (PDT) Received: (qmail 37416 invoked from network); 19 Aug 2011 07:51:37 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 19 Aug 2011 07:51:37 -0000 Message-ID: <4E4E1576.7020803@necom830.hpcl.titech.ac.jp> Date: Fri, 19 Aug 2011 16:49:10 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <8A34D894-4323-4948-811E-6568C838A503@nic.cz> <4E4D7E7E.1070700@necom830.hpcl.titech.ac.jp> <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz> In-Reply-To: <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 07:49:08 -0000 Ondej Sur wrote: >> You fail to explain why the AXFR happens. >>> And there's a lot of stuff which can happen >>> on the master to forget the differences. >> I can see none. > From an operational experience, I see a lot. You can run out of memory, > out of disk space, on disk journal can get corrupt (yes this happens), > DNS software can (and will) have other bugs, people can make mistakes. > Yes, all of this happens in the real world. You are saying people can't properly operate a simple system. Then, the solution can not be something to make the system more complex. >> The simplest solution is not to forget the differences. > From the pure theoretical view point, yes. From the operational view, I'm talking from the operational view point. > The IXFR-only is a simple solution to remedy this problem. It is not. Masataka Ohta From fanf2@hermes.cam.ac.uk Fri Aug 19 02:57:53 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBDF21F880C for ; Fri, 19 Aug 2011 02:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMZaXiSo6ugl for ; Fri, 19 Aug 2011 02:57:52 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0BE21F8802 for ; Fri, 19 Aug 2011 02:57:52 -0700 (PDT) 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-2.csi.cam.ac.uk ([131.111.8.54]:44163) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1QuLqh-0002TL-Eh (Exim 4.72) (return-path ); Fri, 19 Aug 2011 10:58:47 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QuLqh-00074t-Ha (Exim 4.67) (return-path ); Fri, 19 Aug 2011 10:58:47 +0100 Date: Fri, 19 Aug 2011 10:58:47 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: John Levine In-Reply-To: <20110819050440.21024.qmail@joyce.lan> Message-ID: References: <20110819050440.21024.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: dnsext@ietf.org Subject: Re: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 09:57:53 -0000 John Levine wrote: > I was supposed to be doing something else tonight, so I wrote > up a draft of my extension language thing instead. See > > http://www.ietf.org/id/draft-levine-dnsextlang-00.txt I think this is an interesting idea. For auto-provisioning user interfaces I think you need a description for each field, e.g. MX:15 I2 Priority N[A,C] Mail server SRV:33 I2 Priority I2 Weight I2 Port N[A] Server Tony. -- f.anthony.n.finch http://dotat.at/ Bailey: Southeast becoming cyclonic 5 to 7, increasing gale 8 for a time. Moderate or rough, becoming very rough or high later. Rain or showers. Moderate or good, occasionally poor. From s.posner@telekom.de Fri Aug 19 05:54:48 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8E121F8AEA for ; Fri, 19 Aug 2011 05:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAgdO73Fdm9w for ; Fri, 19 Aug 2011 05:54:48 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id CDB0221F8AE9 for ; Fri, 19 Aug 2011 05:54:47 -0700 (PDT) Received: from g8dbse01.krf01.telekom.de ([164.23.31.9]) by tcmail51.telekom.de with ESMTP; 19 Aug 2011 14:54:59 +0200 Received: from QEO40064.de.t-online.corp (QEO40064.de.t-online.corp [10.224.209.64]) by G8DBSE01.krf01.telekom.de with ESMTP; Fri, 19 Aug 2011 14:54:59 +0200 Received: from QEO40072.de.t-online.corp ([169.254.1.155]) by QEO40064.de.t-online.corp ([10.224.209.64]) with mapi; Fri, 19 Aug 2011 14:54:59 +0200 From: "Posner, Sebastian" To: John Levine , "dnsext@ietf.org" Date: Fri, 19 Aug 2011 14:54:56 +0200 Thread-Topic: [dnsext] Draft of an RRTYPE extension language Thread-Index: AcxeLbr4jduRWcjcR4WNWqlMcueFWwAP9uxg Message-Id: <63366D5A116E514AA4A9872D3C533539570853015F@QEO40072.de.t-online.corp> References: <20110819050440.21024.qmail@joyce.lan> In-Reply-To: <20110819050440.21024.qmail@joyce.lan> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 12:54:48 -0000 John Levine wrote: > I was supposed to be doing something else tonight, so I wrote > up a draft of my extension language thing instead. See >=20 > http://www.ietf.org/id/draft-levine-dnsextlang-00.txt I think I'd like to see a qualifier for N that restricts the contained Domain Name to be something that *directly* leads to an address-RR, as required e.g. for the "target"=20 of SRV-Records (http://tools.ietf.org/html/rfc2782). Kind regards, Sebastian -- Sebastian Posner Unix-Systemspezialist AM Data Center Services, Shared Infrastructure Deutsche Telekom AG, Products & Innovation From ondrej.sury@nic.cz Fri Aug 19 07:58:17 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE3A21F8802 for ; Fri, 19 Aug 2011 07:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o80XC4cCunXL for ; Fri, 19 Aug 2011 07:58:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8CC21F86E0 for ; Fri, 19 Aug 2011 07:58:14 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:d03d:a0:8f9b:2ed1] (unknown [IPv6:2001:1488:ac14:1400:d03d:a0:8f9b:2ed1]) by mail.nic.cz (Postfix) with ESMTPSA id 9245F2A288E; Fri, 19 Aug 2011 16:58:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1313765927; bh=9e11HXN0VRIhgprehmmcDQ7PUy4GhoOsMDRS5XAmxhg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rvD9xEZGoNq9BNbIdGaSRdnccWrVVxW/Z8BDGkjoGZK95slIrenInXbN26DD7f0vs w2gJnCiPj8j+qJGVF7+l1XbbX4J12XsCHabD9LvQzoem/UMXVAtWncONKHBcLprtQs iMNr5c1YRyZOY4YfBM1BPrzSFhrCBxKGdPb4OYGA= Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <4E4E1576.7020803@necom830.hpcl.titech.ac.jp> Date: Fri, 19 Aug 2011 16:58:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3F00A878-2637-4DC2-8180-ECD293A82966@nic.cz> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <8A34D894-4323-4948-811E-6568C838A503@nic.cz> <4E4D7E7E.1070700@necom830.hpcl.titech.ac.jp> <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz> <4E4E1576.7020803@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1244.3) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 14:58:17 -0000 On 19. 8. 2011, at 9:49, Masataka Ohta wrote: > > The IXFR-only is a simple solution to remedy this problem. >=20 > It is not. Then I would say that we cannot come to agreement and it seems to be pointless to continue the discussion. The standard IETF mechanisms (consensus of the WG) would decide whether the WG wants to have IXFR-ONLY or not. I am not going to push this forward if the WG doesn't want to adopt this mechanism. O. -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From johnl@iecc.com Fri Aug 19 08:01:01 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2211221F8AF9 for ; Fri, 19 Aug 2011 08:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJMjdpmSCxNC for ; Fri, 19 Aug 2011 08:01:00 -0700 (PDT) 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 67E1821F8AF8 for ; Fri, 19 Aug 2011 08:01:00 -0700 (PDT) Received: (qmail 31384 invoked from network); 19 Aug 2011 15:01:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=7a97.4e4e7ae4.k1108; bh=qtoitMaB3mCMx3rIl9SZw9Gn6dXSWQDgruKCuNAn1/g=; b=tc2mWbsLTc93hMbrvoHyNpSQf5UMKnXlIyKID0S6j1aYgsId0/scPMT89SvWefItYgrXIk/ckdtOlzNH1lkynX4UpQz2gsYrZWkoMbhS5DXk/j05XM5xacd/l7cm+54kGVTCF6bYyme9JFFB7OVucf+0ItQ/BCSFhv8wWp6pyCw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Aug 2011 15:01:34 -0000 Date: 19 Aug 2011 11:01:56 -0400 Message-ID: From: "John R. Levine" To: "Tony Finch" In-Reply-To: References: <20110819050440.21024.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dnsext@ietf.org Subject: Re: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 15:01:01 -0000 > For auto-provisioning user interfaces I think you need a description for > each field, e.g. I had the same thought about five minutes after I posted the draft. Will try and work up a revised version. R's, John From johnl@iecc.com Fri Aug 19 08:14:05 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340AB21F8922 for ; Fri, 19 Aug 2011 08:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7v8ncGzBexxL for ; Fri, 19 Aug 2011 08:14:04 -0700 (PDT) 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 050C621F86CA for ; Fri, 19 Aug 2011 08:14:03 -0700 (PDT) Received: (qmail 31464 invoked from network); 19 Aug 2011 15:15:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=7ae7.4e4e7df4.k1108; bh=bro6tbkC+GsP9bwrih8rTg85GwJhOGigDR0DJ8ZvUyE=; b=YABgdblTkDvB4IYoV5EOJYKlgMWWCNUp9NCL11AqZNGOxQlhhr9TRNO+UctWnpnQVBgC1MP3BlaZptN36A6972+uNSFceopV4ZJghPLKvxq1wmbdn0oAMuMUTxjwDGXRM/FJU5lqftK8dwylvZtMHQ3lb+phgcdHf5MBoWjkCyk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Aug 2011 15:14:38 -0000 Date: 19 Aug 2011 11:15:00 -0400 Message-ID: From: "John R. Levine" To: "Posner, Sebastian" In-Reply-To: <63366D5A116E514AA4A9872D3C533539570853015F@QEO40072.de.t-online.corp> References: <20110819050440.21024.qmail@joyce.lan> <63366D5A116E514AA4A9872D3C533539570853015F@QEO40072.de.t-online.corp> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 15:14:05 -0000 > I think I'd like to see a qualifier for N that restricts > the contained Domain Name to be something that *directly* > leads to an address-RR, as required e.g. for the "target" > of SRV-Records (http://tools.ietf.org/html/rfc2782). You can't enforce that -- even if the target is OK now, someone might change it later, and if I'm editing records in a provisioning system, I might enter the SRV record before the A records it points to. We can also have an argument about whether anyone still cares about that rule in a more than hypothetical way, but not here, please. I suppose there might be some value in assertions that a provisioning system or DNS server could check to warn about semantic errors, but I do not want to fall down the slippery slope to reimplementing the entire DNS in an interpreter. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From benc@hawaga.org.uk Fri Aug 19 10:36:50 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255E221F8B8C for ; Fri, 19 Aug 2011 10:36:50 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYRe+mdZ0AB3 for ; Fri, 19 Aug 2011 10:36:49 -0700 (PDT) Received: from paella.hawaga.org.uk (paella.hawaga.org.uk [IPv6:2001:470:1f0f:784::3]) by ietfa.amsl.com (Postfix) with ESMTP id 70ADF21F85CE for ; Fri, 19 Aug 2011 10:36:49 -0700 (PDT) Received: from [192.168.1.33] (195-240-105-186.ip.telfort.nl [195.240.105.186]) (authenticated bits=0) by paella.hawaga.org.uk (8.14.2/8.14.2/Debian-2build1) with ESMTP id p7JHbbHx018614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Aug 2011 17:37:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hawaga.org.uk; s=kent; t=1313775460; bh=Qivxk6PSE7jCvcDl+6d0Q/w4PIxtZVxV8ejbThAzi/w=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=nnPsCskFrHqo XWJfecT9pqwt7UOh0H2mIhZ3nwk/i214K/CkEKL5A8tY9zm1+uaTzJn80hkd98ejU1i 2PA+Dq7PwxYRGGbams58t0XNJ52Qk/zl+Eei8+mI4ipzxd1sOvNyz58unIPZYjiTvY4 SwHmkFV9lR+AeHtmDl4E1heNA= Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Clifford In-Reply-To: Date: Fri, 19 Aug 2011 19:37:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <530A0726-D5A6-43FA-9B15-AFB80DFF5B38@hawaga.org.uk> References: <20110819050440.21024.qmail@joyce.lan> <63366D5A116E514AA4A9872D3C533539570853015F@QEO40072.de.t-online.corp> To: "John R. Levine" X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (paella.hawaga.org.uk [174.143.245.7]); Fri, 19 Aug 2011 17:37:40 +0000 (UTC) Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 17:36:50 -0000 On Aug 19, 2011, at 5:15 PM, John R. Levine wrote: >=20 > You can't enforce that -- even if the target is OK now, someone might = change it later, and if I'm editing records in a provisioning system, I = might enter the SRV record before the A records it points to. =20 If this draft is aimed squarely at provisioning systems, then the = compression and additional record processing flags are irrelevant. (If = its aimed more to "encapsulate the machine usable pieces of the defining = RFC, whatever that machine may be", then not so...) It can still have some potentially useful advisory role that is still = machine checkable. (modulo the "does anyone care" that was mentioned = elsewhere) Human readable descriptions are advisory too although even less = enforceable (for example, try enforcing that the IP address in an A = record really is the address of the host I intend it to be). --=20 From johnl@iecc.com Fri Aug 19 14:59:12 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2469421F8B27 for ; Fri, 19 Aug 2011 14:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNwFUER4qenZ for ; Fri, 19 Aug 2011 14:59:11 -0700 (PDT) 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 4E6CC21F86AC for ; Fri, 19 Aug 2011 14:59:00 -0700 (PDT) Received: (qmail 34241 invoked from network); 19 Aug 2011 21:59:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=85c0.4e4edcdc.k1108; bh=2gUQKHlb778H5w0GG8JFy8rx8zetT8bVbzEueXSI5cE=; b=hQEVAfdXNZAagWtYOu3iJ/7tbm6bqQ0NX+WctAdqVHOFbzM95K1DXk7Bym8N2Ghjb09bUxs/JqODCCnZ0xx6FoAOS9XgTiNmqCBI91FaMx40FAB27ACvFcZy8OR3No3oj+YAbd2e4xLdoTElUYrKUSuWC651+CRzAVOq/1LPGRw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Aug 2011 21:59:34 -0000 Date: 19 Aug 2011 17:59:56 -0400 Message-ID: From: "John R. Levine" To: "Ben Clifford" In-Reply-To: <530A0726-D5A6-43FA-9B15-AFB80DFF5B38@hawaga.org.uk> References: <20110819050440.21024.qmail@joyce.lan> <63366D5A116E514AA4A9872D3C533539570853015F@QEO40072.de.t-online.corp> <530A0726-D5A6-43FA-9B15-AFB80DFF5B38@hawaga.org.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 21:59:12 -0000 >> You can't enforce that -- even if the target is OK now, someone might change it later, and if I'm editing records in a provisioning system, I might enter the SRV record before the A records it points to. > > If this draft is aimed squarely at provisioning systems, then the compression and additional record processing flags are irrelevant. (If its aimed more to "encapsulate the machine usable pieces of the defining RFC, whatever that machine may be", then not so...) My plan, which I think is expressed reasonably clearly in the draft, is that it's also aimed at authoritative server software, so they can handle new RRTYPEs without code changes and without having to sneak them in via hex escape codes. R's, John From mohta@necom830.hpcl.titech.ac.jp Fri Aug 19 15:51:21 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8728C21F8BC4 for ; Fri, 19 Aug 2011 15:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.857 X-Spam-Level: X-Spam-Status: No, score=0.857 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIh6jgJ0f36p for ; Fri, 19 Aug 2011 15:51:21 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id BFC8E21F8BC5 for ; Fri, 19 Aug 2011 15:51:20 -0700 (PDT) Received: (qmail 46828 invoked from network); 19 Aug 2011 22:53:55 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 19 Aug 2011 22:53:55 -0000 Message-ID: <4E4EE8C5.10607@necom830.hpcl.titech.ac.jp> Date: Sat, 20 Aug 2011 07:50:45 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: ondrej.sury@nic.cz References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <8A34D894-4323-4948-811E-6568C838A503@nic.cz> <4E4D7E7E.1070700@necom830.hpcl.titech.ac.jp> <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz> <4E4E1576.7020803@necom830.hpcl.titech.ac.jp> <3F00A878-2637-4DC2-8180-ECD293A82966@nic.cz> In-Reply-To: <3F00A878-2637-4DC2-8180-ECD293A82966@nic.cz> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 22:51:21 -0000 Ondej Sur wrote: >>> The IXFR-only is a simple solution to remedy this problem. >> >> It is not. > Then I would say that we cannot come to agreement and it seems to > be pointless to continue the discussion. It is simply impossible to make protocols fool proof against severe operational errors such as disk journal corruption. Attempts to do so will result in complicated protocols with a lot more operational problems. If you can't admit so, there can be no agreement, of course. Masataka Ohta From johnl@iecc.com Fri Aug 19 20:42:32 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D26E21F8B17 for ; Fri, 19 Aug 2011 20:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.049 X-Spam-Level: X-Spam-Status: No, score=-111.049 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1A7cq-5cZa2 for ; Fri, 19 Aug 2011 20:42:31 -0700 (PDT) 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 8CC5D21F8B14 for ; Fri, 19 Aug 2011 20:42:31 -0700 (PDT) Received: (qmail 36278 invoked from network); 20 Aug 2011 03:43:29 -0000 Received: from gal.iecc.com (64.57.183.53) by mail2.iecc.com with SMTP; 20 Aug 2011 03:43:29 -0000 Received: (qmail 31827 invoked from network); 20 Aug 2011 03:43:29 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Aug 2011 03:43:29 -0000 Date: 20 Aug 2011 03:43:07 -0000 Message-ID: <20110820034307.40907.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [dnsext] New Version Notification for draft-levine-dnsextlang-01.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 03:42:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension Language for the DNS Author(s) : John Levine Filename : draft-levine-dnsextlang-01.txt Pages : 8 Date : 2011-08-19 Adding new RRTYPEs to the DNS requires that DNS servers and provisioning software be upgraded to support each new RRTYPE in Master files. This document defines a DNS extension language intended to allow most new RRTYPEs to be supported by adding a line to a configuration file read by the DNS software, with no changed software. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levine-dnsextlang-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-levine-dnsextlang-01.txt From marka@isc.org Sun Aug 21 12:04:13 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80EE521F8B03 for ; Sun, 21 Aug 2011 12:04:13 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eipMmY4TSHd for ; Sun, 21 Aug 2011 12:04:13 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id E679E21F8770 for ; Sun, 21 Aug 2011 12:04:09 -0700 (PDT) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 9D92C5F98A2; Sun, 21 Aug 2011 19:04:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (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 3AB5C216C7B; Sun, 21 Aug 2011 19:04: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 A48151303A70; Mon, 22 Aug 2011 05:04:50 +1000 (EST) To: "John R. Levine" From: Mark Andrews References: <20110819050440.21024.qmail@joyce.lan> <63366D5A116E514AA4A9872D3C533539570853015F@QEO40072.de.t-online.corp> <530A0726-D5A6-43FA-9B15-AFB80DFF5B38@hawaga.org.uk> In-reply-to: Your message of "19 Aug 2011 17:59:56 -0400." Date: Mon, 22 Aug 2011 05:04:50 +1000 Message-Id: <20110821190450.A48151303A70@drugs.dv.isc.org> Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 19:04:13 -0000 In message , "John R. Levine" wr ites: > >> You can't enforce that -- even if the target is OK now, someone might chan > ge it later, and if I'm editing records in a provisioning system, I might ent > er the SRV record before the A records it points to. > > > > If this draft is aimed squarely at provisioning systems, then the compressi > on and additional record processing flags are irrelevant. (If its aimed more > to "encapsulate the machine usable pieces of the defining RFC, whatever that > machine may be", then not so...) > > My plan, which I think is expressed reasonably clearly in the draft, is > that it's also aimed at authoritative server software, so they can handle > new RRTYPEs without code changes and without having to sneak them in via > hex escape codes. Compression will NEVER happen with new records. What I do worry about this is that it will artificially limit new RR's to formats that can be expressed in this language. Also this doesn't have to be formalised. ISC's DHCP, for example, supports the defining new DHCP options in the DHCP server and client configurations. The older definition language doesn't support DNS encoding of domain names or AAAA addresses but I believe the newer one does. You will also need stuff like I2[LEN(F1),B] (2 byte int, length of field(#), not printed(B)). For this to be useful you need to be describing presentation to wire and some wire fields don't exist in the presentation. > R's, > John > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From paul.hoffman@vpnc.org Sun Aug 21 12:17:51 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CBC21F8B0A for ; Sun, 21 Aug 2011 12:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KPk8Qee4RsV for ; Sun, 21 Aug 2011 12:17:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0415A21F8B04 for ; Sun, 21 Aug 2011 12:17:50 -0700 (PDT) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p7LJIqFe023356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 21 Aug 2011 12:18:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Paul Hoffman In-Reply-To: <20110821190450.A48151303A70@drugs.dv.isc.org> Date: Sun, 21 Aug 2011 12:18:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110819050440.21024.qmail@joyce.lan> <63366D5A116E514AA4A9872D3C533539570853015F@QEO40072.de.t-online.corp> <530A0726-D5A6-43FA-9B15-AFB80DFF5B38@hawaga.org.uk> <20110821190450.A48151303A70@drugs.dv.isc.org> To: DNSEXT Working Group X-Mailer: Apple Mail (2.1244.3) Subject: Re: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 19:17:51 -0000 On Aug 21, 2011, at 12:04 PM, Mark Andrews wrote: > What I do worry about this is that it will artificially limit new > RR's to formats that can be expressed in this language. =20 Not at all. No one has to make their records work with the new language: = they can expect domain admins to still do hex-stuffing like they do = today. > Also this > doesn't have to be formalised. =20 Correct. Formalization is very useful, but not required. Sometimes work = in the DNSEXT WG is meant to be very useful even if not required. --Paul Hoffman From johnl@iecc.com Sun Aug 21 12:19:04 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B63521F8B14 for ; Sun, 21 Aug 2011 12:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZNL5rNvxiM3 for ; Sun, 21 Aug 2011 12:19:03 -0700 (PDT) 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 5479721F8B0A for ; Sun, 21 Aug 2011 12:19:03 -0700 (PDT) Received: (qmail 69311 invoked from network); 21 Aug 2011 19:20:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=10ebe.4e515a64.k1108; bh=r247XeqGGizo+6NtvyufAw2bsYB2rPIr4lTMQJjjbbQ=; b=SUyfnoUrFh5ppyls7NOy3QNo06wTxys45gn3mjo20cOBRj9RtaHRNy8Uxl5cdqG1F6uBOGEk+w82GC7Wh6h9wHlEjY4DlOCXt+15jr0Um5wKVqCOTgXxeSyeCTbtLBGG7UBCG4jtDLRCBEQBH/XNnEsIWIhSp6vBxb0Jgj7SIEk= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1) with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Aug 2011 19:19:42 -0000 Date: 21 Aug 2011 15:20:03 -0400 Message-ID: From: "John R. Levine" To: "Mark Andrews" In-Reply-To: <20110821190450.A48151303A70@drugs.dv.isc.org> References: <20110819050440.21024.qmail@joyce.lan> <63366D5A116E514AA4A9872D3C533539570853015F@QEO40072.de.t-online.corp> <530A0726-D5A6-43FA-9B15-AFB80DFF5B38@hawaga.org.uk> <20110821190450.A48151303A70@drugs.dv.isc.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Draft of an RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 19:19:04 -0000 >> My plan, which I think is expressed reasonably clearly in the draft, is >> that it's also aimed at authoritative server software, so they can handle >> new RRTYPEs without code changes and without having to sneak them in via >> hex escape codes. > > Compression will NEVER happen with new records. I know. I put it in there to give people the option of describing some existing records the same way as new ones. > What I do worry about this is that it will artificially limit new > RR's to formats that can be expressed in this language. I suppose, but opposed to the current situation of no new RRs at all unless people are incredibly desperate (DNSSEC), it doesn't seem like a bad tradeoff. If you think there are other field types that are likely to be popular enough to be worth describing, I'm not opposed to that. It also occurred to me that if this limits people's desire to add random hard to describe new field types, that wouldn't necessarily be bad. > Also this doesn't have to be formalised. Of course it does. The whole point is to be able to distribute descriptions of new RRTYPEs and have some hope that large numbers of servers and provisioning systems can use them. > You will also need stuff like I2[LEN(F1),B] (2 byte int, length of > field(#), not printed(B)). Ewww. I can see that you might want to insert fixed fields (although that strikes me as an admission that the RRTYPE is poorly designed), but I really don't see it as desirable to encourage people to invent new fields that are so big you can't encode the length in one byte. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From marka@isc.org Sun Aug 21 12:46:16 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9E521F884C for ; Sun, 21 Aug 2011 12:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLrzDTbwxseD for ; Sun, 21 Aug 2011 12:46:15 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id BDFCF21F877F for ; Sun, 21 Aug 2011 12:46:15 -0700 (PDT) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 56506C9422; Sun, 21 Aug 2011 19:47:08 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (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 96111216C81; Sun, 21 Aug 2011 19:47:07 +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 2793E1303C8E; Mon, 22 Aug 2011 05:47:04 +1000 (EST) To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= From: Mark Andrews References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <8A34D894-4323-4948-811E-6568C838A503@nic.cz> <4E4D7E7E.1070700@necom830.hpcl.titech.ac.jp> <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz> In-reply-to: Your message of "Fri, 19 Aug 2011 09:28:59 +0200." <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz> Date: Mon, 22 Aug 2011 05:47:04 +1000 Message-Id: <20110821194704.2793E1303C8E@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2011 19:46:16 -0000 In message <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz>, =?utf-8?Q?Ond=C5=99ej _Sur=C3=BD?= writes: > > On 18. 8. 2011, at 23:05, Masataka Ohta wrote: > > > Ondej Sur wrote: > > > >>> Are your examples essentially different from Brian Dickson's? > > > >> Much simpler. The DNSSEC signed zone is huge and with anycasts > scattered > >> around the world downloading the zone from hidden master(s) I just > don't > >> want the AXFR happen if it can be prevented. > > > > You fail to explain why the AXFR happens. > >> And there's a lot of stuff which can happen > >> on the master to forget the differences. > > > > I can see none. > > From an operational experience, I see a lot. You can run out of memory, > out of disk space, on disk journal can get corrupt (yes this happens), > DNS software can (and will) have other bugs, people can make mistakes. > Yes, all of this happens in the real world. > > >> The problem is that the 500MB zone * number of anycast slaves (25ish) > is > >> 10 GB of data to transfer. Sure, I can just buy a really fat pipe, but > >> I am no friend of "throw more money" there solutions when we can have > >> simple protocol solution. > > > > The simplest solution is not to forget the differences. > > > From the pure theoretical view point, yes. From the operational view, > I cannot agree with you. You seem to operate on the grounds that > the run environment is perfect, the software is bug free, the people > don't make mistakes. The operational experience don't concur with > that view. > > Simply put, I see this as an design flaw in the original IXFR. > The decision on whether to do an AXFR-style IXFR or not should > be the decision of the slave (the client) and not the master server. > It should not be the decision of the server whether to send a few > megabytes of differences (IXFR) or hundreds of megabytes (AXFR-style). Or one could say the it is a design flaw in how the TLD operators generate the deltas. Compression of delta is optional and the consequences of doing so were well documented. The TLD operators wrote software that only compressed deltas then configured the servers exactly as they were warned not to do if they compressed deltas. If one ignores changes to the SOA record, how may bytes do TLD operators actually save by compressing deltas? (2 SOA records cost 2 * (2 + 2 + 2 + 4 + 2 + 2 + 2 + 5 * 4) = 72 bytes as compression pointers can almost always be used). I realise there is extra work to extract all the deltas rather than just the compressed delta from the database. If one saves the last hour (day?) of serials (so you have a precomputed list of recent change sets to extract from the database) how much extra work is it really to extract uncompressed deltas? How far behind do the distribution masters typically get (time and deltas)? > The IXFR-only is a simple solution to remedy this problem. It is > backwards compatible with existing servers and clients, nobody is > forced to use it, yet you are strongly opposed claiming that it's > not needed. Even though at least mine and Shane's experience with > the operations of big-to-huge zones differ. > > O. > -- > Ondřej Surý > vedoucí výzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mohta@necom830.hpcl.titech.ac.jp Sun Aug 21 17:41:25 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA36021F85FE for ; Sun, 21 Aug 2011 17:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.161 X-Spam-Level: * X-Spam-Status: No, score=1.161 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2JKtj65F1Ou for ; Sun, 21 Aug 2011 17:41:25 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 17E6721F854D for ; Sun, 21 Aug 2011 17:41:23 -0700 (PDT) Received: (qmail 76499 invoked from network); 22 Aug 2011 00:44:40 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 22 Aug 2011 00:44:40 -0000 Message-ID: <4E51A5AD.50007@necom830.hpcl.titech.ac.jp> Date: Mon, 22 Aug 2011 09:41:17 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mark Andrews References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <8A34D894-4323-4948-811E-6568C838A503@nic.cz> <4E4D7E7E.1070700@necom830.hpcl.titech.ac.jp> <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz> <20110821194704.2793E1303C8E@drugs.dv.isc.org> In-Reply-To: <20110821194704.2793E1303C8E@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 00:41:26 -0000 Mark Andrews wrote: >> From an operational experience, I see a lot. You can run out of memory, >> out of disk space, on disk journal can get corrupt (yes this happens), >> DNS software can (and will) have other bugs, people can make mistakes. >> Yes, all of this happens in the real world. > Or one could say the it is a design flaw in how the TLD operators > generate the deltas. Compression of delta is optional and the > consequences of doing so were well documented. The TLD operators > wrote software that only compressed deltas then configured the > servers exactly as they were warned not to do if they compressed > deltas. The consequences can be avoided, if the result of compression is consistent between servers. For example, if the compression is done only on the primary server and only for deltas between two consecutive XFRs. But, as journal corruption is mentioned, there should be a lot more severe operational errors involved, I guess. Masataka Ohta From shane@isc.org Mon Aug 22 05:23:57 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DC021F8B42 for ; Mon, 22 Aug 2011 05:23:57 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+vx6dCuSVAd for ; Mon, 22 Aug 2011 05:23:56 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 5B40321F8B40 for ; Mon, 22 Aug 2011 05:23:56 -0700 (PDT) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id C81EC5F984C for ; Mon, 22 Aug 2011 12:24:54 +0000 (UTC) (envelope-from shane@isc.org) Received: from [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00] (unknown [IPv6:2001:610:719:1:beae:c5ff:fe43:aa00]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id DA092216C22; Mon, 22 Aug 2011 12:24:51 +0000 (UTC) (envelope-from shane@isc.org) From: Shane Kerr To: Mark Andrews Date: Mon, 22 Aug 2011 14:24:48 +0200 In-Reply-To: <20110821194704.2793E1303C8E@drugs.dv.isc.org> References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <8A34D894-4323-4948-811E-6568C838A503@nic.cz> <4E4D7E7E.1070700@necom830.hpcl.titech.ac.jp> <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz> <20110821194704.2793E1303C8E@drugs.dv.isc.org> Organization: ISC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.2 (3.0.2-3.fc15) Content-Transfer-Encoding: 7bit Message-ID: <1314015892.2779.45.camel@shane-desktop> Mime-Version: 1.0 Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 12:23:57 -0000 Mark, On Mon, 2011-08-22 at 05:47 +1000, Mark Andrews wrote: > Or one could say the it is a design flaw in how the TLD operators > generate the deltas. Compression of delta is optional and the > consequences of doing so were well documented. The TLD operators > wrote software that only compressed deltas then configured the > servers exactly as they were warned not to do if they compressed > deltas. There are other circumstance which can result in unwanted full zone transfer. Consider an environment where one has 2 distribution servers at a node, which act as slaves to off-site server. These distribution servers act as masters to any number of local slaves on site. If the node suffers a power failure, then it is quite possible that both distribution servers will need a full AXFR when they restart. If zone updates are frequent, there is a good chance that they will not have the exact same starting serial. All of the local slaves will need to do a full zone transfer when they start or soon after, getting the data from the first distribution server to complete the AXFR. At the first zone update, then on average half of them will need to get the entire zone contents again, because they will try a distribution master that does not have the same starting serial. For small zones this is not a big problem, but for large zones this can result in several minutes of delay before zones get updated - at a difficult time operationally. ("Yes, the node is up - it'll be a few more minutes before we can put it back online...") One solution is to have a single distribution server. However, this introduces a single point of failure into the design. It may also be possible to use some sort of high-availability setup to avoid this problem. A better solution would be for something like IXFR-only. There are probably other failure scenarios. My point is that there are cases other than compressed deltas that would benefit from IXFR-only. Forced fallback to full zone transfer is not a crucial operational problem or it would have been solved already. But it is a problem - or as Ondrej calls it a design flaw - and not too difficult to fix. -- Shane From mohta@necom830.hpcl.titech.ac.jp Mon Aug 22 06:07:27 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0A021F8B4E for ; Mon, 22 Aug 2011 06:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.014 X-Spam-Level: X-Spam-Status: No, score=-0.014 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM+KeisAWWXH for ; Mon, 22 Aug 2011 06:07:27 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 020A021F8B4B for ; Mon, 22 Aug 2011 06:07:26 -0700 (PDT) Received: (qmail 81875 invoked from network); 22 Aug 2011 13:11:04 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 22 Aug 2011 13:11:04 -0000 Message-ID: <4E525476.4070001@necom830.hpcl.titech.ac.jp> Date: Mon, 22 Aug 2011 22:07:02 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: dnsext@ietf.org References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <8A34D894-4323-4948-811E-6568C838A503@nic.cz> <4E4D7E7E.1070700@necom830.hpcl.titech.ac.jp> <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz> <20110821194704.2793E1303C8E@drugs.dv.isc.org> <1314015892.2779.45.camel@shane-desktop> In-Reply-To: <1314015892.2779.45.camel@shane-desktop> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 13:07:27 -0000 Shane Kerr wrote: > Consider an environment where one has 2 distribution servers at a node, Only 2 distribution servers? It should be a toy zone. And, do you mean "zone", not "node"? > If the node suffers a power failure, then it is quite possible that both > distribution servers will need a full AXFR when they restart. Are you seriously saying that it is quite possible that two servers simultaneously loss checkpointing information because of power failure? Even then, there is no point of IXFR-only because, with your example, neither server can offer IXFR. > If zone > updates are frequent, there is a good chance that they will not have the > exact same starting serial. So? > One solution is to have a single distribution server. It's no solution. I'm afraid you completely misunderstand DNS. Masataka Ohta From marka@isc.org Mon Aug 22 12:48:58 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481EF21F8C90 for ; Mon, 22 Aug 2011 12:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACslpoy0CabU for ; Mon, 22 Aug 2011 12:48:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id B732221F8C31 for ; Mon, 22 Aug 2011 12:48:57 -0700 (PDT) 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 "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id C6789C9422; Mon, 22 Aug 2011 19:49:53 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6233:4bff:fe01:7585]) (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 2C8F4216C7B; Mon, 22 Aug 2011 19:49: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 0C554130B8DB; Tue, 23 Aug 2011 05:49:51 +1000 (EST) To: Masataka Ohta From: Mark Andrews References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <8A34D894-4323-4948-811E-6568C838A503@nic.cz> <4E4D7E7E.1070700@necom830.hpcl.titech.ac.jp> <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz> <20110821194704.2793E1303C8E@drugs.dv.isc.org> <1314015892.2779.45.camel@shane-desktop> <4E525476.4070001@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Mon, 22 Aug 2011 22:07:02 +0900." <4E525476.4070001@necom830.hpcl.titech.ac.jp> Date: Tue, 23 Aug 2011 05:49:50 +1000 Message-Id: <20110822194951.0C554130B8DB@drugs.dv.isc.org> Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 19:48:58 -0000 In message <4E525476.4070001@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Shane Kerr wrote: > > > Consider an environment where one has 2 distribution servers at a node, > > Only 2 distribution servers? It should be a toy zone. > > And, do you mean "zone", not "node"? > > > If the node suffers a power failure, then it is quite possible that both > > distribution servers will need a full AXFR when they restart. > > Are you seriously saying that it is quite possible that two servers > simultaneously loss checkpointing information because of power > failure? No. I think Shane means that they have been out of contact long enough that the AXFR style response is smaller than the IXFR style response and the upstream supplied a AXFR style response. > Even then, there is no point of IXFR-only because, with your example, > neither server can offer IXFR. You are missing Shanes point, which is that after the initial AXFR style response that the slaves that transferred from the DM that transfered first, and hence had a lower serial, will not be able to get a delta style response from the other DM. > > If zone > > updates are frequent, there is a good chance that they will not have the > > exact same starting serial. > > So? See above. > > One solution is to have a single distribution server. > > It's no solution. I'm afraid you completely misunderstand DNS. Shane isn't saying that it is a desirable solution. The other solution is to prevent the axfr's out from the DM's until they both have the same serials available ixfr from. The is not to say that I'm apposed to ixfr only. > Masataka Ohta > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From warren@kumari.net Mon Aug 22 13:15:20 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347A521F8ABC for ; Mon, 22 Aug 2011 13:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWnaHZhZTIK9 for ; Mon, 22 Aug 2011 13:15:19 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B2E1E21F899F for ; Mon, 22 Aug 2011 13:15:19 -0700 (PDT) Received: from [192.168.0.203] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 80CE21B402CF; Mon, 22 Aug 2011 16:16:24 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <20110818183413.GA29289@shinkuro.com> Date: Mon, 22 Aug 2011 16:16:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <967EA838-7D87-49BA-A56F-D8FDD3F9171D@kumari.net> References: <20110818032224.45073.qmail@joyce.lan> <02B1DC14-4969-4BA3-8364-4F584A1E8369@rfc1035.com> <20110818183413.GA29289@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1084) Cc: dnsext@ietf.org Subject: Re: [dnsext] An RRTYPE extension language X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 20:15:20 -0000 On Aug 18, 2011, at 2:34 PM, Andrew Sullivan wrote: > On Thu, Aug 18, 2011 at 02:06:15PM -0400, John R. Levine wrote: >> I'm happy to do that, but there's not much point if people will just >> insist that either provisioning isn't a problem, or it's too grubby >> for DNSEXT to think about. >=20 > Speaking personally, I think it _is_ a problem and I am willing to > review such a draft. >=20 Coming late to the party, but I too am willing to review and / or = contribute... > Speaking as a co-chair but without having conferred with Olafur, I'm > not totally sure this is something that would fit correctly in > DNSEXT's charter, since this is in support of wire changes instead of > a protocol issue _per se_. This might actually be DNSOP fodder > instead. We can have a jurisdiction fight after there's a draft, > however. Yah. W >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com >=20 > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext >=20 From mohta@necom830.hpcl.titech.ac.jp Mon Aug 22 17:34:49 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C50221F8B28 for ; Mon, 22 Aug 2011 17:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLHLTBHZdnQz for ; Mon, 22 Aug 2011 17:34:49 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id D081521F8B2A for ; Mon, 22 Aug 2011 17:34:48 -0700 (PDT) Received: (qmail 86360 invoked from network); 23 Aug 2011 00:38:23 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 23 Aug 2011 00:38:23 -0000 Message-ID: <4E52F5A5.2080809@necom830.hpcl.titech.ac.jp> Date: Tue, 23 Aug 2011 09:34:45 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Mark Andrews References: <4DB81069.3080404@nic.cz> <4DF9B5BD.7010900@nic.cz> <4DFC9C20.4030401@necom830.hpcl.titech.ac.jp> <4E000B93.3030306@necom830.hpcl.titech.ac.jp> <8A34D894-4323-4948-811E-6568C838A503@nic.cz> <4E4D7E7E.1070700@necom830.hpcl.titech.ac.jp> <80B25AE0-4DB6-4DBB-866B-4DB8F59D6DA0@nic.cz> <20110821194704.2793E1303C8E@drugs.dv.isc.org> <1314015892.2779.45.camel@shane-desktop> <4E525476.4070001@necom830.hpcl.titech.ac.jp> <20110822194951.0C554130B8DB@drugs.dv.isc.org> In-Reply-To: <20110822194951.0C554130B8DB@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-ah-dnsext-rfc1995bis-ixfr-02 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 00:34:49 -0000 Mark Andrews wrote: > No. I think Shane means that they have been out of contact long > enough that the AXFR style response is smaller than the IXFR style > response and the upstream supplied a AXFR style response. So, it's not two distribution servers but their clients, which fail? It's not a problem, as long as the distribution servers are synchronized. But, as Shane said "both distribution servers will need a full AXFR when they restart", he seemingly assumes failures of distribution servers, I'm afraid. Anyway, >> Even then, there is no point of IXFR-only because, with your example, >> neither server can offer IXFR. > > You are missing Shanes point, What? > which is that after the initial AXFR > style response that the slaves that transferred from the DM that > transfered first, and hence had a lower serial, will not be able > to get a delta style response from the other DM. Are you saying two distribution servers (never introduce new terminology such as DM only to amplify the confusion) do not have the same history of a zone? How can it happen without severe operational errors? Note that you don't assume failure of distribution servers. > Shane isn't saying that it is a desirable solution. > > The other solution is to prevent the axfr's out from the DM's until they > both have the same serials available ixfr from. I'm afraid both Shane and you have confused ideas on the configuration of DNS servers, partially because of improper terminologies. Masataka Ohta From sob@academ.com Wed Aug 17 07:30:24 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8138C21F8B34 for ; Wed, 17 Aug 2011 07:30:24 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD4CJPWKV5lM for ; Wed, 17 Aug 2011 07:30:24 -0700 (PDT) Received: from bdr.academ.com (unknown [IPv6:2001:418:6802::76]) by ietfa.amsl.com (Postfix) with ESMTP id D508121F8B2F for ; Wed, 17 Aug 2011 07:30:23 -0700 (PDT) Received: from [10.64.32.30] (gw1.cox.com [24.248.74.254]) (authenticated bits=0) by bdr.academ.com (8.14.4/8.14.4) with ESMTP id p7HEV9Iw044868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Aug 2011 09:31:10 -0500 (CDT) (envelope-from sob@academ.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Stan Barber In-Reply-To: <44172923-8ECC-44D4-A4DE-8040EF94CBC3@gmail.com> Date: Wed, 17 Aug 2011 10:31:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <36D01EF2-B521-4D8E-BE6A-4131FFB260D4@academ.com> References: <44172923-8ECC-44D4-A4DE-8040EF94CBC3@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1244.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (bdr.academ.com [198.137.249.76]); Wed, 17 Aug 2011 09:31:12 -0500 (CDT) X-Mailman-Approved-At: Thu, 25 Aug 2011 06:01:02 -0700 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] A6 to Historic X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2011 14:30:24 -0000 I support moving A6 to historic. On Aug 12, 2011, at 5:35 PM, Ralph Droms wrote: > There has been a discussion on the 6man mailing list about moving A6 = records to Historic. I'd like to get input from dnsext about the = re-designation. >=20 > ipv6@ietf.org is bcc:ed; please reply to dnsext. >=20 > Thanks >=20 > - Ralph >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From bmanning@karoshi.com Tue Aug 30 09:10:33 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A49921F8D18 for ; Tue, 30 Aug 2011 09:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi68lpwfWcOC for ; Tue, 30 Aug 2011 09:10:31 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id B3F4221F8C8C for ; Tue, 30 Aug 2011 09:10:31 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id p7UGBIiD007749; Tue, 30 Aug 2011 16:11:18 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id p7UGBIMA007748; Tue, 30 Aug 2011 16:11:18 GMT Date: Tue, 30 Aug 2011 16:11:18 +0000 From: bmanning@vacation.karoshi.com To: dnsext@ietf.org Message-ID: <20110830161118.GA7666@vacation.karoshi.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Cc: bmanning@vacation.karoshi.com Subject: [dnsext] sands of time X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 16:10:33 -0000 So DNSSEC introduces a new dependency - the availability of accurate time. Mnay of the existant tools programatically encode start/stop times for things like signature validity, packet replay attacks, etc. To a large degree, at least in my experience, we tend to use UTC as a baseline. and now, There is a plan to fundamentally change the calulations of UTC. Stephan posted this a few days back, I'll note that comments are due by 31aug2011 (thats tomorrow for me) http://hpiers.obspm.fr/eop-pc/index.php?index=questionnaire Its worth a look. /bill From nweaver@icsi.berkeley.edu Tue Aug 30 09:16:09 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C5D21F871E for ; Tue, 30 Aug 2011 09:16:09 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWEXyCdSsFje for ; Tue, 30 Aug 2011 09:16:09 -0700 (PDT) Received: from taffy.ICSI.Berkeley.EDU (taffy.ICSI.Berkeley.EDU [192.150.187.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0A60C21F86E0 for ; Tue, 30 Aug 2011 09:16:09 -0700 (PDT) Received: from [10.0.1.3] (c-50-131-91-16.hsd1.ca.comcast.net [50.131.91.16]) (Authenticated sender: nweaver) by taffy.ICSI.Berkeley.EDU (Postfix) with ESMTP id 2DC7436A363; Tue, 30 Aug 2011 09:17:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Nicholas Weaver In-Reply-To: <20110830161118.GA7666@vacation.karoshi.com.> Date: Tue, 30 Aug 2011 09:17:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9989BC64-7D49-4BEA-A39A-05E37764FFF3@icsi.berkeley.edu> References: <20110830161118.GA7666@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: dnsext@ietf.org Subject: Re: [dnsext] sands of time X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 16:16:09 -0000 On Aug 30, 2011, at 9:11 AM, bmanning@vacation.karoshi.com wrote: >=20 > So DNSSEC introduces a new dependency - the availability of accurate = time. > Mnay of the existant tools programatically encode start/stop times for = things > like signature validity, packet replay attacks, etc. To a large = degree, at least > in my experience, we tend to use UTC as a baseline. >=20 > and now, There is a plan to fundamentally change the calulations of = UTC. >=20 > Stephan posted this a few days back, I'll note that comments are due = by 31aug2011 > (thats tomorrow for me) >=20 >=20 > http://hpiers.obspm.fr/eop-pc/index.php?index=3Dquestionnaire >=20 > Its worth a look. =20 This will have pretty much no effect on DNSSEC AFAIK: Everything is = synced by NTP or GPS to UTC (NOT UT1, earth rotational time), and the = presence or absence of leap seconds should not come into play one way or = the other, since all validators need accurate time syncing anyway. However, the worry I have is that this makes the UTC -> Local Time = calculation screwy: after about what would be 60 leap-seconds, there = will be pressure to change the definition of local timezones in bigger = leaps. From ajs@anvilwalrusden.com Tue Aug 30 09:20:20 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF08621F8D90 for ; Tue, 30 Aug 2011 09:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7j71L4RsneZx for ; Tue, 30 Aug 2011 09:20:19 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 1776621F8D8E for ; Tue, 30 Aug 2011 09:20:19 -0700 (PDT) Received: from shinkuro.com (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 mail.yitter.info (Postfix) with ESMTPSA id 0F8B41ECB41C; Tue, 30 Aug 2011 16:21:37 +0000 (UTC) Date: Tue, 30 Aug 2011 12:21:34 -0400 From: Andrew Sullivan To: draft-vandergaast-edns-client-subnet@tools.ietf.org Message-ID: <20110830162134.GB84494@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsext@ietf.org Subject: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 16:20:20 -0000 Dear authors of draft-vandergaast-edns-client-subnet-00: The site http://www.afasterinternet.com came to our attention. It appears to us that you are undertaking a trial deployment of draft-vandergaast-edns-client-subnet-00, and that you are soliciting people to participate in the client portion of this trial. We think this is, in effect, a limited public trial on the public Internet. We would like to urge you, very strongly, to obtain an actual EDNS0 option code assignment from IANA prior to proceeding with this trial. By failing to obtain such a code, and by releasing your software to the Internet, you are potentially polluting the EDNS0 option code space. We are aware of the obstacles to obtaining such an option code, but we believe that the benefits of a faster Internet, which you are avowedly attempting to deliver, will only really be benefits if they don't break others' software, either now or in the future. By using a completely unassigned option code, as you must be doing, you are risking colliding with another assignment. In order to obtain the option code, all that is needed is an RFC to be published. We stand ready and willing to help you pursue that publication, particularly since you intend your protocol to be experimental. Best regards, Andrew and Olafur (co-chairs of the DNSEXT working group, but speaking only for ourselves.) -- Andrew Sullivan ajs@anvilwalrusden.com From jim@rfc1035.com Tue Aug 30 10:54:49 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04A721F8DE5 for ; Tue, 30 Aug 2011 10:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2IcgS7+jUtk for ; Tue, 30 Aug 2011 10:54:49 -0700 (PDT) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBBF21F8CE7 for ; Tue, 30 Aug 2011 10:54:48 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id DBB4015420A1; Tue, 30 Aug 2011 18:56:01 +0100 (BST) Message-Id: <7092C3C3-EA9D-4B92-9853-E12AE28F11F9@rfc1035.com> From: Jim Reid To: Nicholas Weaver In-Reply-To: <9989BC64-7D49-4BEA-A39A-05E37764FFF3@icsi.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 30 Aug 2011 18:56:01 +0100 References: <20110830161118.GA7666@vacation.karoshi.com.> <9989BC64-7D49-4BEA-A39A-05E37764FFF3@icsi.berkeley.edu> X-Mailer: Apple Mail (2.936) Cc: bmanning@vacation.karoshi.com, dnsext@ietf.org Subject: Re: [dnsext] sands of time X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 17:54:49 -0000 On 30 Aug 2011, at 17:17, Nicholas Weaver wrote: > On Aug 30, 2011, at 9:11 AM, bmanning@vacation.karoshi.com wrote: > >> There is a plan to fundamentally change the calulations of UTC. So what? However UTC is calculated, it'll still be UTC. The world will still use it for broadcasting timestamps, driving NTP servers, doing navigation, etc. IIUC the ITU-R proposal is to stop adding leap seconds to UTC so that it's always within a second of International Atomic Time which pretty much only matters to rocket scientists and astronomers who need to care about variations in the rotation of the earth. I wonder though what motivated this proposed change... > This will have pretty much no effect on DNSSEC AFAIK: Everything is > synced by NTP or GPS to UTC (NOT UT1, earth rotational time), and > the presence or absence of leap seconds should not come into play > one way or the other, since all validators need accurate time > syncing anyway. Indeed. Even if a drift between UTC and IAT mattered for DNSSEC, it seems unlikely anyone would (need to) use RRSIG validity intervals as low as a few seconds. > However, the worry I have is that this makes the UTC -> Local Time > calculation screwy: after about what would be 60 leap-seconds, there > will be pressure to change the definition of local timezones in > bigger leaps. Maybe. Or maybe in a few decades leap seconds would come back into fashion again. With a leap second typically getting added once every 18 months or so, it'll be our grandchildren who might have to worry about a 60 second drift between UTC and IAT Nicholas. :-) It's not clear if this ITU-R proposal will be accepted either and if it is, it won't be implemented until 2017. So, nothing to see here, move along... From jim@rfc1035.com Tue Aug 30 11:10:05 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF7221F8E24 for ; Tue, 30 Aug 2011 11:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpUUCBLS4B+f for ; Tue, 30 Aug 2011 11:10:05 -0700 (PDT) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by ietfa.amsl.com (Postfix) with ESMTP id 322C021F8E1B for ; Tue, 30 Aug 2011 11:09:58 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id 6E41015420A1 for ; Tue, 30 Aug 2011 19:11:20 +0100 (BST) Message-Id: <539D7448-892F-47CC-8DDC-8DB1B30558F7@rfc1035.com> From: Jim Reid To: dnsext@ietf.org In-Reply-To: <7092C3C3-EA9D-4B92-9853-E12AE28F11F9@rfc1035.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 30 Aug 2011 19:11:20 +0100 References: <20110830161118.GA7666@vacation.karoshi.com.> <9989BC64-7D49-4BEA-A39A-05E37764FFF3@icsi.berkeley.edu> <7092C3C3-EA9D-4B92-9853-E12AE28F11F9@rfc1035.com> X-Mailer: Apple Mail (2.936) Subject: [dnsext] granularity of RRSIGs X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 18:10:05 -0000 On 30 Aug 2011, at 18:56, Jim Reid wrote: > it seems unlikely anyone would (need to) use RRSIG validity > intervals as low as a few seconds. Replying to my own posting? Hmmmm.... I smell an April 1st RFC. DNSSEC-quad with picosecond resolution RRSIGs. :-) From paf@cisco.com Tue Aug 30 11:15:57 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D5021F8E34 for ; Tue, 30 Aug 2011 11:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WdqZgLJimra for ; Tue, 30 Aug 2011 11:15:57 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 696BD21F8E32 for ; Tue, 30 Aug 2011 11:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paf@cisco.com; l=1242; q=dns/txt; s=iport; t=1314728233; x=1315937833; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nOefIHM3NsBf/8nIftSvliVLR83hXNVXninwYNByM/E=; b=lxqAJ9+WbJeN3VMRBX3htXDR/AMBllp2JSjMmzMXhxjyjDHX/PmR49Zb QceKw9jwsNHJ3eixMsMncMr2ppFAPhD7GJ5KE/guhqPmN3yBVvmQzbQF5 EIit8mhb1vZJjpELQMU5EfsEl/tdVr9IxnlMyFit7caVXwz1eZdW7vNcy w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMFAFAoXU6rRDoH/2dsb2JhbAAoGpkPjyZ3gUABAQEBAgESASc/BQsLRlcZIodQBCOZKgGfMoVtYASTJJEH X-IronPort-AV: E=Sophos;i="4.68,303,1312156800"; d="scan'208";a="17888754" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-7.cisco.com with ESMTP; 30 Aug 2011 18:17:13 +0000 Received: from sjc-vpn5-267.cisco.com (sjc-vpn5-267.cisco.com [10.21.89.11]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7UIHBK2023324; Tue, 30 Aug 2011 18:17:11 GMT Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20110830161118.GA7666@vacation.karoshi.com.> Date: Tue, 30 Aug 2011 20:17:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110830161118.GA7666@vacation.karoshi.com.> To: bmanning@vacation.karoshi.com X-Mailer: Apple Mail (2.1244.3) Cc: dnsext@ietf.org Subject: Re: [dnsext] sands of time X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 18:15:57 -0000 On 30 aug 2011, at 18:11, bmanning@vacation.karoshi.com wrote: > So DNSSEC introduces a new dependency - the availability of accurate = time. > Mnay of the existant tools programatically encode start/stop times for = things > like signature validity, packet replay attacks, etc. To a large = degree, at least > in my experience, we tend to use UTC as a baseline. >=20 > and now, There is a plan to fundamentally change the calulations of = UTC. >=20 > Stephan posted this a few days back, I'll note that comments are due = by 31aug2011 > (thats tomorrow for me) >=20 >=20 > http://hpiers.obspm.fr/eop-pc/index.php?index=3Dquestionnaire >=20 > Its worth a look. =20 Well, obviously it is as this proposal never dies. It was brought up a = few years ago, and people said clearly "no". Now people ask for this = again. Yes, UTC will be UTC all the time, but why should UTC not be related to = earth rotations anymore? In a few years, the sun will not be in the = south at noon etc if we drop leap seconds. Sure, the value of "few" is = large, but still. My view: "just say no". But as Jim said, for DNSSEC, we will still use UTC regardless of whether = it is tied to earth rotations or not. Patrik From fanf2@hermes.cam.ac.uk Tue Aug 30 11:38:06 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322B921F8D73 for ; Tue, 30 Aug 2011 11:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyc1OsxEXI51 for ; Tue, 30 Aug 2011 11:38:05 -0700 (PDT) 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 77F8321F8D07 for ; Tue, 30 Aug 2011 11:38:05 -0700 (PDT) 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-2.csi.cam.ac.uk ([131.111.8.54]:60805) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1QyTDe-0004o7-WP (Exim 4.72) (return-path ); Tue, 30 Aug 2011 19:39:30 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QyTDe-0005KQ-1C (Exim 4.67) (return-path ); Tue, 30 Aug 2011 19:39:30 +0100 Date: Tue, 30 Aug 2011 19:39:30 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Nicholas Weaver In-Reply-To: <9989BC64-7D49-4BEA-A39A-05E37764FFF3@icsi.berkeley.edu> Message-ID: References: <20110830161118.GA7666@vacation.karoshi.com.> <9989BC64-7D49-4BEA-A39A-05E37764FFF3@icsi.berkeley.edu> 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: bmanning@vacation.karoshi.com, dnsext@ietf.org Subject: Re: [dnsext] sands of time X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 18:38:06 -0000 Nicholas Weaver wrote: > > However, the worry I have is that this makes the UTC -> Local Time > calculation screwy: after about what would be 60 leap-seconds, there > will be pressure to change the definition of local timezones in bigger > leaps. No. Local time has a slop on the order of an hour - look at a time zone map and see how much the land boundaries deviate from 7.5 + n * 15 degrees. The abolition of leap seconds would have no practical effect on time zones until centuries in the future. Tony. -- f.anthony.n.finch http://dotat.at/ Sole: Easterly 4 or 5, occasionally 6 in south. Moderate. Occasional rain. Moderate or good. From fanf2@hermes.cam.ac.uk Tue Aug 30 11:54:24 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5235A21F8E11 for ; Tue, 30 Aug 2011 11:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7B7X48B+8gyu for ; Tue, 30 Aug 2011 11:54:23 -0700 (PDT) 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 9690621F8D3F for ; Tue, 30 Aug 2011 11:54:20 -0700 (PDT) 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-2.csi.cam.ac.uk ([131.111.8.54]:49723) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1QyTTM-0008B3-RL (Exim 4.72) (return-path ); Tue, 30 Aug 2011 19:55:44 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1QyTTM-0007Bg-Ex (Exim 4.67) (return-path ); Tue, 30 Aug 2011 19:55:44 +0100 Date: Tue, 30 Aug 2011 19:55:44 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: =?ISO-8859-15?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Message-ID: References: <20110830161118.GA7666@vacation.karoshi.com.> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870024-2117510792-1314730544=:30178" Sender: Tony Finch Cc: bmanning@vacation.karoshi.com, dnsext@ietf.org Subject: Re: [dnsext] sands of time X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 18:54:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870024-2117510792-1314730544=:30178 Content-Type: TEXT/PLAIN; charset=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Patrik F=E4ltstr=F6m wrote: > > Well, obviously it is as this proposal never dies. It was brought up a > few years ago, and people said clearly "no". Now people ask for this > again. The proposal has been working its way through the ITU-R processes for over ten years. There has been no clear consensus either way, so it keeps getting passed up to the next highest committee meeting. The final decision will be next year at the world radiocommunication congress, which is the international treaty agreement meeting of the ITU-R. Being the most senior decision making body it cannot punt :-) This is utterly irrelevant to DNSSEC because whatever happens DNSSEC's idea of time will be civil time, and DNSSEC's accuracy requirements are very relaxed. Tony. --=20 f.anthony.n.finch http://dotat.at/ Fair Isle: North or northwest 3 or 4, occasionally 5 at first. Moderate, occasionally rough at first. Showers. Good. --1870870024-2117510792-1314730544=:30178-- From wilmer@google.com Tue Aug 30 14:08:38 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6105C21F8DBC for ; Tue, 30 Aug 2011 14:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnNMWxljBetf for ; Tue, 30 Aug 2011 14:08:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 31D7421F8D8E for ; Tue, 30 Aug 2011 14:08:37 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p7ULA5dT031399 for ; Tue, 30 Aug 2011 14:10:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314738605; bh=rblVvvdkC3YtDMfmQ+OZ0HJNlTI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=gHt+RM2RrvPlb8RfO9jlWZDPArman5rK8unCmw6SRIH4KczThDc1AzzroWif5ZG/v xOV7fhvb4Nf2hpZ7ig2iA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=ajLY4FgS3jxxrjGxSD9rI3+F2tY8NE+zChykrquyZDM/6KVLYpnWpC+bFgKKiIADI ifrJIa1brF0X6B8mdhGcA== Received: from iagk10 (iagk10.prod.google.com [10.12.212.10]) by wpaz29.hot.corp.google.com with ESMTP id p7UL9jmV001597 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 30 Aug 2011 14:10:03 -0700 Received: by iagk10 with SMTP id k10so23410iag.30 for ; Tue, 30 Aug 2011 14:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cP+D7MIauqkreyhoqlVSORNAJjIUPwC7ANQF5vOAePU=; b=EsB8Cgy3p9eJa2o1cN4UVJwk6QHjPZwpHx/FNxpNxhJ/5MqVPSFLz63MdgUJUd6bfX FKpmyPgoyjEO7Wn8FJww== Received: by 10.231.45.129 with SMTP id e1mr14366762ibf.22.1314738603303; Tue, 30 Aug 2011 14:10:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.45.129 with SMTP id e1mr14366724ibf.22.1314738602112; Tue, 30 Aug 2011 14:10:02 -0700 (PDT) Received: by 10.231.159.136 with HTTP; Tue, 30 Aug 2011 14:10:01 -0700 (PDT) In-Reply-To: <20110830162134.GB84494@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> Date: Tue, 30 Aug 2011 22:10:01 +0100 Message-ID: From: Wilmer van der Gaast To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 21:08:38 -0000 On 30 August 2011 17:21, Andrew Sullivan wrote: > > It appears to us that you are undertaking a trial deployment of > draft-vandergaast-edns-client-subnet-00, and that you are soliciting > people to participate in the client portion of this trial. We think > this is, in effect, a limited public trial on the public Internet. > It's not really a public trial on the public Internet. It's merely a group of open resolvers and a few CDNs who all implemented support for edns-client-subnet in their systems and start to use it amongst just each other. The resolvers use a whitelist to make sure the option only goes to nameservers that expect it. Our goal here, speaking as the authors of the I-D, is to get some real-world numbers on how effective edns-client-subnet really is. Unfortunately my memories of our conversation at IETF78 (Maastricht) are pretty vague by now, but IIRC there was some interest for these numbers. Unfortunately we got sidetracked by our day jobs and didn't have much time to work on this data or the I-D in general - but do intend to allocate more time for it over the next months. > We are aware of the obstacles to obtaining such an option code, but we > believe that the benefits of a faster Internet, which you are avowedly > attempting to deliver, will only really be benefits if they don't > break others' software, either now or in the future. I fully agree. By picking 0x50fa instead of a lower value (it looks like so far EDNS0 options are assigned sequentially) we certainly tried to avoid any problems of this kind. Our plan was to use this temporary option code just to gather data, and with that and a published experimental RFC, get an official number from IANA. Not at any time did we intend to sidestep the IETF process. Apologies if we gave that impression. Our latest I-D has just expired and we have no updates to it. Also there has been very little (none, from what I can remember) discussion on dnsext about it. We welcome any help you can offer to make this I-D suitable for publication on the experimental track. Kind regards, Wilmer van der Gaast, Carlo Contavalli. From alex@alex.org.uk Tue Aug 30 14:51:20 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1840521F8CF5 for ; Tue, 30 Aug 2011 14:51:20 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJICXDwFHDKS for ; Tue, 30 Aug 2011 14:51:19 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id 479DA21F8CDA for ; Tue, 30 Aug 2011 14:51:16 -0700 (PDT) Received: from [192.168.100.16] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 949A6C560F9; Tue, 30 Aug 2011 22:52:42 +0100 (BST) Date: Tue, 30 Aug 2011 22:52:41 +0100 From: Alex Bligh To: Wilmer van der Gaast , Andrew Sullivan Message-ID: <7CA8194350F4804F8DF6CAF3@nimrod.local> In-Reply-To: References: <20110830162134.GB84494@shinkuro.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 21:51:20 -0000 --On 30 August 2011 22:10:01 +0100 Wilmer van der Gaast wrote: > Our latest I-D > has > just expired and we have no updates to it. Also there has been very > little (none, from what I can remember) discussion on dnsext about it. We > welcome any help you can offer to make this I-D suitable for publication > on the experimental track. Is this substantially different from draft-vandergast-client-ip-01 which had 239 messages on it? Hardly no discussion. I suspect the reason why there has been no discussion of draft-vandergast-client-subnet-00 is because it hasn't (at least according to my archive) ever been announced on dnsext. -- Alex Bligh From colm@allcosts.net Tue Aug 30 15:13:07 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC47721F8EC4 for ; Tue, 30 Aug 2011 15:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gEbTMtogJMT for ; Tue, 30 Aug 2011 15:13:06 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 756C821F8BFE for ; Tue, 30 Aug 2011 15:13:06 -0700 (PDT) Received: by qwc23 with SMTP id 23so102173qwc.31 for ; Tue, 30 Aug 2011 15:14:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.181.196 with SMTP id bz4mr3037079qab.60.1314742472990; Tue, 30 Aug 2011 15:14:32 -0700 (PDT) Received: by 10.224.47.66 with HTTP; Tue, 30 Aug 2011 15:14:32 -0700 (PDT) In-Reply-To: <7CA8194350F4804F8DF6CAF3@nimrod.local> References: <20110830162134.GB84494@shinkuro.com> <7CA8194350F4804F8DF6CAF3@nimrod.local> Date: Tue, 30 Aug 2011 15:14:32 -0700 Message-ID: From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Alex Bligh Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-vandergaast-edns-client-subnet@tools.ietf.org, dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 22:13:07 -0000 http://www.ietf.org/mail-archive/web/dnsext/current/msg10563.html On Tue, Aug 30, 2011 at 2:52 PM, Alex Bligh wrote: > > > --On 30 August 2011 22:10:01 +0100 Wilmer van der Gaast > wrote: > >> Our latest I-D >> has >> just expired and we have no updates to it. Also there has been very >> little (none, from what I can remember) discussion on dnsext about it. We >> welcome any help you can offer to make this I-D suitable for publication >> on the experimental track. > > Is this substantially different from draft-vandergast-client-ip-01 which > had 239 messages on it? Hardly no discussion. I suspect the reason why > there has been no discussion of draft-vandergast-client-subnet-00 is > because it hasn't (at least according to my archive) ever been announced > on dnsext. > > -- > Alex Bligh > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- Colm From ajs@anvilwalrusden.com Tue Aug 30 20:11:43 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0061921F8B73 for ; Tue, 30 Aug 2011 20:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHeFA4GBK2Dt for ; Tue, 30 Aug 2011 20:11:38 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAD621F8B65 for ; Tue, 30 Aug 2011 20:11:37 -0700 (PDT) Received: from shinkuro.com (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 mail.yitter.info (Postfix) with ESMTPSA id 3D3E71ECB41C; Wed, 31 Aug 2011 03:13:05 +0000 (UTC) Date: Tue, 30 Aug 2011 23:12:57 -0400 From: Andrew Sullivan To: Wilmer van der Gaast Message-ID: <20110831031256.GA98758@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 03:11:43 -0000 Hi Wilmer, Thanks for your reply. A couple remarks below. I have not passed this by Olafur, and as before, I am _not_ speaking in any official capacity. On Tue, Aug 30, 2011 at 10:10:01PM +0100, Wilmer van der Gaast wrote: > It's not really a public trial on the public Internet. It's merely a > group of open resolvers and a few CDNs who all implemented support for > edns-client-subnet in their systems and start to use it amongst just > each other. The resolvers use a whitelist to make sure the option only > goes to nameservers that expect it. When you initially suggested you wanted to do some experiments, I took that to mean that you were going to do some things in a lab. Because of the way EDNS0 code points are assigned, I recognized that it would likely be better if you did things in your lab beforehand. That was why I told you that, while it would probably be a little tricky to get a code point at that early stage, if you ran an experiment with some code that used a code point clearly not about to be allocated, it was probably safe enough for those purposes. What the pages I already cited say, however, is not that you're doing something in a lab, but that you're doing it on the Internet -- between consenting adults, sure, but on the public Internet nevertheless. By using an unassigned code point this way, you run two risks: 1. Some of the client code that gets used for this hangs around, and continues to set that EDNS0 option. If the option code point gets assigned later, and to something else, you end up setting an option that doesn't do what you think it does (and you don't behave as a server receiving such an option would expect you to). 2. Some server code that gets used for this test hangs around, and continues to respond to that EDNS0 option. This is basically the complement of the above case. It's just as bad. > published experimental RFC, get an official number from IANA. Not at > any time did we intend to sidestep the IETF process. Apologies if we > gave that impression. I actually don't care about the IETF process. What I do care about is the potential for interoperability headaches later because of undocumented collisions in EDNS0 option code interpretation. Avoiding that sort of headache is the exact reason we have a registry. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From colm@allcosts.net Tue Aug 30 20:22:30 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478BB21F8C81 for ; Tue, 30 Aug 2011 20:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx0lb+gPKZr5 for ; Tue, 30 Aug 2011 20:22:29 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86E1821F8D3F for ; Tue, 30 Aug 2011 20:22:29 -0700 (PDT) Received: by qyk34 with SMTP id 34so2727604qyk.10 for ; Tue, 30 Aug 2011 20:23:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.186.132 with SMTP id cs4mr1872308qab.110.1314761032237; Tue, 30 Aug 2011 20:23:52 -0700 (PDT) Received: by 10.224.47.66 with HTTP; Tue, 30 Aug 2011 20:23:51 -0700 (PDT) In-Reply-To: <20110831031256.GA98758@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> Date: Tue, 30 Aug 2011 20:23:51 -0700 Message-ID: From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= To: Andrew Sullivan , dnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 03:22:30 -0000 On Tue, Aug 30, 2011 at 8:12 PM, Andrew Sullivan w= rote: > I actually don't care about the IETF process. =A0What I do care about is > the potential for interoperability headaches later because of > undocumented collisions in EDNS0 option code interpretation. =A0Avoiding > that sort of headache is the exact reason we have a registry. How would you feel about proposing more relaxed registry criteria to IANA (by way of an RFC), similar to how the ports registry works? EDNS0 option codes don't appear to be in much demand, so exhaustion isn't as much of a concern. --=20 Colm From matthew@dempsky.org Tue Aug 30 20:45:38 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C9E21F8D64 for ; Tue, 30 Aug 2011 20:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA8zxGOOjgZi for ; Tue, 30 Aug 2011 20:45:38 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E68D421F8D53 for ; Tue, 30 Aug 2011 20:45:37 -0700 (PDT) Received: by bkar4 with SMTP id r4so398373bka.31 for ; Tue, 30 Aug 2011 20:47:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.16.205 with SMTP id p13mr5702361faa.69.1314762426106; Tue, 30 Aug 2011 20:47:06 -0700 (PDT) Received: by 10.152.20.134 with HTTP; Tue, 30 Aug 2011 20:47:06 -0700 (PDT) In-Reply-To: <20110831031256.GA98758@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> Date: Tue, 30 Aug 2011 20:47:06 -0700 Message-ID: From: Matthew Dempsky To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-vandergaast-edns-client-subnet@tools.ietf.org, dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 03:45:39 -0000 On Tue, Aug 30, 2011 at 8:12 PM, Andrew Sullivan w= rote: > I actually don't care about the IETF process. =A0What I do care about is > the potential for interoperability headaches later because of > undocumented collisions in EDNS0 option code interpretation. =A0Avoiding > that sort of headache is the exact reason we have a registry. I suggested in April 2010 that part of the EDNS0 option code space be reserved for private use, but it received very little feedback (positive response from Colm MacC=E1rthaigh, slightly negative from Paul Vixie, and some meta discussion about how strictly IANA follows its instructions on allocating numbers): http://www.ietf.org/mail-archive/web/dnsext/current/msg07768.html http://tools.ietf.org/html/draft-dempsky-edns0-options-for-private-use-00 Reserving a code point for public (i.e., general, unnegotiated) use doesn't make sense until the protocol has solidified. For a private test (even a large scale one conducted across the Internet between multiple organizations), it seems appropriate to use a private use code so long as the participants have agreed a priori what the code means in transactions between their DNS servers. I don't see anything wrong with (e.g.) privately negotiating to use 65300 to mean draft-vandergaast-edns-client-subnet-00 when querying Google's DNS servers but to then mean draft-xxx-something-else when querying someone else's. From matt@mattmccutchen.net Tue Aug 30 21:00:32 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DE021F8C3D for ; Tue, 30 Aug 2011 21:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFM0s6IPP7Wx for ; Tue, 30 Aug 2011 21:00:31 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 909C221F8AF2 for ; Tue, 30 Aug 2011 21:00:31 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id C3FE859807D; Tue, 30 Aug 2011 21:02:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:date:in-reply-to:references:content-type:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=TzTez+IDB6NNDsOaQql6tlN3LNMACfIhjWFD4nh6Ffv kAtwWKc7c5oCTlu0EgflKqeoH/qN9wczBZBd2EyojC+rcdFVjbx2sAvbBv9VJjxG M/jXghMZ9/s7DMiGFqNkGh9p5hiXxZJuviNs+LHTWGGzQWSSxDAKcKuwN7j0KaNg = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:date:in-reply-to:references:content-type :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=iApwSYo0QcuV5TXRJE4EMX+clgg=; b=H388jffwrB DS5oE2YdqyF4de3B6mgG8Sek28wXtmBs0x7rlyT8Pp9GkUUB9Xb/6QdOvOJbU0nE gmpPVrsqgkyR1hoc6OlhdLqtNGfqruLMMfpRp/EQg2Kiv4k6IqcNubQ7haK7T+DD 5xVGazCkJOBbpxnasP9ZE//ULso9kEv7E= Received: from [192.168.1.39] (pool-96-231-14-14.washdc.east.verizon.net [96.231.14.14]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id 2E2B2598077; Tue, 30 Aug 2011 21:02:00 -0700 (PDT) From: Matt McCutchen To: Matthew Dempsky Date: Wed, 31 Aug 2011 00:01:58 -0400 In-Reply-To: References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.0.3 Message-ID: <1314763320.2774.5.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 04:00:32 -0000 On Tue, 2011-08-30 at 20:47 -0700, Matthew Dempsky wrote: > I suggested in April 2010 that part of the EDNS0 option code space be > reserved for private use, but it received very little feedback > (positive response from Colm MacC=C3=A1rthaigh, slightly negative from = Paul > Vixie, and some meta discussion about how strictly IANA follows its > instructions on allocating numbers): >=20 > http://www.ietf.org/mail-archive/web/dnsext/current/msg07768.html > http://tools.ietf.org/html/draft-dempsky-edns0-options-for-private-use-= 00 >From the peanut gallery, having a private use range seems like a no-brainer. What is Paul suggesting: don't test EDNS0 options at all before publishing the RFC? --=20 Matt From alex@alex.org.uk Tue Aug 30 23:22:33 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3EB21F8B9B for ; Tue, 30 Aug 2011 23:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aVLLGbf9D5s for ; Tue, 30 Aug 2011 23:22:32 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAE521F8B8B for ; Tue, 30 Aug 2011 23:22:31 -0700 (PDT) Received: from [192.168.100.16] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id F0621C560F0; Wed, 31 Aug 2011 07:23:56 +0100 (BST) Date: Wed, 31 Aug 2011 07:23:55 +0100 From: Alex Bligh To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Message-ID: In-Reply-To: References: <20110830162134.GB84494@shinkuro.com> <7CA8194350F4804F8DF6CAF3@nimrod.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: draft-vandergaast-edns-client-subnet@tools.ietf.org, dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 06:22:33 -0000 --On 30 August 2011 15:14:32 -0700 Colm MacC=C3=A1rthaigh = =20 wrote: > http://www.ietf.org/mail-archive/web/dnsext/current/msg10563.html Apologies - I searched for draft-vandergaast-edns-client-subnet-00 (i.e. with the 'draft-'. --=20 Alex Bligh From alex@alex.org.uk Tue Aug 30 23:24:14 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4011921F8C06 for ; Tue, 30 Aug 2011 23:24:14 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq0W9Vm96ZYP for ; Tue, 30 Aug 2011 23:24:13 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAC721F8BAE for ; Tue, 30 Aug 2011 23:24:13 -0700 (PDT) Received: from [192.168.100.16] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id 1EA3FC560F0; Wed, 31 Aug 2011 07:25:40 +0100 (BST) Date: Wed, 31 Aug 2011 07:25:39 +0100 From: Alex Bligh To: Matt McCutchen , Matthew Dempsky Message-ID: <25C39EB7172A1F87DE68B753@nimrod.local> In-Reply-To: <1314763320.2774.5.camel@localhost> References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> <1314763320.2774.5.camel@localhost> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Paul Vixie , dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 06:24:14 -0000 --On 31 August 2011 00:01:58 -0400 Matt McCutchen wrote: > From the peanut gallery, having a private use range seems like a > no-brainer. +1 -- Alex Bligh From jim@rfc1035.com Wed Aug 31 00:39:48 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BFA21F8C39 for ; Wed, 31 Aug 2011 00:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wmXII4ApHiW for ; Wed, 31 Aug 2011 00:39:48 -0700 (PDT) Received: from hutch.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4F121F8BCD for ; Wed, 31 Aug 2011 00:39:48 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jim) by hutch.rfc1035.com (Postfix) with ESMTPSA id E11FF15420A1; Wed, 31 Aug 2011 08:41:03 +0100 (BST) Message-Id: From: Jim Reid To: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 31 Aug 2011 08:41:03 +0100 References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> X-Mailer: Apple Mail (2.936) Cc: dnsext@ietf.org Subject: [dnsext] a lightweight process for assigning EDNS option codes X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 07:39:48 -0000 On 31 Aug 2011, at 04:23, Colm MacC=E1rthaigh wrote: > How would you feel about proposing more relaxed registry criteria to > IANA (by way of an RFC), similar to how the ports registry works? Sounds like a good idea. > EDNS0 option codes don't appear to be in much demand, so exhaustion > isn't as much of a concern. A process comparable to the one for RRtype code assignment could take =20= care of this. The expert review would provide a sanity check and rate =20= limiter in case we started burning through EDNS option codes. What if =20= marketroids were to decide these are more valuable for vanity purposes =20= than new gTLDs? It's a pity RFC6195 didn't ring-fence some of the EDNS OPT code (and =20 Extended RCODE?) number space for private use and/or experiments just =20= like it did for the RRtype, CLASS and RCODE spaces. From sm@resistor.net Wed Aug 31 00:48:21 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD8B21F8B06 for ; Wed, 31 Aug 2011 00:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuCBr8mbCUMl for ; Wed, 31 Aug 2011 00:48:19 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE1521F8B09 for ; Wed, 31 Aug 2011 00:48:07 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id p7V7nQWe016440; Wed, 31 Aug 2011 00:49:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1314776973; bh=YDTWnKWcEKICnVToIahKV+Pt3kgid+8UsU4DmYQx5NA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=cI8p8nxO2f547hf7iuvECmBVrLc7z6bjsEiWgxw/5Q3emQINU3JvO/d6T6ja/shYS iG6irMzaZHUH/+X335jfcF1BX4jTieFRALc6PufPsz6PheV9feXT+eGc7ghnRgH7Re 4Sra6fxRhM5pE7sGqTxnCO8zREUH7QbXdHyw/Rus= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1314776973; bh=YDTWnKWcEKICnVToIahKV+Pt3kgid+8UsU4DmYQx5NA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=i1HQCykX4eth53j/nIWhq36zo/proUPsuYBTcRlRhzHEateF8Ef/loIsBk2xqR18Y 2PPBe/aOUD5twlMyl0UNfJxAG6vG8o8FYx6BBnT6EPxWV16MxsvrXezuINBJ+gvIbV iuEBaGTtwmMDmejcFx4hkeq89Zf7rP6IfXTloOJU= Message-Id: <6.2.5.6.2.20110830225018.0a31ebc0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 31 Aug 2011 00:15:22 -0700 To: Wilmer van der Gaast From: SM In-Reply-To: References: <20110830162134.GB84494@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 07:48:22 -0000 Hi Wilmer, At 14:10 30-08-2011, Wilmer van der Gaast wrote: >I fully agree. By picking 0x50fa instead of a lower value (it looks >like so far EDNS0 options are assigned sequentially) we certainly >tried to avoid any problems of this kind. Our plan was to use this >temporary option code just to gather data, and with that and a >published experimental RFC, get an official number from IANA. Not at You are running a trial over the Internet. Someone out there will think that it is a good idea and write some code for it. Such code generally lingers around for some time. The above qualifies as an experiment and there was a time when it was documented through an Experimental RFC. The code point was part of the book-keeping, i.e. the person is going to run the experiment no matter what and it is better to have a record of that code point being in use. The number from IANA does not mean that the experiment or even proposed standard specification is a good idea. Assuming that the assignment of code points is always sequential encourages "counter-measures" such as non-sequential assignments to make life difficult for people who make such assumptions. There was a time when conventional wisdom was that the world would not run out of 32-bit numbers. Some people looked at the way the assignments were made and decided that 1.1.1.1 could be used safely. If it takes an Experimental RFC (published) to get that number, it is up to the IETF to see it wants to make it difficult for you to get it. I doubt that people would refrain from using the technology if it makes an "Internet" faster. Regards, -sm From ajs@anvilwalrusden.com Wed Aug 31 04:46:04 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD3821F852C for ; Wed, 31 Aug 2011 04:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KxG9F633uGn for ; Wed, 31 Aug 2011 04:46:03 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id AF47F21F852E for ; Wed, 31 Aug 2011 04:46:03 -0700 (PDT) Received: from shinkuro.com (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 mail.yitter.info (Postfix) with ESMTPSA id 27C251ECB41C for ; Wed, 31 Aug 2011 11:47:33 +0000 (UTC) Date: Wed, 31 Aug 2011 07:47:28 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110831114728.GA99123@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 11:46:04 -0000 On Tue, Aug 30, 2011 at 08:23:51PM -0700, Colm MacCárthaigh wrote: > On Tue, Aug 30, 2011 at 8:12 PM, Andrew Sullivan wrote: > > I actually don't care about the IETF process.  What I do care about is > > the potential for interoperability headaches later because of > > undocumented collisions in EDNS0 option code interpretation.  Avoiding > > that sort of headache is the exact reason we have a registry. > > How would you feel about proposing more relaxed registry criteria to > IANA (by way of an RFC), similar to how the ports registry works? In my personal, no-hat opinion, the registry rule could be made first-come, first-served until (say) 50% of the code space was used up. I see no reason not to do this. The current edns0-bis draft actually moves things in the opposite direction: whereas now the rule is RFC Required, the current draft makes things Standards Action. In my opinion (again no hat), this is the wrong direction to be moving. > EDNS0 option codes don't appear to be in much demand, so exhaustion > isn't as much of a concern. Right. And we could solve that worry by making the relaxed rule automatically tighten after a certain number of the codes are gone anyway, just the way we did for the DNSSEC algorithm numbers. A -- Andrew Sullivan ajs@anvilwalrusden.com From jason_livingood@cable.comcast.com Wed Aug 31 05:37:55 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4FA21F8B31 for ; Wed, 31 Aug 2011 05:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.706 X-Spam-Level: X-Spam-Status: No, score=-102.706 tagged_above=-999 required=5 tests=[AWL=-1.271, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1s2yoSL9ze0L for ; Wed, 31 Aug 2011 05:37:55 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id D01CB21F8B27 for ; Wed, 31 Aug 2011 05:37:54 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.51134156; Wed, 31 Aug 2011 06:45:15 -0600 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Wed, 31 Aug 2011 08:39:21 -0400 From: "Livingood, Jason" To: Jim Reid , =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= Thread-Topic: [dnsext] a lightweight process for assigning EDNS option codes Thread-Index: AQHMZ7FlLPjBYtld2EOljN6M0mkcoZU25p6A Date: Wed, 31 Aug 2011 12:39:21 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <836139C6791ECB45A076BD277D0683C7@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] a lightweight process for assigning EDNS option codes X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 12:37:55 -0000 There's always a registration path similar to ENUMservices, a la RFC 6117. This allows for both an RFC-published path and non-RFC path to registration. http://tools.ietf.org/html/rfc6117 Jason On 8/31/11 3:41 AM, "Jim Reid" wrote: >On 31 Aug 2011, at 04:23, Colm MacC=E1rthaigh wrote: > >> How would you feel about proposing more relaxed registry criteria to >> IANA (by way of an RFC), similar to how the ports registry works? > >Sounds like a good idea. > >> EDNS0 option codes don't appear to be in much demand, so exhaustion >> isn't as much of a concern. > >A process comparable to the one for RRtype code assignment could take >care of this. The expert review would provide a sanity check and rate >limiter in case we started burning through EDNS option codes. What if >marketroids were to decide these are more valuable for vanity purposes >than new gTLDs? > >It's a pity RFC6195 didn't ring-fence some of the EDNS OPT code (and >Extended RCODE?) number space for private use and/or experiments just >like it did for the RRtype, CLASS and RCODE spaces. > >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext From wilmer@google.com Wed Aug 31 06:42:35 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934DD21F8B48 for ; Wed, 31 Aug 2011 06:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iqeeo5Yz-7QI for ; Wed, 31 Aug 2011 06:42:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id A256A21F8B57 for ; Wed, 31 Aug 2011 06:42:34 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p7VDi3jQ004137 for ; Wed, 31 Aug 2011 06:44:03 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314798244; bh=TuFFCluw+knq0D+iiOKrI23XccY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Kc+5i/rqLN9QhT1FWrNtLBg2LC4oLZdOO0aEExOfcruXiAbQeOytyjEbxGYybsfBk 9nKDiVZBgI+QcGOVgMgjw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=Nw+zWg9gWRvjxrDnKPyjvESd288U/c9wLzONLf7gtIIc69I4m12pZvbTBBoNZ6Q8E HJ7TfOGPpcamQ7c6OpduA== Received: from gyd5 (gyd5.prod.google.com [10.243.49.197]) by wpaz37.hot.corp.google.com with ESMTP id p7VDi1O5023501 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 31 Aug 2011 06:44:02 -0700 Received: by gyd5 with SMTP id 5so617458gyd.29 for ; Wed, 31 Aug 2011 06:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=aUkvqgtMl6AzmzmsQzVLjifD4ZkJxjlF+fb5nW7EfIQ=; b=TSqduxQwF/ZzWjI34nu1bXnieOHp0vMKTIsvnIO8IpvydVXwY07JHXHYl7Rp7RHmm5 e+ZuShg9POE+iwmqWzrA== Received: by 10.101.73.5 with SMTP id a5mr304436anl.142.1314798241788; Wed, 31 Aug 2011 06:44:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.73.5 with SMTP id a5mr304411anl.142.1314798240071; Wed, 31 Aug 2011 06:44:00 -0700 (PDT) Received: by 10.100.124.10 with HTTP; Wed, 31 Aug 2011 06:43:59 -0700 (PDT) In-Reply-To: <20110831114728.GA99123@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> <20110831114728.GA99123@shinkuro.com> Date: Wed, 31 Aug 2011 14:43:59 +0100 Message-ID: From: Wilmer van der Gaast To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 13:42:35 -0000 On 31 August 2011 12:47, Andrew Sullivan wrote: >> How would you feel about proposing more relaxed registry criteria to >> IANA (by way of an RFC), similar to how the ports registry works? > In my personal, no-hat opinion, the registry rule could be made > first-come, first-served until (say) 50% of the code space was used > up. =A0I see no reason not to do this. > +1 > The current edns0-bis draft actually moves things in the opposite > direction: whereas now the rule is RFC Required, the current draft > makes things Standards Action. =A0In my opinion (again no hat), this is > the wrong direction to be moving. > Which draft are you reading here exactly? It's entirely possible that I'm misreading, but http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-05#section-9 seems to say Standards Action is required for: * new RCODEs * new EDNS0 flags * new EDNSx versions For a new option code, only expert review will be required: "Expert Review is required for allocation of an EDNS Option Code." I'm also definitely in favour of the private-range idea. If for example 0xff00-0xff7f could be reserved for experiments, I'll happily get everyone on the edns-client-subnet experiment to switch. I'm even willing to leave out backward compatibility on our end to encourage switching ASAP. :-) Cheers, --=20 Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From wilmer@google.com Wed Aug 31 07:17:20 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1203721F8B5E for ; Wed, 31 Aug 2011 07:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SS-UNuMXeBQh for ; Wed, 31 Aug 2011 07:17:19 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 10B4321F8AB9 for ; Wed, 31 Aug 2011 07:17:18 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p7VEIgKf015219 for ; Wed, 31 Aug 2011 07:18:44 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314800325; bh=SUOCl3/cbLYTiLfmTZYSu5k+Hfw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Iy8b5hIEoDJPa3PzS7YMdhSLXyb0MsTjO83scnfrDlCK7gIHnJCCAzC/IybYJTBge VGQwcM+a90pvhLHKwGhEg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=kNog4s2EGnikPDAZmuJH+q6QGm03wcSAtD+ITRuACqmWTT2xelF8EDRbTso3o7FJ6 XVpEJhUtmxGJBo3DPcBUg== Received: from ywf9 (ywf9.prod.google.com [10.192.6.9]) by hpaq14.eem.corp.google.com with ESMTP id p7VEIT0G005107 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 31 Aug 2011 07:18:41 -0700 Received: by ywf9 with SMTP id 9so824300ywf.32 for ; Wed, 31 Aug 2011 07:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=95cxsw1lTEyr/br9e86z4FAAWPri74EYyyNUvO1Herc=; b=VjXLJPtNHvjOqe/ATjwRrS/o2ES/rVp94kcnb9WKne+2X4NrW+GsMwcJYbq4shDBjZ /g8fhN9Ntgi2svaPxbAQ== Received: by 10.101.164.25 with SMTP id r25mr109840ano.10.1314800320915; Wed, 31 Aug 2011 07:18:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.164.25 with SMTP id r25mr109830ano.10.1314800320610; Wed, 31 Aug 2011 07:18:40 -0700 (PDT) Received: by 10.100.124.10 with HTTP; Wed, 31 Aug 2011 07:18:40 -0700 (PDT) In-Reply-To: <20110831005457.GA459@debian> References: <20110830162134.GB84494@shinkuro.com> <7CA8194350F4804F8DF6CAF3@nimrod.local> <20110831005457.GA459@debian> Date: Wed, 31 Aug 2011 15:18:40 +0100 Message-ID: From: Wilmer van der Gaast To: Jaidev Sridhar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 14:17:20 -0000 Hello Jaidev, 2011/8/31 Jaidev Sridhar : > > Reading through the draft, I have a question about the NAT section which > says: > [..] I just realised, after looking through our revision history, that we haven't made any changes to the NAT section since edns-client-ip-00 (i.e. January 2010). Since then we have made some changes to transitive behaviour so there are definitely some contradictions to be found here. The original purpose of the section was to sum up some things that may seem clever but should not be done. > I understand why one wouldn't want NAT devices to change a client subnet > address (testing, anonymizer, etc.) but why does the draft say a NAT > device _MUST_ not add a client subnet option? > I think the original idea here was "the recursive resolver will, if it wants, add an edns-client-subnet option using the source IP it sees" -=3D> there should be no need for a NAT device to do it, and generally I do still think a NAT device shouldn't try to be smarter than necessary. > =A0 Note that Authoritative Nameservers or Recursive Resolvers can still > =A0 provide an optimized reply by looking at the source IP of the query. > > When the recursive resolver is behind NAT, the authoritative nameserver > will only know the address of the NAT device, which will not be useful > for geo-location at all with big-bad-NATs. > > Any reason for NAT being excluded this way? > See the explanation above. Thank you for your reminder here, not updating the NAt section at all was definitely an oversight, we'll rewrite it for edns-client-subnet-01. The big-bad-NAT use case is also not a scenario we thought of so far. It's also a pretty hard one to support without putting a lot of additional intelligence into resolvers (i.e. a mapping of internal IP addresses to their external equivalents). I'd like to know if any implementor is actually willing to implement that. Cheers, --=20 Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From ajs@anvilwalrusden.com Wed Aug 31 07:24:27 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA2321F8B59 for ; Wed, 31 Aug 2011 07:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR8xq7Nbku5M for ; Wed, 31 Aug 2011 07:24:27 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id EF90F21F8B1B for ; Wed, 31 Aug 2011 07:24:26 -0700 (PDT) Received: from shinkuro.com (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 mail.yitter.info (Postfix) with ESMTPSA id 81A751ECB41C; Wed, 31 Aug 2011 14:25:56 +0000 (UTC) Date: Wed, 31 Aug 2011 10:25:58 -0400 From: Andrew Sullivan To: Wilmer van der Gaast Message-ID: <20110831142557.GB99260@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> <20110831114728.GA99123@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 14:24:28 -0000 On Wed, Aug 31, 2011 at 02:43:59PM +0100, Wilmer van der Gaast wrote: > Which draft are you reading here exactly? > > For a new option code, only expert review will be required: "Expert > Review is required for allocation of an EDNS Option Code." Oh, phew, and stupid me. I was really really surprised when I (thought I) saw what I did when I checked it earlier. That'll teach me to do such readings in a hurry. You're quite right. And (again no hat) expert review is, IMO, better than RFC required, but I'd still prefer FCFS. A -- Andrew Sullivan ajs@anvilwalrusden.com From wilmer@google.com Wed Aug 31 07:56:31 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C0821F8802 for ; Wed, 31 Aug 2011 07:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2zEYaLLy-7r for ; Wed, 31 Aug 2011 07:56:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC7721F8686 for ; Wed, 31 Aug 2011 07:56:30 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p7VEw0Vx031268 for ; Wed, 31 Aug 2011 07:58:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314802680; bh=tDD6vnW98TCRK/Hj1fT0QSJ0v8E=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=TBHLD5LKnK47AmlH7/nV+qmIlde6EOI8FBaW+FfLvxJfv/B/f5R1gBELbIkOjGCtk XYcPfIlb/nual3+NzIMnQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=OVGMOZnCxlqG6wt9F3zlH9RPxYQClRCVDFr8ChKAfggHaU74hp7j6pBxNdypI7tgB vRBKY0SCbXPgTHnx8EkLA== Received: from yib12 (yib12.prod.google.com [10.243.65.76]) by wpaz1.hot.corp.google.com with ESMTP id p7VEuw3d028962 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 31 Aug 2011 07:57:59 -0700 Received: by yib12 with SMTP id 12so573784yib.10 for ; Wed, 31 Aug 2011 07:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/IIR+dTqIrwqgNusjhdOU7KbclKqDYOTo3bid4gctBs=; b=PMNze7udq6Mjxsrld4CH3CUTl8pP/9NHD7VAuqNXlUS6vpk8yy2ioTmkFyrY9Ca4aK 1DvC4SUyXYvnQA9Bot/w== Received: by 10.101.164.25 with SMTP id r25mr152544ano.10.1314802677011; Wed, 31 Aug 2011 07:57:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.164.25 with SMTP id r25mr152527ano.10.1314802675703; Wed, 31 Aug 2011 07:57:55 -0700 (PDT) Received: by 10.100.124.10 with HTTP; Wed, 31 Aug 2011 07:57:55 -0700 (PDT) In-Reply-To: <20110831142557.GB99260@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> <20110831114728.GA99123@shinkuro.com> <20110831142557.GB99260@shinkuro.com> Date: Wed, 31 Aug 2011 15:57:55 +0100 Message-ID: From: Wilmer van der Gaast To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 14:56:31 -0000 On 31 August 2011 15:25, Andrew Sullivan wrote: >> For a new option code, only expert review will be required: "Expert >> Review is required for allocation of an EDNS Option Code." > You're quite right. =A0And (again no hat) expert review is, IMO, better > than RFC required, but I'd still prefer FCFS. > Agreed. However, we're still quoting an I-D here and not an RFC. I assume we need this draft published before the policy can be followed. (But please do correct me if I'm wrong.) From the last discussion about it (May 2011) it looks to me like the author is still working on a -06 so we're not there yet. Which means that for now edns-client-subnet needs to be published as an experimental RFC, which I assume can't be done in just a few weeks.. We really would like to proceed with the experiment because we need to collect data to decide if edns-client-subnet is worth implementing. This can't be done in a closed lab. By the way, I noticed not all EDNS0 option codes on http://www.iana.org/assignments/dns-parameters have RFC numbers behind them. Under what condition were these option codes assigned, and would it be possible to assign one to edns-client-subnet under similar conditions? Cheers, --=20 Wilmer van der Gaast, Traffic SRE/Google Public DNS team. Google Ireland. From ted.ietf@gmail.com Wed Aug 31 08:58:38 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C92621F8CAE for ; Wed, 31 Aug 2011 08:58:38 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUDC58kjkVC7 for ; Wed, 31 Aug 2011 08:58:37 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5774C21F877F for ; Wed, 31 Aug 2011 08:58:37 -0700 (PDT) Received: by gwb20 with SMTP id 20so223585gwb.31 for ; Wed, 31 Aug 2011 09:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Iefa8oHBx8Ha87bDf0RwmlN5i1tCTTziHbGadRARm7M=; b=e2thylrTdwjjqdb2bjMhIciU6FmHXfsFcmvxyeQz2WNJ3sHbLDRMZSeBsSeooOBIC/ 18Oum/kPn6ds2XV1WrqRkXK7PZpV72nc1usf4S10Vxzs2K4+UBGwQADlUzCeQkrrISNJ 2oNkVyXKkOwQarMKc+h7IC4SITkKiQ27KjL2M= MIME-Version: 1.0 Received: by 10.236.183.164 with SMTP id q24mr2981928yhm.117.1314806407798; Wed, 31 Aug 2011 09:00:07 -0700 (PDT) Received: by 10.236.110.174 with HTTP; Wed, 31 Aug 2011 09:00:07 -0700 (PDT) In-Reply-To: <20110831142557.GB99260@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> <20110831114728.GA99123@shinkuro.com> <20110831142557.GB99260@shinkuro.com> Date: Wed, 31 Aug 2011 09:00:07 -0700 Message-ID: From: Ted Hardie To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 15:58:38 -0000 On Wed, Aug 31, 2011 at 7:25 AM, Andrew Sullivan w= rote: > On Wed, Aug 31, 2011 at 02:43:59PM +0100, Wilmer van der Gaast wrote: > >> Which draft are you reading here exactly? > >> >> For a new option code, only expert review will be required: "Expert >> Review is required for allocation of an EDNS Option Code." > > Oh, phew, and stupid me. =A0I was really really surprised when I > (thought I) saw what I did when I checked it earlier. =A0That'll teach > me to do such readings in a hurry. > > You're quite right. =A0And (again no hat) expert review is, IMO, better > than RFC required, but I'd still prefer FCFS. > > A > I think FCFS works fine for unbounded spaces, but I'm nervous about a blended model where there are easy registrations up until exhaustion looks likely, then it gets restricted. We have lots of evidence that this causes grumpiness in the IP allocation side of the house. Expert review, with clear instructions to reviewer (e.g. that this is not duplicate functionality) seems more likely to get what you want. The trick is in the clear instructions to the reviewer, especially when the reviewer is actually a list with changing membership.... regards, TEd From ted.ietf@gmail.com Wed Aug 31 09:02:04 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E797421F8CF5 for ; Wed, 31 Aug 2011 09:02:04 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReGadCtJhz+B for ; Wed, 31 Aug 2011 09:02:04 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3634A21F8CF4 for ; Wed, 31 Aug 2011 09:02:04 -0700 (PDT) Received: by yie12 with SMTP id 12so862594yie.31 for ; Wed, 31 Aug 2011 09:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=N9+XyXLCrUcbFAcBQeHQCBzL+JpKCgBRkux6aY05edQ=; b=rC2VbzeIVsUwEGd8YFH8Ogs90auM36n4MTbseShPZSUgpqpmQbwFa0mOIOkVb4kHni HtcpcdV45t1/a/k2kjdbuf2RpPjyhRwWSabZeenC81DNzt6lKiflT2ag1CM+bYLxOo9O 2tAtNVhaGa2hu4h6UW5FRiY+tblRC+ZAwwxjI= MIME-Version: 1.0 Received: by 10.236.115.70 with SMTP id d46mr3120674yhh.83.1314806614660; Wed, 31 Aug 2011 09:03:34 -0700 (PDT) Received: by 10.236.110.174 with HTTP; Wed, 31 Aug 2011 09:03:34 -0700 (PDT) In-Reply-To: <20110830162134.GB84494@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> Date: Wed, 31 Aug 2011 09:03:34 -0700 Message-ID: From: Ted Hardie To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:02:05 -0000 As a question to the chairs, the new draft is kind enough to list the changes since the previous version, and one of the authors previously summarized this to the list as: * Rewrote origination sections to clarify that normally only recursive resolvers generate edns-client-subnet options. * Discussion on whitelisting or automatically detecting if an authority supports edns-client-subnet. * More precisely specifying (optional) transitive behaviour. * Minor revisions to improve clarity and correctness w.r.t. other RFCs. None of these changes seem to address the balance of discussion of the previous two versions. Do the chairs intend to open this for full discussi= on again, or is it your opinion that the code point allocation in an Experimen= tal RFC does not need to address these issues? regards, Ted Hardie On Tue, Aug 30, 2011 at 9:21 AM, Andrew Sullivan w= rote: > Dear authors of draft-vandergaast-edns-client-subnet-00: > > The site http://www.afasterinternet.com came to our attention. > > It appears to us that you are undertaking a trial deployment of > draft-vandergaast-edns-client-subnet-00, and that you are soliciting > people to participate in the client portion of this trial. =A0We think > this is, in effect, a limited public trial on the public Internet. > > We would like to urge you, very strongly, to obtain an actual EDNS0 > option code assignment from IANA prior to proceeding with this trial. > By failing to obtain such a code, and by releasing your software to > the Internet, you are potentially polluting the EDNS0 option code > space. > > We are aware of the obstacles to obtaining such an option code, but we > believe that the benefits of a faster Internet, which you are avowedly > attempting to deliver, will only really be benefits if they don't > break others' software, either now or in the future. =A0By using a > completely unassigned option code, as you must be doing, you are > risking colliding with another assignment. > > In order to obtain the option code, all that is needed is an RFC to be > published. =A0We stand ready and willing to help you pursue that > publication, particularly since you intend your protocol to be > experimental. > > Best regards, > > Andrew and Olafur > (co-chairs of the DNSEXT working group, but speaking only for ourselves.) > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From ajs@anvilwalrusden.com Wed Aug 31 09:26:14 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2310921F8B66 for ; Wed, 31 Aug 2011 09:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WflJ1tQdc4Y0 for ; Wed, 31 Aug 2011 09:26:13 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 91A2221F8678 for ; Wed, 31 Aug 2011 09:26:13 -0700 (PDT) Received: from shinkuro.com (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 mail.yitter.info (Postfix) with ESMTPSA id 8DD0F1ECB41C for ; Wed, 31 Aug 2011 16:27:43 +0000 (UTC) Date: Wed, 31 Aug 2011 12:27:45 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20110831162745.GH99260@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> <20110831031256.GA98758@shinkuro.com> <20110831114728.GA99123@shinkuro.com> <20110831142557.GB99260@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 16:26:14 -0000 On Wed, Aug 31, 2011 at 03:57:55PM +0100, Wilmer van der Gaast wrote: > However, we're still quoting an I-D here and not an RFC. I assume we > need this draft published before the policy can be followed. (But > please do correct me if I'm wrong.) From the last discussion about it > (May 2011) it looks to me like the author is still working on a -06 so > we're not there yet. Exactly correct. > Which means that for now edns-client-subnet needs to be published as > an experimental RFC, which I assume can't be done in just a few > weeks. Probably not a few weeks, no. > By the way, I noticed not all EDNS0 option codes on > http://www.iana.org/assignments/dns-parameters have RFC numbers behind > them. Under what condition were these option codes assigned, and would > it be possible to assign one to edns-client-subnet under similar > conditions? Yes. I have no idea how those were assigned, but when I asked IANA about it they said they have to follow the rule. Perhaps previous IANA administration had a different approach or something; I don't know. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Wed Aug 31 10:29:17 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAE821F8DC4 for ; Wed, 31 Aug 2011 10:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF400NZbmKPX for ; Wed, 31 Aug 2011 10:29:16 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id C508C21F8DA3 for ; Wed, 31 Aug 2011 10:29:16 -0700 (PDT) Received: from shinkuro.com (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 mail.yitter.info (Postfix) with ESMTPSA id CFF6F1ECB41C; Wed, 31 Aug 2011 17:30:41 +0000 (UTC) Date: Wed, 31 Aug 2011 13:30:43 -0400 From: Andrew Sullivan To: Ted Hardie Message-ID: <20110831173043.GK99260@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 17:29:17 -0000 On Wed, Aug 31, 2011 at 09:03:34AM -0700, Ted Hardie wrote: > again, or is it your opinion that the code point allocation in an Experimental > RFC does not need to address these issues? Olafur and I consulted over this, and here is our opinion as chairs. Note that we've been wrong before. As a pure matter of the rules, it is our opinion that the code point allocation does not need to address any objections to the idea. The rule is only "RFC Required". An Experimental track RFC is an RFC, and therefore it would qualify. One might take issue with the experiment itself, and one might take issue with what the experiment is attempting to prove, but none of that would be reason to refuse to publish the RFC nor to deny the allocation of a code point. So, any RFC will do. Even an RFC that simply says, "IANA considerations: IANA allocate EDNS0 option NETMASK code TBD. The option is a text string of one of the following formats: 'IP4_addr/mask' or 'IPv6_addr/mask'", along with perhaps a section that says by way of introduction, "This document specifies the NETMASK EDNS0 option, but does not specify its use." Taking my hat off, I note that, if this opinion is correct, RFC Required appears to become a lower bar than Expert Review. I am not sure that the IESG would agree with our interpretation, therefore. A -- Andrew Sullivan ajs@anvilwalrusden.com From ted.ietf@gmail.com Wed Aug 31 11:21:49 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D3821F8CC3 for ; Wed, 31 Aug 2011 11:21:49 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+YzHtdnbeWQ for ; Wed, 31 Aug 2011 11:21:48 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7F021F8CC1 for ; Wed, 31 Aug 2011 11:21:48 -0700 (PDT) Received: by yie12 with SMTP id 12so1003701yie.31 for ; Wed, 31 Aug 2011 11:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FKtdRJhkenInXfrWdybXjegOEZqPHMon6wMdfQ7dCok=; b=ZRj3P54zwMLF0Q0edCBjYCDocrgrE3LdSssaAWZYaS6JdexFbm0D09MIgFOQY5oKyI 29vCgrXkCIFHdaMeZGQP8nnn4nQ2PuREEeYOqKd6mH98VaKio9QqGQIc1XOF7ktpztcy zSko/eYRTeNgoOtatpTs94z6U663atdKNEBN0= MIME-Version: 1.0 Received: by 10.236.182.40 with SMTP id n28mr4069724yhm.49.1314814997393; Wed, 31 Aug 2011 11:23:17 -0700 (PDT) Received: by 10.236.110.174 with HTTP; Wed, 31 Aug 2011 11:23:17 -0700 (PDT) In-Reply-To: <20110831173043.GK99260@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> <20110831173043.GK99260@shinkuro.com> Date: Wed, 31 Aug 2011 11:23:17 -0700 Message-ID: From: Ted Hardie To: Andrew Sullivan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 18:21:49 -0000 On Wed, Aug 31, 2011 at 10:30 AM, Andrew Sullivan wrote: > On Wed, Aug 31, 2011 at 09:03:34AM -0700, Ted Hardie wrote: >> again, or is it your opinion that the code point allocation in an Experi= mental >> RFC does not need to address these issues? > > Olafur and I consulted over this, and here is our opinion as chairs. > Note that we've been wrong before. > > As a pure matter of the rules, it is our opinion that the code point > allocation does not need to address any objections to the idea. =A0The > rule is only "RFC Required". =A0An Experimental track RFC is an RFC, and > therefore it would qualify. =A0One might take issue with the experiment > itself, and one might take issue with what the experiment is > attempting to prove, but none of that would be reason to refuse to > publish the RFC nor to deny the allocation of a code point. > > So, any RFC will do. =A0Even an RFC that simply says, "IANA > considerations: IANA allocate EDNS0 option NETMASK code TBD. =A0The > option is a text string of one of the following formats: > 'IP4_addr/mask' or 'IPv6_addr/mask'", along with perhaps a section > that says by way of introduction, "This document specifies the NETMASK > EDNS0 option, but does not specify its use." > > Taking my hat off, I note that, if this opinion is correct, RFC > Required appears to become a lower bar than Expert Review. =A0I am not > sure that the IESG would agree with our interpretation, therefore. > > A Traditionally expert review has been a lower bar than RFC required because you have to convince someone that it's a good idea to publish the RFC (The independent stream editor, some working group, some AD). That's not been trivial, and it usual comes with questions about the track. An experimental RFC, for example, might be tasked with describing the experiment and what results would constitute success. I can't really see the internet-draft text you cite above passing IETF last call without a few questions. We have seen some docs where the registration document is recognition of a de facto use that is being codified to avoid collision, but even those describe what's going on. Doing that too often with code points that aren't unlimited has, of course, obvious failure conditions. You and Olafur previously said (as individuals) "We stand ready and willing to help you pursue that publication, particularly since you intend your protocol to be experimental.". Since this was evidently not through the working group, did you intend AD sponsorship or an independent stream submission? regards, Ted Hardie From ajs@anvilwalrusden.com Wed Aug 31 11:49:42 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0366821F8E7B for ; Wed, 31 Aug 2011 11:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvlwVe+RlUcT for ; Wed, 31 Aug 2011 11:49:41 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 49FAF21F8E6C for ; Wed, 31 Aug 2011 11:49:41 -0700 (PDT) Received: from shinkuro.com (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 mail.yitter.info (Postfix) with ESMTPSA id 840C41ECB41C; Wed, 31 Aug 2011 18:51:06 +0000 (UTC) Date: Wed, 31 Aug 2011 14:51:07 -0400 From: Andrew Sullivan To: Ted Hardie Message-ID: <20110831185107.GO99260@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> <20110831173043.GK99260@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 18:49:42 -0000 On Wed, Aug 31, 2011 at 11:23:17AM -0700, Ted Hardie wrote: > Traditionally expert review has been a lower bar than RFC required > because you have to convince someone that it's a good idea to publish > the RFC (The independent stream editor, some working group, some AD). > That's not been trivial, and it usual comes with questions about the > track. An experimental RFC, for example, might be tasked with > describing the experiment and what results would constitute success. Right. > You and Olafur previously said (as individuals) "We stand ready and > willing to help > you pursue that publication, particularly since you intend your > protocol to be experimental.". > Since this was evidently not through the working group, did you intend > AD sponsorship or an > independent stream submission? I can't speak for Olafur, but I am prepared to do whatever the authors want. To my mind, it is considerably more valuable that we have stable documentation of the use of this option code than it is that we do things in this or that way. To me, if the experiment goes ahead as is currently planned, we have to mark the option code as used anyway. A -- Andrew Sullivan ajs@anvilwalrusden.com From mohta@necom830.hpcl.titech.ac.jp Wed Aug 31 12:21:06 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807B621F8EF0 for ; Wed, 31 Aug 2011 12:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMNNHOst5oYF for ; Wed, 31 Aug 2011 12:21:06 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 9C4F121F8EE4 for ; Wed, 31 Aug 2011 12:21:05 -0700 (PDT) Received: (qmail 48658 invoked from network); 31 Aug 2011 19:27:37 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 31 Aug 2011 19:27:37 -0000 Message-ID: <4E5E89C1.2000307@necom830.hpcl.titech.ac.jp> Date: Thu, 01 Sep 2011 04:21:37 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Wilmer van der Gaast References: <20110830162134.GB84494@shinkuro.com> <7CA8194350F4804F8DF6CAF3@nimrod.local> <20110831005457.GA459@debian> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 19:21:06 -0000 Wilmer van der Gaast wrote: > 2011/8/31 Jaidev Sridhar : >> When the recursive resolver is behind NAT, the authoritative nameserver >> will only know the address of the NAT device, which will not be useful >> for geo-location at all with big-bad-NATs. Wrong. NAT, in this case, is only as bad as a DHCP server with a large number of clients, addresses of which are assigned randomly and dynamically. It is dynamic assignment of addresses or addresses and port numbers which makes geo-location (and address based black listing) not very useful. NAT with fixed port forwarding is fine, as long as geo-location is based on not only addresses but also port numbers. The problem of NAT against client-subnet option is that DNS messages with strange options may be destroyed on some implementations of NAT. Masataka Ohta From alex@alex.org.uk Wed Aug 31 15:07:24 2011 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201D221F8EAA for ; Wed, 31 Aug 2011 15:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYH-hmeX8HQn for ; Wed, 31 Aug 2011 15:07:22 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id C5FE221F8E99 for ; Wed, 31 Aug 2011 15:07:21 -0700 (PDT) Received: from [192.168.100.16] (87-194-71-186.bethere.co.uk [87.194.71.186]) by mail.avalus.com (Postfix) with ESMTPSA id D2033C5602B; Wed, 31 Aug 2011 23:08:48 +0100 (BST) Date: Wed, 31 Aug 2011 23:08:47 +0100 From: Alex Bligh To: Andrew Sullivan , Ted Hardie Message-ID: In-Reply-To: <20110831173043.GK99260@shinkuro.com> References: <20110830162134.GB84494@shinkuro.com> <20110831173043.GK99260@shinkuro.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Alex Bligh List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 22:07:24 -0000 --On 31 August 2011 13:30:43 -0400 Andrew Sullivan wrote: > Taking my hat off, I note that, if this opinion is correct, RFC > Required appears to become a lower bar than Expert Review. I am not > sure that the IESG would agree with our interpretation, therefore. Concentrating on the practical results of our deliberations rather than the way we got there, and speaking as someone who is sceptical about the draft in question, it seems to me that it would be a bad thing if a draft like this (which whilst I might not like it, is certainly not entirely speculative) neither can get a RFC1918-style allocation, nor relatively easily achieve a 'proper' allocation; it's only going to encourage people to self-allocate, and we are hardly short of code points. Given there has to be some hurdle to getting a real allocation, I think we should do both - assigning 256 code points to RFC1918-style use (i.e. 'beware - your number may clash with other RFC1918-style stuff but won't clash with a real allocation') seems to me a no-brainer. -- Alex Bligh