From jeffrey.damick@neustar.biz Wed Aug 1 07:05:55 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 771CA21F8831; Wed, 1 Aug 2012 07:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 xWUD7CK-Usa8; Wed, 1 Aug 2012 07:05:53 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B118421F8830; Wed, 1 Aug 2012 07:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1343830067; x=1659187926; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=puLjXE1kjwUCoJYky8EQQryTXhRduG2HwVnke/4XXWE=; b=EoP8l0n7l761vhcu1N+L8jwEzKdYzeHrhicQkPMnYypAqgbOUk+8tJ2nSF+ly6 Aw33XTeolia7Z1gJYPS50ptQ== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.12128642; Wed, 01 Aug 2012 10:07:46 -0400 Received: from STNTEXCH02.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 1 Aug 2012 10:05:49 -0400 From: "Damick, Jeffrey" To: "dns-rrtype-applications@ietf.org" , "dnsext@ietf.org" Date: Wed, 1 Aug 2012 10:05:46 -0400 Thread-Topic: draft-damick-dns-associated-names-record.txt-00 Thread-Index: Ac1v7r7xyMmE8iXhKU6Rych3vpCowg== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: L1HL1DU3F3tXTb/G4kTSaQ== Content-Type: multipart/mixed; boundary="_004_CC3EAFFC29F01jeffreydamickneustarbiz_" MIME-Version: 1.0 Subject: [dnsext] draft-damick-dns-associated-names-record.txt-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, 01 Aug 2012 14:05:55 -0000 --_004_CC3EAFFC29F01jeffreydamickneustarbiz_ Content-Type: multipart/alternative; boundary="_000_CC3EAFFC29F01jeffreydamickneustarbiz_" --_000_CC3EAFFC29F01jeffreydamickneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A. Submission Date: 8/1/2012 B. Submission Type: [X] New RRTYPE [ ] Modification to existing RRTYPE C. Contact Information for submitter (will be publicly posted): Name: Jeffrey Damick Email Address: jeffrey.damick@neustar.biz International telephone number: 001-571-434-5324 Other contact handles: D. Motivation for the new RRTYPE application. The goal of this new record type is to provide a mechanism for oper= ators to create a list of associated domain names for a particular QTYPE an= d service name. This will allow client applications to be crafted to handl= e these lists based on the needs of their particular service. Please see a= ttached draft for more details. E. Description of the proposed RR type. See attached draft. F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? None that I am aware. G. What mnemonic is requested for the new RRTYPE (optional)? Note: this can be left blank and the mnemonic decided after the template is accepted. AN H. Does the requested RRTYPE make use of any existing IANA registry or require the creation of a new IANA sub-registry in DNS Parameters? If so, please indicate which registry is to be used or created. If a new sub-registry is needed, specify the allocation policy for it and its initial contents. Also include what the modification procedures will be. It utilizes the "Service Name and Transport Protocol Port Number Regist= ry" for the service name in the record body. I. Does the proposal require/expect any changes in DNS servers/resolvers that prevent the new type from being processed as an unknown RRTYPE (see [RFC3597])? No J. Comments: Draft attached. --_000_CC3EAFFC29F01jeffreydamickneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-damick-dns-associated-names-record.txt-00
A. Submission Date:  8/1/2012

   B. Submission Type:
      [X] New RRTYPE
      [ ] Modification to existing RRTYPE

   C. Contact Information for submitter (will be publicly po= sted):
         Name:  Jeffrey D= amick
         Email Address: jeffrey.damick@neustar.biz
         International telepho= ne number:  001-571-434-5324
         Other contact handles= :

   D. Motivation for the new RRTYPE application.
        
        The goal of this new record= type is to provide a mechanism for operators to create a list of associate= d domain names for a particular QTYPE and service name.  This will all= ow client applications to be crafted to handle these lists based on the nee= ds of their particular service.  Please see attached draft for more de= tails.

   E. Description of the proposed RR type.
        
        See attached draft.
    
    
   F. What existing RRTYPE or RRTYPEs come closest to fillin= g that need
      and why are they unsatisfactory?

      None that I am aware.

   G. What mnemonic is requested for the new RRTYPE (optiona= l)?
      Note: this can be left blank and the mn= emonic decided after the
      template is accepted.

     AN      

   H. Does the requested RRTYPE make use of any existing IAN= A registry
      or require the creation of a new IANA s= ub-registry in DNS
      Parameters?  If so, please indicat= e which registry is to be used
      or created.  If a new sub-registry= is needed, specify the
      allocation policy for it and its initia= l contents.  Also include
      what the modification procedures will b= e.

    It utilizes the “Service Name and Transport P= rotocol Port Number Registry” for the service name in the record body= .

   I. Does the proposal require/expect any changes in DNS       servers/resolvers that prevent the new = type from being processed
      as an unknown RRTYPE (see [RFC3597])?
    No

   J. Comments:
       Draft attached.



 --_000_CC3EAFFC29F01jeffreydamickneustarbiz_-- --_004_CC3EAFFC29F01jeffreydamickneustarbiz_ Content-Type: application/octet-stream; name="draft-damick-dns-associated-names-record.txt-00" Content-Description: draft-damick-dns-associated-names-record.txt-00 Content-Disposition: attachment; filename="draft-damick-dns-associated-names-record.txt-00"; size=11653; creation-date="Wed, 01 Aug 2012 10:05:49 GMT"; modification-date="Wed, 01 Aug 2012 10:05:49 GMT" Content-Transfer-Encoding: base64 CgoKSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgSi4gRGFtaWNrCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTmV1c3RhcgpJbnRlbmRlZCBzdGF0dXM6IFN0YW5k YXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgQXVndXN0IDEsIDIwMTIKRXhwaXJl czogRmVicnVhcnkgMiwgMjAxMwoKCiAgICAgICAgICAgICAgICAgICAgICBBc3NvY2lhdGVkIE5h bWVzIEROUyBSZWNvcmQKICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi14bWwycmZjLXRl bXBsYXRlLTA1CgpBYnN0cmFjdAoKICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBuZXcgcmVz b3VyY2UgcmVjb3JkIGZvciB0aGUgRG9tYWluIE5hbWUKICAgU3lzdGVtIChETlMpIHByb3RvY29s LiAgVGhlIHJlY29yZCBpbnRyb2R1Y2VkIHdpbGwgYWxsb3cgYXNzb2NpYXRlZAogICBkb21haW4g bmFtZXMgdG8gYmUgYXNzb2NpYXRlZCB3aXRoIGEgcGFydGljdWxhciBkb21haW4gbmFtZSBhbmQK ICAgcmV0cmlldmVkIGluIGluIGEgc2luZ2xlIEROUyBxdWVyeS4KClN0YXR1cyBvZiB0aGlzIE1l bW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFu Y2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVy bmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVy aW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxz byBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRo ZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBk cmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBt YXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMg YXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFm dHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFz ICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUg b24gRmVicnVhcnkgMiwgMjAxMy4KCkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykg MjAxMiBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1 bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMg c3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9u cyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cwogICAoaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcv bGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24gdGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24gb2Yg dGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNhcmVmdWxs eSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVz cGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAgQ29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9t IHRoaXMgZG9jdW1lbnQgbXVzdAogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4 dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRydXN0IExlZ2FsIFByb3Zp c2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAgIGRlc2NyaWJlZCBp biB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4KCgoKCkRhbWljayAgICAgICAgICAgICAgICAg IEV4cGlyZXMgRmVicnVhcnkgMiwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVy bmV0LURyYWZ0ICAgICAgICAgQXNzb2NpYXRlZCBOYW1lcyBETlMgUmVjb3JkICAgICAgICAgICBB dWd1c3QgMjAxMgoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMKICAgICAxLjEu ICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAzCiAgIDIuICBPdmVydmlldyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMwogICAzLiAgVXNhZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMKICAgICAzLjEuICBBTiBSREFU QSBGb3JtYXQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzCiAg ICAgMy4yLiAgQ2xpZW50IEhhbmRsaW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNAogICAgIDMuMy4gIFB1Ymxpc2hpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQKICAgICAzLjQuICBFeGFtcGxlIEZsb3cgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0CiAgIDQuICBBY2tu b3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gNgogICA1LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDYKICAgNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2CiAgICAgNi4xLiAgRGVuaWFsIG9m IFNlcnZpY2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNgogICA3 LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDYKICAgICA3LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA2CiAgICAgNy4yLiAgSW5mb3JtYXRpdmUgUmVmZXJl bmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNwogICBBdXRob3IncyBB ZGRyZXNzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDcKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKRGFtaWNrICAgICAgICAgICAgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAyLCAyMDEzICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50 ZXJuZXQtRHJhZnQgICAgICAgICBBc3NvY2lhdGVkIE5hbWVzIEROUyBSZWNvcmQgICAgICAgICAg IEF1Z3VzdCAyMDEyCgoKMS4gIEludHJvZHVjdGlvbgoKICAgVGhlIGN1cnJlbnQgbWVjaGFuaXNt IGZvciBkZXRlcm1pbmluZyBhc3NvY2lhdGVkIGRvbWFpbiBuYW1lcyBmb3IgYQogICBwYXJ0aWN1 bGFyIGRvbWFpbiBuYW1lIHJlcXVpcmVzIG11bHRpcGxlIHF1ZXJpZXMgd2l0aCBpbnRlcmxlYXZl ZAogICBhc3NldCByZXRyaWV2YWwuICBPbmUgZXhhbXBsZSBvZiB0aGlzIG9jY3VycyBpbiByZW5k ZXJpbmcgSFRNTCBwYWdlcwogICB3aGVyZSB0aGUgYmFzZSBkb21haW4gbXVzdCBiZSBxdWVyaWVk IGFuZCB0aGVuIHRoZSBIVE1MIHdpbGwgYmUKICAgcmV0cmlldmVkIGFuZCBpdCB3aWxsIG1vc3Qg bGlrZWx5IHdpbGwgaW5jbHVkZSByZWZlcmVuY2VzIHRvIGV4dGVybmFsCiAgIGFzc2V0cywgc3Vj aCBhcyBzY3JpcHRzIGFuZCBzdHlsZXNoZWV0cywgdG8gYmUgZGVsaXZlcmVkIGZyb20gbWFueQog ICBvdGhlciBkb21haW5zLiAgVGhlIGdvYWwgb2YgdGhpcyByZWNvcmQgaXMgdG8gYWxsb3cgYSBs aXN0IG9mIHRoZQogICBvdGhlciBkb21haW5zIHRoYXQgd2lsbCByZWZlcmVuY2VkIGxhdGVyIGJ5 IGFub3RoZXIgcHJvY2Vzcywgc3VjaCBhcwogICByZW5kZXJpbmcgYW4gSFRNTCBwYWdlLCB0byBi ZSBwdWJsaXNoZWQuICBCeSBwcm92aWRpbmcgdGhlIGxpc3Qgb2YKICAgcmVmZXJlbmNlZCBkb21h aW5zLCB0aGV5IG1heSB1dGlsaXplZCBieSBhIHJlc29sdmVyIHRvIHByZS1jYWNoZQogICByZXN1 bHRzLCBzbyB0aGF0IHdoZW4gYW5vdGhlciBwcm9jZXNzIG5lZWRzIHRoZSByZXN1bHRzIHRoZXkg d2lsbAogICBtb3N0IGxpa2VseSBub3QgaW5jdXIgYSBuZXR3b3JrIHJvdW5kIHRyaXAuCgoxLjEu ICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UKCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBO T1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9V TEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAg ZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBb UkZDMjExOV0uCgoKMi4gIE92ZXJ2aWV3CgogICBUaGUgYXNzb2NpYXRlZCBuYW1lcyAoQU4pIHJl c291cmNlIHJlY29yZCAoUlIpIGNvbnRhaW5zIGEgbGlzdCBvZiBhbnkKICAgZG9tYWluIG5hbWVz IHRoYXQgdG8gYmUgYXNzb2NpYXRlZCB3aXRoIHRoaXMgbmFtZS4KCgozLiAgVXNhZ2UKCiAgIFRo ZSB0eXBlIG51bWJlciBmb3IgdGhlIEFOIFJSIGlzICdUQkQnLgoKMy4xLiAgQU4gUkRBVEEgRm9y bWF0CgogICAgICAgICAgUkRBVEEgRm9ybWF0IGZvciB0aGUgYXNzb2NpYXRlZCBuYW1lcyByZXNv dXJjZSByZWNvcmQuCgogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAg IDIgICAgICAgICAgICAgICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAg ICAgIFFUWVBFICAgICAgICAgICAgICAgfCAgICAgICAgICAgU0VSVklDRSAgICAgICAgICAgICAv CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAvCiAgIC8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAvCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIC8gICAgICAgICAgICAgICAg ICAgICAgQVNTT0NJQVRFRC1OQU1FIC4uLiAgICAgICAgICAgICAgICAgICAgICAvCiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMQoKCgoKRGFtaWNr ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBGZWJydWFyeSAyLCAyMDEzICAgICAgICAgICAgICAg IFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBBc3NvY2lhdGVkIE5hbWVzIEROUyBS ZWNvcmQgICAgICAgICAgIEF1Z3VzdCAyMDEyCgoKICAgUVRZUEU6ICBUaGUgMiBvY3RldCBUWVBF IGNvZGUgYXMgZGVmaW5lZCBpbiBbUkZDMTAzNV0gdG8gdXNlIGZvciB0aGUKICAgICAgICAgYXNz b2NpYXRlZC1uYW1lcyBsaXN0LgoKICAgU0VSVklDRTogIFRoZSBjaGFyYWN0ZXItc3RyaW5nIGFz IGRlZmluZWQgaW4gW1JGQzEwMzVdIG9mIGEgc3ltYm9saWMKICAgICAgICAgbmFtZSBmb3IgdGhl IGRlc2lyZWQgc2VydmljZSwgYXMgZGVmaW5lZCBpbiB0aGUgSUFOQSBPbi1saW5lCiAgICAgICAg IGRhdGFiYXNlIG9mIHNlcnZpY2UgbmFtZXMgW0lBTkEtU0VSVklDRS1OQU1FU10uCgogICBBU1NP Q0lBVEVELU5BTUU6ICBPbmUgb3IgbW9yZSBhYnNvbHV0ZSA8ZG9tYWluLW5hbWU+cyBhcyBkZWZp bmVkIGluCiAgICAgICAgIFtSRkMxMDM1XSB3aGljaCBhcmUgZWFjaCB0ZXJtaW5hdGVkIGJ5IGEg bGFiZWwgb2YgemVybyBsZW5ndGguCgozLjIuICBDbGllbnQgSGFuZGxpbmcKCiAgIEl0IGlzIFJF Q09NTUVOREVEIHRoYXQgY2xpZW50cyB1cG9uIHJlY2VpdmluZyB0aGUgcmVzdWx0cyBvZiB0aGlz CiAgIHR5cGUgdGhlbiBxdWVyeSBmb3IgdGhlIGRvbWFpbi1uYW1lcyBsaXN0ZWQgaW4gdGhlIEFT U09DSUFURUQtTkFNRQogICBzZWN0aW9uLiAgVGhpcyB3aWxsIGFsbG93IHRoZSBjbGllbnQgdG8g ZW5zdXJlIHRoYXQgdGhlIHJlc3VsdHMgZm9yCiAgIHRoZSBkb21haW4tbmFtZXMgd2lsbCBiZSBw b3B1bGF0ZWQgaW4gdGhlIGNhY2hlIG9mIGEgbG9jYWwgcmVzb2x2ZXIKICAgb3IgcmVjdXJzaXZl IHJlc29sdmVyLgoKMy4zLiAgUHVibGlzaGluZwoKICAgSW4gdGhlIGV4YW1wbGUgb2YgYSB3ZWIg c2l0ZSwgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgY29udGVudAogICBvd25lciB1cG9uIHB1 Ymxpc2hpbmcgYSBuZXcgdmVyc2lvbiBvZiB0aGVpciBzaXRlIGFuZC9vciBhc3NvY2lhdGVkCiAg IGFzc2V0cyBhbHNvIHVwZGF0ZSBbUkZDMjEzNl0gdGhlIEFOIHJlc291cmNlIHJlY29yZCB3aXRo IGFueSBhZGRlZCBvcgogICByZW1vdmVkIGFzc29jaWF0ZWQgZG9tYWluIG5hbWVzLgoKMy40LiAg RXhhbXBsZSBGbG93CgogICBUaGlzIGZsb3cgdXNlcyB0aGUgZXhhbXBsZSBvZiBhIHdlYiBzaXRl IGFnYWluOgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCkRhbWljayAgICAgICAgICAgICAgICAgIEV4 cGlyZXMgRmVicnVhcnkgMiwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0 LURyYWZ0ICAgICAgICAgQXNzb2NpYXRlZCBOYW1lcyBETlMgUmVjb3JkICAgICAgICAgICBBdWd1 c3QgMjAxMgoKCiAgICAgICAgICAgICAgICAgICAgICAgICAgIFVwZGF0ZSAoQU4gUlIpCiAgICAg ICAgICAgICAgICAgICAgICAgICAgd3d3LmV4YW1wbGUuY29tCiAgICAgICAgICAgICAgICAgICAg ICAgICAgUVRZUEU6IDEgKEEgUlIpCiAgICAgICAgICAgICAgICAgICAgICAgICAgU0VSVklDRTog aHR0cAogICAgICAgICAgICArLS0tLS0tLS0tLS0rIEFTU09DSUFURUQtTkFNRVM6ICstLS0tLSsK ICAgICAgICAgICAgfCBXZWIgU2l0ZSAgfCBhLnVrLGIuY29tLGMuY29tICB8ICAgICB8CiAgICAg ICAgICAgIHwgUHVibGlzaGVyIHwrLS0tLS0tLS0tLS0tLS0tLS0+fCBETlMgfAogICAgICAgICAg ICB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgIHwgICAgIHwKICAgICAgICAgICAgKy0t LS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICArLS0tLS0rCgoKICAgICAgICAgICAgICAgICAg ICAgICAgUXVlcnkgKEFOIFJSKQogICAgICAgICAgICArLS0tLS0tLS0rIHd3dy5leGFtcGxlLmNv bSAgICstLS0tLSsKICAgICAgICAgICAgfCAgICAgICAgfCstLS0tLS0tLS0tLS0tLS0tLT58ICAg ICB8CiAgICAgICAgICAgIHwgQ2xpZW50IHwgUmVzcG9uc2UgKEFOIFJSKSAgfCBETlMgfAogICAg ICAgICAgICB8ICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tK3wgICAgIHwKICAgICAgICAgICAg Ky0tLS0tLS0tKyBRVFlQRTogMSAgICAgICAgICArLS0tLS0rCiAgICAgICAgICAgICAgICB8ICAg ICAgU0VSVklDRTogaHR0cAogICAgICAgICAgICAgICAgfCAgICAgIEFOOiBhLnVrLGIuY29tLGMu Y29tCiAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICB8CiAgICAgICAgICAgICAgICB8 ICAgICAgICAgUXVlcnkgKEEgUlIpCiAgICAgICAgICAgICAgd3d3LmV4YW1wbGUuY29tLGEudWss Yi5jb20sYy5jb20KICAgICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICArLS0t LS0rCiAgICAgICAgICAgIHwgICAgICAgIHwrLS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgfAogICAg ICAgICAgICB8IENsaWVudCB8Ky0tLS0tLS0tLS0tLS0tLS0tPnwgRE5TIHwKICAgICAgICAgICAg fCAgICAgICAgfCstLS0tLS0tLS0tLS0tLS0tLT58ICAgICB8CiAgICAgICAgICAgIHwgICAgICAg IHwtLS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgfAogICAgICAgICAgICArLS0tLS0tLS0rICAgICAg ICAgICAgICAgICAgICstLS0tLSsKICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgIHwK ICAgICAgICAgICAgICAuLiBwcm9jZXNzICYgcmVuZGVyIGh0bWwgYW5kIHNjcmlwdHMgLi4KICAg ICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgKy0tLS0tLS0tKyst LS0tLSsgICBRdWVyeSAoQSBSUikKICAgICAgICAgICAgfCAgICAgICAgfCstLS0tLSsgIGEudWss Yi5jb20sYy5jb20KICAgICAgICAgICAgfCBDbGllbnQgfCstLS0tLSsgKGFuc3dlciBmcm9tIHN0 dWIgcmVzb2x2ZXIgY2FjaGUpCiAgICAgICAgICAgIHwgICAgICAgIHwgICAgICB8CiAgICAgICAg ICAgIHwgICAgICAgIHw8LS0tLS0rCiAgICAgICAgICAgICstLS0tLS0tLSsKCgogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMgoKCgoKCgoKCkRhbWljayAgICAgICAgICAg ICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMiwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSA1XQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgQXNzb2NpYXRlZCBOYW1lcyBETlMgUmVjb3JkICAgICAg ICAgICBBdWd1c3QgMjAxMgoKCjQuICBBY2tub3dsZWRnZW1lbnRzCgogICBUaGFua3MgdG8gRWR3 YXJkIExld2lzIGFuZCB0aGUgcmVzdCBvZiB0aGUgVWx0cmFETlMgdGVhbSBmb3IgYWxsIG9mCiAg IHRoZWlyIHZhbHVhYmxlIGlucHV0LgoKCjUuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBUaGlz IGRvY3VtZW50IHJlcXVlc3RzIHRoYXQgdGhlIElBTkEgUmVnaXN0cnkgZm9yIEROUyBSZXNvdXJj ZSBSZWNvcmQKICAgVHlwZXMgYXNzaWducyB0eXBlICdUQkQnIHRvIHRoZSBBTiByZXNvdXJjZSBy ZWNvcmQuCgoKNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgo2LjEuICBEZW5pYWwgb2YgU2Vy dmljZQoKICAgVGhlIEROUyBzZXJ2ZXJzIHRoZW1zZWx2ZXMgd2lsbCBub3QgYmUgZWZmZWN0ZWQg ZGlyZWN0bHkgYnkgbWlzdXNlIG9mCiAgIHRoZSBBTiByZWNvcmQgaXQgaXMgc3RpbGwgaW1wb3J0 YW50IHRvIG5vdGUgcG90ZW50aWFsIHJpc2tzIHRvIGEKICAgY2xpZW50IGFwcGxpY2F0aW9uLiAg SXQgaXMgcG9zc2libGUgZm9yIGFuIGF0dGFja2VyIHRvIGNyZWF0ZSBBTgogICByZWNvcmRzIG9m IHRoZSBmb2xsb3dpbmcgdHlwZXM6CgogICBvICBWZXJ5IGxhcmdlIGxpc3Qgb2YgZG9tYWluIG5h bWVzCgogICBvICBEdXBsaWNhdGUgZG9tYWluIG5hbWVzCgogICBXaGVuIGRlYWxpbmcgd2l0aCB0 aGVzZSBzaXR1YXRpb25zIGl0IGlzIGltcG9ydGFudCBmb3IgY2xpZW50CiAgIGFwcGxpY2F0aW9u cyB0byB0YWtlIHByZWNhdXRpb25zIHRvIHByZXZlbnQgYWJ1c2Ugb2YgdGhpcyByZXNvdXJjZQog ICByZWNvcmQuCgogICBvICBDb25zdHJhaW4gdGhlIGxpc3Qgb2YgZG9tYWlucyB0byBhbiB1cHBl ciBib3VuZCwgc3VjaCBhczogNTAKCiAgIG8gIEZpbHRlciBkdXBsaWNhdGUgZG9tYWluIG5hbWVz CgogICBXaGlsZSB0aGVzZSBhcmUgbm90IGZvb2xwcm9vZiBtZXRob2RzLCBpdCB3aWxsIGxpa2Vs eSBwcmV2ZW50IHNpbXBsZQogICBkZW5pYWwgb2Ygc2VydmljZSBhdHRhY2tzLgoKCjcuICBSZWZl cmVuY2VzCgo3LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW1JGQzEwMzVdICBNb2NrYXBl dHJpcywgUC4sICJEb21haW4gbmFtZXMgLSBpbXBsZW1lbnRhdGlvbiBhbmQKICAgICAgICAgICAg ICBzcGVjaWZpY2F0aW9uIiwgU1REIDEzLCBSRkMgMTAzNSwgTm92ZW1iZXIgMTk4Ny4KCiAgIFtS RkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGlj YXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwg TWFyY2ggMTk5Ny4KCgoKCgpEYW1pY2sgICAgICAgICAgICAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5 IDIsIDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UgNl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAg IEFzc29jaWF0ZWQgTmFtZXMgRE5TIFJlY29yZCAgICAgICAgICAgQXVndXN0IDIwMTIKCgo3LjIu ICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBbSS1ELm5hcnRlbi1pYW5hLWNvbnNpZGVyYXRp b25zLXJmYzI0MzRiaXNdCiAgICAgICAgICAgICAgTmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFu ZCwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4KICAgICAgICAgICAgICBJQU5BIENvbnNpZGVy YXRpb25zIFNlY3Rpb24gaW4gUkZDcyIsCiAgICAgICAgICAgICAgZHJhZnQtbmFydGVuLWlhbmEt Y29uc2lkZXJhdGlvbnMtcmZjMjQzNGJpcy0wOSAod29yayBpbgogICAgICAgICAgICAgIHByb2dy ZXNzKSwgTWFyY2ggMjAwOC4KCiAgIFtJQU5BLVNFUlZJQ0UtTkFNRVNdCiAgICAgICAgICAgICAg SUFOQSwgIlNlcnZpY2UgTmFtZSBhbmQgVHJhbnNwb3J0IFByb3RvY29sIFBvcnQgTnVtYmVyCiAg ICAgICAgICAgICAgUmVnaXN0cnkiLCA8aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy8K ICAgICAgICAgICAgICBzZXJ2aWNlLW5hbWVzLXBvcnQtbnVtYmVycy8KICAgICAgICAgICAgICBz ZXJ2aWNlLW5hbWVzLXBvcnQtbnVtYmVycy50eHQ+LgoKICAgW1JGQzIxMzZdICBWaXhpZSwgUC4s IFRob21zb24sIFMuLCBSZWtodGVyLCBZLiwgYW5kIEouIEJvdW5kLAogICAgICAgICAgICAgICJE eW5hbWljIFVwZGF0ZXMgaW4gdGhlIERvbWFpbiBOYW1lIFN5c3RlbSAoRE5TIFVQREFURSkiLAog ICAgICAgICAgICAgIFJGQyAyMTM2LCBBcHJpbCAxOTk3LgoKICAgW1JGQzMyMzJdICBSZXlub2xk cywgSi4sICJBc3NpZ25lZCBOdW1iZXJzOiBSRkMgMTcwMCBpcyBSZXBsYWNlZCBieQogICAgICAg ICAgICAgIGFuIE9uLWxpbmUgRGF0YWJhc2UiLCBSRkMgMzIzMiwgSmFudWFyeSAyMDAyLgoKICAg W1JGQzYzMzVdICBDb3R0b24sIE0uLCBFZ2dlcnQsIEwuLCBUb3VjaCwgSi4sIFdlc3Rlcmx1bmQs IE0uLCBhbmQgUy4KICAgICAgICAgICAgICBDaGVzaGlyZSwgIkludGVybmV0IEFzc2lnbmVkIE51 bWJlcnMgQXV0aG9yaXR5IChJQU5BKQogICAgICAgICAgICAgIFByb2NlZHVyZXMgZm9yIHRoZSBN YW5hZ2VtZW50IG9mIHRoZSBTZXJ2aWNlIE5hbWUgYW5kCiAgICAgICAgICAgICAgVHJhbnNwb3J0 IFByb3RvY29sIFBvcnQgTnVtYmVyIFJlZ2lzdHJ5IiwgQkNQIDE2NSwKICAgICAgICAgICAgICBS RkMgNjMzNSwgQXVndXN0IDIwMTEuCgoKQXV0aG9yJ3MgQWRkcmVzcwoKICAgSmVmZnJleSBEYW1p Y2sKICAgTmV1c3RhcgogICA0NjAwMCBDZW50ZXIgT2FrIFBsYXphCiAgIFN0ZXJsaW5nLCBWQSAg MjAxNjYKICAgVVMKCiAgIEVtYWlsOiBqZWZmcmV5LmRhbWlja0BuZXVzdGFyLmJpegoKCgoKCgoK CgoKCgoKCkRhbWljayAgICAgICAgICAgICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMiwgMjAxMyAg ICAgICAgICAgICAgICBbUGFnZSA3XQoMCg== --_004_CC3EAFFC29F01jeffreydamickneustarbiz_-- From jeffrey.damick@neustar.biz Wed Aug 1 09:59:59 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 E00E711E8087 for ; Wed, 1 Aug 2012 09:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 lCCkcfvqcJso for ; Wed, 1 Aug 2012 09:59:58 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id EC13011E8151 for ; Wed, 1 Aug 2012 09:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1343840511; x=1659198726; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=1z4lZpvU7ivn1MgLkkfxLehqUs71ILIhUgAPYZpkSp4=; b=hkE7lOC8rAi9exauyDw2ujnBQ6+uViwXd6lfeQ63k4/Lb//OY3Rb7xgX8tacx6 LN4u7J/oznmaOCVU1v1IWtoA== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.12134340; Wed, 01 Aug 2012 13:01:50 -0400 Received: from STNTEXCH02.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 1 Aug 2012 12:59:53 -0400 From: "Damick, Jeffrey" To: "dnsext@ietf.org" Date: Wed, 1 Aug 2012 12:59:51 -0400 Thread-Topic: New Version Notification for draft-damick-dns-associated-names-record-00.txt Thread-Index: Ac1v+nyHHfvjuYomTjKMQKIRlfv7zQADJQe1 Message-ID: In-Reply-To: <20120801152943.9384.6547.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: N1mVSPEzCYz/xx/kJ7O+Mg== Content-Type: multipart/alternative; boundary="_000_CC3ED8C729F22jeffreydamickneustarbiz_" MIME-Version: 1.0 Subject: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.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: Wed, 01 Aug 2012 17:00:00 -0000 --_000_CC3ED8C729F22jeffreydamickneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Believe I've posted to the appropriate location now. ------ Forwarded Message From: Date: Wed, 1 Aug 2012 11:29:43 -0400 To: "Damick, Jeffrey" Subject: New Version Notification for draft-damick-dns-associated-names-rec= ord-00.txt A new version of I-D, draft-damick-dns-associated-names-record-00.txt has been successfully submitted by Jeffrey Damick and posted to the IETF repository. Filename: draft-damick-dns-associated-names-record Revision: 00 Title: Associated Names DNS Record Creation date: 2012-08-01 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-damick-dns-assoc= iated-names-record-00.txt Status: http://datatracker.ietf.org/doc/draft-damick-dns-associate= d-names-record Htmlized: http://tools.ietf.org/html/draft-damick-dns-associated-nam= es-record-00 Abstract: This document describes a new resource record for the Domain Name System (DNS) protocol. The record introduced will allow associated domain names to be associated with a particular domain name and retrieved in in a single DNS query. The IETF Secretariat ------ End of Forwarded Message --_000_CC3ED8C729F22jeffreydamickneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: New Version Notification for draft-damick-dns-associated-names-r= ecord-00.txt Believe I’ve posted to the appropriate location now.

------ Forwarded Message
From: <internet-drafts@ietf.= org>
Date: Wed, 1 Aug 2012 11:29:43 -0400
To: "Damick, Jeffrey" <jeffrey.damick@neustar.biz>
Subject: New Version Notification for draft-damick-dns-associated-na= mes-record-00.txt



A new version of I-D, draft-damick-dns-associated-names-record-00.txt
has been successfully submitted by Jeffrey Damick and posted to the
IETF repository.

Filename:        draft-damick-dns-associ= ated-names-record
Revision:        00
Title:           Associat= ed Names DNS Record
Creation date:   2012-08-01
WG ID:           Individu= al Submission
Number of pages: 7
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-damick-dns= -associated-names-record-00.txt
Status:          htt= p://datatracker.ietf.org/doc/draft-damick-dns-associated-names-record Htmlized:        http://tools.ie= tf.org/html/draft-damick-dns-associated-names-record-00


Abstract:
   This document describes a new resource record for the Dom= ain Name
   System (DNS) protocol.  The record introduced will a= llow associated
   domain names to be associated with a particular domain na= me and
   retrieved in in a single DNS query.

            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       


The IETF Secretariat



------ End of Forwarded Message
 --_000_CC3ED8C729F22jeffreydamickneustarbiz_-- From mohta@necom830.hpcl.titech.ac.jp Wed Aug 1 10:26:53 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 1830B11E839C for ; Wed, 1 Aug 2012 10:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.016 X-Spam-Level: X-Spam-Status: No, score=-0.016 tagged_above=-999 required=5 tests=[AWL=0.074, 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 PW88m0fOqQgD for ; Wed, 1 Aug 2012 10:26:52 -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 08DB311E812A for ; Wed, 1 Aug 2012 10:26:50 -0700 (PDT) Received: (qmail 69361 invoked from network); 1 Aug 2012 17:34:49 -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; 1 Aug 2012 17:34:49 -0000 Message-ID: <501966BA.2020507@necom830.hpcl.titech.ac.jp> Date: Thu, 02 Aug 2012 02:26:18 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: dnsext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.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: Wed, 01 Aug 2012 17:26:53 -0000 Damick, Jeffrey wrote: Hi, > Abstract: > This document describes a new resource record for the Domain Name > System (DNS) protocol. The record introduced will allow associated > domain names to be associated with a particular domain name and > retrieved in in a single DNS query. Considering that address RRs will be looked up first and, then, AN RRs, what's wrong to place the information at better place of HTTP header? Masataka Ohta From jeffrey.damick@neustar.biz Wed Aug 1 10:39:25 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 EAA9D21F88D6 for ; Wed, 1 Aug 2012 10:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 PWKQSVLDfeVz for ; Wed, 1 Aug 2012 10:39:22 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC3E21F874A for ; Wed, 1 Aug 2012 10:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1343842504; x=1659200255; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=J9fCc1jfjFNrdCj0uPAAS99iTmwOnRbglWZFNCsXE1k=; b=ArDfiij1+TFIdsLNSOawb9sINLXDtwUicdskNFJITRFBhGHYDgVuoGSP2sUv/Q WGjHHL7MURL9MRGEv+aJMU3Q== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.9380397; Wed, 01 Aug 2012 13:35:03 -0400 Received: from STNTEXCH02.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 1 Aug 2012 13:39:07 -0400 From: "Damick, Jeffrey" To: Masataka Ohta , "dnsext@ietf.org" Date: Wed, 1 Aug 2012 13:39:05 -0400 Thread-Topic: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.txt Thread-Index: Ac1wCuKa9YrktzUISvOZJGKM+JMhTwAAakhu Message-ID: In-Reply-To: <501966BA.2020507@necom830.hpcl.titech.ac.jp> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 7LPr10YahlojveZ2KxHxlw== Content-Type: multipart/alternative; boundary="_000_CC3EE1F929F28jeffreydamickneustarbiz_" MIME-Version: 1.0 Subject: Re: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.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: Wed, 01 Aug 2012 17:39:25 -0000 --_000_CC3EE1F929F28jeffreydamickneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So http is one potential use case for this, not necessarily the only one, I= 've heard other use cases for spdy and other protocols that want to associa= te domains together. On 8/1/12 1:26 PM, "Masataka Ohta" wrote= : Damick, Jeffrey wrote: Hi, > Abstract: > This document describes a new resource record for the Domain Name > System (DNS) protocol. The record introduced will allow associated > domain names to be associated with a particular domain name and > retrieved in in a single DNS query. Considering that address RRs will be looked up first and, then, AN RRs, what's wrong to place the information at better place of HTTP header? Masataka Ohta _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --_000_CC3EE1F929F28jeffreydamickneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dnsext] FW: New Version Notification for draft-damick-dns-assoc= iated-names-record-00.txt So http is one potential use case for this, not necessarily the only = one, I’ve heard other use cases for spdy and other protocols that wan= t to associate domains together.




On 8/1/12 1:26 PM, "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp> wrote:

Damick, Jeffrey wrote:

Hi,

> Abstract:
>     This document describes a new resource record = for the Domain Name
>     System (DNS) protocol.  The record introd= uced will allow associated
>     domain names to be associated with a particula= r domain name and
>     retrieved in in a single DNS query.

Considering that address RRs will be looked up first and, then,
AN RRs, what's wrong to place the information at better place
of HTTP header?

            &nb= sp;            =             &nb= sp;          Masataka Oht= a

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dnsext

--_000_CC3EE1F929F28jeffreydamickneustarbiz_-- From ogud@ogud.com Wed Aug 1 11:03:21 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 47F1B11E80EC for ; Wed, 1 Aug 2012 11:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Xaswh9ebCXB for ; Wed, 1 Aug 2012 11:03:20 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0E811E81CE for ; Wed, 1 Aug 2012 11:03:20 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q71I3HV3073305; Wed, 1 Aug 2012 14:03:18 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <50196F63.9000102@ogud.com> Date: Wed, 01 Aug 2012 14:03:15 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: dnsext@ietf.org, Jeffrey.Damick@neustar.biz References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: Re: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.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: Wed, 01 Aug 2012 18:03:21 -0000 On 01/08/2012 12:59, Damick, Jeffrey wrote: > Believe I’ve posted to the appropriate location now. > I read the draft and have a design question. You are placing the service selector inside the Record and implying that there can be records for multiple services provided by this name. Did you consider having the records stored at different names like _an-https. _an-http. ? In the past DNS has suffered when a RR uses sub-typing inside the record, but in size and in complication of applications selecting the right sub-type. If you store the AN records at selector names you can get rid of the service names inside the record. Olafur > ------ Forwarded Message > *From: * > *Date: *Wed, 1 Aug 2012 11:29:43 -0400 > *To: *"Damick, Jeffrey" > *Subject: *New Version Notification for > draft-damick-dns-associated-names-record-00.txt > > > > A new version of I-D, draft-damick-dns-associated-names-record-00.txt > has been successfully submitted by Jeffrey Damick and posted to the > IETF repository. > > Filename: draft-damick-dns-associated-names-record > Revision: 00 > Title: Associated Names DNS Record > Creation date: 2012-08-01 > WG ID: Individual Submission > Number of pages: 7 > URL: > http://www.ietf.org/internet-drafts/draft-damick-dns-associated-names-record-00.txt > Status: > http://datatracker.ietf.org/doc/draft-damick-dns-associated-names-record > Htmlized: > http://tools.ietf.org/html/draft-damick-dns-associated-names-record-00 > > > Abstract: > This document describes a new resource record for the Domain Name > System (DNS) protocol. The record introduced will allow associated > domain names to be associated with a particular domain name and > retrieved in in a single DNS query. > > > > > The IETF Secretariat > > > > ------ End of Forwarded Message > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > From miekg@atoom.net Wed Aug 1 11:17:10 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 75DB611E825D for ; Wed, 1 Aug 2012 11:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.465, 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 GQ9oemb52bj1 for ; Wed, 1 Aug 2012 11:17:09 -0700 (PDT) Received: from elektron.atoom.net (elektron.atoom.net [85.223.71.124]) by ietfa.amsl.com (Postfix) with ESMTP id 18AD211E8318 for ; Wed, 1 Aug 2012 11:16:59 -0700 (PDT) Received: by elektron.atoom.net (Postfix, from userid 1000) id 8F22F3FF2F; Wed, 1 Aug 2012 20:16:58 +0200 (CEST) Date: Wed, 1 Aug 2012 20:16:58 +0200 From: Miek Gieben To: dnsext@ietf.org Message-ID: <20120801181658.GA21997@miek.nl> Mail-Followup-To: dnsext@ietf.org References: <20120724085304.GB730@miek.nl> <20120724124430.GB5610@mail.yitter.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Subject: Re: [dnsext] nsec/nsec3 whitepaper as i-d 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, 01 Aug 2012 18:17:10 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Quoting in "Re: [dnsext] nsec/nsec3 whitepaper ..= =2E" ] > I agree with Andrew about the "no" for the WG, but disagree with him abou= t not publishing it as an Internet-Draft and eventually as an RFC.=20 I've just uploaded an i-d version of this whitepaper: A new version of I-D, draft-gieben-auth-denial-of-existence-dns-00.txt has been successfully submitted by R. (Miek) Gieben and posted to the IETF repository. Filename: draft-gieben-auth-denial-of-existence-dns Revision: 00 Title: Authenticated Denial of Existence in the DNS Creation date: 2012-08-01 WG ID: Individual Submission Number of pages: 21 URL: http://www.ietf.org/internet-drafts/draft-gieben-auth-deni= al-of-existence-dns-00.txt Status: http://datatracker.ietf.org/doc/draft-gieben-auth-denial-o= f-existence-dns Htmlized: http://tools.ietf.org/html/draft-gieben-auth-denial-of-exi= stence-dns-00 --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlAZcpoACgkQJYuFzziA0PbmNACfVcI+ZbOVYM2j/ZNGlIHBHBS3 ABgAoMVjhG1wKOtXIIEhvixr9qsjdlMV =lMy9 -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From paf@frobbit.se Wed Aug 1 11:41:15 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 4012D11E8180 for ; Wed, 1 Aug 2012 11:41:15 -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 rsm-J4js9pnP for ; Wed, 1 Aug 2012 11:41:14 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 9590911E829A for ; Wed, 1 Aug 2012 11:41:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 96F39144A5F79; Wed, 1 Aug 2012 20:41:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPPshSq2fR0J; Wed, 1 Aug 2012 20:41:12 +0200 (CEST) Received: from [192.168.1.53] (frobbit.cust.teleservice.net [85.30.128.225]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 6CD96144A5F76; Wed, 1 Aug 2012 20:41:12 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <50196F63.9000102@ogud.com> Date: Wed, 1 Aug 2012 20:41:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50196F63.9000102@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1485) Cc: dnsext@ietf.org Subject: Re: [dnsext] New Version Notification for draft-damick-dns-associated-names-record-00.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: Wed, 01 Aug 2012 18:41:15 -0000 1 aug 2012 kl. 20:03 skrev Olafur Gudmundsson : > On 01/08/2012 12:59, Damick, Jeffrey wrote: >> Believe I=92ve posted to the appropriate location now. >>=20 > > I read the draft and have a design question. > You are placing the service selector inside the Record and > implying that there can be records for multiple services provided by = this name. > Did you consider having the records stored at different names like > _an-https. > _an-http. > ? >=20 > In the past DNS has suffered when a RR uses sub-typing inside the = record, but in size and in complication of applications selecting the = right sub-type. > If you store the AN records at selector names you can get rid of the = service names inside the record. Agree with this comment. Please see RFC 5507. You could even use the URI record type with a prefix to announce the = URIs that will be needed, so you can pre-fetch not only the domain = names, but start to fetch the actual data needed... Patrik From jeffrey.damick@neustar.biz Wed Aug 1 12:13:46 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 8983811E810B for ; Wed, 1 Aug 2012 12:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 qwqjPFmfWOP7 for ; Wed, 1 Aug 2012 12:13:44 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id A6E9F11E809B for ; Wed, 1 Aug 2012 12:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1343848331; x=1659205641; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=yWD8WivfrH2wsKl6OvMsERgo1/htlT9gXj5WvveKgpI=; b=SXTQz0BnotL/a/CaWag8Ks859mGHjsNW9yNB5ewsRww+a6ujwODKjFPFdaSBOk gBENExCruFyw30dpnS6x248g== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.7922510; Wed, 01 Aug 2012 15:12:10 -0400 Received: from STNTEXCH02.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 1 Aug 2012 15:13:38 -0400 From: "Damick, Jeffrey" To: Olafur Gudmundsson , "dnsext@ietf.org" Date: Wed, 1 Aug 2012 15:13:34 -0400 Thread-Topic: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.txt Thread-Index: Ac1wD/H2+e3vh121RiqoYb5gsXQxYQACczEf Message-ID: In-Reply-To: <50196F63.9000102@ogud.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: QFfbjoYUwK0B7EoS9EVMDQ== Content-Type: multipart/alternative; boundary="_000_CC3EF81E29F43jeffreydamickneustarbiz_" MIME-Version: 1.0 Subject: Re: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.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: Wed, 01 Aug 2012 19:13:46 -0000 --_000_CC3EF81E29F43jeffreydamickneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe the drawback is that rather than being to in bulk query for all A= N records the client would have to poke for each service they are using. F= or 1 service this isn't really an issue but if the application wanted to f= allback to another another type it would have to re-query for each.. Of co= urse this could be a client optimization exercise. I agree the service name on the name itself may still make more sense, and = I'll review 5507 as Patrik suggested. Thanks -jeff On 8/1/12 2:03 PM, "Olafur Gudmundsson" wrote: On 01/08/2012 12:59, Damick, Jeffrey wrote: > Believe I've posted to the appropriate location now. > I read the draft and have a design question. You are placing the service selector inside the Record and implying that there can be records for multiple services provided by this name. Did you consider having the records stored at different names like _an-https. _an-http. ? In the past DNS has suffered when a RR uses sub-typing inside the record, but in size and in complication of applications selecting the right sub-type. If you store the AN records at selector names you can get rid of the service names inside the record. Olafur > ------ Forwarded Message > *From: * > *Date: *Wed, 1 Aug 2012 11:29:43 -0400 > *To: *"Damick, Jeffrey" > *Subject: *New Version Notification for > draft-damick-dns-associated-names-record-00.txt > > > > A new version of I-D, draft-damick-dns-associated-names-record-00.txt > has been successfully submitted by Jeffrey Damick and posted to the > IETF repository. > > Filename: draft-damick-dns-associated-names-record > Revision: 00 > Title: Associated Names DNS Record > Creation date: 2012-08-01 > WG ID: Individual Submission > Number of pages: 7 > URL: > http://www.ietf.org/internet-drafts/draft-damick-dns-associated-names-rec= ord-00.txt > Status: > http://datatracker.ietf.org/doc/draft-damick-dns-associated-names-record > Htmlized: > http://tools.ietf.org/html/draft-damick-dns-associated-names-record-00 > > > Abstract: > This document describes a new resource record for the Domain Name > System (DNS) protocol. The record introduced will allow associated > domain names to be associated with a particular domain name and > retrieved in in a single DNS query. > > > > > The IETF Secretariat > > > > ------ End of Forwarded Message > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --_000_CC3EF81E29F43jeffreydamickneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dnsext] FW: New Version Notification for draft-damick-dns-assoc= iated-names-record-00.txt I believe the drawback is that rather than being to in bulk query for= all AN records the client would have to poke for each service they are usi= ng.  For 1 service this isn’t  really an issue but if the a= pplication wanted to fallback to another another type it would have to re-q= uery for each..  Of course this could be a client optimization exercis= e.

I agree the service name on the name itself may still make more sense, and = I’ll review 5507 as Patrik suggested= .


Thanks
-jeff


On 8/1/12 2:03 PM, "Olafur Gudmundsson" <ogud@ogud.com> wrote:

On 01/08/2012 12:59, Damick, Jeffrey wrote:=
> Believe I’ve posted to the appropriate location now.
>
<no-hat>
I read the draft and have a design question.
You are placing the service selector inside the Record and
implying that there can be records for multiple services provided by
this name.
Did you consider having the records stored at different names like
    _an-https.<fqdn>
    _an-http.<fqdn>
?

In the past DNS has suffered when a RR uses sub-typing inside the
record, but in size and in complication of applications selecting the
right sub-type.
If you store the AN records at selector names you can get rid of the
service names inside the record.

        Olafur


> ------ Forwarded Message
> *From: *<internet-drafts@ietf.= org>
> *Date: *Wed, 1 Aug 2012 11:29:43 -0400
> *To: *"Damick, Jeffrey" <jeffrey.damick@neustar.biz>
> *Subject: *New Version Notification for
> draft-damick-dns-associated-names-record-00.txt
>
>
>
> A new version of I-D, draft-damick-dns-associated-names-record-00.txt<= BR> > has been successfully submitted by Jeffrey Damick and posted to the > IETF repository.
>
> Filename:        draft-damick-dns-a= ssociated-names-record
> Revision:        00
> Title:           Ass= ociated Names DNS Record
> Creation date:   2012-08-01
> WG ID:           Ind= ividual Submission
> Number of pages: 7
> URL:
> http://www.ietf.org/internet-drafts/draft-damick-= dns-associated-names-record-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-damick-dns-associated-= names-record
> Htmlized:
> http://tools.ietf.org/html/draft-damick-dns-associated-names-r= ecord-00
>
>
> Abstract:
>     This document describes a new resource record = for the Domain Name
>     System (DNS) protocol.  The record introd= uced will allow associated
>     domain names to be associated with a particula= r domain name and
>     retrieved in in a single DNS query.
>
>
>
>
> The IETF Secretariat
>
>
>
> ------ End of Forwarded Message
>
>
> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.i= etf.org/mailman/listinfo/dnsext
>



--_000_CC3EF81E29F43jeffreydamickneustarbiz_-- From paf@frobbit.se Wed Aug 1 12:19:27 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 1D1C621F8833 for ; Wed, 1 Aug 2012 12:19:27 -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 f40HAt-Xlf1c for ; Wed, 1 Aug 2012 12:19:26 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 5F47721F8830 for ; Wed, 1 Aug 2012 12:19:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id BA53B144A6739; Wed, 1 Aug 2012 21:19:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5dgsbsvQWTg; Wed, 1 Aug 2012 21:19:25 +0200 (CEST) Received: from [192.168.1.53] (frobbit.cust.teleservice.net [85.30.128.225]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 90AAF144A6732; Wed, 1 Aug 2012 21:19:25 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: =?windows-1252?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Wed, 1 Aug 2012 21:19:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Damick, Jeffrey" X-Mailer: Apple Mail (2.1485) Cc: "dnsext@ietf.org" , Olafur Gudmundsson Subject: Re: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.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: Wed, 01 Aug 2012 19:19:27 -0000 1 aug 2012 kl. 21:13 skrev "Damick, Jeffrey" = : > I agree the service name on the name itself may still make more sense, = and I=92ll review 5507 as Patrik suggested. Maybe you need what you do _and_ a prefix. The key thing (I wrote 5507 so I can explain) is that you ensure that = clients do not get "too much" data back. If all clients all the time = want to have all records in the rr-set, then you are correct. As soon as = the client must parse the rdata and select the subset that it is = interested in, then you are on the slippery slope and want to insert a = selector in the triple {type, class, owner} in the query so that the = calculation of the subset is made on the server side. Patrik From mohta@necom830.hpcl.titech.ac.jp Wed Aug 1 13:05:16 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 D3DD811E814C for ; Wed, 1 Aug 2012 13:05:16 -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 DqZoIrUFmqQO for ; Wed, 1 Aug 2012 13:05:16 -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 B599611E810A for ; Wed, 1 Aug 2012 13:05:15 -0700 (PDT) Received: (qmail 71850 invoked from network); 1 Aug 2012 20:13:17 -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; 1 Aug 2012 20:13:17 -0000 Message-ID: <50198BDE.2090602@necom830.hpcl.titech.ac.jp> Date: Thu, 02 Aug 2012 05:04:46 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Damick, Jeffrey" References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "dnsext@ietf.org" Subject: Re: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.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: Wed, 01 Aug 2012 20:05:17 -0000 Damick, Jeffrey wrote: > So http is one potential use case for this, not necessarily > the only one, I've heard other use cases for spdy and other > protocols that want to associate domains together. My point is that applications should take care of themselves, because they know how they will behave. Olafur Gudmundsson wrote: > Did you consider having the records stored at different names like The problem is that necessary associated names depend not only on service names but also on file names. Masataka Ohta From jeffrey.damick@neustar.biz Wed Aug 1 14:18:46 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 7FE2F11E833F for ; Wed, 1 Aug 2012 14:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 9-1GN1Wj-4fy for ; Wed, 1 Aug 2012 14:18:44 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8F26A11E8339 for ; Wed, 1 Aug 2012 14:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1343856190; x=1659216132; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=CXhPacN8Rbrk0WVsOK+ANf/wP/0c6efizVsT45qGQmY=; b=rXZuidbLnZ13+FPX2dQdgFJL0jfD9Fg1DpVTiBFpV8uuc4PyOxqjARxmGodI/L paKcmnnT89Hd4Uo17Jm2VT5w== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.12593608; Wed, 01 Aug 2012 17:22:16 -0400 Received: from STNTEXCH02.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 1 Aug 2012 17:17:49 -0400 From: "Damick, Jeffrey" To: Masataka Ohta Date: Wed, 1 Aug 2012 17:17:48 -0400 Thread-Topic: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.txt Thread-Index: Ac1wISBnOyoO+q4hSiaAdlb8iqOV8QACflAi Message-ID: In-Reply-To: <50198BDE.2090602@necom830.hpcl.titech.ac.jp> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: aMxnGBgqDAjNUSo9szq9yw== Content-Type: multipart/alternative; boundary="_000_CC3F153C29F6Cjeffreydamickneustarbiz_" MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.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: Wed, 01 Aug 2012 21:18:46 -0000 --_000_CC3F153C29F6Cjeffreydamickneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 8/1/12 4:04 PM, "Masataka Ohta" wrote= : Damick, Jeffrey wrote: > So http is one potential use case for this, not necessarily > the only one, I've heard other use cases for spdy and other > protocols that want to associate domains together. My point is that applications should take care of themselves, because they know how they will behave. But this record enables applications to take care of themselves, to me it's= analogous to the intent of records like: SPF, SSHFP, MX, etc. Olafur Gudmundsson wrote: > Did you consider having the records stored at different names like The problem is that necessary associated names depend not only on service names but also on file names. Sorry I don't follow the reference to 'file names'? thanks -jeff --_000_CC3F153C29F6Cjeffreydamickneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dnsext] FW: New Version Notification for draft-damick-dns-assoc= iated-names-record-00.txt


On 8/1/12 4:04 PM, "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp> wrote:

Damick, Jeffrey wrote:

> So http is one potential use case for this, not necessarily
> the only one, I've heard other use cases for spdy and other
> protocols that want to associate domains together.

My point is that applications should take care of themselves,
because they know how they will behave.



Olafur Gudmundsson wrote:

> Did you consider having the records stored at different names like

The problem is that necessary associated names depend not only
on service names but also on file names.

 References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "dnsext@ietf.org" Subject: Re: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.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: Wed, 01 Aug 2012 21:47:53 -0000 Damick, Jeffrey wrote: > But this record enables applications to take care of themselves, I mean your proposal depends details of application protocols that let applications take care of themselves, especially because getting HTTP header is not much more time consuming than getting AN RRs. > to me it's analogous to the intent of records like: SPF, SSHFP, > MX, etc. No, unlike them, AN burdens DNS blindly in a way not necessarilly useful to applications. > Sorry I don't follow the reference to 'file names'? Do you want me to call them url-pathes? Masataka Ohta From jeffrey.damick@neustar.biz Thu Aug 2 06:41:24 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 B4BB221F8534 for ; Thu, 2 Aug 2012 06:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 5-tuomXuuBRD for ; Thu, 2 Aug 2012 06:41:22 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC7321F8512 for ; Thu, 2 Aug 2012 06:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1343914792; x=1659239678; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=WmaNQHQHfPGC4rU/kEbr/3JbTD8+fBJeySboUhPxTNo=; b=M0SgSiNVv273n5P3fmQjexd17TfnRBGWbL8BnfaKTLRmGkz7jgxom8B2OZs2CA wcfREOTdjp0c23XEMFGaK0RA== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.7948162; Thu, 02 Aug 2012 09:39:51 -0400 Received: from STNTEXCH02.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 2 Aug 2012 09:41:19 -0400 From: "Damick, Jeffrey" To: Masataka Ohta Date: Thu, 2 Aug 2012 09:41:17 -0400 Thread-Topic: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.txt Thread-Index: Ac1wL2Lrh9rC4ZaJQ/69sbciUze46wAhRrab Message-ID: In-Reply-To: <5019A3D9.8040308@necom830.hpcl.titech.ac.jp> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: RNbNEPLClkz240o/NUfBrA== Content-Type: multipart/alternative; boundary="_000_CC3FFBBE29FBDjeffreydamickneustarbiz_" MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.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: Thu, 02 Aug 2012 13:41:25 -0000 --_000_CC3FFBBE29FBDjeffreydamickneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 8/1/12 5:47 PM, "Masataka Ohta" wrote= : Damick, Jeffrey wrote: > But this record enables applications to take care of themselves, I mean your proposal depends details of application protocols that let applications take care of themselves, especially because getting HTTP header is not much more time consuming than getting AN RRs. As previously mentioned, I'm not trying to solve something just for http, t= hat is of course one use case however I've heard of others.. > to me it's analogous to the intent of records like: SPF, SSHFP, > MX, etc. No, unlike them, AN burdens DNS blindly in a way not necessarilly useful to applications. Would you please elaborate on your position? I still so no difference betw= een this and those other record types which have meaning to other applicati= ons such as, supporting smtp, etc.. > Sorry I don't follow the reference to 'file names'? Do you want me to call them url-pathes? I still don't see the connection you are making to URLs, this is only discu= ssing domain names. -jeff --_000_CC3FFBBE29FBDjeffreydamickneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dnsext] FW: New Version Notification for draft-damick-dns-assoc= iated-names-record-00.txt


On 8/1/12 5:47 PM, "Masataka Ohta" <mohta@necom830.hpcl.titech.ac.jp> wrote:

Damick, Jeffrey wrote:

> But this record enables applications to take care of themselves,

I mean your proposal depends details of application protocols
that let applications take care of themselves, especially
because getting HTTP header is not much more time consuming
than getting AN RRs.


> to me it's analogous to the intent of records like: SPF, SSHFP,
> MX, etc.

No, unlike them, AN burdens DNS blindly in a way not necessarilly
useful to applications.


> Sorry I don't follow the reference to 'file names'?

Do you want me to call them url-pathes?

 From: "Michael Sheldon" To: "dnsext@ietf.org" Date: Thu, 02 Aug 2012 09:59:51 -0700 Mime-Version: 1.0 Subject: Re: [dnsext] draft-damick-dns-associated-names-record.txt-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: Thu, 02 Aug 2012 16:59:54 -0000 I'm trying to figure out what real-world problem this record solves that=0A= could not be handled by SRV?=0A=0AMichael Sheldon=0ADev-DNS Services=0AGoDa= ddy.com=0A=0A> -------- Original Message --------=0A> Subject: [dnsext] dra= ft-damick-dns-associated-names-record.txt-00=0A> From: "Damick, Jeffrey" =0A> Date: Wed, August 01, 2012 7:05 am=0A> To: "= dns-rrtype-applications@ietf.org"=0A> , "= dnsext@ietf.org" =0A> =0A> =0A> A. Submission Date: 8/1/2= 012=0A> =0A> B. Submission Type:=0A> [X] New RRTYPE=0A> [ ] = Modification to existing RRTYPE=0A> =0A From dougb@dougbarton.us Thu Aug 2 10:09:15 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 E44EA21E80C0 for ; Thu, 2 Aug 2012 10:09:15 -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 hEQIAxBzMN-8 for ; Thu, 2 Aug 2012 10:09:15 -0700 (PDT) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id EC9FD21E8090 for ; Thu, 2 Aug 2012 10:09:14 -0700 (PDT) Received: (qmail 6131 invoked by uid 399); 2 Aug 2012 17:09:05 -0000 Received: from unknown (HELO opti.dougb.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 2 Aug 2012 17:09:05 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <501AB436.7000102@dougbarton.us> Date: Thu, 02 Aug 2012 10:09:10 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Michael Sheldon References: <20120802095951.205a61dff9fc1684c258b274662bb912.e73eee9133.wbe@email00.secureserver.net> In-Reply-To: <20120802095951.205a61dff9fc1684c258b274662bb912.e73eee9133.wbe@email00.secureserver.net> X-Enigmail-Version: 1.4.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dnsext@ietf.org" Subject: Re: [dnsext] draft-damick-dns-associated-names-record.txt-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: Thu, 02 Aug 2012 17:09:16 -0000 +1 On 08/02/2012 09:59, Michael Sheldon wrote: > I'm trying to figure out what real-world problem this record solves that > could not be handled by SRV? > > Michael Sheldon > Dev-DNS Services > GoDaddy.com > >> -------- Original Message -------- >> Subject: [dnsext] draft-damick-dns-associated-names-record.txt-00 >> From: "Damick, Jeffrey" >> Date: Wed, August 01, 2012 7:05 am >> To: "dns-rrtype-applications@ietf.org" >> , "dnsext@ietf.org" >> >> >> A. Submission Date: 8/1/2012 >> >> B. Submission Type: >> [X] New RRTYPE >> [ ] Modification to existing RRTYPE >> > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From jeffrey.damick@neustar.biz Thu Aug 2 12:06: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 9A57D11E80E4 for ; Thu, 2 Aug 2012 12:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 P6dMzhlH5Svz for ; Thu, 2 Aug 2012 12:05:59 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id BAE2611E80FB for ; Thu, 2 Aug 2012 12:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1343934101; x=1659293988; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=rBX2d05XHexog2Aoui/J5cfUW0IkKK9gU4LAwBbXExo=; b=IHbcldQOQEg8oOaGOQYQNECDiWNWofnTkIUqzKcnOmBJrRb4cOrOR7tcG5LT3F mwffcU6i/JOYsdUKYp05jnqQ== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.9419868; Thu, 02 Aug 2012 15:01:40 -0400 Received: from STNTEXCH02.cis.neustar.com ([fe80::f828:7b2d:14aa:84b7]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 2 Aug 2012 15:05:43 -0400 From: "Damick, Jeffrey" To: Michael Sheldon , "dnsext@ietf.org" Date: Thu, 2 Aug 2012 15:05:42 -0400 Thread-Topic: [dnsext] draft-damick-dns-associated-names-record.txt-00 Thread-Index: Ac1w0E1E1UOyiGq7Rb6e1+73k3XUIAAEYKKj Message-ID: In-Reply-To: <20120802095951.205a61dff9fc1684c258b274662bb912.e73eee9133.wbe@email00.secureserver.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: zMby9UrehrIXX6V+F6Ajew== Content-Type: multipart/alternative; boundary="_000_CC4047C62A006jeffreydamickneustarbiz_" MIME-Version: 1.0 Subject: Re: [dnsext] draft-damick-dns-associated-names-record.txt-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: Thu, 02 Aug 2012 19:06:00 -0000 --_000_CC4047C62A006jeffreydamickneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well SRV implies the target has an A or AAAA target, whereas the AN record = type proposed allows you specify the type associated with the group. Also = to me, the intent of SRV is more toward discovery of a service (its port, w= hich one to choose, etc), and the AN's intent is toward grouping of domain = names from a given point (name) as they relate to a particular service. So= while I suppose you could overload that record, I think that distorts and = confuses the usage of SRV for clients since you may not actually contact th= e service listed. -jeff On 8/2/12 12:59 PM, "Michael Sheldon" wrote: I'm trying to figure out what real-world problem this record solves that could not be handled by SRV? Michael Sheldon Dev-DNS Services GoDaddy.com > -------- Original Message -------- > Subject: [dnsext] draft-damick-dns-associated-names-record.txt-00 > From: "Damick, Jeffrey" > Date: Wed, August 01, 2012 7:05 am > To: "dns-rrtype-applications@ietf.org" > , "dnsext@ietf.org" > > > A. Submission Date: 8/1/2012 > > B. Submission Type: > [X] New RRTYPE > [ ] Modification to existing RRTYPE > _______________________________________________ dnsext mailing list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext --_000_CC4047C62A006jeffreydamickneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dnsext] draft-damick-dns-associated-names-record.txt-00 Well SRV implies the target has an A or AAAA target, whereas the AN r= ecord type proposed allows you specify the type associated with the group. =  Also to me, the intent of SRV is more toward discovery of a service (= its port, which one to choose, etc), and the AN’s intent is toward gr= ouping of domain names from a given point (name) as they relate to a partic= ular service.  So while I suppose you could overload that record, I th= ink that distorts and confuses the usage of SRV for clients since you may n= ot actually contact the service listed.

-jeff


On 8/2/12 12:59 PM, "Michael Sheldon" <msheldon@godaddy.com> wrote:

I'm trying to figure out what real-world pr= oblem this record solves that
could not be handled by SRV?

Michael Sheldon
Dev-DNS Services
GoDaddy.com

> -------- Original Message --------
> Subject: [dnsext] draft-damick-dns-associated-names-record.txt-00
> From: "Damick, Jeffrey" <Jeffrey.Damick@neustar.biz>
> Date: Wed, August 01, 2012 7:05 am
> To: "dns-rrtype-appl= ications@ietf.org"
> <dns-rrtype-applicatio= ns@ietf.org>, "dnsext@ietf.org&= quot; <dnsext@ietf.org>
>
>
> A. Submission Date:  8/1/2012
>
>    B. Submission Type:
>       [X] New RRTYPE
>       [ ] Modification to existing RRTYP= E
>

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dnsext

--_000_CC4047C62A006jeffreydamickneustarbiz_-- From mohta@necom830.hpcl.titech.ac.jp Thu Aug 2 12:57:28 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 78DC411E81B6 for ; Thu, 2 Aug 2012 12:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.033 X-Spam-Level: X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5 tests=[AWL=0.057, 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 iB4xTI6vIE0D for ; Thu, 2 Aug 2012 12:57:28 -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 976D311E81AF for ; Thu, 2 Aug 2012 12:57:27 -0700 (PDT) Received: (qmail 92044 invoked from network); 2 Aug 2012 20:05: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; 2 Aug 2012 20:05:45 -0000 Message-ID: <501ADB87.7030600@necom830.hpcl.titech.ac.jp> Date: Fri, 03 Aug 2012 04:56:55 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Damick, Jeffrey" References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "dnsext@ietf.org" Subject: Re: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.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: Thu, 02 Aug 2012 19:57:28 -0000 Damick, Jeffrey wrote: >> But this record enables applications to take care of themselves, > > I mean your proposal depends details of application protocols > that let applications take care of themselves, especially > because getting HTTP header is not much more time consuming > than getting AN RRs. > > As previously mentioned, I'm not trying to solve something just > for http, that is of course one use case however I've heard > of others.. And, as I already said, my counter argument is not just for http. >> to me it's analogous to the intent of records like: SPF, SSHFP, >> MX, etc. > > No, unlike them, AN burdens DNS blindly in a way not necessarilly > useful to applications. > > Would you please elaborate on your position? You should learn how to quote others' mails with proper nesting and line wrapping. > I still so no > difference between this and those other record types which > have meaning to other applications such as, supporting smtp, etc.. Suppose there are: http://www.example.com/page0.html with associated names of a.example.com and b.example.com http://www.example.com/page1.htmlhtml with associated names of b.example.com and c.example.com http://www.example.com/page2.htmlhtml with associated names of c.example.com and a.example.com how can you set AN of www.example.com? It all depends on application details of contents of files. > this is only discussing domain names. Not at all. Masataka Ohta From jeffrey.damick@neustar.biz Thu Aug 2 13:17:24 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 E792821E80BF for ; Thu, 2 Aug 2012 13:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 u5ljbXcwrfes for ; Thu, 2 Aug 2012 13:17:23 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4CA11E8072 for ; Thu, 2 Aug 2012 13:17:23 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so914773vbb.31 for ; Thu, 02 Aug 2012 13:17:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=hBRFt4Nfedre5SQ3sI/N2Sy2u4IgDAo4dhys9d/A5rY=; b=ZD8pljlNMJu/5aiCaV17IqnZcc392Wo2k+NbRStj69Cxx+Uwqom0iOO3rF3uTO7KTa 2WeMkbYP61uQ33IRGNoN7U6cVcP7JchIa/TbJCmiPlFJgFDK8+Sn+2zZNlHHSlJBbjJN RqhQsK1sj/x2jTCtnQXA1/D9OFsvVEVqe1n7nxJlZa+aHPZswXJKnAcSwkHQ0S7nUB2U 0tv+CKSzIpO2RDfKsWxqTdx6MKujo8iDA7CLx52WJ4a1xgiD48XgmuYgxZnrdCc7v2h/ yxvtQhEhSsWdpWn4yu5u1obCQHYZHherg/y8NRSglOSr6Iv/IChpxHvjau8kkzkV968M YZpA== MIME-Version: 1.0 Received: by 10.52.70.137 with SMTP id m9mr2117967vdu.49.1343938642517; Thu, 02 Aug 2012 13:17:22 -0700 (PDT) Received: by 10.221.11.135 with HTTP; Thu, 2 Aug 2012 13:17:22 -0700 (PDT) In-Reply-To: <501ADB87.7030600@necom830.hpcl.titech.ac.jp> References: <501ADB87.7030600@necom830.hpcl.titech.ac.jp> Date: Thu, 2 Aug 2012 16:17:22 -0400 Message-ID: From: "Damick, Jeffrey" To: Masataka Ohta Content-Type: multipart/alternative; boundary=bcaec5015e55631db004c64e19bc X-Gm-Message-State: ALoCoQnjcSMv5Wsjyz1tjww4P6Nm6iDtMmHNJyQ0bj/ur3X8c77yf/ZZGrkPEK/yFyA6fm2OFBBa Cc: dnsext@ietf.org Subject: Re: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jeffrey.damick@neustar.biz List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 20:17:24 -0000 --bcaec5015e55631db004c64e19bc Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 2, 2012 at 3:56 PM, Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote: > Damick, Jeffrey wrote: > > > I still so no > > difference between this and those other record types which > > have meaning to other applications such as, supporting smtp, etc.. > > Suppose there are: > > http://www.example.com/page0.html with associated names of > a.example.com and b.example.com > > http://www.example.com/page1.htmlhtml with associated names of > b.example.com and c.example.com > > http://www.example.com/page2.htmlhtml with associated names of > c.example.com and a.example.com > > how can you set AN of www.example.com? > > It all depends on application details of contents of files. > I believe the disconnect is that the AN record doesn't reference to or from URLs, just the domain names. so you could have: www.example.com with associated names: a.example.com, c.example.com, b.example.com But it is not granular to the level of a URL.. -jeff --bcaec5015e55631db004c64e19bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Aug 2, 2012 at 3:56 PM, Masataka= Ohta <mohta@necom830.hpcl.titech.ac.jp> wrot= e:
Damick, Jeffrey wrote:

> I still so no
> difference between this and those other record types which
> have meaning to other applications such as, supporting smtp, etc..

Suppose there are:

=A0 =A0 =A0 =A0 http://www.example.com/page0.html with associated names of
=A0 =A0 =A0 =A0 a.exampl= e.com and b.example.= com

=A0 =A0 =A0 =A0 http://www.example.com/page1.htmlhtml with associated names of=
=A0 =A0 =A0 =A0 b.exampl= e.com and c.example.= com

=A0 =A0 =A0 =A0 http://www.example.com/page2.htmlhtml with associated names of=
=A0 =A0 =A0 =A0 c.exampl= e.com and a.example.= com

how can you set AN of = www.example.com?

It all depends on application details of contents of files.


I believe the disconnect is that the AN= record doesn't reference to or from URLs, just the domain names. =A0

so you could have: w= ww.example.com with associated names: = a.example.com, c.example.com, b.example.com

But it is not granular to the level of a URL..



-jeff




=A0
--bcaec5015e55631db004c64e19bc-- From mohta@necom830.hpcl.titech.ac.jp Thu Aug 2 15:47:59 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 381A511E810D for ; Thu, 2 Aug 2012 15:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.037 X-Spam-Level: X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5 tests=[AWL=0.053, 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 WpRXB3HTFdvA for ; Thu, 2 Aug 2012 15:47:58 -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 4C17711E80A2 for ; Thu, 2 Aug 2012 15:47:58 -0700 (PDT) Received: (qmail 94484 invoked from network); 2 Aug 2012 22:56:15 -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; 2 Aug 2012 22:56:15 -0000 Message-ID: <501B037A.9050507@necom830.hpcl.titech.ac.jp> Date: Fri, 03 Aug 2012 07:47:22 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: jeffrey.damick@neustar.biz References: <501ADB87.7030600@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: dnsext@ietf.org Subject: Re: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.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: Thu, 02 Aug 2012 22:47:59 -0000 Damick, Jeffrey wrote: > so you could have: www.example.com with associated names: a.example.com, > c.example.com, b.example.com Thus, "No, unlike them, AN burdens DNS blindly in a way not necessarilly useful to applications". > But it is not granular to the level of a URL.. Thus, "necessary associated names depend not only on service names but also on file names". Worse, even only with domain names, aggressive name based virtual hosting makes NA practically useless. A virtual name node with a CNAME RR can't have its own AN RRs. Moreover, file contents and DNS may not shnchronize well because of lazy administrations or DNS caching. So, let applications, which exactly, automatically and timely know what they need, take care of themselves. Masataka Ohta From jeffrey.damick@neustar.biz Fri Aug 3 06:01:57 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 2BC2621F8D93 for ; Fri, 3 Aug 2012 06:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Sszae1aPpL+Y for ; Fri, 3 Aug 2012 06:01:56 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35F1221F8D92 for ; Fri, 3 Aug 2012 06:01:55 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so744290vbb.31 for ; Fri, 03 Aug 2012 06:01:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=aGNJX8VQMeZMC7YDolBOZhyx5CSNimFYHqk04TloaOA=; b=pbTYdYfpiR/tVLWKAgoCRoHevi5jTIi7y+pIaSwss36q/Bq+K7O6yANxJAnXLuQAJw ac30sLpSZpaCDnVbL9nIx2wgroCar4fH8hP4CKImIRipCmKPEhvv6aPzB/EgR3NHOEJD XQWpUkD2YPnNU2redR+gwMkmfK4jpR4MGnwREX/HdVJ9Dvbz66B57V5fNt0lfzTcGddU 4Jw9S9C7DCuQelbWFwikK1Pxw5uM6RYRK6eYrotoKSgyr6mf7rMvMAFyDrqmmSuV67Vq Bh/g5YM/pPndWMi7UvCyfxxOi3/fbMmV0Rn9EGecxVDYbmc0hg04fmHze4lMJA7HbqUG jvhg== MIME-Version: 1.0 Received: by 10.220.240.5 with SMTP id ky5mr1193543vcb.57.1343998915241; Fri, 03 Aug 2012 06:01:55 -0700 (PDT) Received: by 10.221.11.135 with HTTP; Fri, 3 Aug 2012 06:01:55 -0700 (PDT) In-Reply-To: <501B037A.9050507@necom830.hpcl.titech.ac.jp> References: <501ADB87.7030600@necom830.hpcl.titech.ac.jp> <501B037A.9050507@necom830.hpcl.titech.ac.jp> Date: Fri, 3 Aug 2012 09:01:55 -0400 Message-ID: From: "Damick, Jeffrey" To: Masataka Ohta Content-Type: multipart/alternative; boundary=14dae9cdc68bebe85e04c65c21bb X-Gm-Message-State: ALoCoQkVQ29MrN69UyVlBqQ0CWelsQuyUS+eOBNVxxZrjhI3vmrR85Sd+RBS1fAXwEl/XrMqmYR2 Cc: dnsext@ietf.org Subject: Re: [dnsext] FW: New Version Notification for draft-damick-dns-associated-names-record-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jeffrey.damick@neustar.biz List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 13:01:57 -0000 --14dae9cdc68bebe85e04c65c21bb Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 2, 2012 at 6:47 PM, Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote: > Damick, Jeffrey wrote: > > > so you could have: www.example.com with associated names: a.example.com, > > c.example.com, b.example.com > > Thus, "No, unlike them, AN burdens DNS blindly in a way not > necessarilly useful to applications". > Can you please provide more substance to this argument as I would assert that many other records are 'not necessarily useful to applications' - it really depends on your point of view. For example if you application cares nothing about email than an SPF or MX record doesn't apply to it so they aren't 'useful' to it. As far as DNS being blind to it, isn't that the point? > > > But it is not granular to the level of a URL.. > > Thus, "necessary associated names depend not only > on service names but also on file names". > > They do not depend on file names, URLs, or URIs, no field like that is defined in the record data.. So there is no tie to 'file names'... > Worse, even only with domain names, aggressive name based > virtual hosting makes NA practically useless. A virtual > name node with a CNAME RR can't have its own AN RRs. However, if I make the modification suggested by Olafur this would be possible. So that's a good reason to pursue that route. > Moreover, file contents and DNS may not shnchronize well > because of lazy administrations or DNS caching. > > So, let applications, which exactly, automatically and timely > know what they need, take care of themselves. > Then why are there records such as SSHFP, IPSSEC, SRV, etc. that 'enable' applications to take care of themselves. The draft doesn't specify the 'how' only the 'what', to enable applications to build on it do whatever makes sense for them in the context of a group of associated domain names.. thanks for the input. -jeff --14dae9cdc68bebe85e04c65c21bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Aug 2, 2012 at 6:47 PM, Masataka= Ohta <mohta@necom830.hpcl.titech.ac.jp> wrot= e:
Damick, Jeffrey wrote:

> so you could have: www.example.com with associated names: a.example.com,
> c.example.com, = b.example.com

Thus, "No, unlike them, AN burdens DNS blindly in a way not
necessarilly useful to applications".

Can you please provide more substance to this a= rgument as I would assert that many other records are 'not necessarily = useful to applications' - it really depends on your point of view. =A0F= or example if you application cares nothing about email than an SPF or MX r= ecord doesn't apply to it so they aren't 'useful' to it.=A0=

As far as DNS being blind to it, isn't that the poi= nt? =A0

=A0

> But it is not granular to the level of a URL..

Thus, "necessary associated names depend not only
on service names but also on file names".


They do not depend on file names= , URLs, or URIs, no field like that is defined in the record data.. =A0So t= here is no tie to 'file names'...
=A0
Worse, even only with domain names, aggressive name based
virtual hosting makes NA practically useless. A virtual
name node with a CNAME RR can't have its own AN RRs.
<= br>
However, if I make the modification suggested by Olafur this = would be possible. So that's a good reason to pursue that route.=A0
=A0
=A0
Moreover, file contents and DNS may not shnchronize well
because of lazy administrations or DNS caching.

So, let applications, which exactly, automatically and timely
know what they need, take care of themselves.

=A0
Then why are there records such as SSHFP, IPSSEC, SRV,= etc. that 'enable' applications to take care of themselves. =A0The= draft doesn't specify the 'how' only the 'what', to en= able applications to build on it do whatever makes sense for them in the co= ntext of a group of associated domain names..

thanks for the input.

-jeff


=A0
--14dae9cdc68bebe85e04c65c21bb-- From fneves@registro.br Fri Aug 3 08:42:18 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 9C5F721F8D36 for ; Fri, 3 Aug 2012 08:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, 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 TzLIeaCpEFKE for ; Fri, 3 Aug 2012 08:42:18 -0700 (PDT) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id F1A3221F8D3C for ; Fri, 3 Aug 2012 08:42:17 -0700 (PDT) Received: by clone.registro.br (Postfix, from userid 1000) id 5342BE04AD; Fri, 3 Aug 2012 12:42:17 -0300 (BRT) Date: Fri, 3 Aug 2012 12:42:17 -0300 From: Frederico A C Neves To: "dnsext@ietf.org" Message-ID: <20120803154217.GF73181@registro.br> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dnsext] draft-damick-dns-associated-names-record.txt-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: Fri, 03 Aug 2012 15:42:18 -0000 Dear Colleagues, Based on author's request, after initial ML comments, and for the record We'll not start an rrtype evaluation process. This request is rejected. Regards, Frederico Neves On Wed, Aug 01, 2012 at 10:05:46AM -0400, Damick, Jeffrey wrote: > > A. Submission Date: 8/1/2012 > > B. Submission Type: > [X] New RRTYPE > [ ] Modification to existing RRTYPE > > C. Contact Information for submitter (will be publicly posted): > Name: Jeffrey Damick > Email Address: jeffrey.damick@neustar.biz > International telephone number: 001-571-434-5324 > Other contact handles: > > D. Motivation for the new RRTYPE application. > > The goal of this new record type is to provide a mechanism for operators to create a list of associated domain names for a particular QTYPE and service name. This will allow client applications to be crafted to handle these lists based on the needs of their particular service. Please see attached draft for more details. > > E. Description of the proposed RR type. > > See attached draft. > > > F. What existing RRTYPE or RRTYPEs come closest to filling that need > and why are they unsatisfactory? > > None that I am aware. > > G. What mnemonic is requested for the new RRTYPE (optional)? > Note: this can be left blank and the mnemonic decided after the > template is accepted. > > AN > > H. Does the requested RRTYPE make use of any existing IANA registry > or require the creation of a new IANA sub-registry in DNS > Parameters? If so, please indicate which registry is to be used > or created. If a new sub-registry is needed, specify the > allocation policy for it and its initial contents. Also include > what the modification procedures will be. > > It utilizes the "Service Name and Transport Protocol Port Number Registry" for the service name in the record body. > > I. Does the proposal require/expect any changes in DNS > servers/resolvers that prevent the new type from being processed > as an unknown RRTYPE (see [RFC3597])? > > No > > J. Comments: > Draft attached. From internet-drafts@ietf.org Fri Aug 3 12:20:27 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 900D011E80D5; Fri, 3 Aug 2012 12:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 ffl2AtHfndHh; Fri, 3 Aug 2012 12:20:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFD211E80A3; Fri, 3 Aug 2012 12:20:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120803192026.17366.96899.idtracker@ietfa.amsl.com> Date: Fri, 03 Aug 2012 12:20:26 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-registry-update-04.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, 03 Aug 2012 19:20:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Upd= ates Author(s) : Scott Rose Filename : draft-ietf-dnsext-dnssec-registry-update-04.txt Pages : 6 Date : 2012-08-03 Abstract: The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. The algorithms specified for use with DNSSEC are reflected in an IANA maintained registry. This document presents a set of changes for some entries of the registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-registry-update-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-registry-update= -04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From scottr.nist@gmail.com Fri Aug 3 12:22:32 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 638E721F8D27 for ; Fri, 3 Aug 2012 12:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4vl4vG6gXlvy for ; Fri, 3 Aug 2012 12:22:31 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id C0A4621F8CCD for ; Fri, 3 Aug 2012 12:22:30 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Aug 2012 15:21:58 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Fri, 3 Aug 2012 15:21:02 -0400 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q73JM6je009952; Fri, 3 Aug 2012 15:22:06 -0400 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_47B6F7D6-597A-42A7-AA59-E61C79A28FBF" From: Scott Rose In-Reply-To: <20120803192027.17366.57431.idtracker@ietfa.amsl.com> Date: Fri, 3 Aug 2012 15:22:06 -0400 Message-ID: References: <20120803192027.17366.57431.idtracker@ietfa.amsl.com> To: X-Mailer: Apple Mail (2.1278) Cc: dnsext chair , Ralph Droms Subject: Re: [dnsext] New Version Notification - draft-ietf-dnsext-dnssec-registry-update-04.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, 03 Aug 2012 19:22:32 -0000 --Apple-Mail=_47B6F7D6-597A-42A7-AA59-E61C79A28FBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" The -04 draft was submitted to address the comments from the IESG = review. One spelling error and changing the References to Informative. Scott On Aug 3, 2012, at 3:20 PM, internet-drafts@ietf.org wrote: >=20 > A new version (-04) has been submitted for = draft-ietf-dnsext-dnssec-registry-update: > = http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-registry-upda= te-04.txt >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > = https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-update/= >=20 > Diff from previous version: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-registry-updat= e-04 >=20 > IETF Secretariat. >=20 =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 Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =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 --Apple-Mail=_47B6F7D6-597A-42A7-AA59-E61C79A28FBF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" The = -04 draft was submitted to address the comments from the IESG review. =  One spelling error and changing the References to = Informative.

Scott

On Aug 3, = 2012, at 3:20 PM, internet-drafts@ietf.org = wrote:


A new version (-04) has been submitted for = draft-ietf-dnsext-dnssec-registry-update:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-d= nssec-registry-update-04.txt


The IETF datatracker page = for this Internet-Draft = is:
https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-= update/

Diff from previous = version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-re= gistry-update-04

IETF = Secretariat.


scott.rose@nist.gov
+1 = 301-975-8439
Google Voice: +1 = 571-249-3671
http://www.dnsops.gov/
=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

= --Apple-Mail=_47B6F7D6-597A-42A7-AA59-E61C79A28FBF-- From mstjohns@comcast.net Sat Aug 4 21:20:01 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 CB90221F8821 for ; Sat, 4 Aug 2012 21:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.436 X-Spam-Level: X-Spam-Status: No, score=-100.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.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 PybKd0tsDcmZ for ; Sat, 4 Aug 2012 21:20:01 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id F3BBD21F881A for ; Sat, 4 Aug 2012 21:20:00 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta01.westchester.pa.mail.comcast.net with comcast id isCh1j0020vyq2s51sL3Uw; Sun, 05 Aug 2012 04:20:03 +0000 Received: from Mike-PC3.comcast.net ([68.83.222.237]) by omta05.westchester.pa.mail.comcast.net with comcast id isLB1j00F57vnMg3RsLBye; Sun, 05 Aug 2012 04:20:11 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 05 Aug 2012 00:20:01 -0400 To: dnsext@ietf.org From: Michael StJohns Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_460588053==.ALT" Message-Id: <20120805042000.F3BBD21F881A@ietfa.amsl.com> Subject: [dnsext] Advancement of RFC 5011 - Call for comments - END 24 August 2012 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, 05 Aug 2012 04:20:02 -0000 --=====================_460588053==.ALT Content-Type: text/plain; charset="us-ascii" During IETF week I had discussions with the chairs, area director and various other IESG members on the possibility of advancing RFC5011 to Standard under the new rules described in RFC6410. My intent is to do this as administrative advancement without the issuance of a new RFC. The conditions for advancement (and my comments on those requirements) are: >(1) There are at least two independent interoperating implementations > with widespread deployment and successful operational experience. RFC5011 is specified as the root key rollover protocol. Other zones appear have adopted this as their mechanism for updating their trust anchors. RFC5011 is a hybrid of operational practices (by the zone owner to signal key changes) and implementations (by the zone owner to sign new keys and revocations, and by the client to automatically update the trust store). There appear to be more than two implementations on the client side. There appears to be sufficient support in zone signing tools for the REVOKE bit. I have anecdotal evidence (and would appreciate more) that successful operational key rollovers have been made with this protocol. > (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. > (3) There are no unused features in the specification that greatly > increase implementation complexity. None identified. > (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 IPR claims are non-specific and do not appear to have affected the implementation of the protocol. What I want to do is open up a three week period to solicit comments on 5011, implementation experience and operational experience. For 5011, I'm looking only for substantive comments on the Normative sections of the document - sections 2-5. Section 9 does contain down-refs to the DNSSEC extensions, but the IESG members I've talked to don't appear to consider them blocking. Comments are open until 24 August. With luck I'll be able to ask the area director to start the IETF last call at that point. Thanks - Mike --=====================_460588053==.ALT Content-Type: text/html; charset="us-ascii" During IETF week I had discussions with the chairs, area director and various other IESG members on the possibility of advancing RFC5011 to Standard under the new rules described in RFC6410.   My intent is to do this as administrative advancement without the issuance of a new RFC.

The conditions for advancement  (and my comments on those requirements) are:


(1) There are at least two
independent interoperating implementations
       with widespread deployment and
successful operational experience.

RFC5011 is specified as the root key rollover protocol.  Other zones appear have adopted this as their mechanism for updating their trust anchors.

RFC5011 is a hybrid of operational practices  (by the zone owner to signal key changes) and implementations (by the zone owner to sign new keys and revocations, and by the client to automatically update the trust store). 

There appear to be more than two implementations on the client side.  There appears to be sufficient support in zone signing tools for the REVOKE bit.

I have anecdotal evidence (and would appreciate more) that successful operational key rollovers have been made with this protocol.




   (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.


   (3) There are
no unused features in the specification that greatly
       increase implementation complexity.

None identified.



   (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 IPR claims are non-specific and do not appear to have affected the implementation of the protocol.


What I want to do is open up a three week period to solicit comments on 5011, implementation experience and operational experience.

For 5011, I'm looking only for substantive comments on the Normative sections of the document - sections 2-5. 

Section 9 does contain down-refs to the DNSSEC extensions, but the IESG members I've talked to don't appear to consider them blocking.


Comments are open until 24 August.  With luck I'll be able to ask the area director to start the IETF last call at that point.

Thanks - Mike


--=====================_460588053==.ALT-- From cet1@hermes.cam.ac.uk Sun Aug 5 09:50:46 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 6023C21F84F8 for ; Sun, 5 Aug 2012 09:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 oBGdUAliaREU for ; Sun, 5 Aug 2012 09:50:45 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 5598C21F848B for ; Sun, 5 Aug 2012 09:50:45 -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]:54792) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:cet1) id 1Sy42N-000493-qE (Exim 4.72) (return-path ); Sun, 05 Aug 2012 17:50:43 +0100 Received: from prayer by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:cet1) id 1Sy42N-0000cf-4p (Exim 4.67) (return-path ); Sun, 05 Aug 2012 17:50:43 +0100 Received: from [131.111.11.47] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.5); 05 Aug 2012 17:50:43 +0100 Date: 05 Aug 2012 17:50:43 +0100 From: Chris Thompson To: Michael StJohns Message-ID: In-Reply-To: <20120805042000.F3BBD21F881A@ietfa.amsl.com> References: <20120805042000.F3BBD21F881A@ietfa.amsl.com> X-Mailer: Prayer v1.3.5 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: Chris Thompson Cc: dnsext@ietf.org Subject: Re: [dnsext] Advancement of RFC 5011 - Call for comments - END 24 August 2012 X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cet1@cam.ac.uk List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 16:50:46 -0000 On Aug 5 2012, Michael StJohns wrote: >During IETF week I had discussions with the chairs, area director >and various other IESG members on the possibility of advancing RFC5011 >to Standard under the new rules described in RFC6410. My intent is to >do this as administrative advancement without the issuance of a new RFC. > >The conditions for advancement (and my comments on those requirements) are: > > >>(1) There are at least two independent interoperating implementations >> with widespread deployment and successful operational experience. > >RFC5011 is specified as the root key rollover protocol. I think that is very considerable stretch. I know of no official description of putative KSK rollovers for the root zone other than https://www.iana.org/dnssec/icann-dps.txt section 6.6 and that does not conform to RFC5011. Specifically, the revoked KSK is never self-signed, so that (correct) RFC5011 client implementations will never invalidate it as a trust anchor (although they may for example warn about its strange absence from the DNSKEY RRset at the end of the sequence). > Other zones appear have adopted this as their mechanism for >updating their trust anchors. I know of various zones implementing RFC 5011 rollovers in order to test RFC 5011 client software, but are there really any that are using it in the expectation that the world in general will have a trust anchor for them managed this way? dlv.isc.org might be one such, as ISC have said that they would follow RFC5011 if they ever rolled its KSK. But as for the root zone, this remains a matter of (a different sort of) trust, as there have not so far been any such rollovers. >RFC5011 is a hybrid of operational practices (by the zone owner >to signal key changes) and implementations (by the zone owner to >sign new keys and revocations, and by the client to automatically >update the trust store). > >There appear to be more than two implementations on the client side. >There appears to be sufficient support in zone signing tools for the >REVOKE bit. > >I have anecdotal evidence (and would appreciate more) that successful >operational key rollovers have been made with this protocol. I have done a number of tests of BIND's client RFC5011 implementation ("managed-keys") presented with correctly implemented rollovers and with ones mangled in various ways. I know of only one (slightly subtle) outstanding bug but a number of infelicities in its ability to let the operator manage the trust anchor state left after a rollover that fails in various ways. Still, this is probably not the place to discuss that. -- 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 mstjohns@comcast.net Sun Aug 5 18:01:48 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 62D4621F85A3 for ; Sun, 5 Aug 2012 18:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.517 X-Spam-Level: X-Spam-Status: No, score=-101.517 tagged_above=-999 required=5 tests=[AWL=1.081, BAYES_00=-2.599, HTML_MESSAGE=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 QycVrREIwz4H for ; Sun, 5 Aug 2012 18:01:47 -0700 (PDT) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by ietfa.amsl.com (Postfix) with ESMTP id 4F44421F859A for ; Sun, 5 Aug 2012 18:01:46 -0700 (PDT) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta12.emeryville.ca.mail.comcast.net with comcast id j76r1j00116AWCUACD1mkn; Mon, 06 Aug 2012 01:01:46 +0000 Received: from Mike-PC3.comcast.net ([68.83.222.237]) by omta06.emeryville.ca.mail.comcast.net with comcast id jD1i1j00S57vnMg8SD1k1P; Mon, 06 Aug 2012 01:01:46 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 05 Aug 2012 21:01:43 -0400 To: cet1@cam.ac.uk From: Michael StJohns In-Reply-To: References: <20120805042000.F3BBD21F881A@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_535089747==.ALT" Message-Id: <20120806010147.4F44421F859A@ietfa.amsl.com> Cc: dnsext@ietf.org Subject: Re: [dnsext] Advancement of RFC 5011 - Call for comments - END 24 August 2012 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, 06 Aug 2012 01:01:48 -0000 --=====================_535089747==.ALT Content-Type: text/plain; charset="us-ascii" At 12:50 PM 8/5/2012, Chris Thompson wrote: >On Aug 5 2012, Michael StJohns wrote: > >> >>>(1) There are at least two independent interoperating implementations >>> with widespread deployment and successful operational experience. >> >>RFC5011 is specified as the root key rollover protocol. > >I think that is very considerable stretch. I know of no official >description of putative KSK rollovers for the root zone other >than https://www.iana.org/dnssec/icann-dps.txt section 6.6 and >that does not conform to RFC5011. I think you're ignoring the other sections where 5011 is mentioned. 6.5 in particular says " RZ KSK roll-over is scheduled to facilitate automatic updates of resolvers' Trust Anchors as described in RFC 5011 [RFC5011]." I'm aware of the issues with the DPS with respect to 5011 and have had a number of discussions both on and off list to fix the "reality" of how the root zone is signed to bring it into line with 5011 recommendations. However, there is nothing preventing the root zone from moving to compliance with 5011 recommendations without adversely affecting client views of the root zone trust anchor set in a manner preventing 5011 rollovers. I stand by my statement - the DPS cites 5011 as the mechanism for automated rollover. > Specifically, the revoked >KSK is never self-signed, so that (correct) RFC5011 client >implementations will never invalidate it as a trust anchor >(although they may for example warn about its strange absence >from the DNSKEY RRset at the end of the sequence). The revoke bit only has function if the RRSet is signed by the key with the revoke bit - that's by design. In the case you describe, the key isn't actually revoked - it's just no longer present in the RRSet, but unless manually removed by a 5011 resolver human owner it will remain in the trust anchor set for the node for that resolver. As I said, several issues with the DPS have been identified. >>I have anecdotal evidence (and would appreciate more) that successful >>operational key rollovers have been made with this protocol. > >I have done a number of tests of BIND's client RFC5011 implementation >("managed-keys") presented with correctly implemented rollovers and >with ones mangled in various ways. I know of only one (slightly subtle) >outstanding bug but a number of infelicities in its ability to let >the operator manage the trust anchor state left after a rollover >that fails in various ways. Still, this is probably not the place >to discuss that. Why wouldn't this be the place. Is there a change needed to 5011? Or is this just a mal-implementation on the client side? Or something in between. >-- >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. --=====================_535089747==.ALT Content-Type: text/html; charset="us-ascii" At 12:50 PM 8/5/2012, Chris Thompson wrote:
On Aug 5 2012, Michael StJohns wrote:


(1) There are at least two independent interoperating implementations
      with widespread deployment and successful operational experience.

RFC5011 is specified as the root key rollover protocol.

I think that is very considerable stretch. I know of no official
description of putative KSK rollovers for the root zone other
than https://www.iana.org/dnssec/icann-dps.txt section 6.6 and
that does not conform to RFC5011.

I think you're ignoring the other sections where 5011 is mentioned.  6.5 in particular says "
RZ KSK roll-over is scheduled to facilitate automatic updates of
   resolvers' Trust Anchors as described in RFC 5011
[RFC5011]."
I'm aware of the issues with the DPS with respect to 5011 and have had a number of discussions both on and off list to fix the "reality" of how the root zone is signed to bring it into line with 5011 recommendations.  However, there is nothing preventing the root zone from moving to compliance with 5011 recommendations without adversely affecting client views of the root zone trust anchor set in a manner preventing 5011 rollovers.

I stand by my statement - the DPS cites 5011 as the mechanism for automated rollover.



 Specifically, the revoked
KSK is never self-signed, so that (correct) RFC5011 client
implementations will never invalidate it as a trust anchor
(although they may for example warn about its strange absence
from the DNSKEY RRset at the end of the sequence).

The revoke bit only has function if the RRSet is signed by the key with the revoke bit - that's by design.  In the case you describe, the key isn't actually revoked - it's just no longer present in the RRSet, but unless manually removed by a 5011 resolver human owner it will remain in the trust anchor set for the node for that resolver.  As I said, several issues with the DPS have been identified.



I have anecdotal evidence (and would appreciate more) that successful
operational key rollovers have been made with this protocol.

I have done a number of tests of BIND's client RFC5011 implementation
("managed-keys") presented with correctly implemented rollovers and
with ones mangled in various ways. I know of only one (slightly subtle)
outstanding bug but a number of infelicities in its ability to let
the operator manage the trust anchor state left after a rollover
that fails in various ways. Still, this is probably not the place
to discuss that.

Why wouldn't this be the place.  Is there a change needed to 5011?  Or is this just a mal-implementation on the client side?  Or something in between.


--
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.

--=====================_535089747==.ALT-- From ajs@anvilwalrusden.com Fri Aug 10 08:16:25 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 2288721F8652 for ; Fri, 10 Aug 2012 08:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=-1.068, BAYES_05=-1.11, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 6NY+lEIwMsKX for ; Fri, 10 Aug 2012 08:16:24 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id AE5DF21F8627 for ; Fri, 10 Aug 2012 08:16:24 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C5D638A031 for ; Fri, 10 Aug 2012 15:16:23 +0000 (UTC) Date: Fri, 10 Aug 2012 11:16:22 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20120810151622.GE87645@crankycanuck.ca> References: <20120718180601.GP340@crankycanuck.ca> <408A5182-25C0-42CB-A237-F56C5F078FDC@gmail.com> <20120810044844.GA5340@vacation.karoshi.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120810044844.GA5340@vacation.karoshi.com.> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Possible changes to draft-ietf-dnsext-dnssec-algo-imp-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: Fri, 10 Aug 2012 15:16:25 -0000 On Fri, Aug 10, 2012 at 04:48:44AM +0000, bmanning@vacation.karoshi.com wrote: > Has anyone asked Pete about his position? Yes. I got sick after Vancouver or we'd already have seen movement here. As things stand, won't get to it this week. -- Andrew Sullivan ajs@anvilwalrusden.com From internet-drafts@ietf.org Mon Aug 13 01:36:42 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 4A53C21F869E; Mon, 13 Aug 2012 01:36:42 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2ewEdpmXWN9; Mon, 13 Aug 2012 01:36:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA29421F86B3; Mon, 13 Aug 2012 01:36:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120813083641.11596.39065.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2012 01:36:41 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-rfc2671bis-edns0-09.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: Mon, 13 Aug 2012 08:36:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Extension Mechanisms for DNS (EDNS(0)) Author(s) : Joao Damas Michael Graff Paul Vixie Filename : draft-ietf-dnsext-rfc2671bis-edns0-09.txt Pages : 16 Date : 2012-08-13 Abstract: 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 EDNS(0) specification (and obsoletes 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-rfc2671bis-edns0 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-rfc2671bis-edns0-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Aug 14 10:22:16 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 4386A21F8773; Tue, 14 Aug 2012 10:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 xvdYIqaFUy4J; Tue, 14 Aug 2012 10:22:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B025321F8758; Tue, 14 Aug 2012 10:22:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120814172215.1223.51485.idtracker@ietfa.amsl.com> Date: Tue, 14 Aug 2012 10:22:15 -0700 Cc: dnsext@ietf.org Subject: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-08.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: Tue, 14 Aug 2012 17:22:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Signaling Cryptographic Algorithm Understanding in DNSSEC Author(s) : Steve Crocker Scott Rose Filename : draft-ietf-dnsext-dnssec-algo-signal-08.txt Pages : 8 Date : 2012-08-14 Abstract: The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-signal-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-algo-signal-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From scottr.nist@gmail.com Tue Aug 14 10:29:31 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 DA5CD21F8793 for ; Tue, 14 Aug 2012 10:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6SMQpFp5CODI for ; Tue, 14 Aug 2012 10:29:30 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1A98521F8792 for ; Tue, 14 Aug 2012 10:29:30 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 14 Aug 2012 13:29:13 -0400 Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.355.2; Tue, 14 Aug 2012 13:27:44 -0400 Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q7EHTQRP030172 for ; Tue, 14 Aug 2012 13:29:27 -0400 From: Scott Rose MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_D1C99A8F-596A-4199-91CC-A593BD712A93" Date: Tue, 14 Aug 2012 13:29:26 -0400 In-Reply-To: <20120814172215.1223.51485.idtracker@ietfa.amsl.com> To: References: <20120814172215.1223.51485.idtracker@ietfa.amsl.com> Message-ID: <2F1ECDC6-1B83-48B1-97A1-94D4861C64B6@gmail.com> X-Mailer: Apple Mail (2.1278) Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-08.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: Tue, 14 Aug 2012 17:29:32 -0000 --Apple-Mail=_D1C99A8F-596A-4199-91CC-A593BD712A93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" New version that addresses the comments received from the -07 version. Significant changes: 1. Ordering of algorithm codes: changed text to stress that the order = can be arbitrary and servers should not infer preference, only that the = client signals understanding. 2. Recursive Resolver setting option: Draft now says that recursive = resolvers should set the list to be the union of their list and the list = of the stub, if present. If no list is present, recursive resolvers = free to put their own list in full. 3. Text added to stress that the EDNS options are all OPTIONAL, do not = have to all appear together, but each option can only appear once. 4. Text added to Security Considerations that the options may give an = attacker clues to the client version based on the option and lists. =20 Comments/questions welcome Scott & Steve On Aug 14, 2012, at 1:22 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the DNS Extensions Working Group of the = IETF. >=20 > Title : Signaling Cryptographic Algorithm = Understanding in DNSSEC > Author(s) : Steve Crocker > Scott Rose > Filename : draft-ietf-dnsext-dnssec-algo-signal-08.txt > Pages : 8 > Date : 2012-08-14 >=20 > Abstract: > The DNS Security Extensions (DNSSEC) were developed to provide = origin > authentication and integrity protection for DNS data by using = digital > signatures. These digital signatures can be generated using > different algorithms. This draft sets out to specify a way for > validating end-system resolvers to signal to a server which digital > signature and hash algorithms they support. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-signal-08 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-algo-signal-08= >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 Scott Rose NIST scott.rose@nist.gov +1 301-975-8439 Google Voice: +1 571-249-3671 http://www.dnsops.gov/ =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 --Apple-Mail=_D1C99A8F-596A-4199-91CC-A593BD712A93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" New = version that addresses the comments received from the -07 = version.

Significant = changes:

1. Ordering of algorithm codes: =  changed text to stress that the order can be arbitrary and servers = should not infer preference, only that the client signals = understanding.

2. Recursive Resolver setting option: =  Draft now says that recursive resolvers should set the list to be = the union of their list and the list of the stub, if present.  If = no list is present, recursive resolvers free to put their own list in = full.

3. Text added to stress that the EDNS = options are all OPTIONAL, do not have to all appear together, but each = option can only appear once.

4. Text added to Security Considerations = that the options may give an attacker clues to the client version based = on the option and lists.  

Comments/questions = welcome

Scott & = Steve

On Aug 14, 2012, at 1:22 PM, internet-drafts@ietf.org = wrote:


A New Internet-Draft is available from the = on-line Internet-Drafts directories.
This draft is a work item of = the DNS Extensions Working Group of the IETF.

Title =           : Signaling = Cryptographic Algorithm Understanding in DNSSEC
Author(s) =       : Steve Crocker
=             &n= bsp;           &nbs= p;Scott Rose
= Filename        : = draft-ietf-dnsext-dnssec-algo-signal-08.txt
Pages =           : 8
Date =            : = 2012-08-14

Abstract:
  The DNS Security Extensions = (DNSSEC) were developed to provide origin
  authentication = and integrity protection for DNS data by using digital
=   signatures.  These digital signatures can be generated = using
  different algorithms.  This draft sets out to = specify a way for
  validating end-system resolvers to = signal to a server which digital
  signature and hash = algorithms they support.



The IETF datatracker status page = for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-signal=

There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-algo-signal-08<= br>
A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnsext-dnssec-algo-si= gnal-08


Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
dnsext mailing = list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

scott.rose@nist.gov
+1 = 301-975-8439
Google Voice: +1 = 571-249-3671
http://www.dnsops.gov/
=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

= --Apple-Mail=_D1C99A8F-596A-4199-91CC-A593BD712A93-- From rwfranks@gmail.com Wed Aug 22 12:03:14 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 5B73921F867A for ; Wed, 22 Aug 2012 12:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.927 X-Spam-Level: X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi4t-4-QNBba for ; Wed, 22 Aug 2012 12:03:12 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C73521F84C5 for ; Wed, 22 Aug 2012 12:03:12 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1532502vbb.31 for ; Wed, 22 Aug 2012 12:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=m2EVuKQGatImwojIcbwWzPHb5ED95MusBP/1kcQHNnU=; b=engd4mh+IOpdgndkyAw8cA9XqlZhueK2/qW/YNvaBxxilz0O+F4oxkgCUn1R1lFbcR 4MM6Yz2F5ESeEF8Qmj7COUdNfzb2JcO88vq9kBiVBB4PY/aQDpG/eHn63j1jyMVb48Ok hQZsH21fhbyhLmIv78/7gP00a/v0RqH+WUtp3ggFLyLQylkaVB7irKmM+n43itkMX8iD oE4JnMrK3VOnX9FwBU7UBJbMAcniyRgp11EjNejbrCo5SNkCzaFUY6oiTKArkR7sV4hd Q2/tDj4ph/3L+p9wPxoLAW5wOfKpB0e53CzH+i/MJbLPqdxrPoczFEPq8UCY0DTskNjS erbg== Received: by 10.52.20.138 with SMTP id n10mr14908250vde.129.1345662191712; Wed, 22 Aug 2012 12:03:11 -0700 (PDT) MIME-Version: 1.0 Sender: rwfranks@gmail.com Received: by 10.58.237.40 with HTTP; Wed, 22 Aug 2012 12:02:51 -0700 (PDT) In-Reply-To: <2F1ECDC6-1B83-48B1-97A1-94D4861C64B6@gmail.com> References: <20120814172215.1223.51485.idtracker@ietfa.amsl.com> <2F1ECDC6-1B83-48B1-97A1-94D4861C64B6@gmail.com> From: Dick Franks Date: Wed, 22 Aug 2012 20:02:51 +0100 X-Google-Sender-Auth: zenvYUN2o1Vrk_l7oDq7RUgiVjo Message-ID: To: Scott Rose Content-Type: text/plain; charset=UTF-8 Cc: dnsext@ietf.org Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-signal-08.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: Wed, 22 Aug 2012 19:03:14 -0000 Scott & Steve, [2, para 4] ALG-CODE is the list of assigned values of DNSSEC zone signing algorithms, DS hash algorithms, or NSEC3 hash algorithms (depending on the OPTION-CODE in use) that the client declares to be supported. The order of the code values can be arbitrary and SHOULD NOT be used to infer preference. WG seems to agree that there is no information to be gleaned from the order in which codes appear in the list. The requirement can therefore be strengthened from SHOULD to MUST. The present wording implies that the order will remain the same from one occasion to another, i.e. sorted using some (arbitrary) ordering relation. There is no requirement that it should. Suggest: ... The list of algorithm codes is unordered and MUST NOT be used to infer preference. [3, para 1] A validating end-system resolver sets the DAU, DHU and/or N3U option, or combination thereof in the OPT meta-RR when sending a query. The validating end-system resolver sets the value(s) in any arbitrary order. The validating end-system resolver MUST also set the DNSSEC-OK bit [RFC4035] to indicate that it wishes to receive DNSSEC RRs in the response. Second sentence is redundant, covered by section 2. [3.1.2] The DAU, DHU and N3U EDNS options are NOT RECOMMENDED for non- validating stub resolvers. As non-validating stub implements no algorithms at all, why does this say "are NOT RECOMMENDED" instead of "MUST NOT be used"? Dick On 14 August 2012 18:29, Scott Rose wrote: > New version that addresses the comments received from the -07 version. > From mstjohns@comcast.net Wed Aug 29 13:51:12 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 7026721F8569 for ; Wed, 29 Aug 2012 13:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.436 X-Spam-Level: X-Spam-Status: No, score=-100.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZJ+G3bj7svF for ; Wed, 29 Aug 2012 13:51:11 -0700 (PDT) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id D307221F8567 for ; Wed, 29 Aug 2012 13:51:11 -0700 (PDT) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by qmta02.emeryville.ca.mail.comcast.net with comcast id shdP1j00F0x6nqcA2krBBc; Wed, 29 Aug 2012 20:51:11 +0000 Received: from Mike-PC3.comcast.net ([76.235.121.110]) by omta12.emeryville.ca.mail.comcast.net with comcast id skr21j00X2P0wdY8Ykr40w; Wed, 29 Aug 2012 20:51:09 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 29 Aug 2012 16:50:59 -0400 To: dnsext@ietf.org From: Michael StJohns In-Reply-To: <7.1.0.9.2.20120804234517.085e05f8@comcast.net> References: <7.1.0.9.2.20120804234517.085e05f8@comcast.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1104120304==.ALT" Message-Id: <20120829205111.D307221F8567@ietfa.amsl.com> Subject: Re: [dnsext] Advancement of RFC 5011 - Call for comments - END 24 August 2012 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, 29 Aug 2012 20:51:12 -0000 --=====================_1104120304==.ALT Content-Type: text/plain; charset="us-ascii" The 24th of August having passed with no actionable comments I will ask the AD to propose RFC5011 for advancement. Mike At 12:20 AM 8/5/2012, Michael StJohns wrote: >During IETF week I had discussions with the chairs, area director and various other IESG members on the possibility of advancing RFC5011 to Standard under the new rules described in RFC6410. My intent is to do this as administrative advancement without the issuance of a new RFC. > >The conditions for advancement (and my comments on those requirements) are: > > >> >>(1) There are at least two independent interoperating implementations >> with widespread deployment and successful operational experience. > >RFC5011 is specified as the root key rollover protocol. Other zones appear have adopted this as their mechanism for updating their trust anchors. > >RFC5011 is a hybrid of operational practices (by the zone owner to signal key changes) and implementations (by the zone owner to sign new keys and revocations, and by the client to automatically update the trust store). > >There appear to be more than two implementations on the client side. There appears to be sufficient support in zone signing tools for the REVOKE bit. > >I have anecdotal evidence (and would appreciate more) that successful operational key rollovers have been made with this protocol. > > > > >> >> (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. > > >> >> (3) There are no unused features in the specification that greatly >> increase implementation complexity. > >None identified. > > > >> >> (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 IPR claims are non-specific and do not appear to have affected the implementation of the protocol. > > >What I want to do is open up a three week period to solicit comments on 5011, implementation experience and operational experience. > >For 5011, I'm looking only for substantive comments on the Normative sections of the document - sections 2-5. > >Section 9 does contain down-refs to the DNSSEC extensions, but the IESG members I've talked to don't appear to consider them blocking. > > >Comments are open until 24 August. With luck I'll be able to ask the area director to start the IETF last call at that point. > >Thanks - Mike --=====================_1104120304==.ALT Content-Type: text/html; charset="us-ascii" The 24th of August having passed with no actionable comments I will ask the AD to propose RFC5011 for advancement.

Mike



At 12:20 AM 8/5/2012, Michael StJohns wrote:
During IETF week I had discussions with the chairs, area director and various other IESG members on the possibility of advancing RFC5011 to Standard under the new rules described in RFC6410.   My intent is to do this as administrative advancement without the issuance of a new RFC.

The conditions for advancement  (and my comments on those requirements) are:



(1) There are at least two independent interoperating
implementations
       with widespread deployment and
successful operational experience.

RFC5011 is specified as the root key rollover protocol.  Other zones appear have adopted this as their mechanism for updating their trust anchors.

RFC5011 is a hybrid of operational practices  (by the zone owner to signal key changes) and implementations (by the zone owner to sign new keys and revocations, and by the client to automatically update the trust store). 

There appear to be more than two implementations on the client side.  There appears to be sufficient support in zone signing tools for the REVOKE bit.

I have anecdotal evidence (and would appreciate more) that successful operational key rollovers have been made with this protocol.





   (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.



   (3) There are no unused features in the specification
that greatly
       increase implementation complexity.

None identified.




   (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 IPR claims are non-specific and do not appear to have affected the implementation of the protocol.


What I want to do is open up a three week period to solicit comments on 5011, implementation experience and operational experience.

For 5011, I'm looking only for substantive comments on the Normative sections of the document - sections 2-5. 

Section 9 does contain down-refs to the DNSSEC extensions, but the IESG members I've talked to don't appear to consider them blocking.


Comments are open until 24 August.  With luck I'll be able to ask the area director to start the IETF last call at that point.

Thanks - Mike

--=====================_1104120304==.ALT-- From wwwrun@rfc-editor.org Wed Aug 29 17:54:14 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 2E21F21E808A; Wed, 29 Aug 2012 17:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.997 X-Spam-Level: X-Spam-Status: No, score=-101.997 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, 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 TCAGzBOGappZ; Wed, 29 Aug 2012 17:54:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 133CA21E8088; Wed, 29 Aug 2012 17:54:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 82DABB1E00E; Wed, 29 Aug 2012 17:51:52 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120830005152.82DABB1E00E@rfc-editor.org> Date: Wed, 29 Aug 2012 17:51:52 -0700 (PDT) Cc: dnsext@ietf.org, rfc-editor@rfc-editor.org Subject: [dnsext] RFC 6725 on DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates 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, 30 Aug 2012 00:54:14 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6725 Title: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates Author: S. Rose Status: Standards Track Stream: IETF Date: August 2012 Mailbox: scottr.nist@gmail.com Pages: 5 Characters: 9236 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsext-dnssec-registry-update-04.txt URL: http://www.rfc-editor.org/rfc/rfc6725.txt The DNS Security Extensions (DNSSEC) require the use of cryptographic algorithm suites for generating digital signatures over DNS data. The algorithms specified for use with DNSSEC are reflected in an IANA-maintained registry. This document presents a set of changes for some entries of the registry. [STANDARDS-TRACK] This document is a product of the DNS Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. 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