From wwwrun@rfc-editor.org Mon Dec 31 08:01:00 2012 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 9D54B21F858A for ; Mon, 31 Dec 2012 08:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.181 X-Spam-Level: X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 gSw0howyLxZc for ; Mon, 31 Dec 2012 08:01:00 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id EC27B21F8584 for ; Mon, 31 Dec 2012 08:00:59 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0EA85B1E002; Mon, 31 Dec 2012 07:51:10 -0800 (PST) To: ben@links.org, geoff-s@panix.com, roy@nominet.org.uk, davidb@verisign.com, rdroms.ietf@gmail.com, brian@innovationslab.net, ogud@ogud.com, ajs@anvilwalrusden.com From: RFC Errata System Message-Id: <20121231155110.0EA85B1E002@rfc-editor.org> Date: Mon, 31 Dec 2012 07:51:10 -0800 (PST) X-Mailman-Approved-At: Tue, 01 Jan 2013 15:16:36 -0800 Cc: ed.lewis@neustar.biz, dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] [Technical Errata Reported] RFC5155 (3441) 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, 31 Dec 2012 16:01:01 -0000 The following errata report has been submitted for RFC5155, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=3441 -------------------------------------- Type: Technical Reported by: Edward Lewis Section: 7.2.3 & 8.5 Original Text ------------- 7.2.3 (contents) 8.5 (contents) Corrected Text -------------- 7.2.3. No Data Responses, QTYPE is not DS If the No Data Response is a result of an empty non-terminal derived from an insecure delegation covered by an Opt-Out NSEC3 RR, the closest provable encloser proof MUST be included in the response. The included NSEC3 RR that covers the "next closer" name for the delegation MUST have the Opt-Out flag set to one. In all other cases, the server MUST include the NSEC3 RR that matches QNAME. This NSEC3 RR MUST NOT have the bits corresponding to either the QTYPE or CNAME set in its Type Bit Maps field. =============================================== 8.5. Validating No Data Responses, QTYPE is not DS If there is an NSEC3 RR that matches QNAME present, the validator must check that both the QTYPE and the CNAME type are not set in its Type Bit Maps field. Note that this test also covers the case where the NSEC3 RR exists because it corresponds to an empty non-terminal, in which case the NSEC3 RR will have an empty Type Bit Maps field. If there is no NSEC3 RR present that matches QNAME, then the validator MUST verify a closest provable encloser proof for the QNAME. The validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that covers the "next closer" name to the delegation name. This test covers the case where the response is due to an Empty Non-Terminal derived from an insecure delegation covered by an Opt-Out NSEC3 RR. Notes ----- The corrections were derived from a private email from an editor of RFC 5155. Note that the ordering of the paragraphs in the proposed 8.5 fix has been changed. No other change is intentional. >From Roy Arends: We missed documenting the case of what a server and a validator should do in case of an opted-out, multi-label delegation. We did make it clear in signing (7.1). This is also not part of the demo zone, included in RFC5155. As suggested text for an errata, may I offer: 7.2.3. No Data Responses, QTYPE is not DS If the No Data Response is a result of an empty non-terminal derived from an insecure delegation covered by an Opt-Out NSEC3 RR, the closest provable encloser proof MUST be included in the response. The included NSEC3 RR that covers the "next closer" name for the delegation MUST have the Opt-Out flag set to one. In all other cases, the server MUST include the NSEC3 RR that matches QNAME. This NSEC3 RR MUST NOT have the bits corresponding to either the QTYPE or CNAME set in its Type Bit Maps field. 8.5. Validating No Data Responses, QTYPE is not DS If there is no NSEC3 RR present that matches QNAME, then the validator MUST verify a closest provable encloser proof for the QNAME. The validator MUST verify that the Opt-Out bit is set in the NSEC3 RR that covers the "next closer" name to the delegation name. This test covers the case where the response is due to an Empty Non-Terminal derived from an insecure delegation covered by an Opt-Out NSEC3 RR. If there is an NSEC3 RR that matches QNAME present, the validator must check that both the QTYPE and the CNAME type are not set in its Type Bit Maps field. Note that this test also covers the case where the NSEC3 RR exists because it corresponds to an empty non-terminal, in which case the NSEC3 RR will have an empty Type Bit Maps field. The following message is the singularly most important one in the errata submission, from David Blacka, commenting on the order of the paragraphs: http://www.ietf.org/mail-archive/web/dnsext/current/msg12835.html The heads of the threads to review: http://www.ietf.org/mail-archive/web/dnsext/current/msg12819.html http://www.ietf.org/mail-archive/web/dnsext/current/msg12821.html http://www.ietf.org/mail-archive/web/dnsext/current/msg12830.html http://www.ietf.org/mail-archive/web/dnsext/current/msg12832.html http://www.ietf.org/mail-archive/web/dnsext/current/msg12839.html http://www.ietf.org/mail-archive/web/dnsext/current/msg12854.html and http://www.ietf.org/mail-archive/web/dnsext/current/msg12864.html Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5155 (draft-ietf-dnsext-nsec3-13) -------------------------------------- Title : DNS Security (DNSSEC) Hashed Authenticated Denial of Existence Publication Date : March 2008 Author(s) : B. Laurie, G. Sisson, R. Arends, D. Blacka Category : PROPOSED STANDARD Source : DNS Extensions Area : Internet Stream : IETF Verifying Party : IESG From iesg-secretary@ietf.org Thu Jan 3 09:32:31 2013 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 3A78611E809C; Thu, 3 Jan 2013 09:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 ayJKpYgccLvs; Thu, 3 Jan 2013 09:32:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0F721F86D2; Thu, 3 Jan 2013 09:32:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130103173230.32293.58026.idtracker@ietfa.amsl.com> Date: Thu, 03 Jan 2013 09:32:30 -0800 Cc: iesg@ietf.org, dnsext-chairs@tools.ietf.org, dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] Protocol Action: 'Automated Updates of DNSSEC Trust Anchors' to Internet Standard (RFC 5011) 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, 03 Jan 2013 17:32:31 -0000 The IESG has approved the following document: - 'Automated Updates of DNS Security (DNSSEC) Trust Anchors,' RFC 5011 as an Internet Standard. This document is the product of the DNS Extensions Working Group. = A URL of this document is: https://datatracker.ietf.org/doc/rfc5011/ Abstract: = This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s). This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. From sm@resistor.net Wed Jan 9 10:32:13 2013 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 2E00621F8479 for ; Wed, 9 Jan 2013 10:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 651h8BdA3yKV for ; Wed, 9 Jan 2013 10:32:12 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B8521F8472 for ; Wed, 9 Jan 2013 10:32:12 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r09IW6er019117 for ; Wed, 9 Jan 2013 10:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1357756330; bh=X9edZyZGpweE37Kb9TSZ66uWhOX52XDkwx94vEnukH4=; h=Date:To:From:Subject; b=gv6TGSHYs+6lFPm81kZi/8+ELxd5KCnVIVuCkgDtSMM/8y/+NQugPEtj9i9Nhm+B2 eqQAyjoDxl2FwaWvOC0/cm/allqROsuy21q5oxs04e8Kybsqj4NcagvCl9ZqRlgMOK 8leBO9+yr922CWTp/efVKqwwM+lQYJQR8KTOk4ME= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1357756330; i=@resistor.net; bh=X9edZyZGpweE37Kb9TSZ66uWhOX52XDkwx94vEnukH4=; h=Date:To:From:Subject; b=CV2d6ruDBfBAJ44by3R5wbDkCaCyNyXQCLegcvOxSm9mGsaxDTQS74o2IzvEN+4md lpcBMZXOdWrlBpnCr0b1Yu4oFLkM/+N8siWzWNTGeBtAHtqzhKlqZ1+LLvPH8uemcF kjVMmay9toruNlRAqoswrRyuz4eM4Pi1Ay6FAaJM= Message-Id: <6.2.5.6.2.20130109102154.0bf5c3b0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 09 Jan 2013 10:28:51 -0800 To: dnsext@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dnsext] Status of draft-ietf-dnsext-dnssec-algo-imp-status-03 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, 09 Jan 2013 18:32:13 -0000 Hello, draft-ietf-dnsext-dnssec-algo-imp-status-03 was evaluated by the IESG about six months ago. What's the status of the document? Regards, -sm From hallam@gmail.com Fri Jan 18 09:35:20 2013 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 3731921F87FA for ; Fri, 18 Jan 2013 09:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.738 X-Spam-Level: X-Spam-Status: No, score=-3.738 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CRkOB9iT8Kd for ; Fri, 18 Jan 2013 09:35:19 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id DAEC121F8834 for ; Fri, 18 Jan 2013 09:35:18 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id gw10so3363629lab.13 for ; Fri, 18 Jan 2013 09:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=ntz48rTXKJDjAYzCWiW8oPc9EC9E5EKo17sg+bkaxf4=; b=WNpPzqXOgRCJPqQg7NQswG3r01wDCkiZ771OsCeS+N46MOCO4RkUhP2zbtBbCTxMzi 5+he9d8uUaTZGwyD+UD8YVN/bQdP2mTYcwdPpaCRUderaGXsheh5KM7PIFbAEAwJ0sem T6WCAe10n+2Hsj8h9gmJd8wCGBeio0lvtxqpFEdDmo1LNO6eDtOe1Mx67vYTbjK5yvhc FfoH9SWO0qhaLQmv9d4oEOA460osmYt/xf26prIjoVYuSGRVX2BwNi1SB3/wiO+z+ubJ t9xYfHT2cudk7uqBOgqjnHLmgShOhWG3NuiuvAckMdfUroRMp1x5E2Cq/dy9v1mu/vd6 UefQ== MIME-Version: 1.0 X-Received: by 10.112.41.202 with SMTP id h10mr4084067lbl.20.1358530517787; Fri, 18 Jan 2013 09:35:17 -0800 (PST) Received: by 10.112.10.36 with HTTP; Fri, 18 Jan 2013 09:35:17 -0800 (PST) Date: Fri, 18 Jan 2013 12:35:17 -0500 Message-ID: From: Phillip Hallam-Baker To: dnsext@ietf.org Content-Type: multipart/alternative; boundary=e0cb4efa6dfcede6aa04d3938842 Subject: [dnsext] Working on a WK record as a replacement for URI (and SRV) 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, 18 Jan 2013 17:35:20 -0000 --e0cb4efa6dfcede6aa04d3938842 Content-Type: text/plain; charset=ISO-8859-1 At the moment, discovery is a mess. We currently use: * Well known ports (not scalable to current needs) * SRV (does not work well for Web services) * URI (not currently used) * SRV + TXT (used in bonjour) * NAPTR (is meta-discovery, not service discovery, involves regular expressions) After discussions with Patrik I now realize that URI has almost all the functionality I would like to have in a discovery scheme except for being able to express policy statements such as the minimum protocol version a protocol supports, the security enhancements required (TLS, IPSEC, CMS, WS-*, etc.) This led me to the following as the ideal format of DNS entry to describe a service entry: _omnibroker._wk.example.com WK 1 1 https://w1.example.com/ _omnibroker._wk.example.com WK 1 1 https://old.example.com / "max=1" _omnibroker._wk.example.com WK 1 1 https://new.example.com / "min=2.0" _omnibroker._wk.example.com WK 1 1 coap://w4.example.com / "ipsec" The first entry is semantically equivalent to the current URI record. It tells us where we can find the service but nothing more. Note that since the target URI is https we effectively get a 'must use TLS' policy statement. The second and third entries show a protocol version transition in progress. The site has deployed services that support the v1 and v2 of the protocol but these are on two separate machines. Expressing this information in the same DNS record where we declare the service endpoint is by far the least error prone approach for administrators. The fourth illustrates offering coap as an alternative to http transport. So far we have only seen Web Service type examples where the application is layered onto the transport using HTTP or the like. That probably accounts for 95% or more of the protocols being designed today. But we can if necessary support a direct IP binding easily enough by introducing an IP URI as follows: ip:tcp:evil.example.com;666 That is a direct tcp transport to port 666 on evil.example.com So the question for this group here is whether making the policy field optional in the presentation format of the record is going to be acceptable. I know that there are existing records with optional fields. In fact there are records with much more complex syntaxes. -- Website: http://hallambaker.com/ --e0cb4efa6dfcede6aa04d3938842 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
At the moment, discovery is a mess. We currently use:

* Well known ports (not scalable to current needs)
* SRV= (does not work well for Web services)
* URI (not currently used)=
* SRV + TXT (used in bonjour)
* NAPTR (is meta-discovery, no= t service discovery, involves regular expressions)

After discussions with Patrik I now realize that URI has almost all the fu= nctionality I would like to have in a discovery scheme except for being abl= e to express policy statements such as the minimum protocol version a proto= col supports, the security enhancements required (TLS, IPSEC, CMS, WS-*, et= c.)

This led me to the following as the ideal format of DNS= entry to describe a service entry:

_omnibroker._wk.example.com=A0WK 1 1=A0https://w1.example.com/
_omnibroker._wk.example= .com=A0WK 1 1=A0https://old.example.com/=A0"max=3D1&= quot;

The first entry is semantically equivalent to the= current URI record. It tells us where we can find the service but nothing = more. Note that since the target URI is https we effectively get a 'mus= t use TLS' policy statement.

The second and third entries show a protocol version tr= ansition in progress. The site has deployed services that support the v1 an= d v2 of the protocol but these are on two separate machines. Expressing thi= s information in the same DNS record where we declare the service endpoint = is by far the least error prone approach for administrators.

The fourth illustrates offering coap as an alternati= ve to http transport.


So far we hav= e only seen Web Service type examples where the application is layered onto= the transport using HTTP or the like. That probably accounts for 95% or mo= re of the protocols being designed today. But we can if necessary support a= direct IP binding easily enough by introducing an IP URI as follows:


That is a direct tcp transport to por= t 666 on evil.example.com


So the question for this group here is whethe= r making the policy field optional in the presentation format of the record= is going to be acceptable. I know that there are existing records with opt= ional fields. In fact there are records with much more complex syntaxes.

--
Website: http://h= allambaker.com/
--e0cb4efa6dfcede6aa04d3938842-- From fanf2@hermes.cam.ac.uk Fri Jan 18 10:27:37 2013 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 F39E121F8798 for ; Fri, 18 Jan 2013 10:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, 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 v8-OvXdcacDF for ; Fri, 18 Jan 2013 10:27:36 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 3B39E21F878F for ; Fri, 18 Jan 2013 10:27:36 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:59370) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1TwGf9-0002wX-X6 (Exim 4.72) (return-path ); Fri, 18 Jan 2013 18:27:35 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1TwGf9-0001dv-7p (Exim 4.72) (return-path ); Fri, 18 Jan 2013 18:27:35 +0000 Date: Fri, 18 Jan 2013 18:27:35 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: 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] Working on a WK record as a replacement for URI (and SRV) 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, 18 Jan 2013 18:27:37 -0000 Phillip Hallam-Baker wrote: > > So the question for this group here is whether making the policy field > optional in the presentation format of the record is going to be > acceptable. I know that there are existing records with optional fields. > In fact there are records with much more complex syntaxes. It's a bad idea since it makes it harder to use generic parsing / serializing code (and it's bad for John Levine's dnsextlang project). I believe the existing RR types that have optional fields are all obsolete: ISDN, NSAP, A6. Best to keep it as simple as possible. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From ed.lewis@neustar.biz Fri Jan 18 13:10:58 2013 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 36C6F21F8767 for ; Fri, 18 Jan 2013 13:10:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 eueoaHr824FY for ; Fri, 18 Jan 2013 13:10:56 -0800 (PST) Received: from eastrmfepo201.cox.net (eastrmfepo201.cox.net [68.230.241.216]) by ietfa.amsl.com (Postfix) with ESMTP id 008C221F8765 for ; Fri, 18 Jan 2013 13:10:47 -0800 (PST) Received: from eastrmimpo209 ([68.230.241.224]) by eastrmfepo201.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20130118211047.KCVX17456.eastrmfepo201.cox.net@eastrmimpo209> for ; Fri, 18 Jan 2013 16:10:47 -0500 Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo209 with cox id pZAm1k00R3cuADQ01ZAm6N; Fri, 18 Jan 2013 16:10:47 -0500 X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020202.50F9BA57.002A,ss=1,re=0.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=2.0 cv=E5JPVNhl c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=x225Vmv_FAsA:10 a=hGBaWAWWAAAA:8 a=hwAyYe6N91YA:10 a=pGLkceISAAAA:8 a=v6W_QK7RAAAA:8 a=48vgC7mUAAAA:8 a=hOZs3lPh3ttO45KIIGYA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=iKVumgxjs76y6foJTQcA:9 a=_W_S_7VecoQA:10 a=Te5YpGkoHemXZ-IZ:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_630706B6-2638-44F6-9684-81322E2C7C41" From: Edward Lewis In-Reply-To: Date: Fri, 18 Jan 2013 16:10:49 -0500 Message-Id: <01DF7994-8060-4521-BD4C-F608CA2170B6@neustar.biz> References: To: dnsextmailing list X-Mailer: Apple Mail (2.1283) Cc: Edward Lewis Subject: Re: [dnsext] Working on a WK record as a replacement for URI (and SRV) 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, 18 Jan 2013 21:10:58 -0000 --Apple-Mail=_630706B6-2638-44F6-9684-81322E2C7C41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii At first I thought about the NAPTR record which needs an empty string = ("") to signify no regex (and a default domain of . after that field in = some cases). But then I thought - what about the TXT record? That = allows for as many strings as desired, each up to 256 octets long, up to = the max length that can be in RDATALEN. Not saying that NAPTR or TXT is right for the job, just looking at them = for the precedent of optional strings. On Jan 18, 2013, at 13:27, Tony Finch wrote: > Phillip Hallam-Baker wrote: >>=20 >> So the question for this group here is whether making the policy = field >> optional in the presentation format of the record is going to be >> acceptable. I know that there are existing records with optional = fields. >> In fact there are records with much more complex syntaxes. >=20 > It's a bad idea since it makes it harder to use generic parsing / > serializing code (and it's bad for John Levine's dnsextlang project). > I believe the existing RR types that have optional fields are all = obsolete: > ISDN, NSAP, A6. >=20 > Best to keep it as simple as possible. >=20 > Tony. > --=20 > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at = first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate = or good, > occasionally poor at first. > _______________________________________________ > 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 =20 NeuStar You can leave a voice message at = +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. --Apple-Mail=_630706B6-2638-44F6-9684-81322E2C7C41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Not saying that NAPTR or TXT is right = for the job, just looking at them for the precedent of optional = strings.

On Jan 18, 2013, at 13:27, Tony = Finch wrote:

Phillip Hallam-Baker <hallam@gmail.com> = wrote:

So the question for this group here is whether making the = policy field
optional in the = presentation format of the record is going to = be
acceptable. I know that = there are existing records with optional = fields.
In fact there are = records with much more complex syntaxes.

It's a bad = idea since it makes it harder to use generic parsing /
serializing = code (and it's bad for John Levine's dnsextlang project).
I believe = the existing RR types that have optional fields are all = obsolete:
ISDN, NSAP, A6.

Best to keep it as simple as = possible.

Tony.
--
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Forties, Cromarty: = East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, = becoming slight or moderate. Showers, rain at first. Moderate or = good,
occasionally poor at = first.
_______________________________________________
dnsext = mailing list
dnsext@ietf.org
https://www.ietf.or= g/mailman/listinfo/dnsext

Edward = Lewis             
NeuStar       = ;          =    You can leave a voice message at = +1-571-434-5468

There are no answers - just tradeoffs, decisions, = and responses.

= --Apple-Mail=_630706B6-2638-44F6-9684-81322E2C7C41-- From dougb@dougbarton.us Fri Jan 18 19:40:09 2013 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 8D63021F8507 for ; Fri, 18 Jan 2013 19:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nwm0h+A7snH for ; Fri, 18 Jan 2013 19:40:09 -0800 (PST) Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id EDB4721F8840 for ; Fri, 18 Jan 2013 19:40:08 -0800 (PST) Received: from [IPv6:2001:470:d:5e7:a931:c844:8b9:7ce6] (unknown [IPv6:2001:470:d:5e7:a931:c844:8b9:7ce6]) by dougbarton.us (Postfix) with ESMTPSA id 31D5D22BC4; Sat, 19 Jan 2013 03:40:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1358566808; bh=1IQEf5RioUqhWCVjiCP6JexcAx5npdsBapP+Wi6xtAY=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=W/v5EjPZ+oFgT+fgthqvaMXcenE5dRqj97PO5DGZapyeOoUqu1x/YvYWXbgtzgwoQ tealhmnbGqbnmLL+O4TaqPutZ5ceuuZspson7qWiFbZ5qJzjclrJnLetfyT/YapSt1 5yrHK0Lw8X4IeOfvaV/tA6oFV+vdXtFCNtC5jVKQ= Message-ID: <50FA1596.6050803@dougbarton.us> Date: Fri, 18 Jan 2013 19:40:06 -0800 From: Doug Barton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: X-Enigmail-Version: 1.4.6 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] Working on a WK record as a replacement for URI (and SRV) 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, 19 Jan 2013 03:40:09 -0000 On 01/18/2013 09:35 AM, Phillip Hallam-Baker wrote: > * SRV (does not work well for Web services) Can you elaborate, or provide a reference? Doug From paul.hoffman@vpnc.org Mon Jan 21 08:08:09 2013 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 E948921F852C for ; Mon, 21 Jan 2013 08:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAG5kiVTTNPA for ; Mon, 21 Jan 2013 08:08:08 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9482D21F8525 for ; Mon, 21 Jan 2013 08:08:08 -0800 (PST) Received: from [10.20.30.101] (50-1-51-83.dsl.dynamic.fusionbroadband.com [50.1.51.83]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r0LG7OvF024407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 21 Jan 2013 09:08:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 21 Jan 2013 08:08:04 -0800 To: DNSEXT Working Group Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [dnsext] New proposal for a DNS API 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, 21 Jan 2013 16:08:10 -0000 Greetings again. There are a few DNS application programming interfaces = (APIs) available that cover things like DNSSEC and non-address records, = but none that have garnered much interest from the application = developers who should be their primary audience. To remedy that, I have = created a new design for such an API. I did that outside the IETF, of = course, given the IETF's general "we don't do APIs" stance and the = oft-stated desire to shut down this WG sooner rather than later. Please see http://www.vpnc.org/getdns-api/ for the current API proposal = and description of the design principles I used to put it together. I am = still seeking input from application developers to say what they would = really want to see in an API, and from DNS people to say which parts of = the DNS should be exposed in what ways to application developers. At = some point in the not-distant-future, I will call the design "finished" = and hopefully someone will want to implement it. Please don't discuss the design on the DSNEXT WG mailing list; it is = really not appropriate here. I just wanted to alert folks of this work. --Paul Hoffman= From hallam@gmail.com Tue Jan 22 06:21:49 2013 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 C2C3021F8941 for ; Tue, 22 Jan 2013 06:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99+NQe7c8PQJ for ; Tue, 22 Jan 2013 06:21:48 -0800 (PST) Received: from mail-wg0-x22a.google.com (wg-in-x022a.1e100.net [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7146421F87FB for ; Tue, 22 Jan 2013 06:21:47 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id 12so1823606wgh.1 for ; Tue, 22 Jan 2013 06:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EjpZJzxf1rYmuAFEzqP9fCDnawO+uuL0s/dL9EeQtFA=; b=0ICFIxswNvoJ5r5fTUM0XNNFPTEnWo1UIBWjnnl0wZY8k8RCvnHXzlYA5I6CsGDP6z RkJAk2C9JkGAywvYde7NqG1/ZJVVFINcGUhsTPlMBRwyLw7uK6z366vbonFXw6O6AN3u OjzT+TWzM5C0dkac3bnFK9IU9u45cQwJfV++ei9h26YjIYfmY/H19XFA4KU6dxDJmdtE 0KT8uTMshlGpNtCi92hg6ZRASlzzlRkZ/GzSsOzV5ZNS+5LHFSsUlsa7b76bzraYtyy9 /WikPyOrGoI+Mu1xFl3g4ZMNv1jq5Atnpe9YsudZ3FtDvPI3ZYmwv38xQIOTBkR4yt/t tKYg== MIME-Version: 1.0 X-Received: by 10.180.101.104 with SMTP id ff8mr21480794wib.11.1358864505971; Tue, 22 Jan 2013 06:21:45 -0800 (PST) Received: by 10.194.59.10 with HTTP; Tue, 22 Jan 2013 06:21:45 -0800 (PST) In-Reply-To: <50FA1596.6050803@dougbarton.us> References: <50FA1596.6050803@dougbarton.us> Date: Tue, 22 Jan 2013 09:21:45 -0500 Message-ID: From: Phillip Hallam-Baker To: Doug Barton Content-Type: multipart/alternative; boundary=f46d041826c82d224e04d3e14c57 Cc: dnsext@ietf.org Subject: Re: [dnsext] Working on a WK record as a replacement for URI (and SRV) 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, 22 Jan 2013 14:21:49 -0000 --f46d041826c82d224e04d3e14c57 Content-Type: text/plain; charset=ISO-8859-1 OK so looks like the optional policy string is not a good idea. At least as far as the normal form goes. On Fri, Jan 18, 2013 at 10:40 PM, Doug Barton wrote: > On 01/18/2013 09:35 AM, Phillip Hallam-Baker wrote: > >> * SRV (does not work well for Web services) >> > > Can you elaborate, or provide a reference? > > Doug > The problem with SRV and Web services is that a typical Web Server deployment supports multiple Web Services, some of which are only going to be called maybe five times a day, if that. So the Web Services actually make use of the stem part of the URI to identify the location on the Web Server. So to use SRV to announce a Web Service you need some way to specify the location on the Web Server. One approach is to specify a .well-known location for the service but that is rather less flexible than many deployments will accept and it stops a server having two different versions of the same protocol running in parallel - something you are very likely to want to do if you are witching between protocol versions or implementation versions. -- Website: http://hallambaker.com/ --f46d041826c82d224e04d3e14c57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
OK so looks like the optional policy string is not a good idea. At lea= st as far as the normal form goes.



On Fri, Jan 18, 2013 at 10:40 PM, Doug Barton <dougb@do= ugbarton.us> wrote:
On 01/18/2013 09:35 AM, Ph= illip Hallam-Baker wrote:
* SRV (does not work well for Web services)

Can you elaborate, or provide a reference?

Doug

The problem with SRV and We= b services is that a typical Web Server deployment supports multiple Web Se= rvices, some of which are only going to be called maybe five times a day, i= f that. So the Web Services actually make use of the stem part of the URI t= o identify the location on the Web Server.

So to use SRV to announce a Web Service you need some way to= specify the location on the Web Server. One approach is to specify a .well= -known location for the service but that is rather less flexible than many = deployments will accept and it stops a server having two different versions= of the same protocol running in parallel - something you are very likely t= o want to do if you are witching between protocol versions or implementatio= n versions.


--
Website: http://hallambaker.com/
--f46d041826c82d224e04d3e14c57-- From fanf2@hermes.cam.ac.uk Wed Jan 23 03:40:21 2013 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 D001D21F8A09 for ; Wed, 23 Jan 2013 03:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 cEOqUpmEreGa for ; Wed, 23 Jan 2013 03:40:21 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id B189F21F8A03 for ; Wed, 23 Jan 2013 03:40:20 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.ucs.cam.ac.uk/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:50506) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Txygl-0005rT-R6 (Exim 4.72) (return-path ); Wed, 23 Jan 2013 11:40:19 +0000 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Txygl-0005Wy-CC (Exim 4.72) (return-path ); Wed, 23 Jan 2013 11:40:19 +0000 Date: Wed, 23 Jan 2013 11:40:19 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Edward Lewis In-Reply-To: <01DF7994-8060-4521-BD4C-F608CA2170B6@neustar.biz> Message-ID: References: <01DF7994-8060-4521-BD4C-F608CA2170B6@neustar.biz> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870869256-265039292-1358941219=:27013" Sender: Tony Finch Cc: dnsextmailing list Subject: Re: [dnsext] Working on a WK record as a replacement for URI (and SRV) 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, 23 Jan 2013 11:40:21 -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. --1870869256-265039292-1358941219=:27013 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Edward Lewis wrote: > At first I thought about the NAPTR record which needs an empty string > ("") to signify no regex (and a default domain of . after that field in > some cases). =C2=A0But then I thought - what about the TXT record? =C2=A0= That > allows for as many strings as desired, each up to 256 octets long, up to > the max length that can be in RDATALEN. Yes, TXT is a bit special, but there is already code to support it, and the same layout is used by SPF records, and it's likely that there will be more RRtypes along those lines. HIP records also have a multiple field (the list of rendezvous servers) but it has other features that prevent it from being handled with generic code, specifically detaching the length fields from the data they cover. The ideal for new RRtypes is to use only subfield types which are already used by other RRtypes, and ensure the presentation format and wire format are in the same order. Tony. --=20 f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first= =2E Rough, becoming slight or moderate. Showers, rain at first. Moderate or goo= d, occasionally poor at first. --1870869256-265039292-1358941219=:27013-- From iesg-secretary@ietf.org Fri Jan 25 06:07:25 2013 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 1F5E121F8878; Fri, 25 Jan 2013 06:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GulIQ15wWNlg; Fri, 25 Jan 2013 06:07:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7E121F8842; Fri, 25 Jan 2013 06:07:08 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130125140708.31815.61232.idtracker@ietfa.amsl.com> Date: Fri, 25 Jan 2013 06:07:08 -0800 Cc: dnsext chair , dnsext mailing list , RFC Editor Subject: [dnsext] Protocol Action: 'Extension Mechanisms for DNS (EDNS(0))' to Internet Standard (draft-ietf-dnsext-rfc2671bis-edns0-10.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: Fri, 25 Jan 2013 14:07:25 -0000 The IESG has approved the following document: - 'Extension Mechanisms for DNS (EDNS(0))' (draft-ietf-dnsext-rfc2671bis-edns0-10.txt) as Internet Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2671bis-edns0/ Technical Summary The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward compatible mechanisms for allowing the protocol to grow. This document updates the EDNS0 specification (RFC 2671) based on feedback from deployment experience in several implementations. It also closes the IANA registry for extended labels created as part of RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name System") which depends on the existence of extended labels. The main contribution of RFC2671 was to allow larger DNS messages over UDP, beween cooperating parties, this is crucial for DNSSEC and other modern DNS uses. Working Group Summary Working group is solidly behind this document. Document Quality There are many implemenations of this specification, the working group wish is that this be published as Internet Standard. This document is the cummulation of fair ammount of work and experience. During the WG process most of the changes in the document were stylistic and presentation ones rather than technical. These are the responses to the questions from RFC 6410 regarding publication as an Internet Standard. (1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience. There are MANY implementations, as a matter of fact almost all DNS implementations support ENDS0, there is great interoperability. The only issues that we have discovered are that some implementations have strange ideas (non-RFC1035 compliant) as what to return when seeing ENDS0 option in message. This is covered in this document. (2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. There are no errata filed against RFC2671 and RFC2671bis takes into account most of the issues that RFC2671 underspecified. (3) There are no unused features in the specification that greatly increase implementation complexity. Correct. (4) If the technology required to implement the specification requires patented or otherwise controlled technology, then the set of implementations must demonstrate at least two independent, separate and successful uses of the licensing process. The technology required to implement the specification requires no patented or otherwise controlled technology. Personnel Olafur Gudmundsson (ogud at ogud.com) is the document shepherd. Ralph Droms is the Responsible AD. From wwwrun@rfc-editor.org Fri Jan 25 15:19:18 2013 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 E786621F8696; Fri, 25 Jan 2013 15:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 kyfGdSn6m0f1; Fri, 25 Jan 2013 15:19:18 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 73FE921F868E; Fri, 25 Jan 2013 15:19:18 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5D86E72E11A; Fri, 25 Jan 2013 15:07:56 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130125230756.5D86E72E11A@rfc-editor.org> Date: Fri, 25 Jan 2013 15:07:56 -0800 (PST) Cc: dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] STD 74, RFC 5011 on Automated Updates of DNS Security (DNSSEC) Trust Anchors 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, 25 Jan 2013 23:19:19 -0000 RFC 5011 has been elevated to Internet Standard. STD 74 RFC 5011 Title: Automated Updates of DNS Security (DNSSEC) Trust Anchors Author: M. StJohns Status: Standards Track Stream: IETF Date: September 2007 Mailbox: mstjohns@comcast.net Pages: 14 Characters: 30138 See Also: STD0074 I-D Tag: draft-ietf-dnsext-trustupdate-timers-06.txt URL: http://www.rfc-editor.org/rfc/rfc5011.txt This document describes a means for automated, authenticated, and authorized updating of DNSSEC "trust anchors". The method provides protection against N-1 key compromises of N keys in the trust point key set. Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s). This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record. [STANDARDS-TRACK] This document is a product of the DNS Extensions Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jinmei@isc.org Thu Jan 31 20:55:39 2013 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 4A6EA21F8840 for ; Thu, 31 Jan 2013 20:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVI8NCgybK7N for ; Thu, 31 Jan 2013 20:55:38 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 9BED121F86DA for ; Thu, 31 Jan 2013 20:55:38 -0800 (PST) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id D8435C94F5 for ; Fri, 1 Feb 2013 04:55:32 +0000 (UTC) (envelope-from jinmei@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1359694538; bh=5bh80wooY13NgQp9fI2hk/tgGYDxYvga6mlYam/Pfbs=; h=Date:From:To:Subject; b=mSdwfzBud5Fai+DXND4Q2zykVsvTQFDDuVUTtu0BKQrrb/fsf/wHTYu+bOGYeivor e8UeL97TssvgrrVJB7Sxji7J+JBAU8IG+++pE5XA8p6T9FePpSFpUM6Jc9B7Bj/w7l FiQjlFK1M9j3q+4VN7rexcsxR1VAjvywGubtQxbk= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS for ; Fri, 1 Feb 2013 04:55:32 +0000 (UTC) (envelope-from jinmei@isc.org) Received: from jmb.jinmei.org (99-105-57-202.lightspeed.sntcca.sbcglobal.net [99.105.57.202]) (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 7C901216C43 for ; Fri, 1 Feb 2013 04:55:32 +0000 (UTC) (envelope-from jinmei@isc.org) Date: Thu, 31 Jan 2013 20:55:36 -0800 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dnsext@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-DCC--Metrics: post.isc.org; whitelist Subject: [dnsext] ENT wildcard derived from insecure delegation + Opt-Out NSEC3 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, 01 Feb 2013 04:55:39 -0000 I have a question related to the recent errata for RFC5155 on empty non terminal: http://www.rfc-editor.org/errata_search.php?rfc=5155&eid=3441 What if the empty non terminal is a wildcard? For example, example. ;; zone origin, has SOA, NS, matching NSEC3 etc ;; x.example. ;; empty, covered by opt-out NSEC3 ;; *.x.example. ;; empty and wildcard, covered by opt-out NSEC3 child.*.x.example. IN NS ns.example.com. ;; insecure, no DS, opt-out and query is y.x.example./A. What should be returned in this case? Section 7.2.5 of RFC5155 states: If there is a wildcard match for QNAME, but QTYPE is not present at that name, the response MUST include a closest encloser proof for QNAME and MUST include the NSEC3 RR that matches the wildcard. This combination proves both that QNAME itself does not exist and that a wildcard that matches QNAME does exist. Note that the closest encloser to QNAME MUST be the immediate ancestor of the wildcard RR (if this is not the case, then something has gone wrong). In this case, the closest encloser proof is NSEC3 that matches example. and NSEC3 that covers x.example (that would have Opt-Out). But there's no "NSEC3 RR that matches the wildcard". Also, the closest (provable) encloser to QNAME (= example.) is not the immediate ancestor of the wildcard (RR), which is x.example. Is this case included in the discussion that led to the errata? I re-read the dnsext archive but couldn't be sure (as far as I can see the wildcard-related discussions at that time were about different issues than this one). Or is this case excluded by some other rules? --- JINMEI, Tatuya Internet Systems Consortium, Inc.