From Gaitonde.Vithalprasad@microsoft.com Mon Sep 2 11:14:36 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E17921E808C for ; Mon, 2 Sep 2013 11:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 i37C9NCr-kGY for ; Mon, 2 Sep 2013 11:14:31 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) by ietfa.amsl.com (Postfix) with ESMTP id A1D6C21E8085 for ; Mon, 2 Sep 2013 11:14:31 -0700 (PDT) Received: from BL2PR03CA013.namprd03.prod.outlook.com (10.141.66.21) by BL2PR03MB161.namprd03.prod.outlook.com (10.255.230.139) with Microsoft SMTP Server (TLS) id 15.0.745.25; Mon, 2 Sep 2013 18:14:29 +0000 Received: from BY2FFO11FD010.protection.gbl (2a01:111:f400:7c0c::23) by BL2PR03CA013.outlook.office365.com (2a01:111:e400:c1b::21) with Microsoft SMTP Server (TLS) id 15.0.745.25 via Frontend Transport; Mon, 2 Sep 2013 18:14:28 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD010.mail.protection.outlook.com (10.1.14.74) with Microsoft SMTP Server (TLS) id 15.0.755.13 via Frontend Transport; Mon, 2 Sep 2013 18:14:28 +0000 Received: from SINEX14HUBC502.southpacific.corp.microsoft.com (157.60.220.61) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.3.136.1; Mon, 2 Sep 2013 18:13:46 +0000 Received: from SINEX14MBXC416.southpacific.corp.microsoft.com ([169.254.16.147]) by SINEX14HUBC502.southpacific.corp.microsoft.com ([fe80::df3:7769:8d99:21e5%13]) with mapi id 14.03.0146.002; Mon, 2 Sep 2013 18:13:43 +0000 From: Vithalprasad Gaitonde To: "dnsext@ietf.org" Thread-Topic: Case sensitivity of RDATA in PTR records Thread-Index: Ac6oCCX2sU9doC0NRCyj8JMZF2A7Kg== Date: Mon, 2 Sep 2013 18:13:43 +0000 Message-ID: <8989710DADDCF44180C6C9FEA3F67C4E4297F7ED@SINEX14MBXC416.southpacific.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.3.90] Content-Type: multipart/alternative; boundary="_000_8989710DADDCF44180C6C9FEA3F67C4E4297F7EDSINEX14MBXC416s_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054003)(189002)(199002)(33656001)(44976005)(76176001)(6806004)(83322001)(74662001)(63696002)(74706001)(47446002)(74502001)(20776003)(76796001)(76786001)(19580395003)(46102001)(80976001)(51856001)(74876001)(65816001)(80022001)(69226001)(4396001)(81686001)(81342001)(81816001)(71186001)(81542001)(49866001)(47736001)(47976001)(50986001)(54316002)(19300405004)(56776001)(55846006)(15202345003)(76482001)(59766001)(77982001)(15188155005)(16236675002)(79102001)(31966008)(16796002)(16799955002)(83072001)(77096001)(56816003)(53806001)(74366001)(54356001)(15975445006)(512934002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB161; H:mail.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0957AD37A0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-Mailman-Approved-At: Mon, 02 Sep 2013 15:32:18 -0700 Subject: [dnsext] Case sensitivity of RDATA in PTR records 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, 02 Sep 2013 18:36:22 -0000 --_000_8989710DADDCF44180C6C9FEA3F67C4E4297F7EDSINEX14MBXC416s_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is a DNS server expected to preserve the case of domain names in resource r= ecord data of PTR records. As per RFC 4343 - Domain Name System case insensitivity clarification, section 4 says - While ASCII label comparisons are case insensitive, [STD13] says case MUST be preserved on output and pr= eserved when convenient on input. But RFC RFC2535 - Domain Name System Security Extensions section 8.1 says = - 8.1 Canonical RR Form For purposes of DNS security, the canonical fo= rm for an RR is the wire format of the RR with domain names (1) fully expanded (no name compression via pointers), (2) all domain name letters set to lower case, (3) owner name wild cards in master file form (no substitution made for *), and (4) the original TTL substituted for the current TTL. RFC 3597 mentions DNSSEC Canonical Form and Ordering DNSSEC defines a canonical form and ordering for= RRs [RFC 2535] (section 8.1). In that canonical form, domain names embedded in the RDATA are converted to lower case. Are these standards contradicting vis-=E0-vis case (in)sensitivity of domai= n names. Or is the canonical form definition only for constructing SIG RRs= as mention in RFC 2535 section 8 - "A canonical form and ordering within an RRset is necessary in consistently= constructing and verifying SIG RRs" Thanks, Prasad --_000_8989710DADDCF44180C6C9FEA3F67C4E4297F7EDSINEX14MBXC416s_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Is a DNS server expected to preserve the case of dom= ain names in resource record data of PTR records.

 

As per RFC 4343 –= ; Domain Name System = case insensitivity clarification, section= 4 says –

While ASCII label comparison= s are case insensitive, [= STD13] says case MUST be preserved on output and preserved when convenient on inp= ut.

 

But RFC RFC2535 - Doma= in Name System Security Extensions  section 8.1 says –

8.1 Canonical RR Form

 

   For purposes of DNS security, the canonical form for= an RR is the

   wire format of the RR with domain= names (1) fully expanded (no name

   compression via pointers), (2) al= l domain name letters set to lower

   case, (3) owner name wild cards i= n master file form (no substitution

   made for *), and (4) the original= TTL substituted for the current

   TTL.=

 

RFC 3597 mentions

DNSSEC Canonical Form and Ordering

 

   DNSSEC defines a canonical form and or= dering for RRs [RFC 2535]

   (section 8.1).  In that cano= nical form, domain names embedded in the

   RDATA are converted to lower case= .

 

Are these standards co= ntradicting vis-=E0-vis case (in)sensitivity of domain names. Or is the can= onical form definition only  for constructing SIG RRs as mention in RF= C 2535 section 8 -

“A ca= nonical form and ordering within an RRset is necessary in consistently cons= tructing and verifying SIG RRs”

 

Thanks,

Prasad

 =

--_000_8989710DADDCF44180C6C9FEA3F67C4E4297F7EDSINEX14MBXC416s_-- From marka@isc.org Mon Sep 2 16:26:34 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD8C21F8FDC for ; Mon, 2 Sep 2013 16:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[AWL=0.896, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JZiTC55BF5l for ; Mon, 2 Sep 2013 16:26:30 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 16F9921F8F78 for ; Mon, 2 Sep 2013 16:26:30 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 65E13C9424; Mon, 2 Sep 2013 23:26:12 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1378164386; bh=YJkrhHd+jXsXR5cGTQhXArS6X+Wl49/adqG3RIZ4kYw=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=GjQYxeVBNTyVFhQDZhjm7zNbgg97y8QW7Nez05cjJDlknofveB0ZInSnoEddISYgo DM8Q/sEgDU8uXi24eSMRPClbjIAcqPw7TKxCqL/7rtEGM+sYKYRcNFomjADamSCKDi gqo5CcjoT5KyxKoBv+cmyILty/gVH0FpYFB3nCAc= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 2 Sep 2013 23:26:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E0214160459; Mon, 2 Sep 2013 23:27:16 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id A859E1603E9; Mon, 2 Sep 2013 23:27:16 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 3B86239179AE; Tue, 3 Sep 2013 09:26:08 +1000 (EST) To: Vithalprasad Gaitonde From: Mark Andrews References: <8989710DADDCF44180C6C9FEA3F67C4E4297F7ED@SINEX14MBXC416.southpacific.corp.microsoft.com> In-reply-to: Your message of "Mon, 02 Sep 2013 18:13:43 +0000." <8989710DADDCF44180C6C9FEA3F67C4E4297F7ED@SINEX14MBXC416.southpacific.corp.microsoft.com> Date: Tue, 03 Sep 2013 09:26:08 +1000 Message-Id: <20130902232608.3B86239179AE@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Case sensitivity of RDATA in PTR records 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, 02 Sep 2013 23:26:34 -0000 In message <8989710DADDCF44180C6C9FEA3F67C4E4297F7ED@SINEX14MBXC416.southpacific.corp.microsoft.com>, Vi thalprasad Gaitonde writes: > > Is a DNS server expected to preserve the case of domain names in resource > record data of PTR records. > > As per RFC 4343 - Domain Name System case insensitivity > clarification, section 4 says - > While ASCII label comparisons are case insensitive, > [STD13] says case MUST be > preserved on output and preserved when convenient on input. > > But RFC RFC2535 - Domain Name System Security Extensions section 8.1 > says - > 8.1 Canonical RR Form > > For purposes of DNS security, the canonical > form for an RR is the > wire format of the RR with domain names (1) fully expanded (no name > compression via pointers), (2) all domain name letters set to lower > case, (3) owner name wild cards in master file form (no substitution > made for *), and (4) the original TTL substituted for the current > TTL. > > RFC 3597 mentions > DNSSEC Canonical Form and Ordering > > DNSSEC defines a canonical form and ordering > for RRs [RFC 2535] > (section 8.1). In that canonical form, domain names embedded in the > RDATA are converted to lower case. > > Are these standards contradicting vis-a-vis case (in)sensitivity of > domain names. Or is the canonical form definition only for constructing > SIG RRs as mention in RFC 2535 section 8 - > "A canonical form and ordering within an RRset is necessary in > consistently constructing and verifying SIG RRs" No, they are not contadictory. For the purposes of sorting the for records "B.example", "a.example", "[.example" and "C.example" sort like this for: DNSSEC order: [.example a.example B.example C.example Note case is preserved. For comparison ASCII order: B.example C.example [.example a.example When signing or verifing you treat "B.example" as if it had been entered as "b.example". When transfering a zone. You look for a previous "B.example" (after expanding compression pointers) if you have a record with "B.example" in it when generating the compression pointer. You do NOT look for "b.example". If you can't find "B.example", you add the label "B" then look for "example" not "EXAMPLE" or "ExAmPlE". Mark > Thanks, > Prasad -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Gaitonde.Vithalprasad@microsoft.com Tue Sep 3 09:23:07 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BE811E80FD for ; Tue, 3 Sep 2013 09:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_17=0.6, NORMAL_HTTP_TO_IP=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 d4xmy1kI7hZq for ; Tue, 3 Sep 2013 09:23:03 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE2911E80F3 for ; Tue, 3 Sep 2013 09:22:59 -0700 (PDT) Received: from DM2PR03CA007.namprd03.prod.outlook.com (10.141.52.155) by BN1PR03MB107.namprd03.prod.outlook.com (10.255.201.17) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 16:22:57 +0000 Received: from BY2FFO11FD028.protection.gbl (2a01:111:f400:7c0c::23) by DM2PR03CA007.outlook.office365.com (2a01:111:e400:2414::27) with Microsoft SMTP Server (TLS) id 15.0.745.25 via Frontend Transport; Tue, 3 Sep 2013 16:22:57 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD028.mail.protection.outlook.com (10.1.15.217) with Microsoft SMTP Server (TLS) id 15.0.755.13 via Frontend Transport; Tue, 3 Sep 2013 16:22:50 +0000 Received: from SINEX14HUBC402.southpacific.corp.microsoft.com (157.60.220.216) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 3 Sep 2013 16:14:57 +0000 Received: from SINEX14MBXC416.southpacific.corp.microsoft.com ([169.254.16.147]) by SINEX14HUBC402.southpacific.corp.microsoft.com ([157.60.220.216]) with mapi id 14.03.0146.002; Tue, 3 Sep 2013 16:14:56 +0000 From: Vithalprasad Gaitonde To: Mark Andrews Thread-Topic: [dnsext] Case sensitivity of RDATA in PTR records Thread-Index: Ac6oCCX2sU9doC0NRCyj8JMZF2A7KgAK7ajvAB2nhSA= Date: Tue, 3 Sep 2013 16:14:55 +0000 Message-ID: <8989710DADDCF44180C6C9FEA3F67C4E42981432@SINEX14MBXC416.southpacific.corp.microsoft.com> References: <8989710DADDCF44180C6C9FEA3F67C4E4297F7ED@SINEX14MBXC416.southpacific.corp.microsoft.com> <20130902232608.3B86239179AE@drugs.dv.isc.org> In-Reply-To: <20130902232608.3B86239179AE@drugs.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.3.88] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454003)(164054003)(13464003)(199002)(189002)(51704005)(47976001)(50986001)(47736001)(81342001)(76796001)(81542001)(49866001)(81686001)(74876001)(56816003)(76786001)(33656001)(4396001)(69226001)(46406003)(19580405001)(77096001)(63696002)(47776003)(20776003)(83322001)(51856001)(6806004)(44976005)(19580395003)(46102001)(74366001)(80022001)(65816001)(50466002)(80976001)(74502001)(74662001)(74706001)(47446002)(16796002)(31966008)(53806001)(54356001)(77982001)(23726002)(81816001)(16799955002)(59766001)(55846006)(56776001)(83072001)(15188155005)(54316002)(76482001)(79102001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB107; H:mail.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 09583628E0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Case sensitivity of RDATA in PTR records 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, 03 Sep 2013 16:23:07 -0000 Thanks Mark for the clarification Is DNS server expected to preserve case of the domain name in PTR RDATA. For example - if a PTR record was created as follows - 1.0.0.10.in-addr.arpa IN PTR A.ExAmPlE Is the reverse lookup for 10.0.0.1 expected to return the name with the cas= e preserved (A.ExAmPlE) Prasad -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 Sent: Tuesday, September 3, 2013 4:56 AM To: Vithalprasad Gaitonde Cc: dnsext@ietf.org Subject: Re: [dnsext] Case sensitivity of RDATA in PTR records In message <8989710DADDCF44180C6C9FEA3F67C4E4297F7ED@SINEX14MBXC416.southpa= cific.corp.microsoft.com>, Vi thalprasad Gaitonde writes: > > Is a DNS server expected to preserve the case of domain names in=20 > resource record data of PTR records. > > As per RFC 4343 - Domain Name System case insensitivity=20 > clarification, section 4 says -=20 > While ASCII label comparisons are case insensitive,=20 > [STD13] says case MUST=20 > be preserved on output and preserved when convenient on input. > > But RFC RFC2535 - Domain Name System Security Extensions section 8.1=20 > says - > 8.1 Canonical RR Form > > For purposes of DNS security, the=20 > canonical form for an RR is the > wire format of the RR with domain names (1) fully expanded (no name > compression via pointers), (2) all domain name letters set to lower > case, (3) owner name wild cards in master file form (no substitution > made for *), and (4) the original TTL substituted for the current > TTL. > > RFC 3597 mentions > DNSSEC Canonical Form and Ordering > > DNSSEC defines a canonical form and=20 > ordering for RRs [RFC 2535] > (section 8.1). In that canonical form, domain names embedded in the > RDATA are converted to lower case. > > Are these standards contradicting vis-a-vis case (in)sensitivity of=20 > domain names. Or is the canonical form definition only for=20 > constructing SIG RRs as mention in RFC 2535 section 8 - "A canonical=20 > form and ordering within an RRset is necessary in consistently=20 > constructing and verifying SIG RRs" No, they are not contadictory. For the purposes of sorting the for records= "B.example", "a.example", "[.example" and "C.example" sort like this for: DNSSEC order: [.example a.example B.example C.example Note case is preserved. For comparison=20 ASCII order: B.example C.example [.example a.example When signing or verifing you treat "B.example" as if it had been entered as= "b.example". When transfering a zone. You look for a previous "B.example" (after expandi= ng compression pointers) if you have a record with "B.example" in it when generating the compression pointer. You do NOT look for "b.exam= ple". If you can't find "B.example", you add the label "B" then look for "example" not "EXAMPLE" or "ExAmPlE". Mark > Thanks, > Prasad -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Tue Sep 3 16:34:55 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E6E21E80FC for ; Tue, 3 Sep 2013 16:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, NORMAL_HTTP_TO_IP=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 EVTDbGbVN7+v for ; Tue, 3 Sep 2013 16:34:51 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2E921E80EC for ; Tue, 3 Sep 2013 16:34:47 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B43E9C94B2; Tue, 3 Sep 2013 23:34:34 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1378251287; bh=t5bqlRBR1nlApahwFAXvvC1Gx9Y3+brq556yjbupHxg=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=aYuF+zrCIYvZYN4g2Nit1Eb845xEB9DWHZGzJx5RWxji+gtxrnj2DcVv+2aG1n0Qo iGhAZwmmylSeqpGq0NqROXexqBWLupyrSBLp6EsLDl5PTeba8a+qwqZoUOjzOYMPE2 NYYXGCL6R/ku3aV1mPee7wAa71gy+kFaXqKYf0hc= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Tue, 3 Sep 2013 23:34:34 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A0212160459; Tue, 3 Sep 2013 23:35:43 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 7257016030E; Tue, 3 Sep 2013 23:35:43 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id 3B632392EAE7; Wed, 4 Sep 2013 09:34:28 +1000 (EST) To: Vithalprasad Gaitonde From: Mark Andrews References: <8989710DADDCF44180C6C9FEA3F67C4E4297F7ED@SINEX14MBXC416.southpacific.corp.microsoft.com> <20130902232608.3B86239179AE@drugs.dv.isc.org> <8989710DADDCF44180C6C9FEA3F67C4E42981432@SINEX14MBXC416.southpacific.corp.microsoft.com> In-reply-to: Your message of "Tue, 03 Sep 2013 16:14:55 +0000." <8989710DADDCF44180C6C9FEA3F67C4E42981432@SINEX14MBXC416.southpacific.corp.microsoft.com> Date: Wed, 04 Sep 2013 09:34:28 +1000 Message-Id: <20130903233428.3B632392EAE7@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Case sensitivity of RDATA in PTR records 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, 03 Sep 2013 23:34:55 -0000 In message <8989710DADDCF44180C6C9FEA3F67C4E42981432@SINEX14MBXC416.southpacific.corp.microsoft.com>, Vi thalprasad Gaitonde writes: > Thanks Mark for the clarification > > Is DNS server expected to preserve case of the domain name in PTR RDATA. Yes. > For example - if a PTR record was created as follows - > 1.0.0.10.in-addr.arpa IN PTR A.ExAmPlE > > Is the reverse lookup for 10.0.0.1 expected to return the name with the > case preserved (A.ExAmPlE) Yes. > Prasad -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ietf@rozanak.com Tue Sep 3 16:53:37 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3766221E8055 for ; Tue, 3 Sep 2013 16:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxX7Rl9psiBo for ; Tue, 3 Sep 2013 16:53:31 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 4670821F9E00 for ; Tue, 3 Sep 2013 16:53:31 -0700 (PDT) Received: from kopoli (e179167018.adsl.alicedsl.de [85.179.167.18]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M7GrG-1WAb6E2Jde-00wKoU; Tue, 03 Sep 2013 19:53:25 -0400 From: "Hosnieh Rafiee" To: "'Mark Andrews'" , "'Vithalprasad Gaitonde'" References: <8989710DADDCF44180C6C9FEA3F67C4E4297F7ED@SINEX14MBXC416.southpacific.corp.microsoft.com> <20130902232608.3B86239179AE@drugs.dv.isc.org> <8989710DADDCF44180C6C9FEA3F67C4E42981432@SINEX14MBXC416.southpacific.corp.microsoft.com> <20130903233428.3B632392EAE7@drugs.dv.isc.org> In-Reply-To: <20130903233428.3B632392EAE7@drugs.dv.isc.org> Date: Wed, 4 Sep 2013 01:53:15 +0200 Message-ID: <002501cea900$c6678410$53368c30$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFweoX7r3Zx+BRiF/ap+r6Q+ARPGAJM3wwlArvLsbkCpW4x2ZozmoDQ Content-Language: en-us X-Provags-ID: V02:K0:9Mq5cZgQN2mPJpBrKWirjC2e9TSfzGDGe0J2LRlPAup MA2nIT8UsvKBc/Qh4qmJ38ooU9oEmQPDl3VkNryjNJ9MT93a/L UINXlSmJlg3pL/QBgk/s3jFgt9kNo1sYSIYBiLBygOFmUJBJul eDD59AdacFimpGzgQDNWcEVyV/5d9KQ178r0FSDP2FhtATrN1y SSaMHtuTylksXYBpBFU40FH7JnpDxnrNIzNf3pbu5Eo/gk+Ecw PXkFPgFMl3iOMPJYfbaI2rSm3L9AIj6khIRZ8j1xdPMCnu5T3U xHl5M88Bogu4phZe0J6TgEPuX4603kjikhC3FxzBfJ0J3YGd0P KmcTRCY8UZpGebe+jTVQ= Cc: dnsext@ietf.org Subject: Re: [dnsext] Case sensitivity of RDATA in PTR records 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, 03 Sep 2013 23:53:37 -0000 > > In message > <8989710DADDCF44180C6C9FEA3F67C4E42981432@SINEX14MBXC416.southp > acific.corp.microsoft.com>, Vi thalprasad Gaitonde writes: > > Thanks Mark for the clarification > > > > Is DNS server expected to preserve case of the domain name in PTR RDATA. > > Yes. I guess so if you are talking about the Linux system which is case sensitive. But I don't think this can happen in windows DNS servers. I don't have experience with the latest versions, but in the older versions it wasn't like this. Hosnieh From marka@isc.org Tue Sep 3 17:30:15 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38BFF11E8152 for ; Tue, 3 Sep 2013 17:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 GWwJL8eZWOpK for ; Tue, 3 Sep 2013 17:30:10 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 288D111E8128 for ; Tue, 3 Sep 2013 17:30:10 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 1DBD3C94B3; Wed, 4 Sep 2013 00:29:52 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1378254605; bh=eMSbrys8DtVA+z/AQO0SW1m+vM03fCrDFqBLGWlLw5A=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=R4wYDU05JhZy5Hhib3J0muZmFjdUK+XU5Z0inxjbEzJKxVPLd7ojDCf+IYr0BgdJN eYLXzqGso67EJHnjtLmKn24D2ypmVk7U3RQvAGQGHlrlg7BH5VkIAafsag5UrU4dtw 2NbHTEdFCDbg0+0zMl8snSuMCFx+mjD4h5w2lNXc= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 4 Sep 2013 00:29:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3009E160459; Wed, 4 Sep 2013 00:31:01 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 0127E16030E; Wed, 4 Sep 2013 00:31:01 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id F02D8392F452; Wed, 4 Sep 2013 10:29:47 +1000 (EST) To: "Hosnieh Rafiee" From: Mark Andrews References: <8989710DADDCF44180C6C9FEA3F67C4E4297F7ED@SINEX14MBXC416.southpacific.corp.microsoft.com> <20130902232608.3B86239179AE@drugs.dv.isc.org> <8989710DADDCF44180C6C9FEA3F67C4E42981432@SINEX14MBXC416.southpacific.corp.microsoft.com> <20130903233428.3B632392EAE7@drugs.dv.isc.org> <002501cea900$c6678410$53368c30$@rozanak.com> In-reply-to: Your message of "Wed, 04 Sep 2013 01:53:15 +0200." <002501cea900$c6678410$53368c30$@rozanak.com> Date: Wed, 04 Sep 2013 10:29:47 +1000 Message-Id: <20130904002947.F02D8392F452@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dnsext@ietf.org Subject: Re: [dnsext] Case sensitivity of RDATA in PTR records 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, 04 Sep 2013 00:30:15 -0000 In message <002501cea900$c6678410$53368c30$@rozanak.com>, "Hosnieh Rafiee" writes: > > > > In message > > <8989710DADDCF44180C6C9FEA3F67C4E42981432@SINEX14MBXC416.southp > > acific.corp.microsoft.com>, Vi thalprasad Gaitonde writes: > > > Thanks Mark for the clarification > > > > > > Is DNS server expected to preserve case of the domain name in PTR RDATA. > > > > Yes. > > I guess so if you are talking about the Linux system which is case > sensitive. But I don't think this can happen in windows DNS servers. I don't > have experience with the latest versions, but in the older versions it > wasn't like this. > > Hosnieh We are talking about what nameservers should do. Yes there are broken implementations out there. Named isn't perfect in this respect as it doesn't correctly preserve the case of owner names of records when adding them to the internal databases. Keeping a bit vector of the case of each octet in the ownername with each record would be one way to address this without consuming too much memory. We don't currently do case preserving compression when responding to general queries. For PTR queries in the reverse tree this is usually not a issue but for other queries it could be. We do preserve case of rdata in ixfr and axfr transfers. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jay@nzrs.net.nz Tue Sep 3 18:06:18 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62B221E8106 for ; Tue, 3 Sep 2013 18:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] 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 Hixs9sO36pHq for ; Tue, 3 Sep 2013 18:06:14 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 898A921E80FB for ; Tue, 3 Sep 2013 18:06:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id DCA0A4B7709 for ; Wed, 4 Sep 2013 13:05:58 +1200 (NZST) X-Virus-Scanned: Debian amavisd-new at srsomail.office.nzrs.net.nz Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qhg4MBab9Ef2 for ; Wed, 4 Sep 2013 13:05:51 +1200 (NZST) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 5CFD34B2568 for ; Wed, 4 Sep 2013 13:05:51 +1200 (NZST) From: Jay Daley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 4 Sep 2013 13:05:51 +1200 To: "dnsext@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dnsext] Making life easier for sherpas with a POL RR 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, 04 Sep 2013 01:06:18 -0000 The Public Suffix List is to get monthly updates of new TLDs: = http://domainincite.com/14378-public-suffix-list-to-get-monthly-new-gtld-u= pdates or alternatively _publicsuffix.nz. POL - "*.nz" just saying. =20 Jay PS yes I know some won't fit, like the 30k long .jp entry --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley From drc@virtualized.org Tue Sep 3 20:15:28 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DEA21E8141 for ; Tue, 3 Sep 2013 20:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 B7TsY5NL3gng for ; Tue, 3 Sep 2013 20:15:23 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id C997F21E8157 for ; Tue, 3 Sep 2013 20:15:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id BA4E087128; Tue, 3 Sep 2013 23:15:21 -0400 (EDT) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 07437-05; Tue, 3 Sep 2013 23:15:21 -0400 (EDT) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id 20286868D4; Tue, 3 Sep 2013 23:15:20 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8681C035-19AD-4E56-8491-7E8D5A6F1F20"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: David Conrad In-Reply-To: Date: Tue, 3 Sep 2013 20:15:19 -0700 Message-Id: References: To: Jay Daley X-Mailer: Apple Mail (2.1508) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Making life easier for sherpas with a POL RR 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, 04 Sep 2013 03:15:28 -0000 --Apple-Mail=_8681C035-19AD-4E56-8491-7E8D5A6F1F20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jay, On Sep 3, 2013, at 6:05 PM, Jay Daley wrote: > The Public Suffix List is to get monthly updates of new TLDs: >=20 > = http://domainincite.com/14378-public-suffix-list-to-get-monthly-new-gtld-u= pdates >=20 > or alternatively >=20 > _publicsuffix.nz. POL - "*.nz" >=20 > just saying. =20 On the one hand, the whole public suffix thing makes me cringe every = time I think about it (or projectile vomit, depending on how much I = think about it). On the other hand, I applaud your efforts to encourage a move from the = moral equivalent of HOSTS.TXT to the DNS. On the gripping hand, POL? We have it on good authority that if you = want things to work, you have to use TXT. > PS yes I know some won't fit, like the 30k long .jp entry Last I checked, 30k would fit in a DNS message (albeit perhaps not a UDP = one). Regards, -drc --Apple-Mail=_8681C035-19AD-4E56-8491-7E8D5A6F1F20 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSJqXHAAoJENV6ebf0/4rXQYwH/jCo25fZ+q4wm+0DsP7oYOto a+Q/rrLWQSynh3mX+PcXd9U2pduVdq8bpqwjPVGK9tt8ilNnIzM4qBhBxhRCQBIB C9slynV/q+wO/WNWUKD3w8fw8ChvOp0hmc0jy2wgtmyp/vX3sI9xhQo/fTY1r1Uq Mg5v+nuIQim+Wlo36PPVFBvtR3yBQ7gUMZjqL+w4FdA6lEeI8OVQEBwFMFuLzjtA gMBgMxUkuJ+TOFxKdXXJ8bdBp78NBi/npaY3cmW+9ERkC6oFgV1BAT7NPEZfgbSL v5BLH2dserV/7jkTiwVY5MgsvDRwvPgLrXSwsE59FlaHGiuHqkCdMfNw1Rlov3s= =9+op -----END PGP SIGNATURE----- --Apple-Mail=_8681C035-19AD-4E56-8491-7E8D5A6F1F20-- From cas@strotmann.de Thu Sep 5 00:51:34 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4C811E817E for ; Thu, 5 Sep 2013 00:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_BAYES_5x8=0.8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poQ+4ABCYC4g for ; Thu, 5 Sep 2013 00:51:33 -0700 (PDT) Received: from csgate3.strotmann.de (cstrotm-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:f1d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5AD11E817A for ; Thu, 5 Sep 2013 00:51:32 -0700 (PDT) Received: from csgate4.strotmann.de.strotmann.de (cstrotm-1-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:f1d::2]) by csgate3.strotmann.de (Postfix) with ESMTP id 6FD3250D1; Thu, 5 Sep 2013 09:51:25 +0200 (CEST) From: Carsten Strotmann To: Carsten Strotmann References: <20130819222037.GA55876@mx1.yitter.info> <93130B0B-5C37-45EE-8380-AF209CA54B8F@frobbit.se> <20130820141029.GQ32655@cisco.com> <521383E9.4080800@strotmann.de> Date: Thu, 05 Sep 2013 09:51:24 +0200 In-Reply-To: <521383E9.4080800@strotmann.de> (Carsten Strotmann's message of "Tue, 20 Aug 2013 16:57:45 +0200") Message-ID: <87txhzpuyr.fsf@csgate4.strotmann.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: Pete Resnick , "dnsext@ietf.org Group" , F@cisco.com, Patrik@cisco.com Subject: Re: [dnsext] Deprecating SPF 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, 05 Sep 2013 07:51:34 -0000 Hi, Carsten Strotmann writes: > > I did some tests on Windows 2008 (R2) in 2009 or 2010 and found that the > Microsoft server does support RFC 3597 for zones loaded from a master > (by zonetransfer) or from a masterfile, but there is no way to add or > edit the data through the GUI (if is however possible to add the records > to a plain text DNS master file using a text editor, if I remember > correctly). I haven't tested zones stored in Active Directory. > I have done some tests using the current Windows 2012 DNS Server (I probably will test Windows 2012R2 later in October, but I don't expect much difference from the results below. If I find differences, I will report here). Test-Setup: DNS Master: Fedora 19 Linux with BIND 9.9.3-rl.13207.22-P2-RedHat-9.9.3-5.P2.fc19 (Extended Support Version) DNS Slave: Windows 2012 GA dns.exe Version 6.2.9200.16384 Record Types supported by Windows 2012 GUI: AFSDB, CNAME, ATMA, DS, DHCID, DNSKEY DNAME, A, AAAA, HINFO, ISDN, MX, MG MB, MINFO, NAPTR, NXT, PTR, KEY, MR RP, RT, SRV, SIG, TXT, WKS, X25 It is not possible (to my knowledge) to add other record types other than the ones above using the Microsoft GUI or command line utilities. Therefore the Windows DNS Server was configured to fetch a master zone from a BIND DNS Server. The zone on the master contained one SPF and one TLSA record. After adding the slave zone to Windows 2012, the Windows DNS server did a full zonetrasfer (AXFR) from the BIND Master. The zonefile created on disk contained the SPF and TLSA records in hexadecimal encoded format: (one long line) _443._tcp 30 #52 03 00 01 54 fffffff3 fffffffd ffffff87 76 32 ffffffa4 1c 65 ffffffb0 ffffffff 4e 50 ffffffe2 54 ffffffdd 7d 18 73 48 62 31 ffffffdc 6c ffffffd5 ffffffe9 ffffffc1 ffffffc1 ffffff96 3d 1e 4e (one long line) spf 30 #99 12 76 3d 73 70 66 31 20 2b 61 20 2b 6d 78 20 2d 61 6c 6c After the first AXFR, the Windows DNS Server did reply correctly to SPF and TLSA queries (tested using "dig"). However, the Windows DNS Server fails to load the written zonefile once restarted. It complains about unknown RRs. The error messages are similar than the ones seen for the IXFR below. After the initial zonetransfer using AXFR, the zonetransfer for changes are done using IXFR. The same records that could be loaded successfully using AXFR are now failing: Error 1 while IXFR from BIND master: The DNS server encountered an non-writeable or unknown resource record (RR) type when writing the zone database to file. The event data is applicable RR type. Error 2 after IXFR from BIND master: The DNS server encountered an unknown or unsupported resource record (RR) type #99 in zone file example.com.dns at line 24. Although the DNS server continues to load, ignoring this RR, it is recommended that you either correct the record type or remove this RR from the zone file. The zone file is located in the %SystemRoot%\System32\Dns directory. I have not found a practical way to provision a Windows 2012 DNS Server with SPF (or TLSA) records. However it seems as if the Windows 2012 DNS server engine can work with unknown RRs, but the zone loader/parser and the IXFR code cannot. It might be interesting to get a statement from Microsoft on the support of unknown RRs (deliberate decision not support unknown RRs, no demand from customers, problem not known ...). Best regards Carsten From johnl@iecc.com Thu Sep 5 09:03:03 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C61E21F9B97 for ; Thu, 5 Sep 2013 09:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.612 X-Spam-Level: X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 mzG1-EYcBqt1 for ; Thu, 5 Sep 2013 09:02:58 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id AB88521E8130 for ; Thu, 5 Sep 2013 09:02:57 -0700 (PDT) Received: (qmail 44567 invoked from network); 5 Sep 2013 16:02:53 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Sep 2013 16:02:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5228ab2d.xn--yuvv84g.k1309; i=johnl@user.iecc.com; bh=rk0r4EFA6Fiqsr2Jd3w5lBIJA0Qqi6BKmMOUFfrid0A=; b=V4E4/bZzcglVdOc/ha5ULoY5U+wfkLn0uPrBJjnqqDBCeGFF+kxveuVXml03meHdCJxRCqhHCmmvI6IbyvVMM3Bal2VTCS188eQAKH6wi0yjWOBgUE3ciKqZZWO0YStZ3bCfbt/k5S0qe+9pJZE/770bnJhbgK2Jj72DBPYimh05A9Sv89khKvQBRS8flUbjcl32r6jgAsYlapvZ5aijwtHkRUuN9/IO2Dlc+aWZ+lB3h2u62UHMGCk5YuHLJ74f DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5228ab2d.xn--yuvv84g.k1309; olt=johnl@user.iecc.com; bh=rk0r4EFA6Fiqsr2Jd3w5lBIJA0Qqi6BKmMOUFfrid0A=; b=FPWLF9b7K8TBxjKl5Y3ZUR/Z3IelkVOvDWBu0OzLIkQFDmWv8HqSX5Ptd3u8mLjbafcS9s7fljkX73t3nV/j8PaRv5BwXUjH2L31ULoTk3VkFKIELqvjc7AG0qATcA2PST0X3mtoIZmyrey2PRFS70AWvjitaqS5KumcF9f8oudUAWbQEK2WK0T0SH1HFLaNZnRgxtJCCWA6HUFnEN39HRtfzBbneZplo8KGy5cVD+0KmgEnnyT+QxhRSyh0YL2v Date: 5 Sep 2013 16:02:30 -0000 Message-ID: <20130905160230.3448.qmail@joyce.lan> From: "John Levine" To: dnsext@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [dnsext] Making life easier for sherpas with a POL RR 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, 05 Sep 2013 16:03:05 -0000 >On the gripping hand, POL? We have it on good authority that if you want things >to work, you have to use TXT. At the next IETF, there will likely be a BoF where Andrew Sullivan and I discuss our DNS versions of the public suffix list. They're quite different, because they address quite different problems. R's, John From ietf@rozanak.com Sun Sep 8 16:23:55 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4175E21E8108; Sun, 8 Sep 2013 16:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 yHQwd9kpOaXA; Sun, 8 Sep 2013 16:23:50 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 721F021E8107; Sun, 8 Sep 2013 16:23:47 -0700 (PDT) Received: from kopoli (g225032200.adsl.alicedsl.de [92.225.32.200]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LymY3-1W4dNT1XEN-016A26; Sun, 08 Sep 2013 19:23:43 -0400 From: "Hosnieh Rafiee" To: , Date: Mon, 9 Sep 2013 01:23:33 +0200 Message-ID: <000c01ceacea$7295d5b0$57c18110$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6s6j1fjDMnNr7wROCtfn2old9LMA== Content-Language: en-us X-Provags-ID: V02:K0:Dvdx7RTdugkIhHRI8y9l6kdvNE3ajPUiNP4/jlgc+jn E/wb+dXI3GBY+oyEZOU6iTsb3WljSVqk+239JeW1NnnJtEJxe9 OzhoeD8DhvEFi2xlrUASKylzsTii5Y2KVnz2g+rS5y7LyAjZEV lBtWvfuzy9wPvTiKtb9criO1ETiaKvAULsNEE96kwM4D+SA6n0 gYjB91dPmmzGLPciJ/49OX03W8eo73wK8oml4KiyIi7Vu2/0vP 6MVVEVsk9Bw055wieZQBE6ilsHVNFZUvFNy231TvLhKPvqxgDY j6OU2L+Igttcjv/WQV1ndMRVAw45ndbkC3WcKcwM55SmZ0KeJ3 +Y6iXQ6JiNzihtJXNynY= Subject: [dnsext] cga-tsig new version - clarification of problem statement 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, 08 Sep 2013 23:23:55 -0000 Hello, I uploaded new version of cga-tsig, I tried to clarify the points and improved the problem statement. I improved the problem statement section and also modified the other section. For example, In the case of adding the IP addresses of other DNS servers manually to the configuration file (DNS update) or the case where you want to authenticate the resolver (you already know the IP address of the resolver via a DHCP server or an option in a RA message), the authentication is based solely on the source IP address. So it is possible for someone to spoof this IP address and poison the client's DNS cache. Of course it is possible to use it during a zone transfer as the authentication is again based on the source IP address if no security mechanisms are used. If it is used, then there is the other problem of dealing with the configuration of DNSSEC and TSIG, or shared secret leakage in TSIG. The purpose of CGA-TSIG is to eliminate these problems and to reduce the number of manual steps needed to carry out a configuration. I also explained in the document the case where the DNS server does not support SeND. So there are two options; it can either generate the CGA parameters by using any external script and then configure the IP address and use it as a means for further authentication, or it can generate the key pairs itself and skip the CGA verification step during the verification process, which is not secure in PTR or source IP address verification. http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig I hope that this clarifies the draft. I have tried to respond to your concerns and I hope that with this version we can move forward. Thanks, Best, Hosnieh P.S. Sorry if any of you received this message twice. From paul@nohats.ca Tue Sep 10 18:15:57 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C245311E81DB for ; Tue, 10 Sep 2013 18:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FUDRtF9XLjr for ; Tue, 10 Sep 2013 18:15:52 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 80CE711E81C9 for ; Tue, 10 Sep 2013 18:15:51 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cZQCk6DwPz7Dp for ; Tue, 10 Sep 2013 21:15:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id re26VCFC_hwt for ; Tue, 10 Sep 2013 21:15:46 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP for ; Tue, 10 Sep 2013 21:15:45 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 4335F848E5; Tue, 10 Sep 2013 21:15:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1674C811F6 for ; Tue, 10 Sep 2013 21:15:46 -0400 (EDT) Date: Tue, 10 Sep 2013 21:15:46 -0400 (EDT) From: Paul Wouters To: DNSEXT Group Working Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-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, 11 Sep 2013 01:15:57 -0000 FYI, Let's make DNSSEC on mobile phones possible without hacking dnssec into X.509 blobs (or JSON or XML) Paul -------- Original Message -------- Subject: New Version Notification for draft-wouters-edns-tcp-chain-query-00.txt Date: Tue, 10 Sep 2013 18:11:35 -0700 From: internet-drafts@ietf.org To: Paul Wouters A new version of I-D, draft-wouters-edns-tcp-chain-query-00.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Filename: draft-wouters-edns-tcp-chain-query Revision: 00 Title: TCP chain query requests in DNS Creation date: 2013-09-10 Group: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-wouters-edns-tcp-chain-query-00.txt Status: http://datatracker.ietf.org/doc/draft-wouters-edns-tcp-chain-query Htmlized: http://tools.ietf.org/html/draft-wouters-edns-tcp-chain-query-00 Abstract: This document defines an EDNS0 extension that can be used by a DNSSEC enabled Recursive Nameserver configured as a forwarder to send a single query over TCP requesting to receive a complete validation path along with the regular query answer. Additionally, use of this option is considered a request to keep the TCP connection open to serve additional DNS requests. Use of this option significantly reduces DNS latency for hosts deploying DNSSEC. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From each@isc.org Tue Sep 10 20:45:18 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A510511E8145 for ; Tue, 10 Sep 2013 20:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79JUGKt2ajmK for ; Tue, 10 Sep 2013 20:45:17 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 114E411E80FE for ; Tue, 10 Sep 2013 20:45:17 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 00B2EC9423; Wed, 11 Sep 2013 03:44:56 +0000 (UTC) (envelope-from each@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1378871106; bh=QoIBqBK0i60F5X0omFzGla5S3SlZ0YjpcKRsvAXitjU=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=kDZCq7nKCVV4YVIMHOdvVMekz0oC4H9LciZzZk99m38Qpad+ttvmewte4ZqMd4B1M EMgMUboprGpBby/J4RzpAXFLVhHWfvISqqFVA+kA2ijtUVM0pLmoyEFIZzbMembOgD 2c56J6eSvlWSGJWIxkKtThYcTQI0pr4dtrQ1/NEI= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS; Wed, 11 Sep 2013 03:44:55 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id E452D216C25; Wed, 11 Sep 2013 03:44:55 +0000 (UTC) Date: Wed, 11 Sep 2013 03:44:55 +0000 From: Evan Hunt To: Paul Wouters Message-ID: <20130911034455.GB2051@isc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-DCC--Metrics: post.isc.org; whitelist Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-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, 11 Sep 2013 03:45:18 -0000 On Tue, Sep 10, 2013 at 09:15:46PM -0400, Paul Wouters wrote: > Let's make DNSSEC on mobile phones possible without hacking dnssec into > X.509 blobs (or JSON or XML) > > Abstract: > This document defines an EDNS0 extension that can be used by a DNSSEC > enabled Recursive Nameserver configured as a forwarder to send a > single query over TCP requesting to receive a complete validation > path along with the regular query answer. Additionally, use of this > option is considered a request to keep the TCP connection open to > serve additional DNS requests. Use of this option significantly > reduces DNS latency for hosts deploying DNSSEC. I'm not certain "request DNSSEC chain" and "keep the TCP connection open" should be combined in a single option, but I support both. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From Jelte.Jansen@sidn.nl Wed Sep 11 00:29:35 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7046421E808C for ; Wed, 11 Sep 2013 00:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_EQ_IP_ADDR=1.119] 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 uTejy-kwIZzn for ; Wed, 11 Sep 2013 00:29:31 -0700 (PDT) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id C14BC11E81DE for ; Wed, 11 Sep 2013 00:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding:x-originating-ip; bh=m9RGw0lLMlrlvpDJswTmxs/JN+XGKkp/voQZo6LnERQ=; b=wa5pvknFvXDWUql3rmsqvVE0eTrwVZq3QxGu0lz/RWKE7IBVGkpb5kALqsVlkNRAhD6yASjg/SlgoXy2brfe4+7Tpc5RM9Z7KZySMgCpVuOhLom0f09maq9zeE0B64o7Vpzgau50cYzYPxntnoQaAVtnh3eW3kOCigl0hJAJ7nY= Received: from kahubcasn02.SIDN.local ([192.168.2.74]) by ede1-kamx.sidn.nl with ESMTP id r8B7TS36014761-r8B7TS38014761 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Wed, 11 Sep 2013 09:29:28 +0200 Received: from [94.198.152.214] (94.198.152.214) by kahubcasn02.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 11 Sep 2013 09:29:27 +0200 Message-ID: <52301BD7.7040004@sidn.nl> Date: Wed, 11 Sep 2013 09:29:27 +0200 From: Jelte Jansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Wouters References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.152.214] Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-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, 11 Sep 2013 07:29:35 -0000 On 09/11/2013 03:15 AM, Paul Wouters wrote: > > Abstract: > This document defines an EDNS0 extension that can be used by a DNSSEC > enabled Recursive Nameserver configured as a forwarder to send a > single query over TCP requesting to receive a complete validation > path along with the regular query answer. Additionally, use of this > option is considered a request to keep the TCP connection open to > serve additional DNS requests. Use of this option significantly > reduces DNS latency for hosts deploying DNSSEC. > Want! Some thoughts after a very quick read: - It should probably mention what to do with CNAMES (my guess would be return data until cname and let client requery with chain option for that) - Depending on above, I don't think *infinite* chains are possible (though prohibitively long ones are) - Should there be a considerations section about timeouts? BTW, I have a sneaking suspicion there also might be a bit of trickery regarding keys of multiple where some chains are valid and some are not, but I haven't got a specific example in my head yet. Jelte From jabley@hopcount.ca Wed Sep 11 05:14:02 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493AF11E822D for ; Wed, 11 Sep 2013 05:14:02 -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 HvIT0YGAtJyj for ; Wed, 11 Sep 2013 05:14:01 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5867C11E8229 for ; Wed, 11 Sep 2013 05:14:01 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id l4so5110802qcv.24 for ; Wed, 11 Sep 2013 05:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H/jZ8cveN8ujlgBO+52N+2mzEzE8sWuBBrVJwKRmkGU=; b=eZ32pWSFpvkv5yrcnb0nFX1cStzwkeCWi4MXNmgaZh+UunCtaTvv79KHqPC4jDy2V6 W3WGiojyHzevnmp15Q3KEfZDyxaEZY1prBRr3he6QQ/19CofHPdMMD88DmjzuM8xvrbG MQmOmHKToBX9CrLvrwT4vVoIU3a63X11VzqKA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=H/jZ8cveN8ujlgBO+52N+2mzEzE8sWuBBrVJwKRmkGU=; b=eJaZEzZ7ew4xseDO2aiAlCfSRncBruP1HMO+tpvTJVM2UpxN8bpVSnWRPCufunrYOn McNkVEE1QHX5Ema3jWnUdHZJBTaFLwAOCF33pGdT9mEKObGSbb4pXD/0fjT0tYPZwmtE VUv2geZDOAZyZnY+dEafqDeBb/iLR4hkvCaqc8OgKTUen1dIy8yiJvyxdVAL11I3jjbC lssdXYUUuCMgX+ngesOB2e+zqecWmecoRFuA/6KhQMGiXgazKcH8amcX6YPBixbO9b/h VCp+PjSpSXINqVVEiW0mIeUXSZknQTvxA2CyyjJpY8Cr9AzCDrghMS0N8OK94Mk3HV8O 4jOg== X-Gm-Message-State: ALoCoQmpyCmMr8SpUGPcwvCrm45fQHxEVP2bcWVAlGXu60SwoYg1O1Nd4+U8aCgg5fOLddHrfk+I X-Received: by 10.49.95.68 with SMTP id di4mr2711130qeb.50.1378901640747; Wed, 11 Sep 2013 05:14:00 -0700 (PDT) Received: from dh26.r1.hopcount.ca ([135.23.68.78]) by mx.google.com with ESMTPSA id u8sm45812279qef.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 05:14:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Joe Abley In-Reply-To: <20130911034455.GB2051@isc.org> Date: Wed, 11 Sep 2013 08:13:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130911034455.GB2051@isc.org> To: Evan Hunt X-Mailer: Apple Mail (2.1508) Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-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, 11 Sep 2013 12:14:02 -0000 On 2013-09-10, at 23:44, Evan Hunt wrote: > On Tue, Sep 10, 2013 at 09:15:46PM -0400, Paul Wouters wrote: >> Let's make DNSSEC on mobile phones possible without hacking dnssec = into >> X.509 blobs (or JSON or XML) >>=20 >> Abstract: >> This document defines an EDNS0 extension that can be used by a = DNSSEC >> enabled Recursive Nameserver configured as a forwarder to send a >> single query over TCP requesting to receive a complete validation >> path along with the regular query answer. Additionally, use of = this >> option is considered a request to keep the TCP connection open to >> serve additional DNS requests. Use of this option significantly >> reduces DNS latency for hosts deploying DNSSEC. >=20 > I'm not certain "request DNSSEC chain" and "keep the TCP connection = open" > should be combined in a single option, but I support both. Isn't "keep the TCP connection open" superfluous, since in DNS the = responsibility for closing the socket lies with the client, not the = server? A client expecting to receive a multi-message reply will presumably know = to keep the socket open. A server capable of sending a multi-message = reply would also know. RFC 1035: 4.2.2. TCP usage Messages sent over TCP connections use server port 53 (decimal). The message is prefixed with a two byte length field which gives the message length, excluding the two byte length field. This length field allows the low-level processing to assemble a complete message before beginning to parse it. Several connection management policies are recommended: - The server should not block other activities waiting for TCP data. - The server should support multiple connections. - The server should assume that the client will initiate connection closing, and should delay closing its end of the connection until all outstanding client requests have been satisfied. - If the server needs to close a dormant connection to reclaim resources, it should wait until the connection has been idle for a period on the order of two minutes. In particular, the server should allow the SOA and AXFR request sequence (which begins a refresh operation) to be made on a single connection. Since the server would be unable to answer queries anyway, a unilateral close or reset may be used instead of a graceful close. Joe= From tale@dd.org Wed Sep 11 07:49:07 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D3921E811B for ; Wed, 11 Sep 2013 07:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQ3RUlsuP-Q2 for ; Wed, 11 Sep 2013 07:49:02 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7B95C21E80B1 for ; Wed, 11 Sep 2013 07:49:00 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 8073C3F438; Wed, 11 Sep 2013 10:48:55 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21040.33495.339145.530959@gro.dd.org> Date: Wed, 11 Sep 2013 10:48:55 -0400 From: Dave Lawrence To: Joe Abley In-Reply-To: References: <20130911034455.GB2051@isc.org> Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-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, 11 Sep 2013 14:49:08 -0000 Joe Abley writes: > Isn't "keep the TCP connection open" superfluous, since in DNS the > responsibility for closing the socket lies with the client, not the > server? Yes, and no. This is definitely what the spec says,. For years many operators have believed it to be a misfeature of the original spec and have subverted it in various ways, including short timeouts before the server kills the connection if a client EOF is not forthcoming. It would be useful to have a way to negotiate the TCP connection behavior, including options like signalling that the server may close the connection as soon as the response is sent, or that the client wants to send more than one request. I don't think this meaning should be bundled into the DNSSEC chain query option, however. From jabley@hopcount.ca Wed Sep 11 08:31:21 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB85211E820B for ; Wed, 11 Sep 2013 08:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCPDr54gTPec for ; Wed, 11 Sep 2013 08:31:21 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id C3AA611E819C for ; Wed, 11 Sep 2013 08:31:18 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id tp5so19916525ieb.0 for ; Wed, 11 Sep 2013 08:31:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d41SD3xT9SDV49pTFO1UWvcgc/TBUtLwtUT0qiqVjN4=; b=ACUvyW+OhUVhgE3nfie5OMXL7cs/fx4QNT+5nEQFgBkN8liZ69wJFDNseg0Ntfs9UU 6NSaJGZxIU7ElfM2t33oKA6jexB561l5iyK91THUTHvYHas2aCEHb8zo1DHqDt2r6clk pzf6x524QMzsdlIFoZGStPQB7yV5DJPtEO4S4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=d41SD3xT9SDV49pTFO1UWvcgc/TBUtLwtUT0qiqVjN4=; b=a8HIeT9lr7cKwf5qc/MzYRCf6XakQRBej2f+4PeqKagD+Dvx8J4e6EIG3aMKk7BWna Pkx92zQ4AAs6uU2dbGpaqmSmwEZv3Tp8UrtrDM7AVoVPyMrA9lBUYqyPJNfZlEZsdw3b 9G3TGgqpNBd9PQGg3KoVgp3ApMDq3rpb+nsWrHvEtzkS03WrjPgC3+upLHAueEBeNPNs FlFzg1MQJSYGkvjAb3m2sTz6zfR0LBoNZvQX2VZbFFg1UZ3/3ORtz/9psZ3Zak/hVubE vXRG2YzrPWoW94pI1rS4yGHn+3+J1UTMU6c1eafZiBAUnXPKK+eMpST9OyMGjlTQywFT kTAA== X-Gm-Message-State: ALoCoQkn221PQSZne97+2wzUULFJi1pj/Yd8ldQstcgoD8167KzIC7SQYk3iUpXReWu3RGGUJ6n6 X-Received: by 10.50.36.5 with SMTP id m5mr12194036igj.3.1378913478228; Wed, 11 Sep 2013 08:31:18 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:1:38ef:fc0f:73eb:dccf? ([2001:4900:1042:1:38ef:fc0f:73eb:dccf]) by mx.google.com with ESMTPSA id x5sm3398667iga.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 08:31:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Joe Abley In-Reply-To: <21040.33495.339145.530959@gro.dd.org> Date: Wed, 11 Sep 2013 11:31:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130911034455.GB2051@isc.org> <21040.33495.339145.530959@gro.dd.org> To: Dave Lawrence X-Mailer: Apple Mail (2.1508) Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-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, 11 Sep 2013 15:31:22 -0000 On 2013-09-11, at 10:48, Dave Lawrence wrote: > It would be useful to have a way to negotiate the TCP connection > behavior, including options like signalling that the server may close > the connection as soon as the response is sent, or that the client > wants to send more than one request. I don't think this meaning > should be bundled into the DNSSEC chain query option, however. So, perhaps an EDNS0 option that allows some degree of capabilities = negotiation (client says I can do { x, y, z }, server may provide = responses with similar options, client issues test query over first = message sent on newly-opened TCP socket to catalogue capabilities). This might also be a way to signal the availability of other transports = like SCTP or HTTP. Joe= From paul@nohats.ca Wed Sep 11 08:54:47 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A044721E815B for ; Wed, 11 Sep 2013 08:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLpdDxnku0ce for ; Wed, 11 Sep 2013 08:54:39 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id C22DD21E80CF for ; Wed, 11 Sep 2013 08:54:38 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cZnjl67Tdz9H9; Wed, 11 Sep 2013 11:54:35 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LvRUch9rFmpx; Wed, 11 Sep 2013 11:54:35 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 11 Sep 2013 11:54:34 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 77677848E5; Wed, 11 Sep 2013 11:54:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6E5C6848E4; Wed, 11 Sep 2013 11:54:35 -0400 (EDT) Date: Wed, 11 Sep 2013 11:54:35 -0400 (EDT) From: Paul Wouters To: Dave Lawrence In-Reply-To: <21040.33495.339145.530959@gro.dd.org> Message-ID: References: <20130911034455.GB2051@isc.org> <21040.33495.339145.530959@gro.dd.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-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, 11 Sep 2013 15:54:48 -0000 On Wed, 11 Sep 2013, Dave Lawrence wrote: > Joe Abley writes: >> Isn't "keep the TCP connection open" superfluous, since in DNS the >> responsibility for closing the socket lies with the client, not the >> server? > > Yes, and no. This is definitely what the spec says,. For years many > operators have believed it to be a misfeature of the original spec and > have subverted it in various ways, including short timeouts before the > server kills the connection if a client EOF is not forthcoming. > > It would be useful to have a way to negotiate the TCP connection > behavior, including options like signalling that the server may close > the connection as soon as the response is sent, or that the client > wants to send more than one request. I don't think this meaning > should be bundled into the DNSSEC chain query option, however. I've heard several people tell me this now and I agree. The question is: 1) do we want to clarify in a separate draft that the TCP connection can remain open for re-use? 2) do we want to use another edns0 option to ask the server to keep the TCP connection, which the server indicates by returning this option in its TCP reply? It seems to be 2) is probably a better idea, and I'm happy to write that up in a separate document. Paul From paul@nohats.ca Wed Sep 11 08:56:57 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B46721F9DAB for ; Wed, 11 Sep 2013 08:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 nEmH1zBeEh+z for ; Wed, 11 Sep 2013 08:56:45 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id D60A521E812A for ; Wed, 11 Sep 2013 08:56:20 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cZnlk49hpz9H9; Wed, 11 Sep 2013 11:56:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 6MfW4ZC0wJVf; Wed, 11 Sep 2013 11:56:18 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 11 Sep 2013 11:56:18 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 2A94A848E5; Wed, 11 Sep 2013 11:56:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 21B2A848E4; Wed, 11 Sep 2013 11:56:19 -0400 (EDT) Date: Wed, 11 Sep 2013 11:56:19 -0400 (EDT) From: Paul Wouters To: Joe Abley In-Reply-To: Message-ID: References: <20130911034455.GB2051@isc.org> <21040.33495.339145.530959@gro.dd.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-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, 11 Sep 2013 15:56:57 -0000 On Wed, 11 Sep 2013, Joe Abley wrote: > So, perhaps an EDNS0 option that allows some degree of capabilities negotiation (client says I can do { x, y, z }, server may provide responses with similar options, client issues test query over first message sent on newly-opened TCP socket to catalogue capabilities). > > This might also be a way to signal the availability of other transports like SCTP or HTTP. I'd prefer an option for just TCP so this doesn't end up getting bikeshedded. The client is (presumbly) already using TCP to connect. (also dns over http is just a bad hack that should not be needed. Let's not multiplex the entire internet over port 80/443) Paul From jabley@hopcount.ca Wed Sep 11 08:59:05 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA7521F9FBC for ; Wed, 11 Sep 2013 08:59:05 -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=[AWL=0.000, 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 FlYhRaDe-OYC for ; Wed, 11 Sep 2013 08:59:05 -0700 (PDT) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 04FF721E80CF for ; Wed, 11 Sep 2013 08:58:55 -0700 (PDT) Received: by mail-vb0-f54.google.com with SMTP id q14so6482744vbe.27 for ; Wed, 11 Sep 2013 08:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RCMg6Oz7O4rjZeSgbsTCOTMhfNv1ufnDkX0n1w2KZU4=; b=bFecJTwAJ2gb85DOMxMCywuRZ/l3lt2DBMWsoYdljpq+bV6GwF246hMWPQBxuS641q YbYMwWYq4bul0l7L2SeKTq0KJFddmvQpcTfFMEsbkgpXLO+MZ8yOBHB8KYXlSjWQcngA sOjegEZPoJAkwghOKua+FMZyaJq8yJhif43BM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=RCMg6Oz7O4rjZeSgbsTCOTMhfNv1ufnDkX0n1w2KZU4=; b=ZAUKDrYlM82OzeYFd4G8AyClN6TwspFPuV+vkFEQivm06y9YTuWgEaMLtK2wAKh8DX sMRW2DO/ee4fZL7B6J9ib7PJ722U0VP/tInOtb7WV8eA4Os+o2CgEU4ZMPRhhftVNPNP CWNEAH7qa6zGFt5cmkvziG2344YHcFPBta0iXzPT4uyZ8RzHbftIBCliMNcISCKo9o4/ O7FkqpL57KGIRnb9ikJq3SvHh185HvLiE2F8IFCMYI6iez8OwJKcVSP/MwzapIosTI0f Zxwlml/23PUoHwHKbBOt8S0wDdaMtXRKTuOlskCyt4a9exY7clN6aqrWHvQhtvbRZcIK 35UA== X-Gm-Message-State: ALoCoQlRGGYf95UP5aRQ9OK8sgYyNet9ayrVxgKVSJsVd2g+mbFcZrRpoIQt/+3sv2v9j35PAMkl X-Received: by 10.220.13.20 with SMTP id z20mr1904336vcz.0.1378915130161; Wed, 11 Sep 2013 08:58:50 -0700 (PDT) Received: from dh26.r1.hopcount.ca ([135.23.68.78]) by mx.google.com with ESMTPSA id uo1sm1159458vec.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 08:58:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Joe Abley In-Reply-To: Date: Wed, 11 Sep 2013 11:58:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130911034455.GB2051@isc.org> <21040.33495.339145.530959@gro.dd.org> To: Paul Wouters X-Mailer: Apple Mail (2.1508) Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-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, 11 Sep 2013 15:59:05 -0000 On 2013-09-11, at 11:56, Paul Wouters wrote: > On Wed, 11 Sep 2013, Joe Abley wrote: >=20 >> So, perhaps an EDNS0 option that allows some degree of capabilities = negotiation (client says I can do { x, y, z }, server may provide = responses with similar options, client issues test query over first = message sent on newly-opened TCP socket to catalogue capabilities). >>=20 >> This might also be a way to signal the availability of other = transports like SCTP or HTTP. >=20 > I'd prefer an option for just TCP so this doesn't end up getting > bikeshedded. The client is (presumbly) already using TCP to connect. I'd prefer a more general option that would allow more connection = parameters to be advertised in future, if/when they become interesting. = Assigning one code point to "persistent TCP connection capable" could = leave the door open in future for bikeshedding, but since that seems = inevitable anyway, what's the harm? I'm keen/able to contribute text to such a document (separate from = edns-tcp-chain-query), if you'd like a co-author. Joe From jabley@hopcount.ca Wed Sep 11 10:01:22 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A353311E80FF for ; Wed, 11 Sep 2013 10:01:11 -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 pWn54PuovyLT for ; Wed, 11 Sep 2013 10:01:02 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id C9BB221E80FD for ; Wed, 11 Sep 2013 10:00:12 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id y16so14823718ieg.12 for ; Wed, 11 Sep 2013 10:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qLcIP0iUguSx1Lgxqq89PJ1yMABnZ2CUdbBo0/p6lbo=; b=n2VQ5JBSGy7s9/LOwTMwptI5aEUsHWO+UqdF8Rp9KRxt6o+iDAzPyJsJrJkjvrumwi kjp9Va3p/kAULrTFBVkwdX4azCss4ENSqVLSPwCv7stu2TPcAnekQ98fS27v0KCjFxhk fPCfpaTEJQiHug9f/JJ4Q5+Ddlgu4Xihq29JM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=qLcIP0iUguSx1Lgxqq89PJ1yMABnZ2CUdbBo0/p6lbo=; b=KcwDD0q902R1asYT0993eoQF5DhCw2bxNnWq2owPdHX0e28SEDY8Toc/tyKP1SfaNc rR0nbwzsz1o/RQc+QCLh8P6E71js3vWQQ/eUbDWVxnZEUwXRP3eOGzZVOcsgT+4QOBfB ReWc5nM4K+LtuF0qNypiVlcJ9uc52jqIvgkZe7H32LJGTpRevKNGie7xBWrxzcd0bCLe cQGqvrodVeZZB4h2BMEEBfOzXlhfSosiZ7WhcWSEKjBXZG7PXe0+f+EcohdZ+DzshoMX 9eOcMt7i7PoLoLo9r+KXPwHkmOverq3N9KRKV46cmZ5aAZdfEWk/C1iwDfZ6PUuTftyk 40tw== X-Gm-Message-State: ALoCoQlqCCUSRJ9OPkQ8t3cwtRM/EXd6HIjbbpryrKYci6U0CJs1LkjYRo3S/OS962jeqBX1JK/P X-Received: by 10.50.122.102 with SMTP id lr6mr12615157igb.0.1378918808360; Wed, 11 Sep 2013 10:00:08 -0700 (PDT) Received: from [10.254.50.227] ([64.235.96.2]) by mx.google.com with ESMTPSA id i3sm3705223igh.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 10:00:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Joe Abley In-Reply-To: Date: Wed, 11 Sep 2013 13:00:06 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130911034455.GB2051@isc.org> <21040.33495.339145.530959@gro.dd.org> To: Paul Wouters X-Mailer: Apple Mail (2.1508) Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-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, 11 Sep 2013 17:01:23 -0000 Hey, Having now spent more than 15 seconds thinking about this... On 2013-09-11, at 11:54, Paul Wouters wrote: > On Wed, 11 Sep 2013, Dave Lawrence wrote: >=20 >> It would be useful to have a way to negotiate the TCP connection >> behavior, including options like signalling that the server may close >> the connection as soon as the response is sent, or that the client >> wants to send more than one request. I don't think this meaning >> should be bundled into the DNSSEC chain query option, however. >=20 > I've heard several people tell me this now and I agree. The question = is: >=20 > 1) do we want to clarify in a separate draft that the TCP connection > can remain open for re-use? Given that this apparently breaks assumptions already present in = widely-deployed software, that sounds like an uphill battle. > 2) do we want to use another edns0 option to ask the server to keep = the > TCP connection, which the server indicates by returning this option > in its TCP reply? I think yes, and upon >15 seconds of reflection I can't think of a = reason why you'd want such an option to be more general than this = specific functionality. Other transport-related signalling can use = different edns0 options. > It seems to be 2) is probably a better idea, and I'm happy to write = that > up in a separate document. Agree. Joe= From bdickson@verisign.com Wed Sep 11 10:37:12 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE98011E81A3 for ; Wed, 11 Sep 2013 10:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.949 X-Spam-Level: X-Spam-Status: No, score=-6.949 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 2dHIcZlLLCPI for ; Wed, 11 Sep 2013 10:37:01 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 95BC521F9967 for ; Wed, 11 Sep 2013 10:36:40 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUjCqJ+WpaAZG+aqpiA/udCfY+T0Hs/W5@postini.com; Wed, 11 Sep 2013 10:36:44 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r8BHaWRW004358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Sep 2013 13:36:36 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 11 Sep 2013 13:36:32 -0400 From: "Dickson, Brian" To: Joe Abley , Paul Wouters Thread-Topic: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-00.txt Thread-Index: AQHOrxVoPvKFocPm1U2Y9NcQSl7rsw== Date: Wed, 11 Sep 2013 17:36:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-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, 11 Sep 2013 17:37:12 -0000 Top-reply (sorry) - agree, sounds great, willing to review and/or contribute ideas/text. BTW - suggestion: include (from the server) info about maximum idle time of an open connection. E.g. no guarantees if you try to use this without keepalives and after 5 minutes has passed. This will often correspond to reaping state on state-ful load balancers. Knowing $REAP_TIME may make operational improvements on implementations where the option has been negotiated. Unusual values of $REAP_TIME may even suggest altering the keep-alive interval on the TCP socket, per server. Brian On 9/11/13 1:00 PM, "Joe Abley" wrote: >Hey, > >Having now spent more than 15 seconds thinking about this... > >On 2013-09-11, at 11:54, Paul Wouters wrote: > >> On Wed, 11 Sep 2013, Dave Lawrence wrote: >>=20 >>> It would be useful to have a way to negotiate the TCP connection >>> behavior, including options like signalling that the server may close >>> the connection as soon as the response is sent, or that the client >>> wants to send more than one request. I don't think this meaning >>> should be bundled into the DNSSEC chain query option, however. >>=20 >> I've heard several people tell me this now and I agree. The question is: >>=20 >> 1) do we want to clarify in a separate draft that the TCP connection >> can remain open for re-use? > >Given that this apparently breaks assumptions already present in >widely-deployed software, that sounds like an uphill battle. > >> 2) do we want to use another edns0 option to ask the server to keep the > >> TCP connection, which the server indicates by returning this option >> in its TCP reply? > >I think yes, and upon >15 seconds of reflection I can't think of a reason >why you'd want such an option to be more general than this specific >functionality. Other transport-related signalling can use different edns0 >options. > >> It seems to be 2) is probably a better idea, and I'm happy to write that >> up in a separate document. > >Agree. > > >Joe >_______________________________________________ >dnsext mailing list >dnsext@ietf.org >https://www.ietf.org/mailman/listinfo/dnsext From paul@nohats.ca Wed Sep 11 11:30:11 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEC311E81D1 for ; Wed, 11 Sep 2013 11:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 MTEY60IN1YPU for ; Wed, 11 Sep 2013 11:30:05 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 793A211E80A2 for ; Wed, 11 Sep 2013 11:30:05 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cZs961Dkbz9cR; Wed, 11 Sep 2013 14:30:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id qLsS_6BT_Uyu; Wed, 11 Sep 2013 14:30:00 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 11 Sep 2013 14:30:00 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 3ED8D80031; Wed, 11 Sep 2013 14:29:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C9BE580030; Wed, 11 Sep 2013 14:29:59 -0400 (EDT) Date: Wed, 11 Sep 2013 14:29:59 -0400 (EDT) From: Paul Wouters To: Joe Abley In-Reply-To: Message-ID: References: <20130911034455.GB2051@isc.org> <21040.33495.339145.530959@gro.dd.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-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, 11 Sep 2013 18:30:11 -0000 On Wed, 11 Sep 2013, Joe Abley wrote: > I think yes, and upon >15 seconds of reflection I can't think of a reason why you'd want such an option to be more general than this specific functionality. Other transport-related signalling can use different edns0 options. > >> It seems to be 2) is probably a better idea, and I'm happy to write that >> up in a separate document. Okay. I'll draft it up. The only real choice I see is the relaying a time period, but that seems silly. Either party might change it mind depending on work and load, so I think it should just be a binary on/off. However, I think we should allow the option to be queried/advertised over UDP. It would actually allow the client to know about the TCP capability without actually wasting a TCP session. Paul From paul@nohats.ca Wed Sep 11 11:36:52 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8D321F9B18 for ; Wed, 11 Sep 2013 11:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b1XlsrbZMCN for ; Wed, 11 Sep 2013 11:36:46 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5D321F8C93 for ; Wed, 11 Sep 2013 11:36:45 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cZsJp6RDTz9HG; Wed, 11 Sep 2013 14:36:42 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id uYe5RwSrmjH3; Wed, 11 Sep 2013 14:36:42 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 11 Sep 2013 14:36:41 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 9D27E80031; Wed, 11 Sep 2013 14:36:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9100B80030; Wed, 11 Sep 2013 14:36:42 -0400 (EDT) Date: Wed, 11 Sep 2013 14:36:42 -0400 (EDT) From: Paul Wouters To: "Dickson, Brian" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-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, 11 Sep 2013 18:36:52 -0000 On Wed, 11 Sep 2013, Dickson, Brian wrote: > Top-reply (sorry) - agree, sounds great, willing to review and/or > contribute ideas/text. > > BTW - suggestion: include (from the server) info about maximum idle time > of an open connection. > E.g. no guarantees if you try to use this without keepalives and after 5 > minutes has passed. > This will often correspond to reaping state on state-ful load balancers. > Knowing $REAP_TIME may make operational improvements on implementations > where the option has been negotiated. > Unusual values of $REAP_TIME may even suggest altering the keep-alive > interval on the TCP socket, per server. I was leaning towards not signaling the time period, but I see no harm in passing along the information from the server to the client. Paul From jabley@hopcount.ca Wed Sep 11 12:57:38 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6004221E808E for ; Wed, 11 Sep 2013 12:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JekTeqram76C for ; Wed, 11 Sep 2013 12:57:37 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B694921E808D for ; Wed, 11 Sep 2013 12:57:37 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id er7so8967297obc.31 for ; Wed, 11 Sep 2013 12:57:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ClM6MW7du/uc/bC5Uu14nQb6eZSni+NcGXej27synuU=; b=I7HQnytcNx1vtfqb/JYVieH/q5H/3I4DE6hX9wXB9SK6l7Wkg8DZEMzEr5B4oqw+OP 7YgSUhBBevUYoTDPSICvnTflF18M1JqrZZLOldN/N5fezbuoEOnMp7ucXYQSO8g1AODG +Dn2BWKvaui66fJv+bfS5VlaVfnaOHVtGZaag= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ClM6MW7du/uc/bC5Uu14nQb6eZSni+NcGXej27synuU=; b=QMYbzuZRB8YUzRoNiCIQL2hsLnvLba+KbqfiR+svEVrP13cTqcoSbx1yfOzfrBPh30 UF24X1d8R/Dz48hXfmZRCI9eI1LOtg6hkPZXGeNmEO+euCTq4Qci7kMugwJW9fJ69wd8 P9V/VjMpmTd1rUNhi8TG8D2ej+sPfsfB9tLPyh3E9HHOBvcqhPf3bzrePNo1gaqlodZs BmNn7Gg21g+IuNNhQeqBTKlMaBWx3W4h27OX9364XJCeynSqWMMqfZMNs/rrkb4J2v8D 0QyN0X3+b4pMKqOq7Pdq0og8Q/eljxiPqWe++wIlgmyZEXl78hdI2cwSXbVOTapMe73c tnFw== X-Gm-Message-State: ALoCoQnKKWJWH7FRBAAYuIUCTh/rKHBuRqW4R7bE9uk7w1bfLi5uQI82wCLkATe8UpomvPuG9QjK X-Received: by 10.182.227.136 with SMTP id sa8mr3111157obc.39.1378929457147; Wed, 11 Sep 2013 12:57:37 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:1:8c4f:8f48:6a01:b939? ([2001:4900:1042:1:8c4f:8f48:6a01:b939]) by mx.google.com with ESMTPSA id rr6sm31203183oeb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 12:57:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Joe Abley In-Reply-To: Date: Wed, 11 Sep 2013 15:57:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <016F7DF5-6A1F-431E-8BEF-A5325945D94D@hopcount.ca> References: <20130911034455.GB2051@isc.org> <21040.33495.339145.530959@gro.dd.org> To: Paul Wouters X-Mailer: Apple Mail (2.1508) Cc: DNSEXT Group Working Subject: Re: [dnsext] New Version Notification for draft-wouters-edns-tcp-chain-query-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, 11 Sep 2013 19:57:38 -0000 On 2013-09-11, at 14:29, Paul Wouters wrote: > However, I think we should allow the option to be queried/advertised > over UDP. It would actually allow the client to know about the TCP > capability without actually wasting a TCP session. I agree. Regardless of the fact that the transport capability being = signalled is TCP-specific, the capability advertisement should be = transport-agnostic. Joe=