From doug.mtview@gmail.com Tue Oct 1 00:55: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 36C7721F93BF; Tue, 1 Oct 2013 00:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 rVyedfpzSkLW; Tue, 1 Oct 2013 00:55:37 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7357F21F89FF; Tue, 1 Oct 2013 00:55:37 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x10so6864183pdj.15 for ; Tue, 01 Oct 2013 00:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xzGTk/YHvuVICyRNxMld0kiT+f/pUWjAspyQ3Zh0yrw=; b=0WxWXf9gdVkde3OdpzcR2/CB8Miovzllez5zRTfqPa1Xelq6fpVusPdlOkdyuO5JAe iYVCY8F3w2Q7JS6eqGL8jlufhMLKqboF87WCzLdn1960lOfh1kspFvZN6k1xhpJrEU2x zr0PqN+m97b29Bu+j9cBmi2xY+fMSYKaFYdxo/gZtF6X7i1H0fsxq1+bB3ui2ka/5hNt EmwTC9qqpiFfogIfcsOjf44Iq39VOGIe+7Gu49+GmNHz3wBz2TMVeMcJnLNYgMLARrRI qlyncEsyNjBz6ljXqYyXc/ttcfcHRozXvsdIiSJgt3zGE8VPHJX8nP/Zqv809tGkyNlW YaYA== X-Received: by 10.68.189.163 with SMTP id gj3mr28063389pbc.102.1380614137146; Tue, 01 Oct 2013 00:55:37 -0700 (PDT) Received: from [192.168.2.201] (c-24-6-103-174.hsd1.ca.comcast.net. [24.6.103.174]) by mx.google.com with ESMTPSA id k4sm5241939pbd.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Oct 2013 00:55:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Douglas Otis In-Reply-To: <20130912150227.57069.qmail@joyce.lan> Date: Tue, 1 Oct 2013 00:55:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <620FDB21-B8AD-41C4-BA4F-1616D8425B98@gmail.com> References: <20130912150227.57069.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1510) Cc: spfbis@ietf.org, "dnsext@ietf.org Group" Subject: Re: [dnsext] [spfbis] Sean Turner's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT) 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, 01 Oct 2013 07:55:38 -0000 Dear John, See comments inline. =20 On Sep 12, 2013, at 8:02 AM, John Levine wrote: > I don't see anything about SPF that makes DNS spoofing more of a > problem than any other DNS application, so I don't see why it needs > another plug for DNSSEC. For the record, I would like to strongly disagree with this statement. = SPFbis represents a significant change in how DNS and DNSSEC can be = abused and network amplifications achieved. =20 SPF introduces predefined "mechanisms" in conjunction with "macros" that = operate on message elements rather than just DNS resources. These = "mechanisms" combine with "macros" (if actually implemented by large = providers) to allow any compromised system to leverage cached Resource = Records to induce recipients into making more than 222 uniquely directed = DNS transactions derived from check_host() message elements (111 DNS = transactions for each of the two SPFbis check_host() message elements). = NO MITIGATION of this type of threat is possible without ignoring SPFbis = records containing "macros". This mitigation remains practical only by = email providers (not DNS operators) since only 0.00053 of the domains = publish records with a "macro" feature. =20 When DNSSEC is used, network amplification calculations change = dramatically. For example, the "PTR" or "MX" "mechanism" can be invoked = 10 times where each instance can resolve addresses for 10 RRs. For the = PTR mechanism, each invocation is permitted to return any number of PTR = RRs where the upper bound on the response size could be 8x larger. = While SPFbis recommends against their publication, there is no = recommendation against these "mechanisms" being processed by recipients = which is where the threat is realized. The complexity is represented = by the target modulation permitted by SPFbis "macros". RFC4033 does not = offer any mitigation for this type of threat which becomes significantly = worse when the DNS Message constraint changes from 512 octets and each = message can then cause 222 massive UDP DNS transactions against two = likely unrelated names constructed by macro expansion that SPFbis = recommends be resolved. > On the other hand, it's not a big deal, if it'll make the discuss go = away, that's fine. I don't think any DNS abuse mitigation strategy would be effective = against SPFbis misuse of DNS. SPFbis offers unknown entities = significant access to DNS resources that can not be blocked by BCP38, = rate limiting, or even be identified by RR Type or naming convention. = Sending a 1KB message could result in network amplifications = significantly greater than that provided by source address spoofing. = The reason this is not likely an issue is that providers are not = processing SPF records that contain macros because they may prefetch SPF = records as a means of whitelisting which precludes use of "macros". If = so, "macros" may introduce significant interchange issues. Too bad no = survey was made regarding the publication or the processing of SPFbis = "macros".=20 Regards, Douglas Otis >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> Should s11.3 also provide a mitigation via a reference for the = spoofed >>>> DNS? Right now it just points to the DNS threats RFC. I guess the >>>> reader can infer they should use DNSSEC if they're worried but = adding a >>>> pointer to the right RFC would be better. Something as simple as = adding >>>> "... and see [RFCXYZ] for a countermeasure" or something like that. >>>=20 >>> I'll suggest: >>>=20 >>> and see RFC 4033 for a countermeasure. >>>=20 >>> and leave it to the SPFBIS WG to comment on the above. >>=20 >> That would work for me. > _______________________________________________ > spfbis mailing list > spfbis@ietf.org > https://www.ietf.org/mailman/listinfo/spfbis From askuma@microsoft.com Thu Oct 3 09:11: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 65AB621E8114 for ; Thu, 3 Oct 2013 09:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmUzqBdOp49D for ; Thu, 3 Oct 2013 09:11:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id C7F7111E80F8 for ; Thu, 3 Oct 2013 09:00:36 -0700 (PDT) Received: from BL2PR03CA014.namprd03.prod.outlook.com (10.141.66.22) by BL2PR03MB097.namprd03.prod.outlook.com (10.255.230.15) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 3 Oct 2013 16:00:22 +0000 Received: from BN1BFFO11FD001.protection.gbl (2a01:111:f400:7c10::160) by BL2PR03CA014.outlook.office365.com (2a01:111:e400:c1b::22) with Microsoft SMTP Server (TLS) id 15.0.785.10 via Frontend Transport; Thu, 3 Oct 2013 16:00:22 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD001.mail.protection.outlook.com (10.58.53.61) with Microsoft SMTP Server (TLS) id 15.0.795.6 via Frontend Transport; Thu, 3 Oct 2013 16:00:21 +0000 Received: from SINEX14HUBC402.southpacific.corp.microsoft.com (157.60.220.216) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.3.136.1; Thu, 3 Oct 2013 15:59:32 +0000 Received: from SINEX14MBXC405.southpacific.corp.microsoft.com ([169.254.5.194]) by SINEX14HUBC402.southpacific.corp.microsoft.com ([157.60.220.216]) with mapi id 14.03.0146.002; Thu, 3 Oct 2013 15:59:28 +0000 From: Kumar Ashutosh To: "dnsext@ietf.org Group" Thread-Topic: Naked domain resolution with DNSSEC Thread-Index: Ac7ATe9x4lHsizWeS1mIFJsSspLh5A== Date: Thu, 3 Oct 2013 15:59:28 +0000 Message-ID: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.3.99] 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:(189002)(199002)(76482001)(46406003)(54316002)(33656001)(4396001)(80976001)(47446002)(81542001)(74662001)(74502001)(56776001)(23726002)(31966008)(16796002)(50986001)(47976001)(49866001)(81686001)(76796001)(76176001)(19580395003)(83322001)(76786001)(85306002)(6806004)(47736001)(56816003)(55846006)(81816001)(44976005)(69226001)(51856001)(77096001)(81342001)(53806001)(59766001)(77982001)(65816001)(80022001)(79102001)(46102001)(74366001)(74876001)(63696002)(74706001)(20776003)(47776003)(54356001)(50466002)(83072001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB097; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; 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: 09888BC01D X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: Sourav Sain Subject: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 16:11:34 -0000 Hi=20 In a scenario where, Server NS1 hosts myzone.com (myzone.com is not DNSSEC signed) with an A rec= ord at zone apex { myzone.com A 10.0.0.1 } And=20 COM server hosts NS for myzone.com pointing to NS1 If the Query for A record of type myzone.com goes to ROOT server from a DN= SSEC validating resolver Now as ROOT ( "." ) zone is signed. Root says that COM is signed by replyin= g with DS record for COM. A DNSSEC aware resolver with this data will conclude that COM is signed. He= nce a record under COM should be signed unless it's a delegation NS record = (at the zone cut). COM replies with NS record pointing to NS1 without any RRSIG and NSEC3 (as = DS for myzone.com is absent indicating an insecure delegation), which is ex= pected. Next the DNSSEC validating resolver asks NS1 for myzone.com. To this resolv= er a record under COM MUST have RRSIG. But NS1 that hosts the myzone.com responds for the A query with an A record= without any RRSIG. The resolver was expecting a signed response for everything under COM, gets= an unsigned response and marks them as BOGUS and returns a SERV_FAIL Some resolvers, do let the response pass but with AD bit set to 0 which a D= NSSEC aware end client may not accept. Is there any guidance around this? Thanks Ashu From fanf2@hermes.cam.ac.uk Thu Oct 3 09:47:29 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 A7CFB21F8BFD for ; Thu, 3 Oct 2013 09:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=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 IfboEZCvgrcU for ; Thu, 3 Oct 2013 09:47:22 -0700 (PDT) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCD921F9248 for ; Thu, 3 Oct 2013 09:32:17 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:49274) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1VRlp1-0004m7-94 (Exim 4.80_167-5a66dd3) (return-path ); Thu, 03 Oct 2013 17:32:15 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VRlp1-0005ek-OK (Exim 4.72) (return-path ); Thu, 03 Oct 2013 17:32:15 +0100 Date: Thu, 3 Oct 2013 17:32:15 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Kumar Ashutosh In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "dnsext@ietf.org Group" , Sourav Sain Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 16:47:29 -0000 Kumar Ashutosh wrote: > > Now as ROOT ( "." ) zone is signed. Root says that COM is signed by > replying with DS record for COM. A DNSSEC aware resolver with this data > will conclude that COM is signed. Hence a record under COM should be > signed unless it's a delegation NS record (at the zone cut). Records under .com can also be unsigned if they are under a provably insecure delegation. > COM replies with NS record pointing to NS1 without any RRSIG and NSEC3 > (as DS for myzone.com is absent indicating an insecure delegation), > which is expected. No: if myzone.com is unsigned the referral will include a proof of insecurity, like this: ; <<>> DiG 9.9.4rc1 <<>> +dnssec +norec myzone.com in a @a.gtld-servers.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42648 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;myzone.com. IN A ;; AUTHORITY SECTION: myzone.com. 2d IN NS ns1.myzone.com. myzone.com. 2d IN NS ns2.myzone.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 1d IN NSEC3 1 1 0 - ( CK0RFQAOES8CTVNVNH4G6Q85NOQAQ8I9 NS SOA RRSIG DNSKEY NSEC3PARAM ) CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 1d IN RRSIG NSEC3 8 2 86400 ( 20131009044051 20131002033051 8795 com. JCPiPpefxwjdDLZFWX2Wab+EthcL8zhDJdT7hykL1w0v 8PlkE0wqQiCJMp1DG0AZITP9sk9YcNyhCK3cZz6SAjl7 DtR/yhqi9zY9Ra/bESrmrLHI7Iw8boG7Us9UPebdMU4o vhe4nNLqwnf6GGJw3lSAzzFpr5UDeIVmS5EdDzs= ) KQ2VMKJAFRRU1S029E7TDJ2ARQAE2DEQ.com. 1d IN NSEC3 1 1 0 - ( KQ33P6J6S3E7AUT6M20OD79E277MR85S NS DS RRSIG ) KQ2VMKJAFRRU1S029E7TDJ2ARQAE2DEQ.com. 1d IN RRSIG NSEC3 8 2 86400 ( 20131008044035 20131001033035 8795 com. jYuq/3PGoVYECWWDT6ZrxBPEbQjEjQa5CmRa1s7mJDz4 ULJBCA5gubj3nRTmx93mf/1DoHZoq/5ZIwl9SvzQXCKl Q79NsVRXWuZOU5CuvNefNsf/RVL5nMjp5rLOk8MvaYNR duZj8hJaHz3cP4nLwg0wv7JmjAO0WCiBSLwiF9s= ) ;; ADDITIONAL SECTION: ns1.myzone.com. 2d IN A 204.244.181.149 ns2.myzone.com. 2d IN A 204.244.181.150 ;; Query time: 146 msec ;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30) ;; WHEN: Thu Oct 03 17:27:34 BST 2013 ;; MSG SIZE rcvd: 592 Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From tale@dd.org Thu Oct 3 10:09: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 BB5BA21E8115 for ; Thu, 3 Oct 2013 10:09:10 -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 nih-WM43ObYi for ; Thu, 3 Oct 2013 10:08:59 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE4011E8174 for ; Thu, 3 Oct 2013 09:49:45 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 252DA3F432; Thu, 3 Oct 2013 12:49:44 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21069.41000.63116.736893@gro.dd.org> Date: Thu, 3 Oct 2013 12:49:44 -0400 From: Dave Lawrence To: Kumar Ashutosh In-Reply-To: References: Cc: "dnsext@ietf.org Group" , Sourav Sain Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 17:09:11 -0000 Kumar Ashutosh writes: > The resolver was expecting a signed response for everything under > COM, gets an unsigned response and marks them as BOGUS and returns a > SERV_FAIL Some resolvers, do let the response pass but with AD bit > set to 0 which a DNSSEC aware end client may not accept. You've observed these behaviours? With which nameservers? From sosain@microsoft.com Sun Oct 6 09:17:33 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 98ECC21F9ED2 for ; Sun, 6 Oct 2013 09:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaSuIoR2RquE for ; Sun, 6 Oct 2013 09:17:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0152.outbound.protection.outlook.com [207.46.163.152]) by ietfa.amsl.com (Postfix) with ESMTP id E9BFF11E810E for ; Sun, 6 Oct 2013 09:17:28 -0700 (PDT) Received: from BY2PR03CA035.namprd03.prod.outlook.com (10.242.234.156) by BY2PR03MB207.namprd03.prod.outlook.com (10.242.36.154) with Microsoft SMTP Server (TLS) id 15.0.785.10; Sun, 6 Oct 2013 16:17:26 +0000 Received: from BL2FFO11FD037.protection.gbl (2a01:111:f400:7c09::103) by BY2PR03CA035.outlook.office365.com (2a01:111:e400:2c2c::28) with Microsoft SMTP Server (TLS) id 15.0.785.10 via Frontend Transport; Sun, 6 Oct 2013 16:17:26 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD037.mail.protection.outlook.com (10.173.161.133) with Microsoft SMTP Server (TLS) id 15.0.795.6 via Frontend Transport; Sun, 6 Oct 2013 16:17:25 +0000 Received: from SINEX14HUBC402.southpacific.corp.microsoft.com (157.60.220.216) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.3.136.1; Sun, 6 Oct 2013 16:16:40 +0000 Received: from SINEX14MBXC421.southpacific.corp.microsoft.com ([169.254.2.161]) by SINEX14HUBC402.southpacific.corp.microsoft.com ([157.60.220.216]) with mapi id 14.03.0146.002; Sun, 6 Oct 2013 16:16:36 +0000 From: Sourav Sain To: Dave Lawrence , Kumar Ashutosh Thread-Topic: [dnsext] Naked domain resolution with DNSSEC Thread-Index: Ac7ATe9x4lHsizWeS1mIFJsSspLh5AACqA0AAJVIAtA= Date: Sun, 6 Oct 2013 16:16:35 +0000 Message-ID: References: <21069.41000.63116.736893@gro.dd.org> In-Reply-To: <21069.41000.63116.736893@gro.dd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.3.99] 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:(13464003)(189002)(199002)(6806004)(44976005)(81342001)(83322001)(19580405001)(81686001)(4396001)(51856001)(74502001)(74662001)(47446002)(33656001)(31966008)(69226001)(16796002)(46102001)(54356001)(81816001)(85306002)(76796001)(47736001)(47976001)(76786001)(53806001)(50986001)(23726002)(56816003)(49866001)(77096001)(55846006)(83072001)(19580395003)(81542001)(1511001)(79102001)(56776001)(54316002)(76482001)(77982001)(59766001)(47776003)(74366001)(80976001)(46406003)(74706001)(63696002)(20776003)(50466002)(74876001)(65816001)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB207; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; 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: 0991CAB7B3 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com X-Mailman-Approved-At: Mon, 07 Oct 2013 07:52:29 -0700 Cc: "dnsext@ietf.org Group" , Sourav Sain Subject: Re: [dnsext] Naked domain resolution with DNSSEC 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, 06 Oct 2013 16:17:33 -0000 Hi Dave Presented below is a name resolution for "facebook.com, type=3DA". In the f= irst name resolution against "218.248.240.179" we see that "69.171.239.12#5= 3(a.ns.facebook.com)" ends up returning an A record for QName=3Dfacebook.co= m. Since COM is signed A record for facebook.com needs to have an RRSIG(A) = in the response, which, obviously is missing as a.ns.facebook.com cannot re= turn the signature for A using keys owned by COM. Our concern is, a securit= y aware validating server, having root or COM's Trust Anchor, will expect a= n RRSIG in the response for facebook.com, type=3DA, not having which, will = conclude the response as BOGUS. Regarding resolvers which lets the response PASS but with AD bit unset, ple= ase see the 2nd and 3rd name resolutions. In the 2nd name resolution, I hav= e tried to resolve "QName=3DCOM, QType=3DDS" and I can see that 8.8.8.8 res= ponds with "flags: qr rd ra ad; Hence the response is Authenticated Data. B= ut in the third name resolution for facebook.com, type=3DA, asking 8.8.8.8 = for validated responses, we do get the response but without "ad" in flags. = Shouldn't there be a Serv Fail in this case (third name resolution for "fac= ebook.com, type=3DA")? ---------------------------------------------------------------------------= ------------------------------- c:\dig\dig-files3>.\dig @218.248.240.179 facebook.com A +trace +dnssec ; <<>> DiG 9.3.2 <<>> @218.248.240.179 facebook.com A +trace +dnssec ; (1 server found) ;; global options: printcmd . 438113 IN NS j.root-servers.net. . 438113 IN NS f.root-servers.net. . 438113 IN NS c.root-servers.net. . 438113 IN NS a.root-servers.net. . 438113 IN NS m.root-servers.net. . 438113 IN NS l.root-servers.net. . 438113 IN NS i.root-servers.net. . 438113 IN NS d.root-servers.net. . 438113 IN NS h.root-servers.net. . 438113 IN NS g.root-servers.net. . 438113 IN NS k.root-servers.net. . 438113 IN NS b.root-servers.net. . 438113 IN NS e.root-servers.net. . 438113 IN RRSIG NS 8 0 518400 2013101000000= 0 20131002230000 59085 . J77jB7Y61aBLsNMii8XphtUr1OwjIlzgwVz2W7FFzf1Yh0gKp1= vyJ7G6 j9 MY3r/1TKEvOup6t/4Gnp4U32P8JP9FS6CzyoJYKOWCE8vSMekgcAr 4zwiBHfhhYndIJKJGpqpa= F0GwnubiEREyXG7c5n53CCMjRh6ZB5/2FN0 V7E=3D ;; Received 857 bytes from 218.248.240.179#53(218.248.240.179) in 172 ms com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73= 294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20131013000000= 20131005230000 59085 . BWF4iHvXMlOSY8AAhufgQuBOqt2kM7KRC5fnUJ14el+t75BKfas= 67coq luq MPJFiXb1ON6SidUE+asWVnVFcRU0FU+503+A/bhSvRcvtncKTSAA LOCd/68q6nvw1+mG3P3IDJ= VxDDEfBS3gpSctqZ73S1Y9dpSLhzjqhuY6 KYM=3D ;; Received 736 bytes from 192.58.128.30#53(j.root-servers.net) in 172 ms facebook.com. 172800 IN NS a.ns.facebook.com. facebook.com. 172800 IN NS b.ns.facebook.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN TYPE50 \# 35 010100000014650= 1B7E9587710CEFEFFBC49036905BE34AD22490007 22000000000290 CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG TYPE50 8 2 86400 20131= 013044124 20131006033124 8795 com. H3vUWw6JkfKMP0xebYmX3dZBrsFWew3z46qhsGw0= 4P+xTexV/ vlHu2e g8w3WUiPMmE8tf+BZsPp3ssV3Ptoybv1h6atVFmbndBg1KxEpBpEM3ui HbEXeC+tR9f= oRz9A7LnsTerG7OdEloyRKgHxRN+OkX4DLy3Q8tgj1XWl Fhs=3D I287JBU8MGU307S65H71L34A9JJD947E.com. 86400 IN TYPE50 \# 34 010100000014909= 129C805FD2BEE60532B8E319B6CDC0D7AF5660006 200000000012 I287JBU8MGU307S65H71L34A9JJD947E.com. 86400 IN RRSIG TYPE50 8 2 86400 20131= 013043923 20131006032923 8795 com. hOj0Qr4RA/BmXNPO0qQsLkg5GFHW8UrLdXctCNFR= gwYO9wK7O aSSBmm Zk4SKjqr8gWosPtwHJYKgSzuXacCUHIv/g8LOz3MliRstmMtJwWR2KXG GHk89e8EDO4= Hd1BjZsqiArXYmq3PZ1gyQjO6omHP1AtGbdJgTI8qC2+Z fWk=3D ;; Received 593 bytes from 192.12.94.30#53(e.gtld-servers.net) in 406 ms facebook.com. 900 IN A 173.252.110.27 facebook.com. 172800 IN NS a.ns.facebook.com. facebook.com. 172800 IN NS b.ns.facebook.com. ;; Received 124 bytes from 69.171.239.12#53(a.ns.facebook.com) in 641 ms ---------------------------------------------------------------------------= ------------------------------- c:\dig\dig-files3>.\dig @8.8.8.8 COM DS +dnssec ; <<>> DiG 9.3.2 <<>> @8.8.8.8 COM DS +dnssec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 932 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;COM. IN DS ;; ANSWER SECTION: COM. 19029 IN DS 30909 8 2 E2D3C916F6DEEAC73= 294E8268FB5885044A833FC5459588F4A9184CF C41A5766 COM. 19029 IN RRSIG DS 8 1 86400 20131013000000= 20131005230000 59085 . BWF4iHvXMlOSY8AAhufgQuBOqt2kM7KRC5fnUJ14el+t75BKfas= 67coq luqB MPJFiXb1ON6SidUE+asWVnVFcRU0FU+503+A/bhSvRcvtncKTSAA LOCd/68q6nvw1+mG3P3IDJ= VxDDEfBS3gpSctqZ73S1Y9dpSLhzjqhuY6 KYM=3D ;; Query time: 187 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sun Oct 06 19:58:11 2013 ;; MSG SIZE rcvd: 239 ---------------------------------------------------------------------------= ------------------------------- c:\dig\dig-files3>.\dig @8.8.8.8 facebook.com A +dnssec ; <<>> DiG 9.3.2 <<>> @8.8.8.8 facebook.com A +dnssec ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 367 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;facebook.com. IN A ;; ANSWER SECTION: facebook.com. 834 IN A 173.252.110.27 ;; Query time: 406 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sun Oct 06 19:58:26 2013 ;; MSG SIZE rcvd: 57 -----Original Message----- From: Dave Lawrence [mailto:tale@dd.org]=20 Sent: 03 October 2013 22:20 To: Kumar Ashutosh Cc: dnsext@ietf.org Group; Sourav Sain Subject: Re: [dnsext] Naked domain resolution with DNSSEC Kumar Ashutosh writes: > The resolver was expecting a signed response for everything under COM,=20 > gets an unsigned response and marks them as BOGUS and returns a=20 > SERV_FAIL Some resolvers, do let the response pass but with AD bit set=20 > to 0 which a DNSSEC aware end client may not accept. You've observed these behaviours? With which nameservers? From jim@rfc1035.com Mon Oct 7 08:21: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 AF48C11E80F1 for ; Mon, 7 Oct 2013 08:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODytZqjqaeRN for ; Mon, 7 Oct 2013 08:21:35 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id AD6A711E8100 for ; Mon, 7 Oct 2013 08:21:34 -0700 (PDT) Received: from [IPv6:2620::ce0:6:10b1:db3b:4718:5350] (unknown [IPv6:2620:0:ce0:6:10b1:db3b:4718:5350]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 54F39CBC41C; Mon, 7 Oct 2013 16:21:29 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jim Reid In-Reply-To: Date: Mon, 7 Oct 2013 16:21:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21069.41000.63116.736893@gro.dd.org> To: Sourav Sain X-Mailer: Apple Mail (2.1510) Cc: dnsext WG Group Subject: Re: [dnsext] Naked domain resolution with DNSSEC 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, 07 Oct 2013 15:21:36 -0000 On 6 Oct 2013, at 17:16, Sourav Sain wrote: > Our concern is, a security aware validating server, having root or = COM's Trust Anchor, will expect an RRSIG in the response for = facebook.com, type=3DA, not having which, will conclude the response as = BOGUS. Your concern would be valid if that was how DNSSEC works. But it = doesn't. facebook.com is not signed. The zone has no DNSKEYs or RRSIGs. = There are no DS records in .com for facebook.com either: hardly = surprising because facebook.com is not signed and has no key-signing = keys. A validating resolver would not expect to find an RRSIG for = facebook.com's A record RRset. It would not be able to validate that = RRSIG if it was present because the zone does not have signed = delegation. [Well, not unless it had some other out of band TA for = facebook.com.] It would know from the metadata in the .com zone that = facebook.com was not signed and continue to resolve names in that = domain, albeit without doing any validation. The answers that validating = resolver returned to its clients will have the AD (Authentic Data) bit = set in the DNS header to indicate if the answer had been sucessfully = validated or not validated at all. From tale@dd.org Mon Oct 7 10:33:25 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93DB11E80F2 for ; Mon, 7 Oct 2013 10:33:25 -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 ySpZO0VO9BuD for ; Mon, 7 Oct 2013 10:33:21 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5DC21F9F6F for ; Mon, 7 Oct 2013 10:33:21 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 136783F432; Mon, 7 Oct 2013 13:33:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21074.61535.976353.482373@gro.dd.org> Date: Mon, 7 Oct 2013 13:33:19 -0400 From: Dave Lawrence To: Sourav Sain In-Reply-To: References: <21069.41000.63116.736893@gro.dd.org> Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Naked domain resolution with DNSSEC 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, 07 Oct 2013 17:33:26 -0000 Sourav Sain writes: > Presented below is a name resolution for "facebook.com, type=A". In > the first name resolution against "218.248.240.179" we see that > "69.171.239.12#53(a.ns.facebook.com)" ends up returning an A record > for QName=facebook.com. Since COM is signed A record for facebook.com > needs to have an RRSIG(A) in the response, which, obviously is missing > as a.ns.facebook.com cannot return the signature for A using keys > owned by COM. Our concern is, a security aware validating server, > having root or COM's Trust Anchor, will expect an RRSIG in the > response for facebook.com, type=A, not having which, will conclude the > response as BOGUS. To expand a little on the answer that Jim Reid gave, it is important to remember the principle that for records at a zone cut, almost all records are authoritatively owned by the delegated zone, not the delegator. The only exception to this is the DS record. Therefore this sentence from above, and the crux of your problem, is not correct: > Since COM is signed A record for facebook.com needs to have an > RRSIG(A) in the response A properly written, standards-compliant validating resolver will recognize that when it originally asked the GTLD servers for facebook.com it got a provably insecure delegation to the facebook.com nameservers. Therefore it will know that all records within the zone, including those at the apex, will not come with signatures. From paul@nohats.ca Tue Oct 15 13:21:46 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 61A0111E8187 for ; Tue, 15 Oct 2013 13:21:46 -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 dvJ3np4FrjdP for ; Tue, 15 Oct 2013 13:21:41 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9C81911E8149 for ; Tue, 15 Oct 2013 13:21:41 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3czp270LP3zCBf for ; Tue, 15 Oct 2013 16:21: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 rhkg-RqdiHFf for ; Tue, 15 Oct 2013 16:21:34 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP for ; Tue, 15 Oct 2013 16:21:34 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id E547F807D0; Tue, 15 Oct 2013 16:21:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D97B18078B for ; Tue, 15 Oct 2013 16:21:34 -0400 (EDT) Date: Tue, 15 Oct 2013 16:21:34 -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-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:21:46 -0000 As discussed, I separated the EDNS TCP keep-alive option from the EDNS chain-query document, and Joe Abley kindly offered his assistance in (re)writing this document. Paul -------- Original Message -------- From: internet-drafts@ietf.org To: Paul Wouters , Joe Abley Subject: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt Date: Tue, 15 Oct 2013 09:39:54 -0700 A new version of I-D, draft-wouters-edns-tcp-keepalive-00.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Filename: draft-wouters-edns-tcp-keepalive Revision: 00 Title: The edns-tcp-keepalive EDNS0 Option Creation date: 2013-10-15 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-wouters-edns-tcp-keepalive-00.txt Status: http://datatracker.ietf.org/doc/draft-wouters-edns-tcp-keepalive Htmlized: http://tools.ietf.org/html/draft-wouters-edns-tcp-keepalive-00 Abstract: DNS messages between clients and servers may be received over either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients are currently limited in their use of the TCP transport as most implementations limit the TCP session to a single DNS query and answer, making use of TCP only suitable as a fallback protocol for UDP. This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS clients and servers to signal their respective readiness to conduct multiple DNS transactions over individual TCP sessions. This signalling facilitates a better balance of UDP and TCP transport between individual clients and servers, reducing the impact of problems associated with UDP transport and allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time. 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 paul@nohats.ca Tue Oct 15 13:24: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 2120F11E81E6 for ; Tue, 15 Oct 2013 13:24: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 Ffb95ZOT1BIG for ; Tue, 15 Oct 2013 13:24:32 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 288D511E8201 for ; Tue, 15 Oct 2013 13:24:30 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3czp5Q1dx2zCBf for ; Tue, 15 Oct 2013 16:24:26 -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 csNdSlKrJWWC for ; Tue, 15 Oct 2013 16:24:25 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP for ; Tue, 15 Oct 2013 16:24:25 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 4B800807D0; Tue, 15 Oct 2013 16:24:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3DB9E8078B for ; Tue, 15 Oct 2013 16:24:26 -0400 (EDT) Date: Tue, 15 Oct 2013 16:24:26 -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; format=flowed; charset=US-ASCII Subject: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-01.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:24:37 -0000 This is the 01 version for edns-tcp-chain-query-01 - Moved TCP Keep-alive into a separate document - Allow edns-tcp-chain-query discovery over UDP - Clarify CNAME / DNAME - Cleanup of text. Paul -------- Original Message -------- From: internet-drafts@ietf.org To: Paul Wouters Subject: New Version Notification for draft-wouters-edns-tcp-chain-query-01.txt Date: Tue, 15 Oct 2013 10:21:52 -0700 A new version of I-D, draft-wouters-edns-tcp-chain-query-01.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Filename: draft-wouters-edns-tcp-chain-query Revision: 01 Title: TCP chain query requests in DNS Creation date: 2013-10-15 Group: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-wouters-edns-tcp-chain-query-01.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-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-wouters-edns-tcp-chain-query-01 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. 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 jay@nzrs.net.nz Wed Oct 16 02:33:19 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 3064511E8178 for ; Wed, 16 Oct 2013 02:33:19 -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 qm-Lm+-UArWE for ; Wed, 16 Oct 2013 02:33: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 8AEAF21F9E01 for ; Wed, 16 Oct 2013 02:33:14 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id BD2304B80FA for ; Wed, 16 Oct 2013 22:33:12 +1300 (NZDT) 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 7oQ10CcAW1P5 for ; Wed, 16 Oct 2013 22:33:04 +1300 (NZDT) Received: from [192.168.1.230] (121-74-114-181.telstraclear.net [121.74.114.181]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id B740F4B80E5 for ; Wed, 16 Oct 2013 22:33:04 +1300 (NZDT) From: Jay Daley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 16 Oct 2013 22:33:03 +1300 To: "dnsext@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 09:33:19 -0000 =46rom my previous post on my draft for a new DNS opcode - servezones - = I think there is reasonable interest in an in-band mechanism that = instructs a nameserver to etiher start or stop serving one or more = zones. The area with less certainty is what that mechanism should be, a = new Opcode (but it's only a 4 bit space!) or extending UPDATE. I'm planing to write a draft that shows how UPDATE could be extended to = do this and then we can compare that with my servezones draft and see = which is preferred. To do that I'd like some help in determining the = algorithm for how the extended UPDATE is processed.=20 Here's my starter for 10. 1. A new EDNS option code is assigned that changes the behaviour of the = UPDATE as follows (alternatively this could be signalled with a ZTYPE = different from SOA) 2. The ZONE section specifies the zones to be added/removed. There can = be any number of zones listed here to add or remove. For each zone, if = the CLASS is ANY then the zone is to be removed, whereas if it is ANY = then the zone is to be added. This use of CLASS corresponds to the way = that it is used to determine if an rrset should be added or removed in = the current UPDATE message. 3. The pre-requisite section is ignored. 4. The Update section can only contain Adds and only when zones are to = be added. If any records are specified here then that means that the = zones to be added are masters and these records are all added to those = zones before serving begin. None of these records may be fully = qualified so as to ensure that they apply to all the zones listed. One = of these records must be a SOA record with an empty name, which will be = replaced with the zone name 5. If there is data in the Additional section then that signifies that = the zones to be added are slaves. The records here must be NS records = that specify the masters for the zones to be added. There can only be = records here or in the Update section but not both as zones cannot be = both masters and slaves. Is that it? Anything need changing? BTW we could extend this just a little bit more: 6. If there is a DNSKEY record in the Additional section then this = specifies a TSIG key that this server should use for pulling the zone. = The name for the DNSKEY record is the name of the key as used by TSIG. = This DNSKEY is not added into the zone. Jay --=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 ietf@rozanak.com Wed Oct 16 02:40:59 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 63C4E11E8169 for ; Wed, 16 Oct 2013 02:40:59 -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 7bq1Lv4sbluc for ; Wed, 16 Oct 2013 02:40:53 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1966F21F9CA9 for ; Wed, 16 Oct 2013 02:40:47 -0700 (PDT) Received: from kopoli ([141.89.226.146]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Ln8L7-1VyG9c1GpB-00hq8w; Wed, 16 Oct 2013 05:40:44 -0400 From: "Hosnieh Rafiee" To: "'Jay Daley'" , References: In-Reply-To: Date: Wed, 16 Oct 2013 11:40:35 +0200 Message-ID: <001a01ceca53$c6fb3010$54f19030$@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: AQNPbtY7r0spbIykxCLUUtreV80m/Zb1yVOQ Content-Language: en-us X-Provags-ID: V02:K0:Mv8duEM9y/PZWgvWGNoSrPoFgEAAp9uDXB9/Pl2krZr d7ZViE5SvUGaGWQUcb5Ox4eDoCQVt4u4dJM+9cOhU3es/29cX9 l+6XNU24JI3s8OjJxF41bF4yvuEVmWykCkAhgr5zkkFC/+EJJx snOOhtAbQNxfJdJA+pUXtTlUyYkM3CVyxNcJ6p3fiy13JQUcgp c75ZSi8yRTvMNzIlN27fwjMy2yldAfEly+fO8T8uCUwhfA675N 4xhdFz9tkk1XLsZ8+eddrBtsKEXHS14+GsEB986Y3l7mr3h1tE dhbxlCSohAZECpEhdYyriGVVawTpXz0XR/5uXIoPgNdTPGFaEq 3U4zcNSln5cd+lsVHnks= Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 09:40:59 -0000 >6. If there is a DNSKEY record in the Additional section then this specifies a TSIG key that this server should use for pulling the zone. The name for the DNSKEY record is the name of the key as used by TSIG. This DNSKEY is not added into the zone. I have a question. What would you do with the other algorithms of TSIG that only use TSIG as an option and is quite different than original TSIG? Such as cga-tsig. Thanks, Hosnieh From jay@nzrs.net.nz Wed Oct 16 02:52:00 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 87E2821F9D12 for ; Wed, 16 Oct 2013 02:52:00 -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 F-s3zoEfKWMW for ; Wed, 16 Oct 2013 02:51:56 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id AB29511E8177 for ; Wed, 16 Oct 2013 02:51:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 5F8044B80FA; Wed, 16 Oct 2013 22:51:53 +1300 (NZDT) 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 kpB1oepXObIV; Wed, 16 Oct 2013 22:51:45 +1300 (NZDT) Received: from [192.168.1.230] (121-74-114-181.telstraclear.net [121.74.114.181]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 958024B80F9; Wed, 16 Oct 2013 22:51:45 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: <001a01ceca53$c6fb3010$54f19030$@rozanak.com> Date: Wed, 16 Oct 2013 22:51:45 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <3DFAFF6B-E090-4276-8025-C5FF52C529D5@nzrs.net.nz> References: <001a01ceca53$c6fb3010$54f19030$@rozanak.com> To: "Hosnieh Rafiee" X-Mailer: Apple Mail (2.1510) Cc: dnsext@ietf.org Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 09:52:00 -0000 On 16/10/2013, at 10:40 PM, "Hosnieh Rafiee" wrote: > I have a question. What would you do with the other algorithms of TSIG = that > only use TSIG as an option and is quite different than original TSIG? = Such > as cga-tsig. I'm not sure how that is relevant - perhaps you could explain? And to = answer your question - I have no idea at all. Jay >=20 > Thanks, > Hosnieh >=20 --=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 gson@araneus.fi Wed Oct 16 03:30: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 7596311E8167 for ; Wed, 16 Oct 2013 03:30: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 ebtpyHyB1hb6 for ; Wed, 16 Oct 2013 03:30:41 -0700 (PDT) Received: from guffaw.gson.org (guffaw.gson.org [83.246.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFCC21F9C60 for ; Wed, 16 Oct 2013 03:30:35 -0700 (PDT) Received: from guava.gson.org (unknown [10.0.1.148]) by guffaw.gson.org (Postfix) with ESMTP id B521634019; Wed, 16 Oct 2013 10:30:30 +0000 (UTC) Received: by guava.gson.org (Postfix, from userid 101) id 641CF75E4E; Wed, 16 Oct 2013 13:30:33 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21086.27336.914845.852272@guava.gson.org> Date: Wed, 16 Oct 2013 13:30:32 +0300 To: Jay Daley In-Reply-To: References: X-Mailer: VM 8.0.14 under 21.4.1 (i386--netbsdelf) From: Andreas Gustafsson Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 10:30:57 -0000 A couple of comments, without taking sides for or against the general idea: > For each zone, if the CLASS is ANY then the zone is to be removed, > whereas if it is ANY then the zone is to be added. Presumably the latter "is ANY" should read "is not ANY". > None of these records may be fully qualified so as to ensure that > they apply to all the zones listed. There is no way to encode that in the DNS protocol. All names are fully qualified on the wire; relative names are merely a convenience notation used in master files and other user interfaces. -- Andreas Gustafsson, gson@araneus.fi From fanf2@hermes.cam.ac.uk Wed Oct 16 04:40: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 C297121F9C78 for ; Wed, 16 Oct 2013 04:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLsOYfj0Q4zR for ; Wed, 16 Oct 2013 04:40:33 -0700 (PDT) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA2D21F9C53 for ; Wed, 16 Oct 2013 04:40:30 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:34525) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1VWPSm-0008Is-6t (Exim 4.80_167-5a66dd3) (return-path ); Wed, 16 Oct 2013 12:40:28 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VWPSm-0002K7-2o (Exim 4.72) (return-path ); Wed, 16 Oct 2013 12:40:28 +0100 Date: Wed, 16 Oct 2013 12:40:28 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Wouters In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 11:40:34 -0000 I think it should be made clear that it is fine for clients to use TCP keepalive without this spec, and servers must support that. (This is particularly handy for asynchronous bulk DNS lookups with software like adns which uses at most two sockets.) My understanding is what this spec is supposed to do is to (1) allow servers to close TCP connections more aggressively than RFC 1035 says, and (2) signal to clients how long they can expect idle connections to last. I think (1) should be allowed regardless of any explicit signalling. Section 3.2.2: Use by DNS Clients - Receiving Responses A DNS client that receives a response using TCP transport that includes the edns-tcp-keepalive option MAY keep the existing TCP session open. I would prefer this to say: A DNS client that receives a response using TCP transport MAY keep the existing TCP session open whether or not the response includes the edns-tcp-keepalive option. A DNS client that receives a response using TCP transport that includes the edns-tcp-keepalive option SHOULD close an idle connection within the period given in the TIMEOUT value. The idea in this second paragraph is to encourage clients to take care of the connection's FIN-WAIT-2 state. Section 3.3.2: Use by DNS Servers - Sending Responses This section is problematic. Absence of a edns-tcp-keepalive option should not imply that keepalive is not allowed, since that is an incompatible change to existing requirements. I think it would be better if no keepalive were signalled with a edns-tcp-keepalive timeout of zero, and indefinite keepalive by omitting the option (since this is an undefined timeout not an infinite one, because infinite is impossible). Even if the timeout is zero this should still be an *idle* timeout, and we should keep the RFC 1035 requirement that the server "should delay closing its end of the connection until all outstanding client requests have been satisfied." Perhaps there is an opportunity to allow servers to kill active connections: a TIMEOUT value of zero could mean "this is the last response on this connection; gotta close it. if you were expecting any more responses they have been discarded, sorry!". But my guess is that aggressively closing active TCP connections will lead to increased load because of connection thrashing. So I suggest deleting the last paragraph of section 3.2.2, which describes how clients should interpret a zero timeout, and I suggest the following text to replace the whole of section 3.3.2: The existing DNS specifications state that DNS servers MUST support multiple DNS transactions on a single TCP connection. They MAY close idle connections, but they SHOULD NOT close the connection until all client requests have been satisfied. DNS servers MAY include the edns-tcp-keepalive option in responses sent using UDP transport to indicate to the client the TIMEOUT value it might expect if it was to open a TCP session with the server and receive a response with the edns-tcp-keepalive option present. DNS servers MAY include the edns-tcp-keepalive option in responses sent using TCP transport to signal how long they are willing to keep idle connections open. Servers MUST specify the TIMEOUT value that is currently associated with the TCP session. It is reasonable for this value to change according to local resource constraints. The DNS server can set the TIMEOUT value to zero to indicate that it intends to close the connection as soon as there are no more outstanding requests. Section 3.6: Anycast Considerations This seems excessively pessimistic about the stability of anycast routing. It works OK for HTTP, so why not DNS over TCP? A short TIMEOUT should be fine. Section 4: Security Considerations This is nonsense! The edns-tcp-keepalive option makes no difference to the ability of clients to make large numbers of concurrent requests. I think this section could discuss points like: * Good: this spec explicitly allows servers to close connections more aggressively in order to avoid resource exhaustion, which improves the availability of servers in overload situations. * Risk: servers and clients must not treat timeout values as strong commitments - the server is always allowed to close connections early to reclaim resources. * Risk: closing connections too early may lead to connection thrashing which may increase load * Risk: servers that close connections have to keep a TCP control block in memory to keep track of the FIN-WAIT-2 period, so it is generally preferable for the client to close the connection and handle FIN-WAIT-2. Good: this spec gives clients a clear indication of when they should close connections. * Advice: perhaps there should be something about the extra memory resources used by tcp connection buffers. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From tale@dd.org Wed Oct 16 07:19: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 D16B121F9967 for ; Wed, 16 Oct 2013 07:19: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=[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 k2+QczdQT2IH for ; Wed, 16 Oct 2013 07:19:06 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by ietfa.amsl.com (Postfix) with ESMTP id B33C911E81D3 for ; Wed, 16 Oct 2013 07:19:04 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 71F753F438; Wed, 16 Oct 2013 10:19:03 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21086.41047.339006.724108@gro.dd.org> Date: Wed, 16 Oct 2013 10:19:03 -0400 From: Dave Lawrence To: Andreas Gustafsson In-Reply-To: <21086.27336.914845.852272@guava.gson.org> References: <21086.27336.914845.852272@guava.gson.org> Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 14:19:11 -0000 Andreas Gustafsson writes: > > None of these records may be fully qualified so as to ensure that > > they apply to all the zones listed. > > There is no way to encode that in the DNS protocol. All names are > fully qualified on the wire; relative names are merely a convenience > notation used in master files and other user interfaces. Well sure there is, you declare "in this special type of message, all of the records in the update section are relative to the zones in the zone section." I inferred the original intent was to be able to add a block of zones all with the same template. Personally I think that's a bad idea, or at the least underspecified in the original description -- does this concept apply only to owner names, or names within rdata as well? It seems like a premature optimization though, and puts too many eggs in one basket. Just using separate messages for each zone with everything fully-qualified does not seem like onerous overhead to me. From paul@nohats.ca Wed Oct 16 08:05:54 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 57ED711E8138 for ; Wed, 16 Oct 2013 08:05:54 -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 hmfvMuV71Nb2 for ; Wed, 16 Oct 2013 08:05:48 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id C52BA21F9DCF for ; Wed, 16 Oct 2013 08:05:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d0GzF41Lxz3dx; Wed, 16 Oct 2013 11:05:45 -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 G207jFlySQJr; Wed, 16 Oct 2013 11:05:39 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 16 Oct 2013 11:05:39 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 25E47807D0; Wed, 16 Oct 2013 11:05:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 18C3B8078B; Wed, 16 Oct 2013 11:05:37 -0400 (EDT) Date: Wed, 16 Oct 2013 11:05:37 -0400 (EDT) From: Paul Wouters To: Tony Finch 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-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:05:54 -0000 On Wed, 16 Oct 2013, Tony Finch wrote: > I think it should be made clear that it is fine for clients to use TCP > keepalive without this spec, and servers must support that. (This is > particularly handy for asynchronous bulk DNS lookups with software like > adns which uses at most two sockets.) My understanding is what this spec > is supposed to do is to (1) allow servers to close TCP connections more > aggressively than RFC 1035 says, and (2) signal to clients how long they > can expect idle connections to last. I think (1) should be allowed > regardless of any explicit signalling. Historically, DNS transactions over TCP only handle 1 query/answer. That's not what the specification was supposed to mean, but that's what it has become in practise. Joe and I therefor thought it would be best to leave that existing deployment as-is, and use a new option to clearly unambiguously indicate that yes we will actually allow more than one query and actively encourage it. That was our number one goal. So while we don't disagree with you that implementators could fix that, we thought it would be error prone to change that. It would be impossible to distinguish between old unpatched DNS software and new patched DNS software. This new option makes it abundantly clear. It avoids mismatched expectations between DNS clients and DNS servers. And while doing so, allows us to warn DNS clients about idle TCP connections, as we expect that a lot of load balances would interfere with long outstanding TCP sessions that would require a special signal to the DNS clients not to linger too long. We will look at your proposed changes, especially the security section ones, and merge in what seems appropriate. But unless I hear more people who would favour making the new option more "optional" I think we should stick to this more clear cut of the undefined past behaviour. Paul From Bob.Halley@nominum.com Wed Oct 16 08:08:40 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 1349611E82B2 for ; Wed, 16 Oct 2013 08:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkrAp2ZoJ43K for ; Wed, 16 Oct 2013 08:08:30 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id E82CF11E8260 for ; Wed, 16 Oct 2013 08:08:26 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUl6r5G5X8B7Y0AWHfqaQOGRhPJU7x4jQ@postini.com; Wed, 16 Oct 2013 08:08:27 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8D40F1B82B6 for ; Wed, 16 Oct 2013 08:08:15 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 870C419005C; Wed, 16 Oct 2013 08:08:15 -0700 (PDT) (envelope-from Bob.Halley@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.03.0158.001; Wed, 16 Oct 2013 08:08:09 -0700 From: Bob Halley To: Dave Lawrence , Andreas Gustafsson Thread-Topic: [dnsext] Extending UPDATE to add/remove zones Thread-Index: AQHOylLD9TIUC8efkka6H41oJN88X5n3li4AgAA/2YD//5hdgA== Date: Wed, 16 Oct 2013 15:08:09 +0000 Message-ID: In-Reply-To: <21086.41047.339006.724108@gro.dd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 15:08:40 -0000 T24gMTAvMTYvMTMsIDc6MTksICJEYXZlIExhd3JlbmNlIiA8dGFsZUBkZC5vcmc+IHdyb3RlOg0K DQo+QW5kcmVhcyBHdXN0YWZzc29uIHdyaXRlczoNCj4+ID4gIE5vbmUgb2YgdGhlc2UgcmVjb3Jk cyBtYXkgYmUgZnVsbHkgcXVhbGlmaWVkIHNvIGFzIHRvIGVuc3VyZSB0aGF0DQo+PiA+ICB0aGV5 IGFwcGx5IHRvIGFsbCB0aGUgem9uZXMgbGlzdGVkLg0KPj4gDQo+PiBUaGVyZSBpcyBubyB3YXkg dG8gZW5jb2RlIHRoYXQgaW4gdGhlIEROUyBwcm90b2NvbC4gIEFsbCBuYW1lcyBhcmUNCj4+IGZ1 bGx5IHF1YWxpZmllZCBvbiB0aGUgd2lyZTsgcmVsYXRpdmUgbmFtZXMgYXJlIG1lcmVseSBhIGNv bnZlbmllbmNlDQo+PiBub3RhdGlvbiB1c2VkIGluIG1hc3RlciBmaWxlcyBhbmQgb3RoZXIgdXNl ciBpbnRlcmZhY2VzLg0KPg0KPldlbGwgc3VyZSB0aGVyZSBpcywgeW91IGRlY2xhcmUgImluIHRo aXMgc3BlY2lhbCB0eXBlIG9mIG1lc3NhZ2UsIGFsbA0KPm9mIHRoZSByZWNvcmRzIGluIHRoZSB1 cGRhdGUgc2VjdGlvbiBhcmUgcmVsYXRpdmUgdG8gdGhlIHpvbmVzIGluIHRoZQ0KPnpvbmUgc2Vj dGlvbi4iICBJIGluZmVycmVkIHRoZSBvcmlnaW5hbCBpbnRlbnQgd2FzIHRvIGJlIGFibGUgdG8g YWRkIGENCj5ibG9jayBvZiB6b25lcyBhbGwgd2l0aCB0aGUgc2FtZSB0ZW1wbGF0ZS4NCg0KV2hp bGUgaXQgd291bGQgYmUgcG9zc2libGUgdG8gaW50ZXJwcmV0IEZRRE5zIGFzIHJvb3RlZCBhdCBz b21lIG90aGVyIHJvb3QNCml0J3Mgbm90IGEgZ29vZCBzb2x1dGlvbiBiZWNhdXNlIHRoZW4gdGhl cmUncyBubyB3YXkgZm9yIHRoZSBkYXRhIGluIHRoZQ0KdXBkYXRlIHNlY3Rpb24gdG8gcmVmZXIg dG8gc29tZXRoaW5nIG91dCBvZiB0aGUgem9uZS4gIFRoYXQncyBPSyBmb3Igb3duZXINCm5hbWVz LCBidXQgaXQncyBub3QgT0sgZm9yIG5hbWVzIGluIHJkYXRhLCBlLmcuIHRoZSB0YXJnZXQgb2Yg YSBDTkFNRS4NClpvbmUgdGVtcGxhdGluZyByZXF1aXJlcyB0aGUgYWJpbGl0eSB0byBzcGVjaWZ5 IGJvdGggcmVsYXRpdmUgYW5kIGFic29sdXRlDQpuYW1lcywgYW5kIHJlbGF0aXZlIG5hbWVzIGFy ZSBub3QgY3VycmVudGx5IHJlcHJlc2VudGFibGUgaW4gdGhlIEROUw0KcHJvdG9jb2wuDQoNCi9C b2INCg0KDQoNCg== From derek@ihtfp.com Wed Oct 16 10:24:30 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 317F421F8EB2 for ; Wed, 16 Oct 2013 10:24:28 -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 nu7Da+YvxZLy for ; Wed, 16 Oct 2013 10:24:26 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 76D5B11E82B4 for ; Wed, 16 Oct 2013 10:24:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 63EFA260230; Wed, 16 Oct 2013 13:24:00 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 14233-06; Wed, 16 Oct 2013 13:23:58 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 18F83260226; Wed, 16 Oct 2013 13:23:58 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.5/Submit) id r9GHNvjP021473; Wed, 16 Oct 2013 13:23:57 -0400 From: Derek Atkins To: Jay Daley References: Date: Wed, 16 Oct 2013 13:23:56 -0400 In-Reply-To: (Jay Daley's message of "Wed, 16 Oct 2013 22:33:03 +1300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a X-Mailman-Approved-At: Wed, 16 Oct 2013 10:30:31 -0700 Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 17:24:30 -0000 Hi, Jay Daley writes: >>From my previous post on my draft for a new DNS opcode - servezones - > I think there is reasonable interest in an in-band mechanism that > instructs a nameserver to etiher start or stop serving one or more > zones. The area with less certainty is what that mechanism should be, > a new Opcode (but it's only a 4 bit space!) or extending UPDATE. > > I'm planing to write a draft that shows how UPDATE could be extended > to do this and then we can compare that with my servezones draft and > see which is preferred. To do that I'd like some help in determining > the algorithm for how the extended UPDATE is processed. [snip] I admit I haven't read the whole draft, but my question is how do you authenticate and, more importantly, authorize the addition or (worse) deletion of zones? Imagine an attack vector where someone could get your domain's DNS servers to stop serving your domain(s)! I think the security of adding and (more importantly) removing zones should be carefully documented and discussed. > Jay -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From alex@alex.org.uk Wed Oct 16 11:18: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 B4C5011E82CF for ; Wed, 16 Oct 2013 11:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhEiXOtnT+mv for ; Wed, 16 Oct 2013 11:18:05 -0700 (PDT) Received: from mail.avalus.com (mail.avalus.com [IPv6:2001:41c8:10:1dd::10]) by ietfa.amsl.com (Postfix) with ESMTP id 73F1111E82AA for ; Wed, 16 Oct 2013 11:18:03 -0700 (PDT) Received: by mail.avalus.com (Postfix) with ESMTPSA id 7DF2032A6001; Wed, 16 Oct 2013 19:17:50 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Alex Bligh In-Reply-To: Date: Wed, 16 Oct 2013 19:17:50 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1D9E3C41-0632-4FBE-9564-6CE8FB34AEA4@alex.org.uk> References: To: Derek Atkins X-Mailer: Apple Mail (2.1085) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 18:18:05 -0000 On 16 Oct 2013, at 18:23, Derek Atkins wrote: > I admit I haven't read the whole draft, but my question is how do you > authenticate and, more importantly, authorize the addition or (worse) > deletion of zones? Imagine an attack vector where someone could get > your domain's DNS servers to stop serving your domain(s)! > > I think the security of adding and (more importantly) removing zones > should be carefully documented and discussed. I'm not sure why this would be different from someone doing an update to remove the entire content of the zone served. Thus I don't really see why it should need security any different from the existing provisions for security. -- Alex Bligh From jay@nzrs.net.nz Wed Oct 16 13:27:25 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CC411E82D9 for ; Wed, 16 Oct 2013 13:27:25 -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 DUnvV8Vby1c7 for ; Wed, 16 Oct 2013 13:27:21 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 55EBC11E820B for ; Wed, 16 Oct 2013 13:27:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 07DCD4B251A for ; Thu, 17 Oct 2013 09:27:20 +1300 (NZDT) 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 8XGvGwdocpSr for ; Thu, 17 Oct 2013 09:27:12 +1300 (NZDT) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 7BFC44B4072 for ; Thu, 17 Oct 2013 09:27:12 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: Date: Thu, 17 Oct 2013 09:00:20 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> References: To: "dnsext@ietf.org Group" X-Mailer: Apple Mail (2.1510) Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 20:27:26 -0000 Thanks to all those that replied. I've summarised and responded to the = points below: 1. The restriction on FQDNs is too complex and there's no problem with = provisioning multiple zones in multiple packets. I agree and I'll change it so that only one master can be added per = update. I was indeed thinking about zone templating and that's not a = DNS issue.=20 2. Clarify what the ZCLASS needs to be set to. ZCLASS =3D=3D ANY means delete, ZCLASS !=3D ANY means add. 3. There is a substantial security risk here that needs to be = addressed. I agree. Both zone transfer and dynamic updates have security added = over the top through IP address restriction and/or TSIG and I think the = same approach should be taken here of identifying the security issue and = recommending over the top security but not requiring any. It would also = be useful to state that implementors must support TSIG for this and must = not turn it on by default. One more question - do we really need an EDNS option code as we could do = it all by the ZTYPE + ZCLASS without breaking anything: ZTYPE =3D=3D SOA and ZCLASS !=3D ANY means update an existing = zone ZTYPE =3D=3D NS and ZCLASS !=3D ANY means add an existing zone ZTYPE =3D=3D NS and ZCLASS =3D ANY means delete an existing zone Any thoughts? Jay --=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 marka@isc.org Wed Oct 16 13:48:42 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 908B611E81A7 for ; Wed, 16 Oct 2013 13:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, 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 z9m1ObBJmQIe for ; Wed, 16 Oct 2013 13:48:37 -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 AE2E711E8303 for ; Wed, 16 Oct 2013 13:47:45 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 2D5B7C94EF; Wed, 16 Oct 2013 20:47:31 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1381956465; bh=38TXy6iypmo6LqoSRd0mQT1QtBJ56D1+fAAH2ehqWpU=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=M7wePBLmXVY43RsiKIeesfNP8bEqeVw0+wctOCjEHn8s4GbK8PUo7IgG01NTqKMpk VEFAAaQ0ywabbayiKrLvOn79ICDPG7s9aw3Ow5VtVSyoiVhi6QAmdvVhz/bIRCR0g7 4YV0m/PhLwg60116y3CTDVQ3/nsz2sMnIJPuYQek= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 16 Oct 2013 20:47:31 +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 B35DB160470; Wed, 16 Oct 2013 20:51:47 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 8490B160449; Wed, 16 Oct 2013 20:51:47 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 3116B848699; Thu, 17 Oct 2013 07:47:28 +1100 (EST) To: Jay Daley From: Mark Andrews References: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> In-reply-to: Your message of "Thu, 17 Oct 2013 09:00:20 +1300." <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> Date: Thu, 17 Oct 2013 07:47:28 +1100 Message-Id: <20131016204728.3116B848699@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 20:48:42 -0000 In message <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz>, Jay Daley writes : > Thanks to all those that replied. I've summarised and responded to the point > s below: > > > 1. The restriction on FQDNs is too complex and there's no problem with provi > sioning multiple zones in multiple packets. > > I agree and I'll change it so that only one master can be added per update. > I was indeed thinking about zone templating and that's not a DNS issue. > > > 2. Clarify what the ZCLASS needs to be set to. > > ZCLASS == ANY means delete, ZCLASS != ANY means add. If you have example.net/in and example.net/hs which example.net are you referring to with example.net/any? 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 Wed Oct 16 13:50:58 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B903521F9E1A for ; Wed, 16 Oct 2013 13:50:58 -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 a9cK6jZ-D87t for ; Wed, 16 Oct 2013 13:50:54 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 51C0121F9CA8 for ; Wed, 16 Oct 2013 13:50:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id B8E834B586D; Thu, 17 Oct 2013 09:50:40 +1300 (NZDT) 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 5otj7UmK7sVu; Thu, 17 Oct 2013 09:50:33 +1300 (NZDT) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 2F8344B4072; Thu, 17 Oct 2013 09:50:33 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: <20131016204728.3116B848699@rock.dv.isc.org> Date: Thu, 17 Oct 2013 09:50:32 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz> References: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> <20131016204728.3116B848699@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1510) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 20:50:58 -0000 On 17/10/2013, at 9:47 AM, Mark Andrews wrote: >=20 > In message <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz>, Jay = Daley writes > : >> Thanks to all those that replied. I've summarised and responded to = the point >> s below: >>=20 >>=20 >> 1. The restriction on FQDNs is too complex and there's no problem = with provi >> sioning multiple zones in multiple packets. >>=20 >> I agree and I'll change it so that only one master can be added per = update. =20 >> I was indeed thinking about zone templating and that's not a DNS = issue.=20 >>=20 >>=20 >> 2. Clarify what the ZCLASS needs to be set to. >>=20 >> ZCLASS =3D=3D ANY means delete, ZCLASS !=3D ANY means add. >=20 > If you have example.net/in and example.net/hs which example.net are = you > referring to with example.net/any? We've already got that problem: In UPDATE as it currently exists if you have two different RRs of the = same type and different class in the same zone then which is being = referred to with CLASS =3D=3D ANY ? Jay >=20 > Mark > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org --=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 marka@isc.org Wed Oct 16 14:09:14 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 59BC011E8160 for ; Wed, 16 Oct 2013 14:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 8bKIYjN96SDW for ; Wed, 16 Oct 2013 14:09:09 -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 D238011E8166 for ; Wed, 16 Oct 2013 14:09:02 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B59A1C94F8; Wed, 16 Oct 2013 21:08:48 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1381957742; bh=dM7RD7RH6xzJXR0cpY7lpcH04gxZwhYJYRX+iY8qxZo=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=VG/CLfREhVNzwMno6ZKTUslrOXk/3AJHlYNZXepJokaMohrQdAbbS72zbyMiGiMOZ InqKJg3pBePJEraMuVEHxtW90cMyePG13SalCxlf4o7ENLCHxwvcFF6D0BjxzlljCA VetxcEQiErpg0FZ1ejIimjU2PohVLWrXR4jfC5Yk= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 16 Oct 2013 21:08:48 +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 5870F160470; Wed, 16 Oct 2013 21:13:05 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 29F30160449; Wed, 16 Oct 2013 21:13:05 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 604B78489A9; Thu, 17 Oct 2013 08:08:46 +1100 (EST) To: Jay Daley From: Mark Andrews References: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> <20131016204728.3116B848699@rock.dv.isc.org> <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz> In-reply-to: Your message of "Thu, 17 Oct 2013 09:50:32 +1300." <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz> Date: Thu, 17 Oct 2013 08:08:46 +1100 Message-Id: <20131016210846.604B78489A9@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 21:09:14 -0000 In message <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz>, Jay Daley writes : > > On 17/10/2013, at 9:47 AM, Mark Andrews wrote: > > > > > In message <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz>, Jay > Daley writes > > : > >> Thanks to all those that replied. I've summarised and responded to > the point > >> s below: > >> > >> > >> 1. The restriction on FQDNs is too complex and there's no problem > with provi > >> sioning multiple zones in multiple packets. > >> > >> I agree and I'll change it so that only one master can be added per > update. > >> I was indeed thinking about zone templating and that's not a DNS > issue. > >> > >> > >> 2. Clarify what the ZCLASS needs to be set to. > >> > >> ZCLASS == ANY means delete, ZCLASS != ANY means add. > > > > If you have example.net/in and example.net/hs which example.net are you > > referring to with example.net/any? > > We've already got that problem: > > In UPDATE as it currently exists if you have two different RRs of the > same type and different class in the same zone then which is being > referred to with CLASS == ANY ? A zone, by definition, only contains records of a single class. The zone section specify the class of the zone being operated on. Zone: example.net IN SOA Update: example.net ANY TXT Says delete all example.net IN TXT records. > Jay > > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > -- > 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 > -- 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 Wed Oct 16 14:31: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 554E811E81D7 for ; Wed, 16 Oct 2013 14:31: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 4z+t2pi62oPF for ; Wed, 16 Oct 2013 14:31:32 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id B2AF611E8186 for ; Wed, 16 Oct 2013 14:31:25 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id E2F824B4173; Thu, 17 Oct 2013 10:31:18 +1300 (NZDT) 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 HfkbOTTyfGsU; Thu, 17 Oct 2013 10:31:11 +1300 (NZDT) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 53B794B5766; Thu, 17 Oct 2013 10:31:11 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: <20131016210846.604B78489A9@rock.dv.isc.org> Date: Thu, 17 Oct 2013 10:31:11 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz> References: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> <20131016204728.3116B848699@rock.dv.isc.org> <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz> <20131016210846.604B78489A9@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1510) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 21:31:37 -0000 On 17/10/2013, at 10:08 AM, Mark Andrews wrote: > A zone, by definition, only contains records of a single class. It's not that I doubt you but can you provide a reference to that so = that I can if there is any wriggle room there? And what would your solution be to signifying that a zone is to be = deleted? Without one we have to abandon extending UPDATE and burn an = opcode. Jay --=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 ietf@rozanak.com Wed Oct 16 14:36:49 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A9C11E8137 for ; Wed, 16 Oct 2013 14:36:49 -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 Y1tqUlUZI10D for ; Wed, 16 Oct 2013 14:36:45 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5986711E81F0 for ; Wed, 16 Oct 2013 14:36:39 -0700 (PDT) Received: from kopoli (e179165194.adsl.alicedsl.de [85.179.165.194]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MeyZt-1V8BK82MTB-00OXRi; Wed, 16 Oct 2013 17:36:08 -0400 From: "Hosnieh Rafiee" To: "'Jay Daley'" References: <001a01ceca53$c6fb3010$54f19030$@rozanak.com> <3DFAFF6B-E090-4276-8025-C5FF52C529D5@nzrs.net.nz> In-Reply-To: <3DFAFF6B-E090-4276-8025-C5FF52C529D5@nzrs.net.nz> Date: Wed, 16 Oct 2013 23:35:59 +0200 Message-ID: <000001cecab7$b7bf0c20$273d2460$@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: AQNPbtY7r0spbIykxCLUUtreV80m/QK2S9e9Aa9gewWW02IhsA== Content-Language: en-us X-Provags-ID: V02:K0:ynNulRCI1qumbWFaQ5o8CtteF7q2341iUjbMVuRRwU2 VmUrzRaJeX5USqs4FjURoZ2HNEA5EErC6pi7CcHwesYJT3g3kV D6zy/cAibPNnLXcNwZf125PqGIQ0XXULGk+suUZiJ85AWQmRo3 7M+qUyREjDwkVEYMnrXjKzdFU040/sHKSKE1M85BG2JxodHSeQ Ns2m/xbyBiwPoZJZU9Ggx0CEXXBvmGNi7zb4o3zs2ZbT3nBWXI enAOeePDSz+6jAsa9v3D3ff28w7KGPXlJenaEnYkFI6S0vxz3P bxjeehL52nwoXt+pY8VfI6PHGQpW+uH1OhseI+AI5BZjKeXbP+ 97pTgisWdUR3C1nHqAvk= Cc: dnsext@ietf.org Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 21:36:49 -0000 >I'm not sure how that is relevant - perhaps you could explain? And to answer your question - I have no idea at all. Cga-tsig addresses secure authentication during different scenarios such as FQDN, zone transfer, resolver to client, resolver to authoritative servers, etc. It uses cga parameters as a means for this authentication. CGA proves the address ownership of nodes by finding a binding between the nodes' public key and its iP address. Cga-tsig adds cga parameters to the otherdata section of TSIG RDATA. So, it is quite different than TSIG but it will be a new algorithm in tsig. http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-06 - What is the difference between your proposed work with cga-tsig draft and tsig? What is the overlap between your proposed work and cga-tsig draft? Thanks, Best, Hosnieh From jay@nzrs.net.nz Wed Oct 16 14:44: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 6E0FC11E82E7 for ; Wed, 16 Oct 2013 14:44:12 -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 LiIkHUq0da2f for ; Wed, 16 Oct 2013 14:44:08 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 327D311E81F0 for ; Wed, 16 Oct 2013 14:44:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id DB0064B7A43; Thu, 17 Oct 2013 10:44:05 +1300 (NZDT) 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 PMkL1BvvP82J; Thu, 17 Oct 2013 10:43:58 +1300 (NZDT) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 3F62F4B5F83; Thu, 17 Oct 2013 10:43:58 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: <000001cecab7$b7bf0c20$273d2460$@rozanak.com> Date: Thu, 17 Oct 2013 10:43:57 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <5F35EC3E-A4E9-43C0-B808-A66354D6FDC9@nzrs.net.nz> References: <001a01ceca53$c6fb3010$54f19030$@rozanak.com> <3DFAFF6B-E090-4276-8025-C5FF52C529D5@nzrs.net.nz> <000001cecab7$b7bf0c20$273d2460$@rozanak.com> To: Hosnieh Rafiee X-Mailer: Apple Mail (2.1510) Cc: dnsext@ietf.org Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 21:44:12 -0000 On 17/10/2013, at 10:35 AM, Hosnieh Rafiee wrote: >> I'm not sure how that is relevant - perhaps you could explain? And = to > answer your question - I have no idea at all. >=20 > Cga-tsig addresses secure authentication during different scenarios = such as > FQDN, zone transfer, resolver to client, resolver to authoritative = servers, > etc. > It uses cga parameters as a means for this authentication. CGA proves = the > address ownership of nodes by finding a binding between the nodes' = public > key and its iP address. Cga-tsig adds cga parameters to the otherdata > section of TSIG RDATA. So, it is quite different than TSIG but it will = be a > new algorithm in tsig.=20 > http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-06 >=20 > - What is the difference between your proposed work with cga-tsig = draft and > tsig? What is the overlap between your proposed work and cga-tsig = draft? No Hosnieh I'm not falling for that. If you think there is any = overlap/conflict/interaction between my proposed work and the cga-tsig = draft then please identify it and I will address it. =20 To be clear, since it appears to me that you might not have understood, = the only idea I am floating around TSIG is that a DNSKEY record is given = to a nameserver with the intention that is should use to authenticate = (via TSIG) a zone transfer request for a new zone that it is asked to = serve as a slave. Jay --=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 ietf@rozanak.com Wed Oct 16 15:13: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 D0CEE11E82ED for ; Wed, 16 Oct 2013 15:13:05 -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 NVf0RZLlkmuf for ; Wed, 16 Oct 2013 15:13:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8B31F11E82BE for ; Wed, 16 Oct 2013 15:12:59 -0700 (PDT) Received: from kopoli (e179165194.adsl.alicedsl.de [85.179.165.194]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M8eMt-1VjACz2TUh-00vQTq; Wed, 16 Oct 2013 18:12:57 -0400 From: "Hosnieh Rafiee" To: "Jay Daley" References: <001a01ceca53$c6fb3010$54f19030$@rozanak.com> <3DFAFF6B-E090-4276-8025-C5FF52C529D5@nzrs.net.nz> <000001cecab7$b7bf0c20$273d2460$@rozanak.com> <5F35EC3E-A4E9-43C0-B808-A66354D6FDC9@nzrs.net.nz> In-Reply-To: Date: Thu, 17 Oct 2013 00:12:48 +0200 Message-ID: <000201cecabc$dc64f7b0$952ee710$@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: AQNPbtY7r0spbIykxCLUUtreV80m/QK2S9e9Aa9gewUB6KXQyAJtDTORlrC7XWCAAAWNYA== Content-Language: en-us X-Provags-ID: V02:K0:3RV49TnckpopC6wrEDN5ojndAbjufRouacASYT2njBv bgjn+S4FGms1ccfRT/RkqlQXJ9QYH8Fm90KGy6z3f9yu/AmmT/ c8rbWGl2S7I+hYKRodIn6GlbNK5hanHUVTuS4VAx9fFvrw03GQ MM1KoAfBEbfKlPd6H/20hIb9Wi7zw3+h2a8Sy+D6bkYJiPmLvu ux/t5cw3fzb4SrOjsOnaCYsZC4T5d17rqQbelXJQoazaGlGxGj Oac/qGW2VOIWfR3TrthwhPneGai5s89UygMjR+P5QWZ2QKkwGN gWf1K8ZjSYQI8u2NSLUgR8+UaNtCgzPA6T6wauLYGSaaSb9JeR JV0NR635uqXtMvbenEec= Cc: dnsext@ietf.org Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 22:13:06 -0000 Sorry I forgot to submit it to the list ... >No Hosnieh I'm not falling for that. If you think there is any overlap/conflict/interaction between my proposed work and the cga-tsig draft then please >identify it and I will address it. >To be clear, since it appears to me that you might not have understood, the only idea I am floating around TSIG is that a DNSKEY record is given to a >nameserver with the intention that is should use to authenticate (via TSIG) a zone transfer request for a new zone that it is asked to serve as a slave. I am attempting to rephrase my question. Correct me if I am wrong... I think DNSKEY is for DNSSEC and not for TSIG. TSIG uses shared secret and it is added to DNS configuration file (isn't stored in any record in database) . dissimilar to a part of DNSSEC it is not public key cryptography. This means that you cannot add the shared secret in DNSKEY for authentication. Security problem... TSIG might use TKEY which is different than DNSKEY. Secondly, I guess addressing TSIG here does not really make sense as you are not fully addressing security but you're planning to make the DNS update more efficient. So, I suggest that you only think about making the Update more efficient and let other approaches like other RRs TSIG, cga-tsig secure your approach. Thanks, Best, Hosnieh From marka@isc.org Wed Oct 16 15:17: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 8F8A811E82CA for ; Wed, 16 Oct 2013 15:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 Ra6u7oGdDsm8 for ; Wed, 16 Oct 2013 15:17:01 -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 0AE3111E812B for ; Wed, 16 Oct 2013 15:17:00 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id B5021C94ED; Wed, 16 Oct 2013 22:16:43 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1381961816; bh=nVRqMqYsLX1fibRh+NYsqUzP/oQOvCFO/+GxAh3wA0c=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=HpgKHxOzIPBv6vA2Ux5UXI/hg+J4KDN7ot6mbNRyTmC8G3OsxBWm34vjbdf8TxNWQ l5bz1r/7vJOkmaru8pUzU0qSab9ZzAgh2BSBLK1FYLWMbGeavEBmwFc3emOt2R3oaz VGYQuv1dwI9gdcZIUX9HC9TVe07V7jhMS+Rg6Rf0= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 16 Oct 2013 22:16:43 +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 80A19160470; Wed, 16 Oct 2013 22:21:00 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 4B498160449; Wed, 16 Oct 2013 22:21:00 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 46E1C849211; Thu, 17 Oct 2013 09:16:40 +1100 (EST) To: Jay Daley From: Mark Andrews References: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> <20131016204728.3116B848699@rock.dv.isc.org> <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz> <20131016210846.604B78489A9@rock.dv.isc.org> <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz> In-reply-to: Your message of "Thu, 17 Oct 2013 10:31:11 +1300." <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz> Date: Thu, 17 Oct 2013 09:16:39 +1100 Message-Id: <20131016221640.46E1C849211@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 22:17:05 -0000 In message <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz>, Jay Daley writes : > > On 17/10/2013, at 10:08 AM, Mark Andrews wrote: > > > A zone, by definition, only contains records of a single class. > > It's not that I doubt you but can you provide a reference to that so = > that I can if there is any wriggle room there? RFC 1034 4.2. How the database is divided into zones I won't quote all of this but you can't achieve what is defined there without zones being a single class. RFC 1035 5.2. Use of master files to define zones When a master file is used to load a zone, the operation should be suppressed if any errors are encountered in the master file. The rationale for this is that a single error can have widespread consequences. For example, suppose that the RRs defining a delegation have syntax errors; then the server will return authoritative name errors for all names in the subzone (except in the case where the subzone is also present on the server). Several other validity checks that should be performed in addition to insuring that the file is syntactically correct: 1. All RRs in the file should have the same class. 2. Exactly one SOA RR should be present at the top of the zone. 3. If delegations are present and glue information is required, it should be present. > And what would your solution be to signifying that a zone is to be = > deleted? Without one we have to abandon extending UPDATE and burn an = > opcode. > > Jay > > --=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 > -- 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 Wed Oct 16 15:20: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 4B30A11E831B for ; Wed, 16 Oct 2013 15:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kypU8OJ4Z6-C for ; Wed, 16 Oct 2013 15:20:22 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id AD0DA11E82CA for ; Wed, 16 Oct 2013 15:20:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id CC80A4B7A3F; Thu, 17 Oct 2013 11:20:21 +1300 (NZDT) 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 MJVzk7a-vnzU; Thu, 17 Oct 2013 11:20:14 +1300 (NZDT) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 3A4474B7A4A; Thu, 17 Oct 2013 11:20:14 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: <20131016221640.46E1C849211@rock.dv.isc.org> Date: Thu, 17 Oct 2013 11:20:14 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <4F2CBEA5-57E2-441B-A50C-B50ED0DD6284@nzrs.net.nz> References: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> <20131016204728.3116B848699@rock.dv.isc.org> <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz> <20131016210846.604B78489A9@rock.dv.isc.org> <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz> <20131016221640.46E1C849211@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1510) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 22:20:35 -0000 On 17/10/2013, at 11:16 AM, Mark Andrews wrote: > 1. All RRs in the file should have the same class. Great thanks - so overloading class to signify deletion can't be used at = the zone level as there is no wriggle room at all. That still leaves the following question (it was after all you that said = we should extend UPDATE instead of defining another opcode): >> And what would your solution be to signifying that a zone is to be =3D >> deleted? Without one we have to abandon extending UPDATE and burn an = =3D >> opcode. Jay --=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 jay@nzrs.net.nz Wed Oct 16 15:31:42 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 C872811E81D7 for ; Wed, 16 Oct 2013 15:31:42 -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 6uqRKqWVv0hl for ; Wed, 16 Oct 2013 15:31:38 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8557211E818D for ; Wed, 16 Oct 2013 15:31:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id C6DE34B7A7B; Thu, 17 Oct 2013 11:31:32 +1300 (NZDT) 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 sb3T+yABQGFV; Thu, 17 Oct 2013 11:31:24 +1300 (NZDT) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id E0E3C4B7A8B; Thu, 17 Oct 2013 11:31:24 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: <000201cecabc$dc64f7b0$952ee710$@rozanak.com> Date: Thu, 17 Oct 2013 11:31:24 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <58918AA6-2721-4CA2-BE72-19B755FD058E@nzrs.net.nz> References: <001a01ceca53$c6fb3010$54f19030$@rozanak.com> <3DFAFF6B-E090-4276-8025-C5FF52C529D5@nzrs.net.nz> <000001cecab7$b7bf0c20$273d2460$@rozanak.com> <5F35EC3E-A4E9-43C0-B808-A66354D6FDC9@nzrs.net.nz> <000201cecabc$dc64f7b0$952ee710$@rozanak.com> To: "Hosnieh Rafiee" X-Mailer: Apple Mail (2.1510) Cc: dnsext@ietf.org Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 22:31:42 -0000 On 17/10/2013, at 11:12 AM, "Hosnieh Rafiee" wrote: > Sorry I forgot to submit it to the list ... >=20 >> No Hosnieh I'm not falling for that. If you think there is any > overlap/conflict/interaction between my proposed work and the cga-tsig = draft > then please >identify it and I will address it. =20 >=20 >> To be clear, since it appears to me that you might not have = understood, the > only idea I am floating around TSIG is that a DNSKEY record is given = to a >> nameserver with the intention that is should use to authenticate (via = TSIG) > a zone transfer request for a new zone that it is asked to serve as a = slave. >=20 > I am attempting to rephrase my question. Correct me if I am wrong... I = think > DNSKEY is for DNSSEC and not for TSIG. TSIG uses shared secret and it = is > added to DNS configuration file (isn't stored in any record in = database) . > dissimilar to a part of DNSSEC it is not public key cryptography. This = means > that you cannot add the shared secret in DNSKEY for authentication. = Security > problem... TSIG might use TKEY which is different than DNSKEY.=20 Yes it probably ought to be TKEY since this is what it is specifically = designed for and not a DNSKEY but DNSKEY is so much simpler so I was = just trying it on ... > Secondly, I guess addressing TSIG here does not really make sense as = you are > not fully addressing security but you're planning to make the DNS = update > more efficient. So, I suggest that you only think about making the = Update > more efficient and let other approaches like other RRs TSIG, cga-tsig = secure > your approach.=20 You've misunderstood why the TSIG key appears in this message. I am = investigating adding new functionality to UPDATE and part of that new = functionality requires the transmission of a TSIG key as data inside the = packet, for the receiver to use elsewhere. This TSIG key is not used in = this transaction. Jay =20 --=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 marka@isc.org Wed Oct 16 15:34: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 8D26611E8189 for ; Wed, 16 Oct 2013 15:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 ed0ctpulCrVe for ; Wed, 16 Oct 2013 15:34:14 -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 62D9711E812B for ; Wed, 16 Oct 2013 15:34:14 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id E203CC9497; Wed, 16 Oct 2013 22:33:57 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1381962851; bh=xTNHhdr26FJrs6ZjKawgsfXHsn3iQnKWHC0qFx9PE+8=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=n/rzk++bDHc/n4m32J6XcGKAVArdhBNov5F23wvYLGJIsAfAHxYcfE+tpl1iRHOOv fKDtMLN7pMU3kp8NKmO4N/l7bTNzdFwZoJ/42WGHhZrpZl8W48Q/B5NY67ver/IfYZ z5RL4EeXvz6Guu+7ERJkgnDNCzOnXSnn39GnOHV4= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 16 Oct 2013 22:33:57 +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 C2494160470; Wed, 16 Oct 2013 22:38:14 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 8F096160449; Wed, 16 Oct 2013 22:38:14 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7F73A849421; Thu, 17 Oct 2013 09:33:55 +1100 (EST) To: Jay Daley From: Mark Andrews References: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> <20131016204728.3116B848699@rock.dv.isc.org> <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz> <20131016210846.604B78489A9@rock.dv.isc.org> <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz> In-reply-to: Your message of "Thu, 17 Oct 2013 10:31:11 +1300." <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz> Date: Thu, 17 Oct 2013 09:33:55 +1100 Message-Id: <20131016223355.7F73A849421@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 22:34:18 -0000 In message <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz>, Jay Daley writes : > And what would your solution be to signifying that a zone is to be > deleted? Without one we have to abandon extending UPDATE and burn an > opcode. > > Jay Add zone: Zone: NS Update: SOA ..... Additional: master TXT [port=value] [A=value] [AAAA=value] [key=name[:alg:secret]] [name=name] key TXT [key=name[:algorithm:secret]] port TXT [port=value] allow-transfer TXT allow-query TXT allow-update TXT Delete zone: Zone: NS Update: ANY SOA The use of type NS in the zone section indicates that this is a whole of zone operation. Mark > -- > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From Ted.Lemon@nominum.com Wed Oct 16 15:37: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 C12B011E81A6 for ; Wed, 16 Oct 2013 15:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7mGBdnafebR for ; Wed, 16 Oct 2013 15:37:26 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id F067011E8195 for ; Wed, 16 Oct 2013 15:37:21 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUl8VIRFFU0CwLFTDfxiltiJs61m8+pD5@postini.com; Wed, 16 Oct 2013 15:37:21 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 7F9E21B82E4 for ; Wed, 16 Oct 2013 15:37:21 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 65A9519005C; Wed, 16 Oct 2013 15:37:21 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 16 Oct 2013 15:37:21 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: Ted Lemon In-Reply-To: <58918AA6-2721-4CA2-BE72-19B755FD058E@nzrs.net.nz> Date: Wed, 16 Oct 2013 18:37:20 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <752957F6-BA00-4740-ABA3-969670E08D61@nominum.com> References: <001a01ceca53$c6fb3010$54f19030$@rozanak.com> <3DFAFF6B-E090-4276-8025-C5FF52C529D5@nzrs.net.nz> <000001cecab7$b7bf0c20$273d2460$@rozanak.com> <5F35EC3E-A4E9-43C0-B808-A66354D6FDC9@nzrs.net.nz> <000201cecabc$dc64f7b0$952ee710$@rozanak.com> <58918AA6-2721-4CA2-BE72-19B755FD058E@nzrs.net.nz> To: Jay Daley X-Mailer: Apple Mail (2.1812) X-Originating-IP: [192.168.1.10] Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 22:37:34 -0000 On Oct 16, 2013, at 6:31 PM, Jay Daley wrote: > Yes it probably ought to be TKEY since this is what it is specifically = designed for and not a DNSKEY but DNSKEY is so much simpler so I was = just trying it on ... You can use SIG(0) to authenticate DNS updates. This relies on DNSKEY, = and is indeed simple. From marka@isc.org Wed Oct 16 16:28:04 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 4930411E8197 for ; Wed, 16 Oct 2013 16:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 nyqW6izxqsr6 for ; Wed, 16 Oct 2013 16:27:59 -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 EB8E311E8189 for ; Wed, 16 Oct 2013 16:27:56 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id D5DE6C9484; Wed, 16 Oct 2013 23:27:41 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1381966074; bh=DU0/iZ+/0vY8EB3ENhZM4W+mH+nEt62dTy3sZckLT3c=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=GGF/HG8tp6r0aSZvGntcCTdJ/yVmece5R8/Mp5fq2gZVyYbzMvza4n3AUXoghnVBw VMaE73xrB8Rk2t1lfTg9BtVhkoJq8FrwJ21h2RIfwWhVaHrqFMUeaP+oJWUHwLsX6o U9hT8QhFpDNWkj8clEN5F7S9mo9DoPUHOtpfPM5A= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 16 Oct 2013 23:27:41 +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 DCD59160470; Wed, 16 Oct 2013 23:31:58 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id AEA5D160449; Wed, 16 Oct 2013 23:31:58 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7AA1184A162; Thu, 17 Oct 2013 10:27:39 +1100 (EST) To: Ted Lemon From: Mark Andrews References: <001a01ceca53$c6fb3010$54f19030$@rozanak.com> <3DFAFF6B-E090-4276-8025-C5FF52C529D5@nzrs.net.nz> <000001cecab7$b7bf0c20$273d2460$@rozanak.com> <5F35EC3E-A4E9-43C0-B808-A66354D6FDC9@nzrs.net.nz> <000201cecabc$dc64f7b0$952ee710$@rozanak.com> <58918AA6-2721-4CA2-BE72-19B755FD058E@nzrs.net.nz> <752957F6-BA00-4740-ABA3-969670E08D61@nominum.com> In-reply-to: Your message of "Wed, 16 Oct 2013 18:37:20 -0400." <752957F6-BA00-4740-ABA3-969670E08D61@nominum.com> Date: Thu, 17 Oct 2013 10:27:39 +1100 Message-Id: <20131016232739.7AA1184A162@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 16 Oct 2013 23:28:04 -0000 In message <752957F6-BA00-4740-ABA3-969670E08D61@nominum.com>, Ted Lemon writes : > On Oct 16, 2013, at 6:31 PM, Jay Daley wrote: > > Yes it probably ought to be TKEY since this is what it is specifically desi > gned for and not a DNSKEY but DNSKEY is so much simpler so I was just trying > it on ... > > You can use SIG(0) to authenticate DNS updates. This relies on DNSKEY, and > is indeed simple. No, it relies on KEY but I agree with you that it is simple. > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jay@nzrs.net.nz Wed Oct 16 17:46: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 275F511E81A6 for ; Wed, 16 Oct 2013 17:46: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=[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 abOR3LVNVoHQ for ; Wed, 16 Oct 2013 17:46:42 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 13A0511E819A for ; Wed, 16 Oct 2013 17:46:39 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 8AE164B7AFD; Thu, 17 Oct 2013 13:46:38 +1300 (NZDT) 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 HwNnx0eWlrrO; Thu, 17 Oct 2013 13:46:30 +1300 (NZDT) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id E43CD4B7B21; Thu, 17 Oct 2013 13:46:20 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: <20131016223355.7F73A849421@rock.dv.isc.org> Date: Thu, 17 Oct 2013 13:46:21 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <5DEFA0E6-EFAC-4E40-BD01-FD56D542FA8D@nzrs.net.nz> References: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> <20131016204728.3116B848699@rock.dv.isc.org> <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz> <20131016210846.604B78489A9@rock.dv.isc.org> <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz> <20131016223355.7F73A849421@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1510) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 17 Oct 2013 00:46:47 -0000 On 17/10/2013, at 11:33 AM, Mark Andrews wrote: > Add zone: > Zone: NS > Update: SOA ..... > > Additional: > master TXT [port=3Dvalue] [A=3Dvalue] [AAAA=3Dvalue] = [key=3Dname[:alg:secret]] [name=3Dname] > key TXT [key=3Dname[:algorithm:secret]] > port TXT [port=3Dvalue] > allow-transfer TXT > allow-query TXT > allow-update TXT I sympathise with just how easy this would be, especially if the labels = were prefixed with an underscore to prevent collisions, but I think this = is a step too far given the variance in implementations and we should = use NSCP instead. >=20 > Delete zone: > Zone: NS > Update: ANY SOA That's excellent thank you. I'll put together a draft. Jay --=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 marka@isc.org Wed Oct 16 18:38:06 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 79DF911E8143 for ; Wed, 16 Oct 2013 18:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 7c96Yg3fwacu for ; Wed, 16 Oct 2013 18:38:01 -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 56B4111E81F9 for ; Wed, 16 Oct 2013 18:38:00 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id E11D2C94FA; Thu, 17 Oct 2013 01:37:47 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1381973879; bh=VDR8cBNm+o/9L+lBOSqYuv6D4vbbyYShB4WY/uX4Eak=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=METXTVL+MwgzzvRdVupJ6ZA+ambanfKKFCdZVHFVRzgj9Ldk0l/Qj+Xv+6ZL8PmgT c321W03+P2uK67WwxWNzfLETlSSWrwat5aPzt4PsX4PXs148ZCHW+cGe/0XXRFVxfP RJb0ci/qWcx1P0gQphjjOqFjLN0LHSPNg54gwP4g= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 17 Oct 2013 01:37:47 +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 55B19160482; Thu, 17 Oct 2013 01:42:05 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id B1B9D160475; Thu, 17 Oct 2013 01:42:04 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0090F84BA23; Thu, 17 Oct 2013 12:37:40 +1100 (EST) To: Jay Daley From: Mark Andrews References: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> <20131016204728.3116B848699@rock.dv.isc.org> <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz> <20131016210846.604B78489A9@rock.dv.isc.org> <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz> <20131016223355.7F73A849421@rock.dv.isc.org> <5DEFA0E6-EFAC-4E40-BD01-FD56D542FA8D@nzrs.net.nz> In-reply-to: Your message of "Thu, 17 Oct 2013 13:46:21 +1300." <5DEFA0E6-EFAC-4E40-BD01-FD56D542FA8D@nzrs.net.nz> Date: Thu, 17 Oct 2013 12:37:40 +1100 Message-Id: <20131017013741.0090F84BA23@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 17 Oct 2013 01:38:06 -0000 In message <5DEFA0E6-EFAC-4E40-BD01-FD56D542FA8D@nzrs.net.nz>, Jay Daley writes : > > On 17/10/2013, at 11:33 AM, Mark Andrews wrote: > > > Add zone: > > Zone: NS > > Update: SOA ..... > > > > Additional: > > master TXT [port=3Dvalue] [A=3Dvalue] [AAAA=3Dvalue] = > [key=3Dname[:alg:secret]] [name=3Dname] > > key TXT [key=3Dname[:algorithm:secret]] > > port TXT [port=3Dvalue] > > allow-transfer TXT > > allow-query TXT > > allow-update TXT > > I sympathise with just how easy this would be, especially if the labels = > were prefixed with an underscore to prevent collisions, but I think this = > is a step too far given the variance in implementations and we should = > use NSCP instead. Additional records don't get added to the zone. They supplemental data just like OPT TSIG SIG are supplemental data. That said they could be defined later. > >=20 > > Delete zone: > > Zone: NS > > Update: ANY SOA > > That's excellent thank you. > > I'll put together a draft. > > Jay > > --=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 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ogud@ogud.com Wed Oct 16 21:18:13 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF00B11E816F for ; Wed, 16 Oct 2013 21:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 NUnxelt7C16h for ; Wed, 16 Oct 2013 21:18:08 -0700 (PDT) Received: from smtp107.ord1c.emailsrvr.com (smtp107.ord1c.emailsrvr.com [108.166.43.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB1611E81F4 for ; Wed, 16 Oct 2013 21:18:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 94B2898A76; Thu, 17 Oct 2013 00:18:05 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 354DE98AB5; Thu, 17 Oct 2013 00:17:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: <20131016223355.7F73A849421@rock.dv.isc.org> Date: Thu, 17 Oct 2013 00:17:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6642EDCF-DA2E-44B8-97F0-3B9208F170AA@ogud.com> References: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> <20131016204728.3116B848699@rock.dv.isc.org> <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz> <20131016210846.604B78489A9@rock.dv.isc.org> <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz> <20131016223355.7F73A849421@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1510) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 17 Oct 2013 04:18:13 -0000 On Oct 16, 2013, at 6:33 PM, Mark Andrews wrote: >=20 > In message <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz>, Jay = Daley writes > : >> And what would your solution be to signifying that a zone is to be >> deleted? Without one we have to abandon extending UPDATE and burn an >> opcode. >>=20 >> Jay >=20 > Add zone: > Zone: NS > Update: SOA ..... > > Additional: > master TXT [port=3Dvalue] [A=3Dvalue] [AAAA=3Dvalue] = [key=3Dname[:alg:secret]] [name=3Dname] > key TXT [key=3Dname[:algorithm:secret]] > port TXT [port=3Dvalue] > allow-transfer TXT > allow-query TXT > allow-update TXT >=20 > Delete zone: > Zone: NS > Update: ANY SOA >=20 > The use of type NS in the zone section indicates that this is a whole = of zone > operation. >=20 Mark and Jay,=20 why not burn RRTYPES for these commands ?=20 To add a secondary (easier than primary)=20 ADDZONE =20 To create a zone on primary NEWZONE (Zone source exampe : = file:///var/tmp/newzone/name)=20 ALLOW (This is like a TXT = record but with structure in order and number of fields) =20 GRANT =20 (ALLOW can also be supplied to secondary) To Remove a zone=20 DELZONE =20 We can keep going=20 ADDFORWARD =20 DELFORWARD [empty]=20 TAADD =20 TADEL (Avoiding using the name "DELTA") Olafur From marka@isc.org Wed Oct 16 21:39: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 9F7C511E8214 for ; Wed, 16 Oct 2013 21:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 wSul+gOCz76w for ; Wed, 16 Oct 2013 21:39:25 -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 B4B3011E823A for ; Wed, 16 Oct 2013 21:39:15 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id A4C55C942D; Thu, 17 Oct 2013 04:39:01 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1381984755; bh=bOYn58yfuExR0abtaaPiHld8sqIsZy6WUTsVTrtb+zU=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=cy21553SNSoJQBWbVYi9Szn0UtSTKcLEtW7bHtpgXUnmFjkCeVz3YpAm6Qs823Dmo rUA70f3vrC94EC4J2V6pznULAbfbuKwgD0/LAmLe+1fyP9MMteqzQn5IQ1QrmOvZG4 jFbLLuRHnoIEKJrG+ed/Q0jcoBZwTUTODGbW2+eg= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 17 Oct 2013 04:39:01 +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 9A50D160449; Thu, 17 Oct 2013 04:43:19 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 612BE1603E9; Thu, 17 Oct 2013 04:43:19 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 83AB084CDBE; Thu, 17 Oct 2013 15:38:59 +1100 (EST) To: Olafur Gudmundsson From: Mark Andrews References: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> <20131016204728.3116B848699@rock.dv.isc.org> <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz> <20131016210846.604B78489A9@rock.dv.isc.org> <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz> <20131016223355.7F73A849421@rock.dv.isc.org> <6642EDCF-DA2E-44B8-97F0-3B9208F170AA@ogud.com> In-reply-to: Your message of "Thu, 17 Oct 2013 00:17:44 -0400." <6642EDCF-DA2E-44B8-97F0-3B9208F170AA@ogud.com> Date: Thu, 17 Oct 2013 15:38:59 +1100 Message-Id: <20131017043859.83AB084CDBE@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 17 Oct 2013 04:39:34 -0000 In message <6642EDCF-DA2E-44B8-97F0-3B9208F170AA@ogud.com>, Olafur Gudmundsson writes: > > On Oct 16, 2013, at 6:33 PM, Mark Andrews wrote: > > > > > In message <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz>, Jay > Daley writes > > : > >> And what would your solution be to signifying that a zone is to be > >> deleted? Without one we have to abandon extending UPDATE and burn an > >> opcode. > >> > >> Jay > > > > Add zone: > > Zone: NS > > Update: SOA ..... > > > > Additional: > > master TXT [port=value] [A=value] [AAAA=value] [key=name[:alg:secret]] > [name=name] > > key TXT [key=name[:algorithm:secret]] > > port TXT [port=value] > > allow-transfer TXT > > allow-query TXT > > allow-update TXT > > > > Delete zone: > > Zone: NS > > Update: ANY SOA > > > > The use of type NS in the zone section indicates that this is a whole > of zone > > operation. > > > Mark and Jay, > > why not burn RRTYPES for these commands ? > > To add a secondary (easier than primary) > ADDZONE > > To create a zone on primary > NEWZONE (Zone source exampe : > file:///var/tmp/newzone/name) > ALLOW (This is like a TXT > record but with structure in order and number of fields) > GRANT > > (ALLOW can also be supplied to secondary) > > To Remove a zone > DELZONE > > We can keep going > ADDFORWARD > > DELFORWARD [empty] > TAADD > TADEL (Avoiding using the name "DELTA") > > Olafur I don't really care which way we go. It is the concepts that I want to nail down first. We also want the scheme to be extensible. Class could be used to signal the removal of a field which would slow the burn rate. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From muks@isc.org Wed Oct 16 21:59:04 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 77DBD21F992A for ; Wed, 16 Oct 2013 21:59:04 -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 GqENcIW41+Cu for ; Wed, 16 Oct 2013 21:59:02 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:141:43e5::3]) by ietfa.amsl.com (Postfix) with ESMTP id 9886E21F9635 for ; Wed, 16 Oct 2013 21:58:55 -0700 (PDT) Received: from totoro.home.mukund.org (unknown [115.118.43.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id A0E6A1C00220; Thu, 17 Oct 2013 04:58:47 +0000 (GMT) Date: Thu, 17 Oct 2013 10:28:42 +0530 From: Mukund Sivaraman To: Jay Daley Message-ID: <20131017045842.GA1965@totoro.home.mukund.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 17 Oct 2013 04:59:04 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Oct 16, 2013 at 10:33:03PM +1300, Jay Daley wrote: > 5. If there is data in the Additional section then that signifies > that the zones to be added are slaves. The records here must be NS > records that specify the masters for the zones to be added. There can > only be records here or in the Update section but not both as zones > cannot be both masters and slaves. Would glue be allowed here? Mukund --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQgcBAEBCgAGBQJSX25/AAoJENJq4EOcI417xaY//0bip3NlY7V65FhgB9Wz05x+ pYoU0ga7izZm6/Vuw95dAnluhx+xnQSklmUt9KmAcLm6t7bGyeoeDNs1FpU81Tyb UltwjUAjCet2ZvG7IVuzFP3WDriIZ0CV2VpHabGmqplcaHuB3jZC2Dhw8tSDGEa+ NlLZC7AwkcPtGXU31a79zZRlg0B91sspYAYvSAW0UQzp5FzvXxb9+goSojTF9o/V nPeRSNcv01W/TUffEvMcy+nu0tU7FS1bW78DoLtxgbykyv5QGdmSoAygOh/1A451 7milmsse/YnyjKWm5137siokA/rwzsRPoHm78E7Ttq1UwcD7OZU6nLa8Lu6Ka70p IE1tjYu02A3MdabOTSLcJQRnWqbEOvkFE0lHZzBNhRFT92fyb2rkH3clvF2VH7O2 toMW320kJj4nxD1ExoWToBdYGGlI3YDSpbIC6F0fu2jykKp9IBnDRJ91REj07Np6 kuuvRcgeU76rTCxJfh4U2/TpNDmPccWl4iA32lGmWeCFa86BDRsNpUL2aaBAGca7 lu1oyRjrBwIiEn8qAdr6UyvJvbZGSQ8ejbjF7B16767WTN187FkhzSuj99lwwDhG 1H+CFxXr945HY5OcU+q6itx9J+ZnuWoUCd+pfssG+C/G0YzBtotnJtQAr8V5mmLV xB5hIieKJxYFP1gQZQsVNrhf4uEE5Ehv914BnMfQzOzHsbRWhkDW0WeCIm3znFF6 6bT93IixHKvfG+ct+Q84qmCorrZsk819G5geVm/9AO6pk0Ye0xfmt7hjVdr9l/n7 Co6brNFF0/GL+Cg/eOYWL4hgfiRVtQSEl01Lcakjn/c76JlUZY8bdAulIsGIErY6 6xvlVwRkqv9L3HzMasZ+J86+xtkzzFWX3cRzCG4GJXtO+5MJImDkJQNi32OkRc7t v+Wl5HE1jgsuHf1xVTuto68uRo9D+EFpL6q6rQCSFQxyIyeI/NykLzyH6kjQMBhO dSHNkpmZS3HmK21MnOC2bqj0xu83b5Rz3Mpa5dH0/iU7tUsgbPmCqaCGHchg6QW7 BHh33d/YDHun+D7i+0t03+giXE8HqFZCfXtHl1u5Hzou6sH4aPfeveE/PloQC9BX 1gSnN7ZLKdpZT0FU/grzwJeaxUy0gxS99GCl/+aPhbznYgoc1O3TcHGFoFiCTPNt U5GloZaAKb1VsIhkJ6YsG7V1ihYJi9WB8Z4+2X0+E6A7SLLPv/6MYe+fLt895+dd Xc/eqZg04L0mgPIAgJsK/VhjuJ/myn1mimqIsD4MOZWIKTQURaeTfRVKBjt8mQR9 PW+tcMHUwBsHzZ9jx7vuBbB44Dir5n1K5XgSsF3JII/Kr1McwmlrsbcOiuvIT7lB SaSU/P2dX7KHuiobuTJ3br0u3nk5zozox+yGBlrmOVw4SSZgC8T1ekr0ty0Ta5tT 6f91zkZ4MdsXwXAnyKNwL+W5fI/+MjLMBc/mIuZmil/BvBjGluIp3btGII18K0+M yh9+UVgjes6ekuOZP1n5q9y4aiD2mJ1Q1mFQtw6TNZaG51uQX+xL7h1FTEUFvxn+ njX84Io3oV1osFsz1kXroaqQERy+g5uDxhcKrLX8f/tRcaIBZLfwgbTakbLfuN6r sJ03OGNA6DQRN1DAUhV2y9kRiqoV5GZ/1DrOU5V8n2GJucUSg7uiLitxtQ2CXTOS fT6EAtkBpM/WQ/GHn1HnOjwqy9a/5PlnKJES3LxK8dIs290RAi8J7hXuAprLkTGI pzzlmXPnRC3guCwIglnGvHH4qP6qr+AToduEF0ZvKF6ycNQF8fYqrBTDUj7eo/cz IBki9aXmlEEAaGU3dBt5yCbfYyv6s92wHw3lH+4OmBLG37+Zv1/a/O1acyC0wMXY VVfKOQ4K/Ds/snUUPYIuWHqbEr5dG7Ns/t4Fd5KMhydValGnBOyZLSMxxhdGNGwY 6dL6EQqLjmnTi1cpoQC2mUIz0GM2KsCOQgMnYhRx2X9f5ug95TUSCLVnYzniYTwt GyJXeZIMiswiUMLXAXIpm9u47u9hJ6zsbvc9+DrWfdpyPWdhIJc0dWHmaBQ0p2aA EcGuDfxn9nlrv2KuRMQg+WPVomLRO9SY0t4Ph1GbVyNs+CeTSTKQokCV6DDHX9pi W9Qa6SIB81aXWkI147NoV7+HFlsTNsA5pe8A5FlaLjFPS9XDlNiarLd1ud0siPQP ffYH0b521JIunNuGi40rlsAyZ+o+F05tmAtYWhKwFp416zJ5pjY7rTsVTOIAYt/i SOex9S2vu/XM7LUxNnv4AlAifcNC8dr04o+fZRVnuBuaMvfYqlAeZCjDCbTT/UyR eNCG4kjAq56A7bNk0q/W4Zjk87uUmxmADESOsBmbAHUKRstvP3AnKsiokC4LP7gk qT5WqlK1I4FXsonXUBZAYWpewLyYsW5L3wLQa8U+TV+x0I8R75aVCbrJ96x57DZx /EB1ZLqmHgeDCMFHbc/bjkxFhYohITcx9A7NGjPOsibd6JvwT1tzu6SDV2YozwaE OYx+oHKbLsTCPWUgQqabKhE18DNtBw1dBX6vr7KFMAHj5x4vpS+Ia0pFRBW8upZk AL+3myyV5CMBkFhMlOEflJajCPyO9PxJPk9rZ1DFyJXSmzmrtm5yZ2oUCbNPtlif NerA6Pe43yUHx0Bj7L0NRemqAWFL0tkhNws/x6wgUlPKUGsMZth8WO1A9KYiw5Ro jAWA6y6Ts8c7FgeSo8Q3 =l/As -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From muks@isc.org Wed Oct 16 22:06:26 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 B297821F9ECA for ; Wed, 16 Oct 2013 22:06:26 -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 CKKx9V+U2ppP for ; Wed, 16 Oct 2013 22:06:26 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:141:43e5::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA3A21F9E2B for ; Wed, 16 Oct 2013 22:06:15 -0700 (PDT) Received: from totoro.home.mukund.org (unknown [115.118.43.64]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id C05061C00220; Thu, 17 Oct 2013 05:06:10 +0000 (GMT) Date: Thu, 17 Oct 2013 10:36:07 +0530 From: Mukund Sivaraman To: Jay Daley Message-ID: <20131017050607.GA2267@totoro.home.mukund.org> References: <20131017045842.GA1965@totoro.home.mukund.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <20131017045842.GA1965@totoro.home.mukund.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 17 Oct 2013 05:06:26 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 17, 2013 at 10:28:42AM +0530, Mukund Sivaraman wrote: > On Wed, Oct 16, 2013 at 10:33:03PM +1300, Jay Daley wrote: > > 5. If there is data in the Additional section then that signifies > > that the zones to be added are slaves. The records here must be NS > > records that specify the masters for the zones to be added. There can > > only be records here or in the Update section but not both as zones > > cannot be both masters and slaves. >=20 > Would glue be allowed here? I didn't see Mark's reply earlier, but something like that (to specify the IP address, port, etc. of the master) would be needed. Mukund --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQgcBAEBCgAGBQJSX3A7AAoJENJq4EOcI417nR1AAMIxbXYDZus5zbRdy0Oc324v n/O0F2ab3IfWMh5tdbPwV2BdcoYoEcsASeI5dyzL75yGVxH7Vhk4IL7J+/J1kBzk dFFUZlhTnMxffUDO5nzA3/VtGU5Z10eDvXvbzRW1w1oYEA/5tHx4GUgixv2pLrgE nW3HDUoHU5W4fRhPg1In6V6Fd6ghgXdEyS+JhtFXgh0Emq03R6R2wtpDZilR5VaR QCL6W5vCWeVZlmHWnrr2tbHJG2vRHBv7hxMRB0EfdnhnBzDb5WuPJnlg7eATVGO5 EDVO3OdMWSXeQNqGyh88VCpaUT9kEN1MqHwop6h7b6xGmrX031JFWMP2J5F30qeZ KmD5CrTnIPI3yfY2DoopklsAjqcxipTThM7Uqug4STP66n13CRUZrchw9fFf5pIG InR+8MYTBEFeJksh22wNCBvzDB67ZP8iHXapqXwwN7HdFLoDNzAYlSF1Zw/VDMRb J2u7d7Q5/T8arYFjQz4x8hVj/s0uC9zJSAWSSV/uYIJ7NT7THutRchSEiV3TeZJy apKKuC7tKU4NEK/2It2e5/fSCLu3waBVxQrrmvwKwfHOW9TA3BKSfwbulUjgOAEG tp1n3jpiLfPDDR6DBQUeQBOKoy5/eLrsG8+2t9EZuuPCa2mvrOrAWK4uYu94apK8 9U+2+jh44bVFETcAIxrk4A/dYCTWhRJ4/oVWelqOQuCkOaXK7+5k/MoUNFdhQnlH AdCY7siU5s3oAz/WgG0UjLLooAdH2ssSX980bcd7Vafa/nptoMirB99lRPW+a+XJ toLSPhhIxbbawcIy+QYrw4c3DkOECYlj4+B6uIhPp55aK2vMMvR759jSSERABYiV lDP3x9NsvYh9XA/0XbcUcV0liWK5MuEIKUUuhXpZlnehGIBFozYJWxHOHl0MXy7e ka3+GxKUinKQ70vN6NY7i4k4CiAnldVy1xTlb0YWhjs35lgHTyscX5MJPInhw1YL 9gG8I49FIWvC/JHHkRKRKzjxAtqY66tiP5uDKRsI4BN3tedTZwKV9QyvRwacqtIX dheiIVD857KTz9W6z38dhDZdCTQSPSIoeN5l/NaqP72P1v7d+yRAqVrKGP+NVb+p 1fnSHln1kMdtSZ+DTHrW7j4986/6Nw6Gnz0Vb1zA19PbhQxPeM6jqKxKD0OyaByc a3UMtSGNogaBtms73mAQNSnOMgmY+FFRtvUBQpxliXlcwl6bFhXbFikGwrDEt0X7 bXEbTYqld4kI+5TYRPFwqnRl3q47qXF/q+J4vgMMDteL1k5N0dgX4hC7GHduubXa A+xbDbRYtsvzg07yDCpUSFSRms9yzifAfalWGnfRqz6qb05UvK3HcsOsCDMBwqUX QcmfL0CWOzyW/ZOBDJFN9I65//4KDdqg9r7kirma6C2dNQrt0fJ7YHByJQBg5HM1 UBQmyFGZO7Req/30fX367ylb6chI7/x2jEUwZndqkEl5yRJl4kHmsV0d1Zxq6b5F c1vSL4syvYVCtf+tc4DC4ObTMI10POilBfkh0eFtVpFyAU7OuNphAhfuRQCgHsE3 ceHihZMyGOxKyylaDLDDswDizlfirOTr+0yoRDsRqw0uEwEGZktg+9tWKp/Zxjpd +tZlaWgLtDqXMlg5s6g5dUPw7EoTrOhJu0jLQxoN1V1rr5Jd3q5m0tXsj0S6KO/c uSN3qxmv6zKJnRneRjUgG8ksyPEP/KoSinbG0I5WXdABDAaExf+/Q8nIXoh3CzMH ER6A1pbgtvfL/a1h4Cvo18S+dl31udy0/mxvLnU0fCiFyvi7s/6E6SjJvVesx6xL g2wY+Xt07Z9Vshak5fQT1lUNdly1GIwd4Q+pMiEyX8ONbLhxREmAHl6XACZcx/Bc FkqW1sXluqbCIRmA00+jGGKZVs6g2VukN7mRbLvaYdDWvfTlnhLSos3H2F0dzXkD E8L7VFW+kbzGxiz0LdKVfkw4eW5WNA0X36oPHeGQIR9UiSfWmtEnzI44G144jljq UvzbF/p3/wTG5qVTw08Bm84Fpeg9DHIKcr/9piVXhf44jgPJhM5iuk4O5EvaDNxT lFP2RcK8+gj58lf1Hx8JZKvz8YTKq4Hvcj6v7IwzPOTw86uLbBryQuxvMIVG81nz uC5NSPUsbxGpllxOQZMPdJYN71CnVLBx1C4YbYGMNGUwW4qUjfZPUCvNikoeBNRO ZdtEWLTZdS+voUhaK9ZDOKYLS+QcHAPrcfDMNUHINUzcEz1J2lOaIcFY0TpguvrY jzQTVEwJDXcftIOEg9rtUEg3O+EEqdX6atDwEzF6LAAF18qObhLwBfOrW4jGo11o HRFSc3qLlzaZCCC9Q8RaYuXtSjJRLdkMWs1LKyIBnIKN2iDYV3C243+yuhKfTYsq GcuOAFxD8rm2F2qfw30kxeAAAuWwI4Cc/o2VliuuzVYOz3/WmOUQLLrhfP2c1meJ /U6snoKeFwCmK3ZJYuj9CIAfKC69TxggSzQqgYfhVoniXx4pVS/0TZd0c7uRc2dM gcvq/HMCVE94mMB9ludH/HXBwa9jtwgATUUon7wmjRfJbPkmXPAocV+pmTXwf+A0 efXLBSIPSCyZFxFbmJkf3e4xKFRPqb6tO4pyJRb28KzyDs06QhI2ZvPHoKHsX0xa Uzkc1TpxdGSYPOO6Ers4zdZL88E7w0WGf//MkHSiMxmuX0WKIsHPT8AsFhyvIczI K5lefBwUGl5HPL0A2UHs =6+wg -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From mansaxel@besserwisser.org Thu Oct 17 00:35:56 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 AD02011E8252 for ; Thu, 17 Oct 2013 00:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjRWHnf4tl3s for ; Thu, 17 Oct 2013 00:35:56 -0700 (PDT) Received: from jaja.besserwisser.org (jaja.besserwisser.org [IPv6:2a01:298:4:0:211:43ff:fe36:1299]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7B311E8250 for ; Thu, 17 Oct 2013 00:35:55 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 97E6C9EA5; Thu, 17 Oct 2013 09:35:50 +0200 (CEST) Date: Thu, 17 Oct 2013 09:35:50 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Olafur Gudmundsson Message-ID: <20131017073550.GF29568@besserwisser.org> References: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> <20131016204728.3116B848699@rock.dv.isc.org> <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz> <20131016210846.604B78489A9@rock.dv.isc.org> <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz> <20131016223355.7F73A849421@rock.dv.isc.org> <6642EDCF-DA2E-44B8-97F0-3B9208F170AA@ogud.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qftxBdZWiueWNAVY" Content-Disposition: inline In-Reply-To: <6642EDCF-DA2E-44B8-97F0-3B9208F170AA@ogud.com> X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 17 Oct 2013 07:35:56 -0000 --qftxBdZWiueWNAVY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] Extending UPDATE to add/remove zones Date: Thu, Oct 1= 7, 2013 at 12:17:44AM -0400 Quoting Olafur Gudmundsson (ogud@ogud.com): >=20 > why not burn RRTYPES for these commands ?=20 Excellent idea. Nobody is going to request any new RRTYPEs anyway, since TXT is good enough, so we've got loads of them to burn. I think it might work -- it is not as bad an idea as my sarcasm above might= depict it as.=20 OTOH, a part of me ponders the phrase "out of scope" and points to https://github.com/kirei/dper or similar mechanisms. I have not decided yet. But am a happy user of dper.=20 --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 TONY RANDALL! Is YOUR life a PATIO of FUN?? --qftxBdZWiueWNAVY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlJfk1YACgkQ02/pMZDM1cUloACfQFkK9FD7BKOzTbjPqCcpZJCF Au4Amwd/N9FRAPMG5HbJAXvCp9SkOb/x =8QpD -----END PGP SIGNATURE----- --qftxBdZWiueWNAVY-- From jaap@NLnetLabs.nl Thu Oct 17 00:45:33 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 4370521F9EA8 for ; Thu, 17 Oct 2013 00:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZvevuid2Tao for ; Thu, 17 Oct 2013 00:45:32 -0700 (PDT) Received: from bela.nlnetlabs.nl (bela.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4ccb]) by ietfa.amsl.com (Postfix) with ESMTP id 614CD11E8243 for ; Thu, 17 Oct 2013 00:45:32 -0700 (PDT) Received: from bela.nlnetlabs.nl (localhost [IPv6:::1]) by bela.nlnetlabs.nl (8.14.7/8.14.7) with ESMTP id r9H7jRap032026; Thu, 17 Oct 2013 09:45:27 +0200 (CEST) (envelope-from jaap@NLnetLabs.nl) Authentication-Results: bela.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl Message-Id: <201310170745.r9H7jRap032026@bela.nlnetlabs.nl> To: =?utf-8?B?TcOlbnM=?= Nilsson From: Jaap Akkerhuis In-reply-to: <20131017073550.GF29568@besserwisser.org> References: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> <20131016204728.3116B848699@rock.dv.isc.org> <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz> <20131016210846.604B78489A9@rock.dv.isc.org> <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz> <20131016223355.7F73A849421@rock.dv.isc.org> <6642EDCF-DA2E-44B8-97F0-3B9208F170AA@ogud.com> <20131017073550.GF29568@besserwisser.org> Comments: In-reply-to =?utf-8?B?TcOlbnM=?= Nilsson message dated "Thu, 17 Oct 2013 09:35:50 +0200." Date: Thu, 17 Oct 2013 09:45:27 +0200 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (bela.nlnetlabs.nl [IPv6:::1]); Thu, 17 Oct 2013 09:45:28 +0200 (CEST) Cc: "dnsext@ietf.org Group" , Olafur Gudmundsson Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 17 Oct 2013 07:45:33 -0000 OTOH, a part of me ponders the phrase "out of scope" and points to https://github.com/kirei/dper or similar mechanisms. I'm not familiar with dper but I too wonder about the tendency to turn DNS servers into a provision engine as well. jaap From jay@nzrs.net.nz Thu Oct 17 00:48:04 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 156A311E820C for ; Thu, 17 Oct 2013 00:48:04 -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 zb9gNQntxnfC for ; Thu, 17 Oct 2013 00:47:59 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2753C11E80F5 for ; Thu, 17 Oct 2013 00:47:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id A4D3D4B5B79; Thu, 17 Oct 2013 20:47:56 +1300 (NZDT) 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 Y5DESAixdPkG; Thu, 17 Oct 2013 20:47:48 +1300 (NZDT) Received: from [192.168.1.230] (121-74-114-181.telstraclear.net [121.74.114.181]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 8833C4B4152; Thu, 17 Oct 2013 20:47:48 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: <6642EDCF-DA2E-44B8-97F0-3B9208F170AA@ogud.com> Date: Thu, 17 Oct 2013 20:47:48 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <5B21B921-1C20-4752-9B0D-B9452388F522@nzrs.net.nz> References: <0A7FCD00-56F0-480F-97BE-4978510534D0@nzrs.net.nz> <20131016204728.3116B848699@rock.dv.isc.org> <8275EE16-6026-4FAD-8CD6-702D4B018F81@nzrs.net.nz> <20131016210846.604B78489A9@rock.dv.isc.org> <1333FFAC-06F8-4D09-B9F7-70D8830D2A9C@nzrs.net.nz> <20131016223355.7F73A849421@rock.dv.isc.org> <6642EDCF-DA2E-44B8-97F0-3B9208F170AA@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1510) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 17 Oct 2013 07:48:04 -0000 On 17/10/2013, at 5:17 PM, Olafur Gudmundsson wrote: > Mark and Jay,=20 >=20 > why not burn RRTYPES for these commands ?=20 Perhaps we should ask the Yadifa people to write up their overloading of = RR types for in-band control as a draft to save us reinventing the = wheel? Jay >=20 > To add a secondary (easier than primary)=20 > ADDZONE =20 >=20 > To create a zone on primary > NEWZONE (Zone source exampe : = file:///var/tmp/newzone/name)=20 > ALLOW (This is like a TXT = record but with structure in order and number of fields) =20 > GRANT =20 >=20 > (ALLOW can also be supplied to secondary) >=20 > To Remove a zone=20 > DELZONE =20 >=20 > We can keep going=20 > ADDFORWARD =20 >=20 > DELFORWARD [empty]=20 > TAADD =20 > TADEL (Avoiding using the name "DELTA") >=20 >=20 > Olafur >=20 >=20 --=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 fanf2@hermes.cam.ac.uk Thu Oct 17 03:01:01 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 30F1611E825D for ; Thu, 17 Oct 2013 03:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGyGAEuiL8xe for ; Thu, 17 Oct 2013 03:01:00 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f52]) by ietfa.amsl.com (Postfix) with ESMTP id 49E4511E8271 for ; Thu, 17 Oct 2013 03:00:50 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:59081) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1VWkNr-0004y9-ES (Exim 4.80_167-5a66dd3) (return-path ); Thu, 17 Oct 2013 11:00:47 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VWkNr-0006V6-1w (Exim 4.72) (return-path ); Thu, 17 Oct 2013 11:00:47 +0100 Date: Thu, 17 Oct 2013 11:00:47 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Wouters In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 10:01:01 -0000 Paul Wouters wrote: > > Historically, DNS transactions over TCP only handle 1 query/answer. Really? I was using persistent TCP connections back in the 1990s. They work really nicely. Note also that RFC 5966 says that servers MUST support TCP and support multiple queries per connection. I think edns-tcp-keepalive should be compatible with that requirement. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From jay@nzrs.net.nz Thu Oct 17 03:34: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 B834721F9C3A for ; Thu, 17 Oct 2013 03:34:21 -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 DsFyd+ProA6e for ; Thu, 17 Oct 2013 03:34:17 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 429DF21F9A61 for ; Thu, 17 Oct 2013 03:34:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 0560B4B7962; Thu, 17 Oct 2013 23:34:16 +1300 (NZDT) 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 wetqGYqftqeV; Thu, 17 Oct 2013 23:34:08 +1300 (NZDT) Received: from [192.168.1.230] (121-74-114-181.telstraclear.net [121.74.114.181]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 366464B78AC; Thu, 17 Oct 2013 23:34:08 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: <20131017045842.GA1965@totoro.home.mukund.org> Date: Thu, 17 Oct 2013 23:34:06 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131017045842.GA1965@totoro.home.mukund.org> To: Mukund Sivaraman X-Mailer: Apple Mail (2.1510) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 17 Oct 2013 10:34:21 -0000 On 17/10/2013, at 5:58 PM, Mukund Sivaraman wrote: > On Wed, Oct 16, 2013 at 10:33:03PM +1300, Jay Daley wrote: >> 5. If there is data in the Additional section then that signifies >> that the zones to be added are slaves. The records here must be NS >> records that specify the masters for the zones to be added. There = can >> only be records here or in the Update section but not both as zones >> cannot be both masters and slaves. >=20 > Would glue be allowed here? I see what you are getting at and I think that rather than NS + glue the = records that must be here are either A or AAAA records that are the = addresses of the servers to contact to pull the zone from. Jay >=20 > Mukund --=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 muks@isc.org Thu Oct 17 04:18:25 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB12F11E81C6 for ; Thu, 17 Oct 2013 04:18:25 -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 vAsJM5-L3s9d for ; Thu, 17 Oct 2013 04:18:25 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:141:43e5::3]) by ietfa.amsl.com (Postfix) with ESMTP id 07C9D11E828B for ; Thu, 17 Oct 2013 04:17:18 -0700 (PDT) Received: from totoro.home.mukund.org (unknown [115.118.27.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 2B3681C001EF; Thu, 17 Oct 2013 11:17:14 +0000 (GMT) Date: Thu, 17 Oct 2013 16:47:11 +0530 From: Mukund Sivaraman To: Jay Daley Message-ID: <20131017111711.GA14875@totoro.home.mukund.org> References: <20131017045842.GA1965@totoro.home.mukund.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 17 Oct 2013 11:18:26 -0000 --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 17, 2013 at 11:34:06PM +1300, Jay Daley wrote: >=20 > On 17/10/2013, at 5:58 PM, Mukund Sivaraman wrote: >=20 > > On Wed, Oct 16, 2013 at 10:33:03PM +1300, Jay Daley wrote: > >> 5. If there is data in the Additional section then that signifies > >> that the zones to be added are slaves. The records here must be NS > >> records that specify the masters for the zones to be added. There can > >> only be records here or in the Update section but not both as zones > >> cannot be both masters and slaves. > >=20 > > Would glue be allowed here? >=20 > I see what you are getting at and I think that rather than NS + glue > the records that must be here are either A or AAAA records that are > the addresses of the servers to contact to pull the zone from. One more thing: RFC 1035 calls for durable storage of zone data. This is not a strict requirement for configured secondaries if you consider that a secondary can AXFR data from scratch during startup and store it in volatile memory. There are no updates to zone data made at secondaries - transfers not being considered as updates to data. So far, the "catalog" (RFC 1035) is a part of the secondary implementation's static configuration. The secondary can run without writing to durable storage. The case where a secondary crashes, loses its dynamic configuration should be addressed. Is an admin expected to reconfigure the secondary on startup each time? Is the secondary expected to save the updated catalog to durable storage? (The latter may not be agreeable to everyone, so support for both should be considered.) Mukund --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQgcBAEBCgAGBQJSX8czAAoJENJq4EOcI417w9FAAJ9e+TBP6wPsCjy1ERm7bouN aGZMlPKm6NUaxqF4uOXOOAWwcLstRIoqB7hxzpyMg0Th9bWgO0xQutiw/rIl8IRe DpGucPNen/AqNf7Mo3XDFndJAhtpkreqheWP3puDc5sZ4Iy8vgAKYW10ofNaowI9 pRLNTB3Wb8UcxzLwAKPWwwSV01Gj2wdaLEYOjcpE3CyBAWB6Cf5LdzVOw5tVplXE tT5RJWdOW5f3S5D8O7/NDC7SjFiikHM7gNX2SYwT24+gG+6jWu9f/PMOCaYvwA+P 1JnGwLob6Seqt9eEeOfq5qX+BcrU6gP/HaViG8RtOtJdSjkTClYqjpekpHh3MBVB 1WSifFkFCoz7eIj21jwmS5qj5eSRPjKFEiUtH8P+UyWYWxGt8OJy8kkXhNkypvlp WAwoidIv2bD/P600jQCpcRTv7ecdpXP5qVOeimV0w3yZcGVqnUSlW3Iis2o17Ij1 TmnaPc73RK9NdayTskpod72rxOA+rEppZ9soLT8gHNuT992mx1yqwyCBMloJ4vz1 oQFr7gEwyw5L7uWdKdGiu1OQEFSLRarogXnJ0MboaIAKehcB6+st2VGPlpDX0yam adpVg8QPlnQwj0+hBAevwwSTdQJW4OuanBmVUACu9nDU9YG/Lg3gUyC1T8mVTmNe ybPpCzyKyC9Ac9XQOiXcas3j9SIlQsY1fvEySuz3WHmjRthqjq6hH/VnDGjzJ9S/ A8wZf+HCE9NUunKgfUXZEZ15YW0JuuuXEIocwECuqrV8/D01dXvGikVg3I/6t7AF 7oYXQzLoUOxy4672KVGL+9uToYAC3T1L+cBbyKn5F77PS/ZrTc6sfkWS/mIB/9sT jvLHu0L+AfSSFGAgwumAwVE9NW6IFF7tTX8pJfv0XDbWnTFdWUvDMCB3DocAJ8Lv /SC0SWzskU6sBq8XfITDqC5FXpEyEcgiUgXdSNvenErIOcbkCUd3SP0peCYuzKI8 HLMLTOoD0bO76riWUdVj1RABH7QD8r1J3+n1xfoU7Dc2x4D3busDxUgUlPuI4IMt Wz/MjEmIsats3Z/ezu4nXvfaY0Yn+bGwof5tVVEvjuhbizmWqwsvUktcmRLur+PF ATvI9r3Z0K1Q8Fghp7o8oB0mkW2fVEzXv6Taju5jEtG/a9OKnuvjfZ/Dsx4UZQYg /C0xHGg/yym4Nv25zygwtzpAdy5XjoO16O2dv4COwTF011LUEJrYpxtN/+sOlKy9 F4pftu3pKYJVG2ESMGNu0tu8WBfq4Arj3llyn47xAUY5yNobxJnq/l6YKS2c7lk/ 8BkuLqUMjeSIKIbDNWRTzMAFEhf9qfbO2a3QRaRDc2Mb0jWqKjOacCYM5x4RGAjQ wBWgiKjtpltj94Wx413X2nbtNOKnRCCYEquDqf6cqccRidUgsmdtuyZZWFPn9Pnc fpndLnCCHcvBU2wTez4A/C0c04t2b5J2Y4NULYwZaF3ToXXBOwDY3uCqhSfoGq6z fEfJCG7KJzdQhAOVunwnBFjnTW1Mvhca2xtM8zW1MG8VkYxmq7kFlCAMO0nHsW1S DOH8U3kjJzTS8v/RjQ0c1yOszEliM36T7/gpTTjbS3qQ14VT4zd2OckexQOTGota bagI3bEL0WP/juu8SALtLVv1jjCehCiSb0FTgNl/NF6t/h2tbusA1qlw+zs2AP+N lO7SFqk3N0rBNfn0iP8NhBsjkYo6c9De4WTUuSRE8c4NTeLXAo6+59zX07VuBKaf B7L3YbQkBCIqjoaGk8zYK66b3dddCX5v7DjytXS+e5wSCEnJyQ/g/eZuTI4sxKSw ofmubOIej9BrO2LGZrnuv1+wfNP9Q1mzauQqSaFMJcuVVa3fDl1zd5VueWd0Z/pF 8KIT7K4zjik2N7GS+a7Obdr9AHra44jh9hpqUlUz+EnMex4mFKIHzMgxvQLsYGEO tJo4pf8/2XF6EE9sVcZbmxeguI28KTxB27hpfYePlugSlYVRAWEhtG8gfYsXPOe3 y8Tsfey3Jlwg3Yf6kXasfIFF9Q7a/h6lOsAI3JjUFgDxpGJI9CoqZR9GsUqje5EZ nBBK8+xlVe9UBUexZ5vgy6hN6FhjdquVuvXwnMVnYnH5+XSIX+pY++4Pg/7URdQp kXNIna0E7TTl/u9mck0HnXGQ4mUOhpKZttdXZO2qtlg5apxq1r2kckdSZW2zduze IP6A6i1S9WBE16F74ZTp3KPc4uJ6XhAV+74HfTshBBF4qhzck7kGLLyr77Yl7z66 Sv+9WwTm2O6bDozUOMN8ATo/OgxcVllTqfEiid9nbFMkQwzl2csrnbPNfntZX9EP cjH5xRatWPVqWbRkuB3wnH2gitxuWJW2THq6DOQDhskshSsSflWU6kcVRCMcOCuY sqyfXYC6RKFzWhkgyS2P7+3F1yW6PYlqc4hk10FGq/lh25cReQWqCDzIwVgITjN4 S8T9sALhe3uefj6FkFvaFDAyyc0vye0pmJTpUz6Wv+f7Dh+BMzyEI8rWW/rCX23r AIgTGo31XxsQZ1qKMY0Fam8GJ1W4njvXxMImn/dC8PhdGZ8niWpdNl2iPdq05i+o jQdVmBLymN6d6wy2vaw/D3o7+8KGS06Ch7HZA3roNazuuhh9wBNilmCJ8vcFumX4 /yAgI3vkR5dug/gJQNP0QtDc5SJ6zzKWCOZWL76dNOMwZbD22vpPNlH0ECxCtrrH pz3rR2t3IuglkNfjFzrK =sQTk -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- From jabley@hopcount.ca Thu Oct 17 04:20: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 8948D11E81B4 for ; Thu, 17 Oct 2013 04:20:07 -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 nyR3N6GUOjY0 for ; Thu, 17 Oct 2013 04:20:06 -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 2CA8F11E827A for ; Thu, 17 Oct 2013 04:17:52 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id l4so1700394qcv.10 for ; Thu, 17 Oct 2013 04:17:51 -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=1eSeJULyUsFP2kiSYtUaNPw94q57nuZxTLjareAp9NU=; b=VrTPMMGPRqwPPkIWgliW8e35+eC0LntUXGaXDdX5C1r4UCGROaP1mQ9UTz+ng8WmUi 1mYmGuLRFHuM98FCAtzBLafa9ZPhFUJCtPRUPj7TWPpH+na7AKcyImDmALKVT6edVzjt 01yOSuBWC+u5VIN7yEwoScl2ggSb8Q0u7sEnA= 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=1eSeJULyUsFP2kiSYtUaNPw94q57nuZxTLjareAp9NU=; b=Kwhfb9Yz4syUcRcn07H53QuDIzQ/E3CyIBZzyuSFF6m9tX+QK0+HOAsQEwaNN/GmAL jscekC+WAIHtSPNp/Bn07xegoV22WYzrb5aMktR6MCpE0Ruc7O5FbPk7Q06iGYPmHImJ 5X1q+SYkncLRzqz86BZeB0ElciAZnwnW06JZIgPVLJld3cBEOZQ1KA0Evn+zUQzTnqMl 4URFmKvozdxKTJ6lG5LtGpIl2ONo6UOAThZ40IEeZ6Bd4jBD2HqG7zlsLiCRTccta0je LMJ+/TxfC+FQf41/lxz3NKcncsVBmjwmeayqoaj10B0nN0oKpCFAwDiEFRoeFyDiGn2A uY/g== X-Gm-Message-State: ALoCoQkNTtOl+78jSrJ3mpv3K3P1SdZw+IIm7KwHWO+AGQSMmCLYNpF7kMDFNvmAxGfvrX/rQwec X-Received: by 10.224.75.200 with SMTP id z8mr11125518qaj.71.1382008671449; Thu, 17 Oct 2013 04:17:51 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:1:98cb:25e2:54c7:79f5? ([2001:4900:1042:1:98cb:25e2:54c7:79f5]) by mx.google.com with ESMTPSA id 4sm175160460qak.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 04:17:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Joe Abley In-Reply-To: Date: Thu, 17 Oct 2013 07:17:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <23FA2E5D-F0F3-4D0B-AF7F-4402F68C37F4@hopcount.ca> References: To: Tony Finch X-Mailer: Apple Mail (2.1510) Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 11:20:07 -0000 On 2013-10-17, at 06:00, Tony Finch wrote: > Paul Wouters wrote: >>=20 >> Historically, DNS transactions over TCP only handle 1 query/answer. >=20 > Really? I was using persistent TCP connections back in the 1990s. They > work really nicely. I think the problem is not necessarily that serious authority server = implementations don't implement TCP; the problem is more that TCP = support is provided as a fallback mechanism with short server-side = timeouts and a small capacity for active sessions, and TCP from clients = is generally treated as the exception rather than the rule (we hope = they'll use it if we set TC=3D1, but otherwise we don't really expect = it). The goal of this option is to define a signalling mechanism whereby a = client and server can both be confident that the other side has set = these expectations aside, and instead might well prefer to do TCP over = UDP. This has implications for both the server and the client with = respect to the assumptions in the previous paragraph, the most obvious = of which is for a server to reign in any aggressive = close-after-response. The protocol elements in this -00 could surely use improvement. However, = the basic idea, as described above, is necessary if we want to find a = way to use pools of TCP connections between busy endpoints as an = alternative to the usual source-spoofed UDP spray. > Note also that RFC 5966 says that servers MUST support TCP and support > multiple queries per connection. I think edns-tcp-keepalive should be > compatible with that requirement. No argument there. Joe From ajs@anvilwalrusden.com Thu Oct 17 06:00:53 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 7581021F9BD3 for ; Thu, 17 Oct 2013 06:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoa5jzjXjGVs for ; Thu, 17 Oct 2013 06:00:43 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 08FE811E8112 for ; Thu, 17 Oct 2013 06:00:36 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C016A8A031 for ; Thu, 17 Oct 2013 13:00:33 +0000 (UTC) Date: Thu, 17 Oct 2013 09:00:31 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20131017130031.GA1596@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 13:00:53 -0000 On Wed, Oct 16, 2013 at 11:05:37AM -0400, Paul Wouters wrote: > it has become in practise. Joe and I therefor thought it would be best > to leave that existing deployment as-is, and use a new option to clearly > unambiguously indicate that yes we will actually allow more than one > query and actively encourage it. That was our number one goal. I very strongly agree with this, and I like the overall approach this document takes. The problem with the STD13 specification is that neither side of the connection has any guidance as to how the other side will behave. The most prudent thing to do in that case is to use a connection one time and then tear down as soon as possible, even though that's not by any means the best thing for either side. This option gives a way for both sides to co-ordinate their behaviour; it's a good example of the sort of interoperability enhancement that we should like to see. It provides an incentive to keep connections up. Clever implementations could even use different timeouts for different connections, based in part on things like recent rate of queries, the reputation of the connecting IP, and so on. I thank Paul and Joe for writing this up. I think it's something we need. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From tale@dd.org Thu Oct 17 06:51:44 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 91FC211E81DD for ; Thu, 17 Oct 2013 06:51:44 -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 MCqAZWlGx06B for ; Thu, 17 Oct 2013 06:51:39 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0B45211E825F for ; Thu, 17 Oct 2013 06:51:37 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 34A773F432; Thu, 17 Oct 2013 09:51:36 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21087.60263.989338.253036@gro.dd.org> Date: Thu, 17 Oct 2013 09:51:35 -0400 From: Dave Lawrence To: Paul Wouters In-Reply-To: References: Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 13:51:46 -0000 Paul Wouters writes: > But unless I hear more people who would favour making the new option > more "optional" I think we should stick to this more clear cut of > the undefined past behaviour. Just for the record, to balance out any comments for changing course, I support this approach. I do not speak for my employer, but I expect that we would implement it in our nameserver. From fanf2@hermes.cam.ac.uk Thu Oct 17 10:16:45 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 C6DA911E8138 for ; Thu, 17 Oct 2013 10:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VDY3G-q08Zd for ; Thu, 17 Oct 2013 10:16:45 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f52]) by ietfa.amsl.com (Postfix) with ESMTP id 78C4A21F942D for ; Thu, 17 Oct 2013 10:16:43 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:49153) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1VWrBe-00022E-D8 (Exim 4.80_167-5a66dd3) (return-path ); Thu, 17 Oct 2013 18:16:38 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VWrBd-0007Mo-Tz (Exim 4.72) (return-path ); Thu, 17 Oct 2013 18:16:37 +0100 Date: Thu, 17 Oct 2013 18:16:37 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Lawrence In-Reply-To: <21087.60263.989338.253036@gro.dd.org> Message-ID: References: <21087.60263.989338.253036@gro.dd.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 17:16:45 -0000 Dave Lawrence wrote: > Paul Wouters writes: > > But unless I hear more people who would favour making the new option > > more "optional" I think we should stick to this more clear cut of > > the undefined past behaviour. > > Just for the record, to balance out any comments for changing course, > I support this approach. I am worried that this will make edns-tcp-keepalive clients perform unnecessarily badly when talking to RFC 5966 servers, so developers are going to have to add a configuration switch to make the client do persistent TCP even in the absence of edns-tcp-keepalive. This is ugly: it should be handled automatically by the protocol not by system integrators debugging performance problems. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From jabley@hopcount.ca Thu Oct 17 10:30:23 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 80B2411E8146 for ; Thu, 17 Oct 2013 10:30:23 -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 LjXN2AiPGxJB for ; Thu, 17 Oct 2013 10:30:22 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CA73E11E818C for ; Thu, 17 Oct 2013 10:30:19 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id c9so1782099qcz.3 for ; Thu, 17 Oct 2013 10:30:19 -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=xz/Ilc5gjR44HBswb+BJb7Z32t/6dyXL5ULbd+Wv3eE=; b=Mn4UrhOsMCyQ3DZW97kV5eZusvt759Uod4GUxXTNfGXFNh9GD4SK0GkETX7X2x5WBx 4DCZ6s0Ln4TobZC9iNZSvOjGsB9B+rcfa5SidzdhTktOaHDtIziGUqHTOyxjNJdSNKdM 41kg3joQ4Zgt/DXZ1i4CytSGM1xeMrb96fQIM= 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=xz/Ilc5gjR44HBswb+BJb7Z32t/6dyXL5ULbd+Wv3eE=; b=i374TQ3A/02lu6jQd8Z+ky+vI2/16RLWGhELdwOKNhJ2/xOII1PE2CK8u9XihkverN jwHd35gA/o78PwJy0mXNKmmga7+iD+T2RQK8xqlAfAEG1rz7f0h+qHf8mtnE07Fr8plP DS0qUyvJycE1/yjUuJBzkF9pZnFcCvRZJLrs2NCWRRMFmHCjwtFvwkxke9oZ9UsPFMMh /sV1bAGFfCnSRuOYSo0UdcTNZQWoEcC9VEkStTk28xOLtJknhexBT82krHpCLFDpEvm1 MY5q4+ihVH2jGkitb6rQQUNV1rTdsmmIPLyAzssbZQkOJ9vYKACEf3I6hkGA2MpC23GV ceAQ== X-Gm-Message-State: ALoCoQmAJnjOPu0wDSbXfPiPSMEhf4+a6l2j+IWOf05em3pOsM9ntynFKEblbfh9ypxu4jZi6FSt X-Received: by 10.224.1.194 with SMTP id 2mr13933229qag.70.1382031019272; Thu, 17 Oct 2013 10:30:19 -0700 (PDT) Received: from [199.212.90.44] (135-23-68-78.cpe.pppoe.ca. [135.23.68.78]) by mx.google.com with ESMTPSA id d7sm98905783qas.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 10:30:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Joe Abley In-Reply-To: Date: Thu, 17 Oct 2013 13:30:17 -0400 Content-Transfer-Encoding: 7bit Message-Id: <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> References: <21087.60263.989338.253036@gro.dd.org> To: Tony Finch X-Mailer: Apple Mail (2.1510) Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 17:30:23 -0000 On 2013-10-17, at 13:16, Tony Finch wrote: > I am worried that this will make edns-tcp-keepalive clients perform > unnecessarily badly when talking to RFC 5966 servers, could you explain how? Joe From marka@isc.org Thu Oct 17 15:40:17 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 7D65511E80E0 for ; Thu, 17 Oct 2013 15:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, GB_I_INVITATION=-2] 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 imvdNjVFa7vR for ; Thu, 17 Oct 2013 15:40:12 -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 2077921F96E4 for ; Thu, 17 Oct 2013 15:40:12 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 7D8C5C9424; Thu, 17 Oct 2013 22:39:58 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1382049611; bh=15RF+2TL2mV5teesufvwcHNhQqet2N0M0CpsU6krz1U=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=PzWlaeSKvtWzIZbiNlWJg7Kn/u9fkg/xEcBhMw80gSIAxCAqPNCMGUguPIvsMJfUy 2ha/XuQCDf7gtidUa6/yFw68IaTljKVm/YFLUs9Wq/ji/xpGSWsu9PEJ2hPn4P3cZ/ xNY3PLKWgWTS78NCVT/0w/8+DN2i8r4/7ErVHvkQ= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 17 Oct 2013 22:39:58 +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 BF24B160470; Thu, 17 Oct 2013 22:44:19 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 88FBB160446; Thu, 17 Oct 2013 22:44:19 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 1D34B8529A2; Fri, 18 Oct 2013 09:39:56 +1100 (EST) To: Joe Abley From: Mark Andrews References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> In-reply-to: Your message of "Thu, 17 Oct 2013 13:30:17 -0400." <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> Date: Fri, 18 Oct 2013 09:39:55 +1100 Message-Id: <20131017223956.1D34B8529A2@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 22:40:17 -0000 In message <516321C1-1988-4946-A524-B2529752726F@hopcount.ca>, Joe Abley writes : > > On 2013-10-17, at 13:16, Tony Finch wrote: > > > I am worried that this will make edns-tcp-keepalive clients perform > > unnecessarily badly when talking to RFC 5966 servers, > > could you explain how? Yes please explain. For DNSSEC you just send the requests then look for the responses. You can even send the multiple requests in one write operation. Even a RFC 5966 server which has the timers turned down to a couple of seconds will see the multiple requests. RFC 5966 servers are still expected to handle multiple requests over a single TCP connection. RFC 5966 changes RFC 1035 by dropping the "two minutes" down to "a couple of seconds". 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. No where does RFC 5966 say "read a single request then close the socket". No where does RFC 1035 say "read a single request then close the socket". No where does RFC 5966 say "read a single request then close the socket unless it is a SOA query". No where does RFC 1035 say "read a single request then close the socket unless it is a SOA query". Nameservers that "read a single request then close the socket" with or without "unless it is a SOA query" are not following RFC 1035. The forth recommendation is about choosing which socket to close if you are FORCED to close a socket. It is not a invitation to always close the socket if the first request is not a SOA request. Now I am not saying that telling the server that you intend to send more requests over this socket is a bad thing but it shouldn't be necessary to be able to pipeline multiple DNSSEC requests over a single socket. A nameserver that does not attempt to read a second request on a TCP socket is *broken*. If you are the vendor of such a product fix it and issue a update notice. Mark > Joe > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From paul@nohats.ca Thu Oct 17 17:17: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 09C3811E8149 for ; Thu, 17 Oct 2013 17:17: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 hMoiEKp3rUKQ for ; Thu, 17 Oct 2013 17:17:51 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3B62F11E8190 for ; Thu, 17 Oct 2013 17:17:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d179j1wJlzDML; Thu, 17 Oct 2013 20:17:45 -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 R2Woi9SF2oXy; Thu, 17 Oct 2013 20:17:44 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 17 Oct 2013 20:17:44 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 650CC807D2; Thu, 17 Oct 2013 20:17:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 58D23807CA; Thu, 17 Oct 2013 20:17:45 -0400 (EDT) Date: Thu, 17 Oct 2013 20:17:45 -0400 (EDT) From: Paul Wouters To: Mark Andrews In-Reply-To: <20131017223956.1D34B8529A2@rock.dv.isc.org> Message-ID: References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> <20131017223956.1D34B8529A2@rock.dv.isc.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-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 00:17:57 -0000 On Fri, 18 Oct 2013, Mark Andrews wrote: > A nameserver that does not attempt to read a second request on a > TCP socket is *broken*. If you are the vendor of such a product > fix it and issue a update notice. Do you still see value in the edns-tcp-keepalive and timeout value, or do you think dns clients can already assume they can sent multiple queries and keep the tcp connection open for a reasonably time as per RFC 5966? Is there any measurement data out there to see how well multiple queries over TCP works? Paul From marka@isc.org Thu Oct 17 17:58: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 8DA7211E82D9 for ; Thu, 17 Oct 2013 17:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 JVNs1On9FhEu for ; Thu, 17 Oct 2013 17:58:00 -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 7FD1711E82D7 for ; Thu, 17 Oct 2013 17:57:43 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 5721EC94BD; Fri, 18 Oct 2013 00:57:30 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1382057863; bh=1NAyRx3eINKcCj9zhrJpzrGMelTYY5/T6RKrbINZP3I=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=UXH+t1ryIYTSdDfCW94TWsIJpEXaGG8AVt4sN8gKH9R2IBTlVKP5+UB6aTjJpstH9 I1APwLLd0y8gy/Q0ODXZtsSB/klssuPsxHV9i+cAiEh+8llSfFYtfrOndfBUyaGOMb IRgKLnRUPGAsD5X9pXd2yiUIs5fcI+D06UBb1Cfs= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 18 Oct 2013 00:57:30 +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 0C0B3160470; Fri, 18 Oct 2013 01:01:52 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id D2400160446; Fri, 18 Oct 2013 01:01:51 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 87613854260; Fri, 18 Oct 2013 11:57:27 +1100 (EST) To: Paul Wouters From: Mark Andrews References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> <20131017223956.1D34B8529A2@rock.dv.isc.org> In-reply-to: Your message of "Thu, 17 Oct 2013 20:17:45 -0400." Date: Fri, 18 Oct 2013 11:57:27 +1100 Message-Id: <20131018005727.87613854260@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 00:58:05 -0000 In message , Paul Wouters w rites: > On Fri, 18 Oct 2013, Mark Andrews wrote: > > > A nameserver that does not attempt to read a second request on a > > TCP socket is *broken*. If you are the vendor of such a product > > fix it and issue a update notice. > > Do you still see value in the edns-tcp-keepalive and timeout value, > or do you think dns clients can already assume they can sent multiple > queries and keep the tcp connection open for a reasonably time as per > RFC 5966? It will either work (the server is conformant and not over loaded) or it won't (the server is over loaded or broken). Sending multiple queries over TCP is a optimisation. If there is more than one broken vendor then writing a RFC saying this is a common problem may be useful. > Is there any measurement data out there to see how well multiple queries > over TCP works? > > Paul -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fanf2@hermes.cam.ac.uk Fri Oct 18 03:40:33 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 F39EC11E81DA for ; Fri, 18 Oct 2013 03:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 QtTXyO63VrK2 for ; Fri, 18 Oct 2013 03:40:32 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f52]) by ietfa.amsl.com (Postfix) with ESMTP id F3E9F11E81DC for ; Fri, 18 Oct 2013 03:40:30 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39495) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1VX7Tl-0005Lx-Eq (Exim 4.80_167-5a66dd3) (return-path ); Fri, 18 Oct 2013 11:40:25 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VX7Tl-00059E-GP (Exim 4.72) (return-path ); Fri, 18 Oct 2013 11:40:25 +0100 Date: Fri, 18 Oct 2013 11:40:25 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Joe Abley In-Reply-To: <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> Message-ID: References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 10:40:33 -0000 Joe Abley wrote: > On 2013-10-17, at 13:16, Tony Finch wrote: > > > I am worried that this will make edns-tcp-keepalive clients perform > > unnecessarily badly when talking to RFC 5966 servers, > > could you explain how? An RFC 5966 server supports persistent TCP but does not advertise this fact. An edns-tcp-keepalive client interprets this lack of advertisement as lack of support, so it will send only one query per TCP connection. This increases latency and means it can't make concurrent queries over TCP without multiple TCP connections, and for high query volumes it risks port exhaustion from all the FIN-WAIT-2 states. If you run the client in RFC 5966 mode then it will try persistent TCP regardless of what the server says and avoid these problems. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From Ray.Bellis@nominet.org.uk Fri Oct 18 04:04:16 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 8097011E81CA for ; Fri, 18 Oct 2013 04:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDUzPFGYaba8 for ; Fri, 18 Oct 2013 04:04:11 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id D4A8821F9D50 for ; Fri, 18 Oct 2013 04:04:08 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=wPEHwTE9s5s5OzCgRA583EwVy83/dRNhvHMou+Apuw0IBclNuWRVSryY DWDvHjgZbWwvp/l3oOt4JWw0JKHn1FY4I165Vkl1Z5oi1kFrVczDiwkZS ZflimrGKmSGZWwLmm/66pPoj7jNYyyXJXX3AtoNrYEVc9TEy1T8A7Vfm8 2lXS+SwjcRgMYdGwql6cA3SIJdkF2ENISK1sP2OuF3buUpDgJ4HEOtL3i phbj/oRnluMqQyo4GQsD8mmPsdk5m; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1382094249; x=1413630249; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=P9XphxjPwt6huXeqix9JNMuNN7d/LztqitUDHY6IdG4=; b=Kb2r4RbYkmKrKrboSWE6BFE+mcs6sPkN41KeeaQOb7KZLOVvYWzXqshO dz4e4eV6u86/rhsSjSRpie6+zNETquyjYrytCdkXF9CQGlmliMBfVFIlZ ZvFYtbAwrbTZvNmqB4FrmSm9BT3YS0/YD2EHktjCH5o+qYnk2dtCGWMda lHytgFvopfGlIB71MAbguGaSkxuhFyzskK4yexmNBiFeGtTwKDD+TFj/i Oq8TMwLw09wt4aDYMniKoGRVM1uH/; X-IronPort-AV: E=Sophos;i="4.93,521,1378854000"; d="scan'208";a="4154337" X-IPAS-Result: AhgFAEoUYVLV+MWR/2dsb2JhbABagmYhgQq+F4ElFnSCJQEBAQECAToZJAIFCwIBCA4UFBAyJQIEDgUIh3gHA8Bdjx4CMQeDH4EKA6oQgWaBPoIp Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 18 Oct 2013 12:04:07 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 12:04:07 +0100 From: Ray Bellis To: Tony Finch Thread-Topic: [dnsext] New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) Thread-Index: AQHOy/HDlvj/7G7aP0yje+ZQojdRYA== Date: Fri, 18 Oct 2013 11:04:06 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DED54D6@wds-exc1.okna.nominet.org.uk> References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <4335D1F2E000204F97201574BE920740@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 11:04:16 -0000 On 18 Oct 2013, at 11:40, Tony Finch wrote: > An RFC 5966 server supports persistent TCP but does not advertise this > fact. It shouldn't have to - every DNS server should already support persistent T= CP. Mostly, all that 5966 did was clarify the requirements to support TCP = *at all* and drop the minimum idle time. The use of an individual TCP session per query is client habit, and in no w= ay mandated by anything in the earlier DNS documents. Ray From jabley@hopcount.ca Fri Oct 18 04:32: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 E997311E8103 for ; Fri, 18 Oct 2013 04:32:28 -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 eD6KOVMqJSHq for ; Fri, 18 Oct 2013 04:32:28 -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 E550111E81B1 for ; Fri, 18 Oct 2013 04:32:24 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id ar20so6074235iec.26 for ; Fri, 18 Oct 2013 04:32:24 -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=75GBnzfyFmoFPJ+BNsNfRdQgaSvWCt9DXlkra1Zy9rg=; b=of7fySwx9OCEgMnNKe7sqHfR1jCakUurWp/zCuAyntVtuZEbJjf8slq+7rSFUhtZSA 3JmUk8y6pxsJnnmVRmJK1mnGtkSyzdLZdZf7Jjzgt3D6AizFSXDyAGvb9BsW3Ge5FJyb mhanf/8uzsOM7RXcIA9SiboNT71AhBqoBLL3I= 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=75GBnzfyFmoFPJ+BNsNfRdQgaSvWCt9DXlkra1Zy9rg=; b=GztCDW2r8yy7xb1ZIF/hRrS0PIxuojdZ/x7hBOh5+YSdoQ207IgOve/JtN/Be0q9+a BoXtHfDno4Mz+w3DyYneBh+u0KokcUXTOdd5ZKl91h+OjKyfawm0swocNFf4PwxbS4Fc ldQqzNJMc2LH/HoBhO1D2q60X/0Sf0OE7LkO71BAl5aXtqe9cY4toEs0VUUbPaVsyBRR u/pWlarO6aaEAgzs4AD+ah3aNnZkq6mKtG9Cr1d9iHwsrWvwqN6PWFWpmgT+9IHvjXsz XQhoebLtE395CsZors7Imf1vHZO+8NdZ1nzK7GWPEFI54ViO4LhNaB97d0/eDVL7t939 JZbA== X-Gm-Message-State: ALoCoQnKNb0EUnVyRdD5NEhgnzVj/yt/9exU4LJVg4Vo0pXpaRFxT5kG3VKvoUOuTJ9jcPCsfk5w X-Received: by 10.50.20.99 with SMTP id m3mr2255359ige.54.1382095944192; Fri, 18 Oct 2013 04:32:24 -0700 (PDT) Received: from [199.212.90.44] ([135.23.68.78]) by mx.google.com with ESMTPSA id i3sm1095028igh.0.2013.10.18.04.32.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 04:32:23 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Joe Abley In-Reply-To: Date: Fri, 18 Oct 2013 07:32:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4AF34D3B-CB94-417A-BE05-4021C68AA5CC@hopcount.ca> References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> To: Tony Finch X-Mailer: Apple Mail (2.1510) Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 11:32:29 -0000 On 2013-10-18, at 06:40, Tony Finch wrote: > Joe Abley wrote: >> On 2013-10-17, at 13:16, Tony Finch wrote: >>=20 >>> I am worried that this will make edns-tcp-keepalive clients perform >>> unnecessarily badly when talking to RFC 5966 servers, >>=20 >> could you explain how? >=20 > An RFC 5966 server supports persistent TCP but does not advertise this > fact. I think we all agree on this. > An edns-tcp-keepalive client interprets this lack of advertisement > as lack of support, so it will send only one query per TCP connection. What we're trying to optimise is (a) the ability for a server to manage a finite resource (a TCP = connection pool) in a way that is most likely to result in those sockets = being well-used; (b) the ability for a client who desires multiple exchanges over the = same TCP socket to know what the timeout on the server is, so that it = knows when to fall back to UDP. In the case of a busy resolver (Google, OpenDNS, Comcast, whatever) = sending regular and frequent queries to a busy server (one of the CO.UK = servers, say) perhaps the "few seconds" timeout on the server is not an = issue. But if the server has the resources to keep a TCP socket open to = receive 0.3 queries per second from a particular resolver, the ability = to use this signalling to extend the timeout on the server side allows = multiple exchanges where normal behaviour (absent signalling) would not. In the case of a mobile device sending less frequent queries to a = resolver, the default TCP timeout on the server might well be a problem. = A busy resolver might not be able to spare the resources to keep the = socket open for such a client today, but the idea here is to think ahead = to a world where TCP is not the exception to the rule and perhaps some = of the scaling techniques used by web servers that can support orders of = magnitude more concurrent TCP connections than most DNS servers do = today. Keeping the socket open on the server for a relatively low query rate = from a resolver avoids the overhead of closing and reopening a TCP = socket, and provides source address validation of the client, protecting = it from collateral damage that might result from (e.g.) RRL. I think the potential advantages are non-imaginary. > This increases latency and means it can't make concurrent queries over = TCP > without multiple TCP connections, and for high query volumes it risks = port > exhaustion from all the FIN-WAIT-2 states. If you run the client in = RFC > 5966 mode then it will try persistent TCP regardless of what the = server > says and avoid these problems. So the key observation here, if I'm reading it correctly, is that = clients might reasonably try to re-use an open socket even if the = edns-tcp-keepalive option is not present, anticipating a short (but not = impossible) timeout on the server side. Joe= From tale@dd.org Fri Oct 18 06:24:20 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D1B11E8112 for ; Fri, 18 Oct 2013 06:24:17 -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 myiRFWluC9-r for ; Fri, 18 Oct 2013 06:24:12 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2F611E812D for ; Fri, 18 Oct 2013 06:24:09 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 9F1FA3F438; Fri, 18 Oct 2013 09:24:04 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21089.13940.466083.947280@gro.dd.org> Date: Fri, 18 Oct 2013 09:24:04 -0400 From: Dave Lawrence To: Tony Finch In-Reply-To: References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 13:24:20 -0000 Tony Finch writes: > Joe Abley wrote: > > On 2013-10-17, at 13:16, Tony Finch wrote: > > > I am worried that this will make edns-tcp-keepalive clients perform > > > unnecessarily badly when talking to RFC 5966 servers, > > > > could you explain how? > > An RFC 5966 server supports persistent TCP but does not advertise this > fact. An edns-tcp-keepalive client interprets this lack of advertisement > as lack of support, so it will send only one query per TCP connection. So your concern is about as-yet-unwritten software being written badly? This can't be reasonably addressed by references in the proposed RFC along the lines of "The DNS standard has always been to support multiple requests over TCP (ref: 1035 and 5966), therefore a client that does not receive the keepalive option from the server SHOULD assume that multiple requests are supported until demonstrated otherwise." People will still write bad software, but it's not like they weren't informed. From paul@nohats.ca Fri Oct 18 06:28:23 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 E2FF911E8112 for ; Fri, 18 Oct 2013 06:28:22 -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 2oyV2UIxm1dJ for ; Fri, 18 Oct 2013 06:28:09 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2B711E81D1 for ; Fri, 18 Oct 2013 06:27:56 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d1SjF4t14zDMq; Fri, 18 Oct 2013 09:27:45 -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 pBL5tvCcZigY; Fri, 18 Oct 2013 09:27:45 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 18 Oct 2013 09:27:45 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 8DC6E807D1; Fri, 18 Oct 2013 09:27:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 81AE0807CA; Fri, 18 Oct 2013 09:27:45 -0400 (EDT) Date: Fri, 18 Oct 2013 09:27:45 -0400 (EDT) From: Paul Wouters To: Tony Finch In-Reply-To: Message-ID: References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> 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-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 13:28:23 -0000 On Fri, 18 Oct 2013, Tony Finch wrote: >>> I am worried that this will make edns-tcp-keepalive clients perform >>> unnecessarily badly when talking to RFC 5966 servers, >> >> could you explain how? > > An RFC 5966 server supports persistent TCP but does not advertise this > fact. I hope to have some measurements done in time for Vancouver to see what the percentage of queries/servers is where this is a problem. That could help assess whether or not we still need a special indication via edns or not. Paul From marka@isc.org Fri Oct 18 07:12:04 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 ED9A011E8268 for ; Fri, 18 Oct 2013 07:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 LO3t-5frfqoU for ; Fri, 18 Oct 2013 07:12:00 -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 CC43711E8278 for ; Fri, 18 Oct 2013 07:11:59 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 9C726C9478; Fri, 18 Oct 2013 14:11:46 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1382105519; bh=1V2gOECQ3Un4RtS5fsgcAQTdV0FIdTFmQ907wl2/Q14=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=dBqSHSh/bSKweXGCET6FQSs67mMjoqxvlBf1iHjSo+mBdJsrlIk9LdRy1agEkExy1 9YxH6sxzbilCy/rHZNsdLm6C9/ZOVJa2NNp+1WwZRY3sLv9JEBPwmrQHjzwnyiV27I 6nW0OcaAszy1SstOe8XItwzsTesjNkYklLmMBa/U= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 18 Oct 2013 14:11:46 +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 B8E38160470; Fri, 18 Oct 2013 14:16:10 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 8A6FF160446; Fri, 18 Oct 2013 14:16:10 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 344FD85CD4D; Sat, 19 Oct 2013 01:11:43 +1100 (EST) To: Paul Wouters From: Mark Andrews References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> In-reply-to: Your message of "Fri, 18 Oct 2013 09:27:45 -0400." Date: Sat, 19 Oct 2013 01:11:43 +1100 Message-Id: <20131018141143.344FD85CD4D@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 14:12:05 -0000 In message , Paul Wouters w rites: > On Fri, 18 Oct 2013, Tony Finch wrote: > > >>> I am worried that this will make edns-tcp-keepalive clients perform > >>> unnecessarily badly when talking to RFC 5966 servers, > >> > >> could you explain how? > > > > An RFC 5966 server supports persistent TCP but does not advertise this > > fact. > > I hope to have some measurements done in time for Vancouver to see what > the percentage of queries/servers is where this is a problem. That could > help assess whether or not we still need a special indication via edns > or not. Why? Clients should be able to handle the connection being closed unexpectedly and retry any uncompleted queries. > Paul > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From paul@nohats.ca Fri Oct 18 07:22:04 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 8AA8D11E82B1 for ; Fri, 18 Oct 2013 07:22:04 -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 7SintwA6IQox for ; Fri, 18 Oct 2013 07:21:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id C1E5B11E81CF for ; Fri, 18 Oct 2013 07:21:57 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d1Tvl06CxzDMr; Fri, 18 Oct 2013 10:21:55 -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 SbXkxI-zASyO; Fri, 18 Oct 2013 10:21:53 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 18 Oct 2013 10:21:53 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 50612807D1; Fri, 18 Oct 2013 10:21:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 426FF807CA; Fri, 18 Oct 2013 10:21:54 -0400 (EDT) Date: Fri, 18 Oct 2013 10:21:54 -0400 (EDT) From: Paul Wouters To: Mark Andrews In-Reply-To: <20131018141143.344FD85CD4D@rock.dv.isc.org> Message-ID: References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> <20131018141143.344FD85CD4D@rock.dv.isc.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-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 14:22:04 -0000 On Sat, 19 Oct 2013, Mark Andrews wrote: >>> An RFC 5966 server supports persistent TCP but does not advertise this >>> fact. >> >> I hope to have some measurements done in time for Vancouver to see what >> the percentage of queries/servers is where this is a problem. That could >> help assess whether or not we still need a special indication via edns >> or not. > > Why? Clients should be able to handle the connection being closed > unexpectedly and retry any uncompleted queries. I'm trying to reduce dns(sec) latency, not adding more repeating tcp failures. If it turns out that most obtained DNS resolvers are useless for TCP than there is a need to give a clear indication to a client that a resolver does work well. The question is how pervasive are rfc 5966 compliant resolvers out there, and whether there is a need to advertise those who are. Paul From Ray.Bellis@nominet.org.uk Fri Oct 18 07:31:59 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 A9A9B11E81CF for ; Fri, 18 Oct 2013 07:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQrimXbbNe3Y for ; Fri, 18 Oct 2013 07:31:54 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id ECFA811E81CD for ; Fri, 18 Oct 2013 07:31:50 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=vt1YUcipW7aYvLpRr62rbfDdec+eCifgUWnH6Q4KBuwOtheC2RovK69n tNLubq3Gikuo4+OxdgYovD3nYAnhmiAV4tfUA0ljU/2RumfZNaqWZksk6 He8Y0uhqG/9pHt3vi1YFKuwIQsZttJnusWzU+ooa+A/kprw2AOWI6elcF zDx0zhcy+gACRVv4BHfeHiq7mVl5zg+z9pWbKIcpd1EmO+0894CvPA6Vm jrOWRXmmEsYnqfMi0XW1MWbe+KL6E; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1382106711; x=1413642711; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fSYKNAi7nHAr9iPc/e6254dYPlSPPEZg0eU1EWtMABI=; b=rE1rBzlARU1cgcY4Gn1N2QPCStT/EDXiDRuPp32ffNVf+hoR9ZNm0qk8 CB+gdNk8BtObnxYgzXDJr1GFbk7t9PSCyXENi/QUE7K50bPHb0SCstEUr /UNfHf6im1zS/2HADOSHqhO9IfQOxzNaJINUvWtoUGl7ZTyMUmgmtufZu Surcicp/jYBjsMhz91XWFMIgUP5xVJDbF/LIReaDCS9EqF4pzRcWmIDou lCA5hJsiGwxNGTcAsDay6jj96vDIY; X-IronPort-AV: E=Sophos;i="4.93,523,1378854000"; d="scan'208";a="4166018" X-IPAS-Result: AhQFALxFYVLV+MWR/2dsb2JhbABagmYhgQq+IIEhFnSCJQEBAQECAToZJAIFCwIBCCIUEDIlAgQOBQiHeAcDwH+PIwIxB4MfgQoDlCqVZoFmgT6CKQ Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 18 Oct 2013 15:31:49 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Fri, 18 Oct 2013 15:31:49 +0100 From: Ray Bellis To: Paul Wouters Thread-Topic: [dnsext] New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) Thread-Index: AQHOzA7Hx7AAdQU+ZEG7w1DzAHr/3A== Date: Fri, 18 Oct 2013 14:31:47 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DED6639@wds-exc1.okna.nominet.org.uk> References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> <20131018141143.344FD85CD4D@rock.dv.isc.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] 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] New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 14:31:59 -0000 On 18 Oct 2013, at 15:21, Paul Wouters wrote: > The question is how pervasive are rfc 5966 compliant resolvers out > there, and whether there is a need to advertise those who are. As the author of RFC 5966, I'm confused by your use of "5966 compliant". AFAICR (and assuming a server that already supports TCP) the only significa= nt normative change in RFC 5966 was the recommendation to drop the idle tim= eout from two minutes down to being "of the order of seconds". Everything else was just clarification of stuff from previous RFCs that mos= t people took as read, but wasn't necessarily written down as clearly as it= might have been. Any enterprise grade DNS server that does already support TCP should handle= multiple queries over the same socket without complaint. kind regards, Ray From fanf2@hermes.cam.ac.uk Fri Oct 18 10:07:01 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 B3F4B11E82E7 for ; Fri, 18 Oct 2013 10:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntMiyKzbUYGO for ; Fri, 18 Oct 2013 10:06:59 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f52]) by ietfa.amsl.com (Postfix) with ESMTP id 2C23121F9DAF for ; Fri, 18 Oct 2013 10:05:52 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:54738) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1VXDUV-0005Av-Dq (Exim 4.80_167-5a66dd3) (return-path ); Fri, 18 Oct 2013 18:05:35 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VXDUV-0001UI-74 (Exim 4.72) (return-path ); Fri, 18 Oct 2013 18:05:35 +0100 Date: Fri, 18 Oct 2013 18:05:35 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Lawrence In-Reply-To: <21089.13940.466083.947280@gro.dd.org> Message-ID: References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> <21089.13940.466083.947280@gro.dd.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:07:01 -0000 Dave Lawrence wrote: > Tony Finch writes: > > > > An RFC 5966 server supports persistent TCP but does not advertise this > > fact. An edns-tcp-keepalive client interprets this lack of advertisement > > as lack of support, so it will send only one query per TCP connection. > > So your concern is about as-yet-unwritten software being written > badly? No, the above is what edns-tcp-keepalive specifies. It says: The DNS server MAY omit including the edns-tcp- keepalive option if it deems its local resources are too low to service more TCP keepalive sessions. So a correctly written client that follows this spec will interpret the absence of the option as lack of support for persistent TCP. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From tim.wicinski@teamaol.com Fri Oct 18 10:14:48 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 A0CAC11E8320 for ; Fri, 18 Oct 2013 10:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tnB+lTtN-44 for ; Fri, 18 Oct 2013 10:14:42 -0700 (PDT) Received: from omr-m09.mx.aol.com (omr-m09.mx.aol.com [64.12.143.82]) by ietfa.amsl.com (Postfix) with ESMTP id DF49011E8293 for ; Fri, 18 Oct 2013 10:14:39 -0700 (PDT) Received: from AOLDTCMEI33.ad.aol.aoltw.net (aoldtcmei33-redir.office.aol.com [10.180.121.156]) by omr-m09.mx.aol.com (Outbound Mail Relay) with ESMTP id 4D056700000BA; Fri, 18 Oct 2013 13:14:39 -0400 (EDT) Received: from [10.172.255.120] (172.17.8.193) by AOLDTCMEI33.ad.aol.aoltw.net (10.180.121.160) with Microsoft SMTP Server id 14.3.123.3; Fri, 18 Oct 2013 13:14:39 -0400 Message-ID: <52616C7E.3000408@teamaol.com> Date: Fri, 18 Oct 2013 13:14:38 -0400 From: Tim Wicinski User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Jay Daley , "dnsext@ietf.org Group" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.8.193] Subject: Re: [dnsext] Extending UPDATE to add/remove zones X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:14:48 -0000 While this is discussed in dnsext, but there is a lot of good discussion on this, I wonder if we should carve out some time during DNSOP to discuss this? tim On 10/16/13 5:33 AM, Jay Daley wrote: > From my previous post on my draft for a new DNS opcode - servezones - I think there is reasonable interest in an in-band mechanism that instructs a nameserver to etiher start or stop serving one or more zones. The area with less certainty is what that mechanism should be, a new Opcode (but it's only a 4 bit space!) or extending UPDATE. > > I'm planing to write a draft that shows how UPDATE could be extended to do this and then we can compare that with my servezones draft and see which is preferred. To do that I'd like some help in determining the algorithm for how the extended UPDATE is processed. > > Here's my starter for 10. > > 1. A new EDNS option code is assigned that changes the behaviour of the UPDATE as follows (alternatively this could be signalled with a ZTYPE different from SOA) > > 2. The ZONE section specifies the zones to be added/removed. There can be any number of zones listed here to add or remove. For each zone, if the CLASS is ANY then the zone is to be removed, whereas if it is ANY then the zone is to be added. This use of CLASS corresponds to the way that it is used to determine if an rrset should be added or removed in the current UPDATE message. > > 3. The pre-requisite section is ignored. > > 4. The Update section can only contain Adds and only when zones are to be added. If any records are specified here then that means that the zones to be added are masters and these records are all added to those zones before serving begin. None of these records may be fully qualified so as to ensure that they apply to all the zones listed. One of these records must be a SOA record with an empty name, which will be replaced with the zone name > > 5. If there is data in the Additional section then that signifies that the zones to be added are slaves. The records here must be NS records that specify the masters for the zones to be added. There can only be records here or in the Update section but not both as zones cannot be both masters and slaves. > > Is that it? Anything need changing? > > > BTW we could extend this just a little bit more: > > 6. If there is a DNSKEY record in the Additional section then this specifies a TSIG key that this server should use for pulling the zone. The name for the DNSKEY record is the name of the key as used by TSIG. This DNSKEY is not added into the zone. > > > Jay > From fanf2@hermes.cam.ac.uk Fri Oct 18 10:36:40 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 233DB11E819D for ; Fri, 18 Oct 2013 10:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 ADzX4N4ED5ng for ; Fri, 18 Oct 2013 10:36:39 -0700 (PDT) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id 1436D11E8231 for ; Fri, 18 Oct 2013 10:36:36 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:33035) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1VXDyQ-0005S3-7a (Exim 4.80_167-5a66dd3) (return-path ); Fri, 18 Oct 2013 18:36:30 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VXDyQ-0003VI-9l (Exim 4.72) (return-path ); Fri, 18 Oct 2013 18:36:30 +0100 Date: Fri, 18 Oct 2013 18:36:30 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Joe Abley In-Reply-To: <4AF34D3B-CB94-417A-BE05-4021C68AA5CC@hopcount.ca> Message-ID: References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> <4AF34D3B-CB94-417A-BE05-4021C68AA5CC@hopcount.ca> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:36:40 -0000 Joe Abley wrote: > > So the key observation here, if I'm reading it correctly, is that > clients might reasonably try to re-use an open socket even if the > edns-tcp-keepalive option is not present, anticipating a short (but not > impossible) timeout on the server side. Right. There are (basically) three kinds of server: Working edns-tcp-keepalive servers support persistent TCP and advertise this fact. RFC 5966 clients and edns-tcp-keepalive clients will both use persistent TCP connections and everyone is happy. Working RFC 5966 servers support persistent TCP but do not advertise this. RFC 5966 clients will use persistent TCP connections, but edns-tcp-keepalive clients will think the server is in overload and will not use persistent TCP even though they could. Sadface. Broken servers may or may not advertise support for persistent TCP. An edns-tcp-keepalive server may be broken because there is a nasty middlebox in the way, or perhaps it got overloaded without being able to signal this to the client. So clients have to detect broken servers based on their ability to keep a TCP connection open to the server, and in any case they have to be able to recover gracefully from an abruptly closed connection. I'm a bit doubtful that there is any benefit in an explicit "I'm broken" signal from the server using the edns-tcp-keepalive option. I like the aims of the draft and I think it is useful for the server to be able to say to the client, please use TCP, and please close idle connections within N seconds. But the current version is a wee bit buggy. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From jabley@hopcount.ca Fri Oct 18 10:39:26 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 A609811E826F for ; Fri, 18 Oct 2013 10:39:26 -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 kpTp5l6vr-IH for ; Fri, 18 Oct 2013 10:39:26 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0B32A11E819D for ; Fri, 18 Oct 2013 10:39:25 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l13so2860788qcy.4 for ; Fri, 18 Oct 2013 10:39:25 -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=JjHtnDsZy4lhNjBghejX3KePi1HJTZpogXj/zcKrRWY=; b=JlxcJMPb8z/6akm3i3Y4GJEfu6aNhvA2CVYfL1bETaMjcq3hEiMNJmFTMKdn2KIh8P CH2/n2ApkRjZM5atooVnfyE7QLExOHa9V2OMURm0k3dqN5fvSaGqoRgMJ7EUTMvJGOZg 4NRpqNuuFXTrL8WZEYKH1CnCi6JAiVu9BVHHA= 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=JjHtnDsZy4lhNjBghejX3KePi1HJTZpogXj/zcKrRWY=; b=D1o3y3GTvY84+h8dezYgyWKbAqb1aMDjxdFHl0Sae5dVPm/oFOOCN8KqAZYlRdvDpD 6ibdD/NbUQKcwjMimp/a26QZL4T6uLTa5nBbd6kxT5IGJUxXoeBgVg2/9GJv1WSoc72R NktCZNRfS24hfb4+1zTEBlVgPjJ/vqvYMzEyp4HaRgk8BWvL6pdCe4RlH3D+95CfCROf wl4dOoUSrmJeabNOWKvIHcz/1HfQMa4DcZS88PA6uJ8EE4T38PXBwtkVib8eJa+BZYCp 0SYLheG8u2NHs8fcT6kVP9ndM0Zaog2MwPpDjsfLBYJ1lZrmDatNicgA0HFSfTj8wr6I W06A== X-Gm-Message-State: ALoCoQlkqNNLSppWMXjpCZ9ch0tGQUzL7vtL/fLKR2LmR+rD9s3m+xNSfnJRPv6UB2ZxAUIQXHep X-Received: by 10.224.66.193 with SMTP id o1mr6466257qai.14.1382117965403; Fri, 18 Oct 2013 10:39:25 -0700 (PDT) Received: from ?IPv6:2001:4900:1042:1:b443:860b:9ac6:4cd3? ([2001:4900:1042:1:b443:860b:9ac6:4cd3]) by mx.google.com with ESMTPSA id u3sm4741184qej.8.2013.10.18.10.39.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 10:39:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Joe Abley In-Reply-To: Date: Fri, 18 Oct 2013 13:39:25 -0400 Content-Transfer-Encoding: 7bit Message-Id: <348BBAD5-D36C-4D3E-86A7-89A6C2245F3A@hopcount.ca> References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> <4AF34D3B-CB94-417A-BE05-4021C68AA5CC@hopcount.ca> To: Tony Finch X-Mailer: Apple Mail (2.1510) Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:39:26 -0000 On 2013-10-18, at 13:36, Tony Finch wrote: > I like the aims of the draft and I think it is useful for the server to be > able to say to the client, please use TCP, and please close idle > connections within N seconds. But the current version is a wee bit buggy. Absolutely. It's a 00. Your bug reports are helpful! Joe From ajs@anvilwalrusden.com Fri Oct 18 10:51:09 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1838E21F991E for ; Fri, 18 Oct 2013 10:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIJPB-0F5OO9 for ; Fri, 18 Oct 2013 10:51:03 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 494DD11E80F9 for ; Fri, 18 Oct 2013 10:51:03 -0700 (PDT) Received: from mx1.yitter.info (nat-01-mht.dyndns.com [216.146.45.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 7245F8A031 for ; Fri, 18 Oct 2013 17:51:02 +0000 (UTC) Date: Fri, 18 Oct 2013 13:51:01 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20131018175100.GF4528@mx1.yitter.info> References: <52616C7E.3000408@teamaol.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52616C7E.3000408@teamaol.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Extending UPDATE to add/remove zones X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:51:09 -0000 On Fri, Oct 18, 2013 at 01:14:38PM -0400, Tim Wicinski wrote: > > While this is discussed in dnsext, but there is a lot of good > discussion on this, I wonder if we should carve out some time during > DNSOP to discuss this? Well, you certainly couldn't discuss it in the meeting of DNSEXT :) My personal opinion is that DNS is an application, and that if you want to make improvements to that application, the right WG to go to is APPSAWG. I'm aware that I'm sometimes regarded as an eccentric for this view. A -- Andrew Sullivan ajs@anvilwalrusden.com From jinmei.tatuya@gmail.com Fri Oct 18 12:07:33 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 D6D4811E8325 for ; Fri, 18 Oct 2013 12:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKkUXQ+aQCBp for ; Fri, 18 Oct 2013 12:07:33 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id E4C4A11E8315 for ; Fri, 18 Oct 2013 12:07:32 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so2447357wgh.0 for ; Fri, 18 Oct 2013 12:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lVGC2pEpv9KjQOdy8lUnU2edpdkU67OHc2Qqgd1Jf20=; b=UwcsffzPA/13o8jmwNWQtNKams36m/pHX/jph/mSn1ihXM8DRuWxrm00iw+ovpPmGm wzSGkZm7BhRvLxR0cbOZvqML9tF5r7Jh85UbJxLNaO6PoQeJ014mC/7WjjCpcF2stxTe fCsIvapgUq/rbDxS4kvZ45HdAkbJ0wR+4bFBfIzxsHg+2lgcHt7BE/v4WlshevMguEtq K5UQFyw0/90PjsMFFMu3eZF4J1+uvleD16Rp4UtGbNoW8d2s5mxoqmzRvI6sAsF1xZqN sWOc8kKFZjkxDrTJRM7+OmXez5hur459DxAn0rlKvyJnPfsqom7fLVYUbcuAXqkMipl+ ARJQ== MIME-Version: 1.0 X-Received: by 10.180.208.49 with SMTP id mb17mr633351wic.64.1382123251489; Fri, 18 Oct 2013 12:07:31 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Fri, 18 Oct 2013 12:07:31 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Oct 2013 12:07:31 -0700 X-Google-Sender-Auth: i5ZXmF3ka5nwiH3tSjL9Wm-HdGU Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:07:34 -0000 At Tue, 15 Oct 2013 16:21:34 -0400 (EDT), Paul Wouters wrote: > As discussed, I separated the EDNS TCP keep-alive option from the EDNS > chain-query document, and Joe Abley kindly offered his assistance in > (re)writing this document. I have some comments on the draft. I've noticed some of them were covered in the followup discussion in this thread, but I thought it's more handy to summarize mine in a single message. Overall, the motivation and approach of the proposal seem to make sense to me. I have some comments and questions on details. - The definition of "timeout" isn't clear to me. In Section 3.1 it only states "a timeout value for the TCP connection". Section 3.3.2 explains it as: "the TIMEOUT value that is currently associated with the TCP session", which is not really clear to me. Is that the (maximum) duration while the server is waiting for more DNS messages from the client (and it would close the connection if there's no message during the period)? Maybe this is obvious for some, but I think it's helpful to define it more clearly and specifically. - In Abstract, it says: "However, clients are currently limited in their use of the TCP transport as most implementations limit the TCP session to a single DNS query and answer". Does this "implementations" mean clients or servers? According to the general sense of the draft, I guess it means servers, but it's not super clear. If it means servers, is this true? And, whether or not it is, I think what should matter more is what the deployed servers instances do, rather than how many implementations do this out of all existing implementations that would include many non-compliant ones. In that sense, IIRC ISC BIND 9, which I believe is still the majority in terms of deployment base, supports multiple queries/responses on a single TCP connection. - In my understanding of the draft, clients and servers send this option independently, and, in particular, the server may or may not send it whether or not the client includes it in the request. (That is, unlike (e.g.) NSID, including this option in a request doesn't mean the client requests the server to include it in the response). Is this correct? Maybe obvious, but I think it's helpful to clarify that more explicitly. - I don't understand this part of Section 4: The edns-tcp-keep-alive option can potentially be abused to request large numbers of sessions in a quick burst. Could you (or the next version of the draft) be more specific about it? -- JINMEI, Tatuya From jinmei.tatuya@gmail.com Fri Oct 18 12:11: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 4EBDA21F9FAC for ; Fri, 18 Oct 2013 12:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DGAfx+qBFkV for ; Fri, 18 Oct 2013 12:11:46 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id A53DF21F9FA4 for ; Fri, 18 Oct 2013 12:11:46 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id w62so4119621wes.7 for ; Fri, 18 Oct 2013 12:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZlIC4vLF8wJqdI9DpyZ0eVg13DM6oX9wpoNkhH+dDGM=; b=gLtKxks5EK5XjHDaf+22kwfbxFT3vwFkomNYMdU2iNpcxKWAViQrSwF2UPCxvicVXx SYpJnYLRPsVMCOqjZJrbbXEAw9NlZc4NJAl4dgV066M78kXPrkHBBAj7K7kQ6AJwtgZm BUd055PsQby2RHaJEkIO1GTawueLndYfbuCIGdOjQAuTj2wIeIl3jq9Vp5ZQhSxkUhWQ PL8eZO810JpRPdZdmio6ZpOmqyOL4tovVv/c1QQ7hX2nL6tEs9UWHNqANy8yjlcu9mFq udnFMqsBCK+1KVYocCTa+QoZwVzbQfTQ1p7w6FfqNa95diOWhQ/+gYcLqRw91KmnwAes s7ow== MIME-Version: 1.0 X-Received: by 10.180.105.230 with SMTP id gp6mr671458wib.48.1382123505771; Fri, 18 Oct 2013 12:11:45 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Fri, 18 Oct 2013 12:11:45 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Oct 2013 12:11:45 -0700 X-Google-Sender-Auth: QoB5WH-Jmq8dhCZQLNRU1OFet9M Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:11:47 -0000 At Wed, 16 Oct 2013 11:05:37 -0400 (EDT), Paul Wouters wrote: > We will look at your proposed changes, especially the security section > ones, and merge in what seems appropriate. But unless I hear more people > who would favour making the new option more "optional" I think we should > stick to this more clear cut of the undefined past behaviour. I'm not really sure what 'more "optiona"' specifically means here, but I think it makes sense to introduce a "timeout" value indicating the server will close the connection immediately. -- JINMEI, Tatuya From paul@nohats.ca Fri Oct 18 12:20: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 9C9FF11E819E for ; Fri, 18 Oct 2013 12:20:22 -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 oWx0JFL87akW for ; Fri, 18 Oct 2013 12:20:18 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 90C7711E8182 for ; Fri, 18 Oct 2013 12:20:16 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d1cWy2rZlzDN4; Fri, 18 Oct 2013 15:20:14 -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 LL3dE5nWZgKh; Fri, 18 Oct 2013 15:20:13 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 18 Oct 2013 15:20:12 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 334E9807D1; Fri, 18 Oct 2013 15:20:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 28138807CA; Fri, 18 Oct 2013 15:20:13 -0400 (EDT) Date: Fri, 18 Oct 2013 15:20:13 -0400 (EDT) From: Paul Wouters To: =?ISO-2022-JP?Q?=1B$B=3F=40L=40C#=3AH=1B=28J?= 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=ISO-2022-JP; format=flowed Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:20:22 -0000 On Fri, 18 Oct 2013, $B?@L@C#:H(J wrote: > I have some comments on the draft. I've noticed some of them were > covered in the followup discussion in this thread, but I thought it's > more handy to summarize mine in a single message. Thanks for your feedback, > Overall, the motivation and approach of the proposal seem to make > sense to me. I have some comments and questions on details. > > - The definition of "timeout" isn't clear to me. In Section 3.1 it > only states "a timeout value for the TCP connection". Section 3.3.2 > explains it as: "the TIMEOUT value that is currently associated with > the TCP session", which is not really clear to me. Is that the > (maximum) duration while the server is waiting for more DNS messages > from the client (and it would close the connection if there's no > message during the period)? Maybe this is obvious for some, but I > think it's helpful to define it more clearly and specifically. We will clarify. What was meant was the timeout value for idle TCP sessions. servers can use this if they are behind a load balancer which terminates these connections irrespective of the DNS software implementation. > - In Abstract, it says: "However, clients are currently limited in > their use of the TCP transport as most implementations limit the TCP > session to a single DNS query and answer". Does this > "implementations" mean clients or servers? According to the general > sense of the draft, I guess it means servers, but it's not super > clear. What is a client? If you mean gethostbyname() or getaddrinfo(), those functions don't really have an API to support more then one query. So a client in this context is a recursive resolver acting as a forwarder. > If it means servers, is this true? And, whether or not it is, I > think what should matter more is what the deployed servers instances > do, rather than how many implementations do this out of all existing > implementations that would include many non-compliant ones. In that > sense, IIRC ISC BIND 9, which I believe is still the majority in > terms of deployment base, supports multiple queries/responses on a > single TCP connection. That's good to know. > - In my understanding of the draft, clients and servers send this > option independently, and, in particular, the server may or may not > send it whether or not the client includes it in the request. no, the server never sends the option to the client if they client did not ask for it. I see that is unclear in 3.3.2 and will fix the text. > - I don't understand this part of Section 4: > > The edns-tcp-keep-alive option can potentially be abused to request > large numbers of sessions in a quick burst. > > Could you (or the next version of the draft) be more specific about > it? Will do. What we meant was the client could "stuff" the tcp pipe with query after query without waiting for any answers with the sole purpose to make the upstream resolver work really hard and use up all its resources. This becomes more important if combined with edns-tcp-chain-query http://tools.ietf.org/html/draft-wouters-edns-tcp-chain-query-01 Paul From marka@isc.org Fri Oct 18 13:44:54 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 2297611E833F for ; Fri, 18 Oct 2013 13:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 gVx7UfXYLg+0 for ; Fri, 18 Oct 2013 13:44:49 -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 CB95611E80E3 for ; Fri, 18 Oct 2013 13:44:48 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 7878CC9492; Fri, 18 Oct 2013 20:44:35 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1382129088; bh=Ca8NVw7Bho1FRz6LhgLdUF3FF9ltHrR+2dJ9U0KLy1Y=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=NIFV4zR5qYHuF0/TOzTk37yV2DOxqieO8h21s2sUP+utnRmiJpr+OqU6LEmDuSmZO X6rZnLucCxv22fRoUDL+sImQp2CsXo7hOiqulqsUAnOgEB42i9P7b7mWBwvLIoDWzf By0hH7aAgM5tNjUj0A2PiHPGa7PRemoyi4QCcpM4= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 18 Oct 2013 20:44:35 +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 C34A4160470; Fri, 18 Oct 2013 20:49:00 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 8A18D160446; Fri, 18 Oct 2013 20:49:00 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EA89085D2D8; Sat, 19 Oct 2013 07:44:32 +1100 (EST) To: Paul Wouters From: Mark Andrews References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> <20131018141143.344FD85CD4D@rock.dv.isc.org> In-reply-to: Your message of "Fri, 18 Oct 2013 10:21:54 -0400." Date: Sat, 19 Oct 2013 07:44:32 +1100 Message-Id: <20131018204432.EA89085D2D8@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 20:44:54 -0000 In message , Paul Wouters w rites: > On Sat, 19 Oct 2013, Mark Andrews wrote: > > >>> An RFC 5966 server supports persistent TCP but does not advertise this > >>> fact. > >> > >> I hope to have some measurements done in time for Vancouver to see what > >> the percentage of queries/servers is where this is a problem. That could > >> help assess whether or not we still need a special indication via edns > >> or not. > > > > Why? Clients should be able to handle the connection being closed > > unexpectedly and retry any uncompleted queries. > > I'm trying to reduce dns(sec) latency, not adding more repeating tcp > failures. If it turns out that most obtained DNS resolvers are useless > for TCP than there is a need to give a clear indication to a client > that a resolver does work well. > > The question is how pervasive are rfc 5966 compliant resolvers out > there, and whether there is a need to advertise those who are. > > Paul All DNS servers should already handle multiple questions over a TCP socket. This is *basic* RFC 1035. Just send the queries and deal with the fact that you may have broken servers. Adding a new option often the worst thing you can do to fix a failure to follow specification. It is definitely not needed to fix this problem. Just write a RFC with a title like "Common DNS server errors in handling queries over TCP" which points out that DNS servers are expected to handle multiple queries over TCP. Then a user has a second clue bat to go beat the vendor over the head with. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Fri Oct 18 14:28:29 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 06DCA11E82E3 for ; Fri, 18 Oct 2013 14:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=-0.639, BAYES_00=-2.599, MISSING_HEADERS=1.292] 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 SADurk6hXfa6 for ; Fri, 18 Oct 2013 14:28:24 -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 B6AEC11E8104 for ; Fri, 18 Oct 2013 14:28:24 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 1261FC94A2; Fri, 18 Oct 2013 21:28:11 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1382131703; bh=aXkUypQKIWRg6il26XPbTxZn8ZmLzgtqF1B8Zr+R+Sw=; h=Cc:From:References:Subject:In-reply-to:Date; b=P2I6zTM8e8bPDx/EQIhpAMeJLohrnur7kXqyUt+4zRy8uLeuk08vs7ydl2zlAzHha MzZvW52JSL4r0JU+yotTDSQQFLk3M1lejFr6fhxh0vgiiEMFZKFPKgVlZzqaRz2fjZ 48LmgseiaWfLlu0xqV166QFLK1Gj0gjYoLEf53jg= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 18 Oct 2013 21:28:11 +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 7EE14160470; Fri, 18 Oct 2013 21:32:36 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 2644D160446; Fri, 18 Oct 2013 21:32:36 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 4F11585E22E; Sat, 19 Oct 2013 08:28:09 +1100 (EST) From: Mark Andrews References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> <20131018141143.344FD85CD4D@rock.dv.isc.org> <20131018204432.EA89085D2D8@rock.dv.isc.org> In-reply-to: Your message of "Sat, 19 Oct 2013 07:44:32 +1100." <20131018204432.EA89085D2D8@rock.dv.isc.org> Date: Sat, 19 Oct 2013 08:28:09 +1100 Message-Id: <20131018212809.4F11585E22E@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 21:28:29 -0000 In message <20131018204432.EA89085D2D8@rock.dv.isc.org>, Mark Andrews writes: > > In message , Paul Wouters > w > rites: > > On Sat, 19 Oct 2013, Mark Andrews wrote: > > > > >>> An RFC 5966 server supports persistent TCP but does not advertise this > > >>> fact. > > >> > > >> I hope to have some measurements done in time for Vancouver to see what > > >> the percentage of queries/servers is where this is a problem. That could > > >> help assess whether or not we still need a special indication via edns > > >> or not. > > > > > > Why? Clients should be able to handle the connection being closed > > > unexpectedly and retry any uncompleted queries. > > > > I'm trying to reduce dns(sec) latency, not adding more repeating tcp > > failures. If it turns out that most obtained DNS resolvers are useless > > for TCP than there is a need to give a clear indication to a client > > that a resolver does work well. > > > > The question is how pervasive are rfc 5966 compliant resolvers out > > there, and whether there is a need to advertise those who are. > > > > Paul > > All DNS servers should already handle multiple questions over a TCP > socket. This is *basic* RFC 1035. Just send the queries and deal > with the fact that you may have broken servers. > > Adding a new option often the worst thing you can do to fix a failure > to follow specification. It is definitely not needed to fix this > problem. > > Just write a RFC with a title like "Common DNS server errors in > handling queries over TCP" which points out that DNS servers are > expected to handle multiple queries over TCP. Then a user has a > second clue bat to go beat the vendor over the head with. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext Just so you can have a something to test with I hacked dig to keep the tcp socket open. It needs more work to be production quality. dig @server +tcp -f querylist Now I know named handles multiple queries over a socket. Perhaps others can report what works for them. Mark diff --git a/bin/dig/dighost.c b/bin/dig/dighost.c index 79b11d0..a10742a 100644 --- a/bin/dig/dighost.c +++ b/bin/dig/dighost.c @@ -120,7 +120,8 @@ isc_boolean_t usesearch = ISC_FALSE, showsearch = ISC_FALSE, qr = ISC_FALSE, - is_dst_up = ISC_FALSE; + is_dst_up = ISC_FALSE, + keep_open = ISC_TRUE; in_port_t port = 53; unsigned int timeout = 0; unsigned int extrabytes; @@ -151,6 +152,8 @@ static void idn_check_result(idn_result_t r, const char *msg); int idnoptions = 0; #endif +isc_socket_t *keep = NULL; + /*% * Exit Codes: * @@ -2339,6 +2342,16 @@ send_tcp_connect(dig_query_t *query) { } INSIST(query->sock == NULL); + + if (keep != NULL) { +fprintf(stderr, "REUSING socket\n"); + sockcount++; + isc_socket_attach(keep, &query->sock); + query->waiting_connect = ISC_FALSE; + launch_next_query(query, ISC_TRUE); + goto search; + } + result = isc_socket_create(socketmgr, isc_sockaddr_pf(&query->sockaddr), isc_sockettype_tcp, &query->sock); @@ -2361,6 +2374,7 @@ send_tcp_connect(dig_query_t *query) { result = isc_socket_connect(query->sock, &query->sockaddr, global_task, connect_done, query); check_result(result, "isc_socket_connect"); + search: /* * If we're at the endgame of a nameserver search, we need to * immediately bring up all the queries. Do it here. @@ -2725,6 +2739,12 @@ connect_done(isc_task_t *task, isc_event_t *event) { UNLOCK_LOOKUP; return; } + if (keep_open) { +fprintf(stderr, "SAVING socket\n"); + if (keep != NULL) + isc_socket_detach(&keep); + isc_socket_attach(query->sock, &keep); + } launch_next_query(query, ISC_TRUE); isc_event_free(&event); UNLOCK_LOOKUP; @@ -3541,6 +3561,9 @@ destroy_libs(void) { isc_result_t result; #endif + fprintf(stderr, "CLOSING socket\n"); + if (keep != 0) + isc_socket_detach(&keep); debug("destroy_libs()"); if (global_task != NULL) { debug("freeing task"); -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jinmei.tatuya@gmail.com Fri Oct 18 15:54:44 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 76BE911E80E4 for ; Fri, 18 Oct 2013 15:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Pp41OZhkd-l for ; Fri, 18 Oct 2013 15:54:44 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D706721F9BD5 for ; Fri, 18 Oct 2013 15:54:39 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id z12so4508934wgg.24 for ; Fri, 18 Oct 2013 15:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Cg5TX2HmPFiXnwC2EkE6ZJGE7FFcIUzzFMzKWFFyEXQ=; b=YaEBRfiBPgXHivT1hAGSqlenyNfv34mdAexd4jrR2HtGAbjyl1wfjpVeme59pa0UDg TIwg/w6ZL9XNtGOl0R9+lj2BxBCnAp75D6umkKK/hcQctzVMVk63JiP2anJ1NgcJgCLO NVUFJmTBiG4OAJ+TeMvpaV/8L0wmsCW/Y2kdtUX84UCyabPXiIDX+Nrrf1Nx1IRV6KIK G83wjfnXc1aMzR9R1XuiE07yfXpoqg21zKQ6cKUMDb9vId8sIXie82/2cqhwmPETb8k5 Pfl7RjcpqPWbmpdC27kW38TCW31nLyD8VZM5W0NWy4uDHdAkm7VE0OIGvPTefD/oRQ7U Ghqw== MIME-Version: 1.0 X-Received: by 10.194.2.108 with SMTP id 12mr520wjt.64.1382136878810; Fri, 18 Oct 2013 15:54:38 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Fri, 18 Oct 2013 15:54:38 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Oct 2013 15:54:38 -0700 X-Google-Sender-Auth: xQprt-8mU6EMsiNIBq9PYX6dOI4 Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 22:54:44 -0000 At Fri, 18 Oct 2013 15:20:13 -0400 (EDT), Paul Wouters wrote: > > - The definition of "timeout" isn't clear to me. > > We will clarify. What was meant was the timeout value for idle TCP > sessions. servers can use this if they are behind a load balancer which > terminates these connections irrespective of the DNS software > implementation. Hmm, so, for example, if an administrator uses a load balancer configured with a "TCP timeout" value would configure the backend name server so it will include that value for this EDNS option? I suspect ordinary readers without much background would need a lot of imagination to come up with this scenario just from the draft text:-) > > - In Abstract, it says: "However, clients are currently limited in > > their use of the TCP transport as most implementations limit the TCP > > session to a single DNS query and answer". Does this > > "implementations" mean clients or servers? According to the general > > sense of the draft, I guess it means servers, but it's not super > > clear. > > What is a client? If you mean gethostbyname() or getaddrinfo(), those > functions don't really have an API to support more then one query. So > a client in this context is a recursive resolver acting as a forwarder. First off, I didn't think it was a client, but the text wasn't really clear. Secondly, if it was really about clients, "what kind of client" would actually be my next question, as there are different types of "clients" (stub resolver and recursive server) and it was not really clear from the draft text. Thirdly, since you asked, IIRC the very basic primitive "libresolv" library supports the "stay open" option flag. See, e.g. lines 514-517 of http://svnweb.freebsd.org/base/head/lib/libc/resolv/res_send.c?view=markup&pathrev=255336 although this doesn't matter much in the context of this draft anyway. > > The edns-tcp-keep-alive option can potentially be abused to request > > large numbers of sessions in a quick burst. > > > > Could you (or the next version of the draft) be more specific about > > it? > > Will do. > > What we meant was the client could "stuff" the tcp pipe with query after > query without waiting for any answers with the sole purpose to make the > upstream resolver work really hard and use up all its resources. Okay, but this doesn't seem to be an abuse of the proposed option, but just a possible attack on a server that accepts multiple queries on a single connection in general (I remember it was already pointed out in the thread). -- JINMEI, Tatuya From paul@nohats.ca Fri Oct 18 20:10:25 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879CD11E8140 for ; Fri, 18 Oct 2013 20:10:25 -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 3-GmmtJNjI54 for ; Fri, 18 Oct 2013 20:10:19 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 546DF11E8136 for ; Fri, 18 Oct 2013 20:10:15 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d1py92LhmzDN9; Fri, 18 Oct 2013 23:10:09 -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 RohGWfpBikxP; Fri, 18 Oct 2013 23:10:08 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 18 Oct 2013 23:10:08 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 57049807D1; Fri, 18 Oct 2013 23:10:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4B38C807CA; Fri, 18 Oct 2013 23:10:06 -0400 (EDT) Date: Fri, 18 Oct 2013 23:10:06 -0400 (EDT) From: Paul Wouters To: Mark Andrews In-Reply-To: <20131018212809.4F11585E22E@rock.dv.isc.org> Message-ID: References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> <20131018141143.344FD85CD4D@rock.dv.isc.org> <20131018204432.EA89085D2D8@rock.dv.isc.org> <20131018212809.4F11585E22E@rock.dv.isc.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-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 03:10:25 -0000 On Sat, 19 Oct 2013, Mark Andrews wrote: > Just so you can have a something to test with I hacked dig to keep > the tcp socket open. It needs more work to be production quality. Thanks! I've used the patch to test some servers > Now I know named handles multiple queries over a socket. > Perhaps others can report what works for them. I've tested against: - unbound - dnsmasq - powerdns-recursor - bind9.7 All of these returned pipelined queries that I threw at them (upto a few hundred) OpenDNS worked as well. Google DNS worked but puts a limit of 64 queries on a TCP connection. I have not yet tested how long these servers and services keep idle connections open. Paul From fanf2@hermes.cam.ac.uk Sat Oct 19 08:20:44 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 AFAA311E81AB for ; Sat, 19 Oct 2013 08:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUJT9GyZ+Qjv for ; Sat, 19 Oct 2013 08:20:43 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f32]) by ietfa.amsl.com (Postfix) with ESMTP id 227CF11E81C7 for ; Sat, 19 Oct 2013 08:20:40 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51102) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1VXYKS-0004e9-2y (Exim 4.80_167-5a66dd3) (return-path ); Sat, 19 Oct 2013 16:20:36 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VXYKS-0006Bq-SS (Exim 4.72) (return-path ); Sat, 19 Oct 2013 16:20:36 +0100 Date: Sat, 19 Oct 2013 16:20:36 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Mark Andrews In-Reply-To: <20131018204432.EA89085D2D8@rock.dv.isc.org> Message-ID: References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> <20131018141143.344FD85CD4D@rock.dv.isc.org> <20131018204432.EA89085D2D8@rock.dv.isc.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 15:20:44 -0000 Mark Andrews wrote: > > All DNS servers should already handle multiple questions over a TCP > socket. This is *basic* RFC 1035. Just send the queries and deal > with the fact that you may have broken servers. > > Adding a new option often the worst thing you can do to fix a failure > to follow specification. It is definitely not needed to fix this > problem. Right. I have been thinking about what changes this draft implies relative to RFC 5966. There's a general encouragement to use TCP, but that doesn't require protocol changes. I don't think it implies any changes to server connection management. There are quality-of-implementation questions, but they doesn't need protocol changes. The only difference it makes to the client is it can close connections based on the server's idle timeout, instead of keeping them open indefinitely. This is beneficial to the server, since it offloads FIN-WAIT-2 to the client. It is not beneficial to the client since it implies extra timeout handling and extra bandwidth usage - think radio power. Perhaps the server should only send the option when its timeout is less than indefinite, or if it changes in the lifetime of the connection. Then in most cases the client will not have to bear the extra costs. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From fanf2@hermes.cam.ac.uk Sat Oct 19 10:00:42 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 79AAA11E8215 for ; Sat, 19 Oct 2013 10:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 EKXoBJTD91v5 for ; Sat, 19 Oct 2013 10:00:40 -0700 (PDT) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f52]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6D811E8228 for ; Sat, 19 Oct 2013 10:00:38 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44833) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1VXZtE-0006FR-Ee (Exim 4.80_167-5a66dd3) (return-path ); Sat, 19 Oct 2013 18:00:36 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VXZtE-0005Wa-F6 (Exim 4.72) (return-path ); Sat, 19 Oct 2013 18:00:36 +0100 Date: Sat, 19 Oct 2013 18:00:36 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Wouters In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-01.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 17:00:42 -0000 This feature could be hugely beneficial - see below for some numbers. I think it is worth being more clear about what is possible without this draft both in principle and separately in practice. The first paragraph of section 3 is saying that in practice, validating resolvers (BIND, Unbound) are not currently optimized to minimize latency. This ought to be fixed, but it does not imply that you have to suffer many RTTs without edns-tcp-chain-query. Editorial suggestions: I think section 1 and section 3 are doing basically the same job and should be merged into one section. The term "Resolving Nameserver" is peculiar and isn't defined in the terminology section. In principle you can send all the queries and get all the responses needed for validation in one RTT, or two if the answer contains a CNAME chain, because you need the validation chain for the CNAME targets and you don't know the targets until you get the response. So I think the key benefit of edns-tcp-chain-query is not so much latency, but reducing the amount of data sent and received to get a validation chain. (It turns out to be difficult to completely eliminate the second RTT in the CNAME case; more on that below.) Perhaps it is worth calculating how much data could be saved. Let's use webmail.hermes.cam.ac.uk as an example since it should make edns-tcp-chain-query look really good :-) Given an empty cache, to look it up and get the validation chain, a stub would query for: webmail.hermes.cam.ac.uk. IN A webmail.hermes.cam.ac.uk. IN AAAA webmail.hermes.cam.ac.uk. IN DNSKEY webmail.hermes.cam.ac.uk. IN DS hermes.cam.ac.uk. IN DNSKEY hermes.cam.ac.uk. IN DS cam.ac.uk. IN DNSKEY cam.ac.uk. IN DS ac.uk. IN DNSKEY ac.uk. IN DS uk. IN DNSKEY uk. IN DS . IN DNSKEY Which is 536 bytes sent in 13 queries. Our campus resolvers return 7826 bytes of UDP response to these queries. My resolver configured for minimal responses only reduces this to 6568 bytes by omitting the additional gubbins in the first response. That's about half a second of data at GPRS speeds. Those numbers come from the following script. I have patched dig to print the query size: https://github.com/fanf2/bind-9/commit/b1d6fc85 h=webmail.hermes.cam.ac.uk. s=127.0.0.1 ( dig +dnssec +noall +qr +stats @$s $h IN A $h IN AAAA; while [ "$h" != "" ]; do dig +dnssec +noall +qr +stats @$s $h IN DNSKEY $h IN DS; h=${h#*.}; done; dig +dnssec +noall +qr +stats @$s . IN DNSKEY ) | grep SIZE A lot of these are NODATA responses, the 2nd to 6th queries inclusive. These responses are entirely redundant, since the RRSIG in the A response indicates there is no AAAA and the nearest enclosing zone cut is cam.ac.uk below which there are no DNSKEY nor DS records. Leaving those out would save 2349 bytes, for a total of 4219 bytes of reply. The remaining redundancy that edns-chain-query would eliminate is the repetetive headers and OPT RRs. I think (without having checked in detail) that this saves from the response the same amount of data as all but two of the queries. (The first two queries still need to be separate; the client would send one with the chain option and one without.) This saves another 430 bytes, reducing the total to 3789 bytes. That is less than half the original. On the query side, we now only need to send queries for A and AAAA, and include the edns-chain option in one of them, making 111 bytes which is about 20% of the original. Some more suggestions and questions ... Section 5.2 generating a query: I think the Last Known Query Name needs to be the First Unknown Query Name. In the empty cache case, the client only has a root trust anchor so it needs the root DNSKEY RRset. So when it sends . in the edns-chain-query option it wants to get everything up to and including the root. Section 5.3 generating a response: Why include the NS RRsets? The client is making forwarding queries to an upstream recursive server, so it doesn't need to know the names or addreses of the authoritative servers. Those are only useful for direct iterative resolving. I think more needs to be said about additional section processing. It seems sensible to me to do additional section processing only for direct answers to the client's query, not for the validation chain (i.e. omit the NS RRsets and their targets). For instance if the client asks for the MX, include the MX target RRs in the additional section. What about the MX target validation chain(s)? If I query for example.ac.uk and they have outsourced mail to example.net, I can put ac.uk in edns-chain option, but I don't know in advance that the response will have anything to say about example.net, and I can't tell the server that I already have example.net in my cache. (There's a similar problem for CNAME responses.) So the server has a dilemma: include everything to ensure that the client doesn't have to make any more queries, which is a waste of bandwidth if the client's cache is populated, or make the client suffer another round trip to deal with the targets if the cache isn't populated? Perhaps it would make sense to send the validation chain for CNAME targets and additional records only if the client's edns-chain domain is a parent of the target. The server can then be sure it only sends records the client does not have. If the targets are not under the client's edns-chain domain, then the client might have to send a follow-up query. Section 6.5 anycast considerations: Again I think this is too pessimistic about the anycast and TCP. Section 4 option format: Why use the term FQDN? This is a domain name in wire format, right? (which will compress nicely since it is a parent of the QNAME) Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From fanf2@hermes.cam.ac.uk Sat Oct 19 12:47:39 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B975E11E81DB for ; Sat, 19 Oct 2013 12:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 vGx8HevHsnHm for ; Sat, 19 Oct 2013 12:47:39 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f33]) by ietfa.amsl.com (Postfix) with ESMTP id 98EAB11E8244 for ; Sat, 19 Oct 2013 12:47:38 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51721) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1VXcUq-00067M-gL (Exim 4.80_167-5a66dd3) (return-path ); Sat, 19 Oct 2013 20:47:36 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VXcUq-0005G3-2W (Exim 4.72) (return-path ); Sat, 19 Oct 2013 20:47:36 +0100 Date: Sat, 19 Oct 2013 20:47:36 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Wouters In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-01.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 19:47:39 -0000 Tony Finch wrote: Sorry, there was an error in my calculations. > A lot of these are NODATA responses, the 2nd to 6th queries inclusive. > These responses are entirely redundant, since the RRSIG in the A response > indicates there is no AAAA and the nearest enclosing zone cut is cam.ac.uk > below which there are no DNSKEY nor DS records. Leaving those out would > save 2349 bytes, for a total of 4219 bytes of reply. The RRSIG only proves the nonexistence of the DNSKEY and DS records. We need the NSEC to prove the nonexistence of the AAAA record. And the A and AAAA queries have to be separate, so the AAAA response should be a full NODATA response. So we only save 1872 bytes and the total is 4694 bytes. > The remaining redundancy that edns-chain-query would eliminate is the > repetetive headers and OPT RRs. I think (without having checked in detail) > that this saves from the response the same amount of data as all but two > of the queries. (The first two queries still need to be separate; the > client would send one with the chain option and one without.) This saves > another 430 bytes, reducing the total to 3789 bytes. Actually 4264 which is 55% of the original. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From Ray.Bellis@nominet.org.uk Mon Oct 21 02:23:08 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 AF3D621F9FD5 for ; Mon, 21 Oct 2013 02:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RkAeo8HDH5m for ; Mon, 21 Oct 2013 02:23:02 -0700 (PDT) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id F17AF11E84E8 for ; Mon, 21 Oct 2013 02:22:35 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=WQB+wedyUvBRDerK9NzKtRFWptRN6d14iSA1jqQ+uLriDNiGkHzP0qG1 Nk/m4bYEY6zGNnVZ842FBWvtHFec8SjRNyaZ05T7U5cQqB4F9UQKU2ilD 0x2rbnfDzJPBTjaT7sbbarP6DYp4fa6cYWh+09gU6oogYsXDcq9GxPl8p qnZD7D6jiUPC9oEG5GRJoEQLDQ5e1T3SxDdecFkU4JE4eb0hcOp5+Q6AU Ge3yp9fpbFBLRgHaJEunr7C/UCve2; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1382347359; x=1413883359; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yJon+7FMRQwgUV2HmKe/IgyRQHCP6XklExfL+amwDbs=; b=ZqVE6ypwIxP3ayGObrmmp3AKgGtKn+CBqz1flARkkUcfl+WOxjaM8CT2 GwLm+GM0ZDPoKt2XnXBiwvD2dJk8uJC+wnqbI0A77yzaT5+cz5KhV+k8W 1DJQy0E7jFZzLHK59l3AXQc8/RqEXZ4aH7gpMGWUPQ7AeG13Phoi61H93 VrevfcT/Au0Pd/wvXhyv/rqUNRqS19Bx3NKDL9JPTz9kmyRKZHOuh5s01 h9TtKhw4k4zp5OusARxCErADqkeGD; X-IronPort-AV: E=Sophos;i="4.93,537,1378854000"; d="scan'208";a="3806679" X-IPAS-Result: AjEFAFrxZFLV+MWR/2dsb2JhbABZgmYhgQy+LYEpFnSCJQEBAQECAToZJAIFCwIBCCIUEDIlAgQOBQiHeAcDvWePKQIxB4MfgQoDlCqVZoFmgT6CKg Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 21 Oct 2013 10:22:25 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 10:22:24 +0100 From: Ray Bellis To: Mark Andrews Thread-Topic: [dnsext] New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) Thread-Index: AQHOzj8N7UeMBiFshkmmAdZS/+Zlrg== Date: Mon, 21 Oct 2013 09:22:23 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DED83C2@wds-exc1.okna.nominet.org.uk> References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> <20131018141143.344FD85CD4D@rock.dv.isc.org> <20131018204432.EA89085D2D8@rock.dv.isc.org> In-Reply-To: <20131018204432.EA89085D2D8@rock.dv.isc.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <3DE7D1A0E4B2894DA2216132C230E375@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 09:23:09 -0000 On 18 Oct 2013, at 21:44, Mark Andrews wrote: > Just write a RFC with a title like "Common DNS server errors in > handling queries over TCP" which points out that DNS servers are > expected to handle multiple queries over TCP. Then a user has a > second clue bat to go beat the vendor over the head with. It's already implicit in 5966, where there's text clarifying that responses= on a TCP connection may arrive in a different order to requests. kind regards, Ray From muks@isc.org Mon Oct 21 07:22: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 245AE21E8091 for ; Mon, 21 Oct 2013 07:22: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 Lho1RWEDPIPn for ; Mon, 21 Oct 2013 07:22:51 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:141:43e5::3]) by ietfa.amsl.com (Postfix) with ESMTP id 853A811E81A6 for ; Mon, 21 Oct 2013 07:22:23 -0700 (PDT) Received: from totoro.home.mukund.org (unknown [115.118.177.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id D8E361C00155; Mon, 21 Oct 2013 14:22:15 +0000 (GMT) Date: Mon, 21 Oct 2013 19:52:11 +0530 From: Mukund Sivaraman To: Mark Andrews Message-ID: <20131021142210.GA10464@totoro.home.mukund.org> References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> <20131018141143.344FD85CD4D@rock.dv.isc.org> <20131018204432.EA89085D2D8@rock.dv.isc.org> <20131018212809.4F11585E22E@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <20131018212809.4F11585E22E@rock.dv.isc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 14:22:52 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 19, 2013 at 08:28:09AM +1100, Mark Andrews wrote: > Just so you can have a something to test with I hacked dig to keep > the tcp socket open. It needs more work to be production quality. >=20 > dig @server +tcp -f querylist >=20 > Now I know named handles multiple queries over a socket. > Perhaps others can report what works for them. I remember seeing a config option in the NSD configuration for the number of queries it's allowed to serve on a TCP connection. So I guess other DNS servers also implement it. Mukund --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQgcBAEBCgAGBQJSZTiPAAoJENJq4EOcI417NEg//2AYbUdGoevSTKLL6x7wqjjy hCphj4V+qmMNUcxvGGEBY79YV8vI1byhU6egAobM6aqj50QuS2112fKGFXPcPJ5X XReiE7lWACcbwxxgvoFXkW6YtWRJaokWpJH+MG3dsqINp1rT2xvh5BrWgJnVXo0q lrmKo5Jlq7lNkEEYNiQ+pc1O30bkBEv0E5i+oAjNcJVLilQFzy4fjw2Fpt1uTHME 0aKCSjOeWPa9cwb8rzr8GWtsfLLlDyUGOzoPazLaCV0krRw/5JYrlo28AeN2/Noc zuszlMlyGqmjFEhKUClJ+hAfRGV7M2aBs7VcQgoHLBXDH1mRKOUK69+u3EKl6mIv 5FL9S09sXIYnUNyY7QKaYsJ5HKotjQiznfyQXn2ZsgdGEOmT+dMEeAtVzOvRkpUp e0BmzkUxjjhdBATz3gL3vEG70oY11UxfE/bwyTv6rqUvtbssM0FQy3XuOM8re/jw UazyJSTwvg5R+6MjU360fkCUR6bFDe6gLq1NGW80+Yz25BfdrFjJUVG0fNRHSw+l 6tYjbOrXBp9o2v1RxfWk9huNk5yuofNxQQjATYwZ0GfD2gzG6zTTHMGIIK+OtJe5 OK8ZCxBifzoWuZjWUi3JnbkA8b0yHogfMSkyQjzVuEWrj7rYfElY/bkCK//IuLGX 86MefmoD/nAvu56AazlHm9puCUxkCSdUTzxTT/8iBXD7g8wWoeZ1sPyl5R37jipn JqCrrRdb0oEQD/5Q0Oi/fxMM2TKmQFMS1h8k+clc+Ve1wkPOLrWFMfkV9yHwkYHN K82TxCvDQqquEiZRzNf/0zDxOyN9l1aKjkkPdV7PtpNrzRAhOSwOiVlzvUYN7Rfl nXsrYdaq9mTgTvYqECGUVZRwBQVKZLo0Bi8+kgF6kfXD8uEPAjcxJdGzukMk3jiQ UIoyfiTtirCk+XANKP6sMAXD3VVxW07k96q4O58sSAoWzEY3FkBnlza3ybbCoW0S 5yGS9FEz1zXDMOXsYZPueda0Ct1lqw65653aLnJ7HEeD4vTYPutpoxUCL+LG7WJp 0X+smH9QSENhYHGFXl5e+kZmQiKG+m4tEhl9zX09GtomBP4+xMt8xEH6d9Kht+lC PdFzBr901Z/3LhkNmG63iQegxzFgqYae5/MLwVI3ee9oUIiRnIw2V5gTQSRz/dkk PrxCPk0yw9Q23BPhOR7N0WmpvDJw2csxa4E1mOaZ8bhDdhB2qsA53ZUlp7PlLFAF q3538DrOI8qlm0+lfaxAV/vz69+GqhQxrlGnkWClwDN4jWiIT7lm7/2dKXecFeJC zcgo7qczHDn2THExdXsVyO15QPGjWnc0IUJZ8wxpZFDbJG9cHs2j3s+HlRMJxFq9 ksUe4l8HeUZKW5B+0zoDr5X9+UjWqsgJ+oiCY4al20LP8B28v9un+LH4B+0tav11 hKqOU93WK+W3V9iMG+CNAmnFI2o/vzofCi8SzmlceRRn68/QYpqYCY3Ta53FU8lE 7dP4fdASZ54zZiatLqIaRIAe6/DqL9oxATkp6xFfMlQwrZ7eMrnZ3CE01jlYhlLU tSkQ80DTpa5lyw/8dCFnoN/OL2Ut4fIwnHgon0k67/RDWV64BbQN66QQbhXcYogY q0De5jQBJpNdUcGweCHxah79rOEsmf04Rr28O34XGh3Vqrxcwp5pPUD/B0dygZiS KeXhKuo2VJs626MEV9mw6uWQvPKI9iD7tfY5XYwJV7ZIKGeI0/3Mi9Z9tt4aiL+j cKTp84t5b4lkv4htQ+WFac9WIBOKd8yRxLaMKm2B2Nqq2OLoe+9SA2MyHmQhGC4k 4PEg4k6YMYBbkdCk9PsZ0LdVoO66N6v1nP5s6Av/LPgVHTg+RGQMRDjWZbvJkkun p+0SGHCzjdijSBYqn/JqKFdNAEK1Hyc2oJpAcHj/wdUuw6v/jDqqEltIQDy/ouR2 i9FR27Dg7V5tmDx/XUNIIlaTpM4a1YccIyD5DAm7p08LFVeI6MPRkHY2MB8R8rSt G+FPgbbSHEFc5qUQ/M0s/AsWJWIPGB/CWxdwHlA8iiRZa5qvKi0yNKiduvU161f0 AWAS5c7np91ryq1iEmznB+z0HpHcmibukjeP8pnd4hPURtqOBteRIYy9OZ+C+DkX UMj+1sfJgYBe0gIrGInDFZpz4RVzp4qfVQ9xZQQ6f+OjFmLMrH+7uMGlHrYDeXj0 HySt+uwQVbbKP3N6kdgMT3gNgQtKertxPYTLELnA0fqGUq4owRipvQryPITpVU1e lDb7QCLQQgHK6SCj219VhyjbkGTx+HZ0rITaPEsOQr3LSeT6v/K+5UvMBoNUDeu3 HOgjYgws0xeVrxK3TP5bchK+Q8XWuL867UMyDjgswQnuCt9sWAtsVSdMvjH2KXJZ BQ95+YwLuC8fZR60APmpc9AmX2muaT3P8pHEVvGvZ4dgiw+TbhwgKd72xVsdzzcu L9QDAGar1DPfEnkUrjbrA6q40HaN7+xhuaXask42K9IkCUFW5v/1gwgcN1s+8Bp6 Z7rQ7JGQ+FaL5+Qp27WraEcsndbVwww8b4XIBhNj8iNP4aLZERJLwgHDa1LfUW05 zUEQtvAYG6ZB3G6vm3Itc5ph7NUfzL23TaTnAhpsHnxOspqBTdNO2v9HEx1M+21a H/LIjJ+2S3FWvjjAAQWhEj+byEI9inCR7TTD67B1LBMrKvDZBUdVPppG+LbVflYd N+SkK6UJpFiNff3cXvp5 =kXuk -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From marka@isc.org Mon Oct 21 15:51: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 1956D11E82B0 for ; Mon, 21 Oct 2013 15:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB8B+LDrzKAw for ; Mon, 21 Oct 2013 15:50:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D248011E87B9 for ; Mon, 21 Oct 2013 15:49:35 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 2377FC942B; Mon, 21 Oct 2013 22:49:09 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1382395762; bh=+4rzYH8wnKA91Qzcccg+uU3cfYsU+mdwdSG3OHcBj5c=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=sBgXEHW4bCRAx73bePqDktfOPnzxLEo6aQ9yJ024/T5g/iHozXxUeodgWmAs1w2D6 3+690+LINNGgRwEcaes92pG1siDWsX62mTZWrDtlfp0DCneI2pr00zu7sgx/5j/hJs QMY+JYSkFii+Ma0GgAbA0IShLOIGwnRcS80ymxl8= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 21 Oct 2013 22:49:09 +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 EA21A160470; Mon, 21 Oct 2013 22:53:47 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id B8EF1160459; Mon, 21 Oct 2013 22:53:47 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2552F878E48; Tue, 22 Oct 2013 09:49:06 +1100 (EST) To: Ray Bellis From: Mark Andrews References: <21087.60263.989338.253036@gro.dd.org> <516321C1-1988-4946-A524-B2529752726F@hopcount.ca> <20131018141143.344FD85CD4D@rock.dv.isc.org> <20131018204432.EA89085D2D8@rock.dv.isc.org> <53F00E5CD8B2E34C81C0C89EB0B4FE732DED83C2@wds-exc1.okna.nominet.org.uk> In-reply-to: Your message of "Mon, 21 Oct 2013 09:22:23 -0000." <53F00E5CD8B2E34C81C0C89EB0B4FE732DED83C2@wds-exc1.okna.nominet.org.uk> Date: Tue, 22 Oct 2013 09:49:05 +1100 Message-Id: <20131021224906.2552F878E48@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:51:02 -0000 In message <53F00E5CD8B2E34C81C0C89EB0B4FE732DED83C2@wds-exc1.okna.nominet.org.uk>, Ray Bellis writes: > > On 18 Oct 2013, at 21:44, Mark Andrews wrote: > > > Just write a RFC with a title like "Common DNS server errors in > > handling queries over TCP" which points out that DNS servers are > > expected to handle multiple queries over TCP. Then a user has a > > second clue bat to go beat the vendor over the head with. > > It's already implicit in 5966, where there's text clarifying that > responses on a TCP connection may arrive in a different order to requests. > > kind regards, > > Ray Sometimes it is just better to says things explicitly. Sometimes it is just better to not mix a correction with a extension. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From paul@nohats.ca Mon Oct 21 19:29:51 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 B4EAC11E80EC for ; Mon, 21 Oct 2013 19:29:51 -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 JCgSJHPSagP4 for ; Mon, 21 Oct 2013 19:29:47 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id DF8FE11E8301 for ; Mon, 21 Oct 2013 19:29:46 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d3dw33W5jzDNK; Mon, 21 Oct 2013 22:29:39 -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 ImyYnB5O0Uu3; Mon, 21 Oct 2013 22:29:36 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 21 Oct 2013 22:29:36 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 2C203807CA; Mon, 21 Oct 2013 22:29:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1FEC0805BD; Mon, 21 Oct 2013 22:29:37 -0400 (EDT) Date: Mon, 21 Oct 2013 22:29:37 -0400 (EDT) From: Paul Wouters To: Tony Finch 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-01.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 02:29:51 -0000 On Sat, 19 Oct 2013, Tony Finch wrote: > This feature could be hugely beneficial Great, I think so too :) > The first paragraph of section 3 is saying that in practice, validating > resolvers (BIND, Unbound) are not currently optimized to minimize latency. > This ought to be fixed, but it does not imply that you have to suffer many > RTTs without edns-tcp-chain-query. There is not much they can do to fix it if I'm using a phone over 3g with a validator on the phone. > Editorial suggestions: I think section 1 and section 3 are doing basically > the same job and should be merged into one section. The term "Resolving > Nameserver" is peculiar and isn't defined in the terminology section. Thanks will look into that. > In principle you can send all the queries and get all the responses needed > for validation in one RTT, or two if the answer contains a CNAME chain, > because you need the validation chain for the CNAME targets and you don't > know the targets until you get the response. So I think the key benefit of > edns-tcp-chain-query is not so much latency, but reducing the amount of > data sent and received to get a validation chain. I figure when it comes to bytes send/received, if DNS is your issue you have bigger problems with what's asking the DNS questions. It's nice to reduce the size if we can, but I don't think there is much impact with reduced size? > That's about half a second of data at GPRS speeds. Well, I guess it you meassure at GPRS speeds.... :) > Section 5.2 generating a query: > > I think the Last Known Query Name needs to be the First Unknown Query > Name. I was avoiding that because the client does not know what it doesn't know. There might not be zone cuts on every dot. Which is why I opted for it to convey that it did know. > In the empty cache case, the client only has a root trust anchor so > it needs the root DNSKEY RRset. So when it sends . in the edns-chain-query > option it wants to get everything up to and including the root. Yes. Was this not clear in the draft? > Section 5.3 generating a response: > > Why include the NS RRsets? The client is making forwarding queries to an > upstream recursive server, so it doesn't need to know the names or > addreses of the authoritative servers. Those are only useful for direct > iterative resolving. Because roaming devices run the risk of changing to a network where they have to operate without forwarder. In which case it would be really nice to already have those NS records validated and ready. It seemed like an optimization that might cause more problems than it solves. > I think more needs to be said about additional section processing. It > seems sensible to me to do additional section processing only for direct > answers to the client's query, not for the validation chain (i.e. omit the > NS RRsets and their targets). For instance if the client asks for the MX, > include the MX target RRs in the additional section. I guess that depends on how the resolver is configured. unbound seems to be minimal responses, while my old named seems to add it A records to the additional section. So I think that would be out of scope for this draft, but perhaps a mention that it would be recommended not to configure resolvers with minimum responses (unlike authoritative servers?) > What about the MX target validation chain(s)? If I query for example.ac.uk > and they have outsourced mail to example.net, I can put ac.uk in > edns-chain option, but I don't know in advance that the response will have > anything to say about example.net, and I can't tell the server that I > already have example.net in my cache. (There's a similar problem for CNAME > responses.) I don't think there is a principle reason why not to add those to the additional section. In fact, I had thought about a special query that would signal to the upstream resolver "give me your 1% hot cache entries with a TTL of more then 5 minutes". > So the server has a dilemma: include everything to ensure that the client > doesn't have to make any more queries, which is a waste of bandwidth if > the client's cache is populated, or make the client suffer another round > trip to deal with the targets if the cache isn't populated? right. so we can either make an option, or not optimize here. I'd say that MX is not that important because it is not very interactive (but a background process) and that CNAME/DNAME could be avoided if people cared about the extra 1 RTT for the followup (TCP keepalive) query. > Perhaps it would make sense to send the validation chain for CNAME targets > and additional records only if the client's edns-chain domain is a parent > of the target. The server can then be sure it only sends records the > client does not have. If the targets are not under the client's edns-chain > domain, then the client might have to send a follow-up query. I think that's what Jelte was hinting at too. I think I'll try to write this up for the next version. It covers a quite common case, and without the risk of needing to include a whole new hierarchy of which we don't know if the client knows it or not. > Section 6.5 anycast considerations: > > Again I think this is too pessimistic about the anycast and TCP. I can tone it down a bit and just state implementors should be careful. > Section 4 option format: > > Why use the term FQDN? This is a domain name in wire format, right? (which > will compress nicely since it is a parent of the QNAME) You are right, will fix in next draft. thanks for the feedback! Paul From jay@nzrs.net.nz Mon Oct 21 19:54: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 5A78F11E8120 for ; Mon, 21 Oct 2013 19:54:21 -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 CSSby+hFotcZ for ; Mon, 21 Oct 2013 19:54:17 -0700 (PDT) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 6391D11E8109 for ; Mon, 21 Oct 2013 19:54:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 212D54B7B42; Tue, 22 Oct 2013 15:54:12 +1300 (NZDT) 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 9iknsrsolPko; Tue, 22 Oct 2013 15:54:04 +1300 (NZDT) Received: from [192.168.22.173] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 8CB604B7C39; Tue, 22 Oct 2013 15:54:04 +1300 (NZDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jay Daley In-Reply-To: <20131017111711.GA14875@totoro.home.mukund.org> Date: Tue, 22 Oct 2013 14:50:49 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131017045842.GA1965@totoro.home.mukund.org> <20131017111711.GA14875@totoro.home.mukund.org> To: Mukund Sivaraman X-Mailer: Apple Mail (2.1510) Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 02:54:21 -0000 On 18/10/2013, at 12:17 AM, Mukund Sivaraman wrote: > One more thing: >=20 > RFC 1035 calls for durable storage of zone data. This is not a strict > requirement for configured secondaries if you consider that a = secondary > can AXFR data from scratch during startup and store it in volatile > memory. There are no updates to zone data made at secondaries - > transfers not being considered as updates to data. >=20 > So far, the "catalog" (RFC 1035) is a part of the secondary > implementation's static configuration. The secondary can run without > writing to durable storage. >=20 > The case where a secondary crashes, loses its dynamic configuration > should be addressed. Is an admin expected to reconfigure the secondary > on startup each time? Is the secondary expected to save the updated > catalog to durable storage? (The latter may not be agreeable to > everyone, so support for both should be considered.) I think that is an implementation specific decision that should not be = hard-coded in the protocol. i.e. some may choose to require a dynamic = re-configuration while others may store the configuration persistently. Jay >=20 > Mukund --=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 fanf2@hermes.cam.ac.uk Tue Oct 22 02:33:09 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269CF11E8110 for ; Tue, 22 Oct 2013 02:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 y93jflVTvdGb for ; Tue, 22 Oct 2013 02:33:01 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f33]) by ietfa.amsl.com (Postfix) with ESMTP id 0270C11E8192 for ; Tue, 22 Oct 2013 02:32:53 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:34510) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1VYYKR-0002ZD-ic (Exim 4.80_167-5a66dd3) (return-path ); Tue, 22 Oct 2013 10:32:43 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VYYKR-0001J3-PK (Exim 4.72) (return-path ); Tue, 22 Oct 2013 10:32:43 +0100 Date: Tue, 22 Oct 2013 10:32:43 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Wouters In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-01.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 09:33:09 -0000 Paul Wouters wrote: > On Sat, 19 Oct 2013, Tony Finch wrote: > > > The first paragraph of section 3 is saying that in practice, validating > > resolvers (BIND, Unbound) are not currently optimized to minimize latency. > > This ought to be fixed, but it does not imply that you have to suffer many > > RTTs without edns-tcp-chain-query. > > There is not much they can do to fix it if I'm using a phone over 3g > with a validator on the phone. If they care about latency they should send all the necessary queries at once, as in the example I posted. It seems to me that edns-chain-query is just a more concise way to express this basic strategy. A client that is adapted to use edns-chain-query can equally well be adapted to make equivalent concurrent queries. That is, whenever you would like to send an edns-chain-query, you can get roughly the same latency if you send the basic query and at the same time send queries for DS and DNSKEY for every domain name from your QNAME to its topmost uncached parent domain. So I think the draft should be more clear about the benefits of this protocol change, relative to the backwards-compatible concurrent query strategy. I say "roughly" above since the option might allow you to save the second round trip for validating out-of-zone CNAME targets. > > Section 5.2 generating a query: > > > > I think the Last Known Query Name needs to be the First Unknown Query > > Name. > > I was avoiding that because the client does not know what it doesn't > know. There might not be zone cuts on every dot. Which is why I opted > for it to convey that it did know. If the client is querying for www.example.com and it knows com, and it knows it doesn't know example.com, it should put example.com in the option. It doesn't matter if that is a zone cut or not. > > In the empty cache case, the client only has a root trust anchor so > > it needs the root DNSKEY RRset. So when it sends . in the edns-chain-query > > option it wants to get everything up to and including the root. > > Yes. Was this not clear in the draft? But as currently written, the client will not get the . DNSKEY RRset, because the option says it knows the root. If it only has a trust anchor, not the complete . DNSKEY RRset, it won't be able to validate the TLD DS record. It will have to make a separate query for the . DNSKEY RRset. If you change it to be the last unknown domain name, then this problem goes away. > > Section 5.3 generating a response: > > > > Why include the NS RRsets? The client is making forwarding queries to an > > upstream recursive server, so it doesn't need to know the names or > > addreses of the authoritative servers. Those are only useful for direct > > iterative resolving. > > Because roaming devices run the risk of changing to a network where they > have to operate without forwarder. In which case it would be really nice > to already have those NS records validated and ready. It seemed like an > optimization that might cause more problems than it solves. Oh, that makes sense. It would be helpful to have that rationale in the NS record considerations section of the draft. And now to additional validation chains outside the client's last known name... > I don't think there is a principle reason why not to add those to the > additional section. In fact, I had thought about a special query that > would signal to the upstream resolver "give me your 1% hot cache > entries with a TTL of more then 5 minutes". Sounds like a self-ddos option to me :-) > > So the server has a dilemma: include everything to ensure that the client > > doesn't have to make any more queries, which is a waste of bandwidth if > > the client's cache is populated, or make the client suffer another round > > trip to deal with the targets if the cache isn't populated? > > right. so we can either make an option, or not optimize here. > > I'd say that MX is not that important because it is not very interactive > (but a background process) and that CNAME/DNAME could be avoided if > people cared about the extra 1 RTT for the followup (TCP keepalive) query. Note that (when comparing with clients that don't use this option and just send all the necessary queries at once) this second RTT for CNAME validation is the one that the option can eliminate. > > Perhaps it would make sense to send the validation chain for CNAME targets > > and additional records only if the client's edns-chain domain is a parent > > of the target. The server can then be sure it only sends records the > > client does not have. If the targets are not under the client's edns-chain > > domain, then the client might have to send a follow-up query. > > I think that's what Jelte was hinting at too. I think I'll try to write > this up for the next version. It covers a quite common case, and without > the risk of needing to include a whole new hierarchy of which we don't > know if the client knows it or not. Cool. I still have a nagging question if there is a better way to eliminate more of these follow-up queries. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From paul@nohats.ca Tue Oct 22 07:48: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 5C65D11E81A7 for ; Tue, 22 Oct 2013 07:48:15 -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 GT5AVL5++XDB for ; Tue, 22 Oct 2013 07:48:10 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2E811E81B3 for ; Tue, 22 Oct 2013 07:48:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d3yJ53dZKz1Kj; Tue, 22 Oct 2013 10:48:05 -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 ZzU_hG5NFlkB; Tue, 22 Oct 2013 10:48:04 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 22 Oct 2013 10:48:04 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 78852807CA; Tue, 22 Oct 2013 10:48:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6BAC0805BD; Tue, 22 Oct 2013 10:48:05 -0400 (EDT) Date: Tue, 22 Oct 2013 10:48:05 -0400 (EDT) From: Paul Wouters To: Tony Finch 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-01.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 14:48:15 -0000 On Tue, 22 Oct 2013, Tony Finch wrote: >> There is not much they can do to fix it if I'm using a phone over 3g >> with a validator on the phone. > > If they care about latency they should send all the necessary queries at > once, as in the example I posted. But you mostly cannot know. There is not much quering all possible zone cuts of a.b.c.d.e.fg.h.i.j.k.l.com if the nameserver of l.com is ns1.nohats.ca. Now if l.com's NS records are ns1.nohats.ca, than sure we could add the relatively small stuff for .ca and nohats.ca. to the additional section as well. The question is where do you draw the line? I think latency is a little more important than saving a few bytes, so I'd rather get some redundant data. Can we leave that decision as a local policy, analogue to a 'minimal responses' switch ? > It seems to me that edns-chain-query is > just a more concise way to express this basic strategy. A client that is > adapted to use edns-chain-query can equally well be adapted to make > equivalent concurrent queries. But when you are hammering all imaginary zone cuts, and you really needed .ca, that seems overly aggressive to me. The client does not have a good idea what to ask. The server does have a good idea of what it should return. Therefor I think the client should simply ask what it wants to know, and the server should think about sending additional data to satisfy the original question. > So I think the draft should be more clear about the benefits of this > protocol change, relative to the backwards-compatible concurrent query > strategy. I'll try and write something up. But I hope the above explanation makes sense to you? >>> I think the Last Known Query Name needs to be the First Unknown Query >>> Name. >> >> I was avoiding that because the client does not know what it doesn't >> know. There might not be zone cuts on every dot. Which is why I opted >> for it to convey that it did know. > > If the client is querying for www.example.com and it knows com, and it > knows it doesn't know example.com, it should put example.com in the > option. It doesn't matter if that is a zone cut or not. What if it does know example.com, just not www.example.com. It puts in www.example.com? And what is "knowing" with regard to RRtype? It might not "know" something because it does not exist. I prefer chaining the question to something we know exists. >>> In the empty cache case, the client only has a root trust anchor so >>> it needs the root DNSKEY RRset. So when it sends . in the edns-chain-query >>> option it wants to get everything up to and including the root. >> >> Yes. Was this not clear in the draft? > > But as currently written, the client will not get the . DNSKEY RRset, > because the option says it knows the root. If it only has a trust anchor, > not the complete . DNSKEY RRset, it won't be able to validate the TLD DS > record. It will have to make a separate query for the . DNSKEY RRset. > > If you change it to be the last unknown domain name, then this problem > goes away. I see. That's true. Let me think on this a bit more. I'm not sure if this one corner case is important enough to matter. Let's see what others have to say about this? >>> Section 5.3 generating a response: >>> >>> Why include the NS RRsets? The client is making forwarding queries to an >>> upstream recursive server, so it doesn't need to know the names or >>> addreses of the authoritative servers. Those are only useful for direct >>> iterative resolving. >> >> Because roaming devices run the risk of changing to a network where they >> have to operate without forwarder. In which case it would be really nice >> to already have those NS records validated and ready. It seemed like an >> optimization that might cause more problems than it solves. > > Oh, that makes sense. It would be helpful to have that rationale in the > NS record considerations section of the draft. Will do. >>> Perhaps it would make sense to send the validation chain for CNAME targets >>> and additional records only if the client's edns-chain domain is a parent >>> of the target. The server can then be sure it only sends records the >>> client does not have. If the targets are not under the client's edns-chain >>> domain, then the client might have to send a follow-up query. >> >> I think that's what Jelte was hinting at too. I think I'll try to write >> this up for the next version. It covers a quite common case, and without >> the risk of needing to include a whole new hierarchy of which we don't >> know if the client knows it or not. > > Cool. > > I still have a nagging question if there is a better way to eliminate > more of these follow-up queries. We should probably take a look at some common resolves (on phones) and see what dns data we currently have. google for instance has straight A records for gmail.com but CNAMEs for mail.google.com. Paul From fanf2@hermes.cam.ac.uk Tue Oct 22 08:24: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 38B2A11E83FA for ; Tue, 22 Oct 2013 08:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 rqyLqwYkIcy0 for ; Tue, 22 Oct 2013 08:24:04 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f33]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC4911E8461 for ; Tue, 22 Oct 2013 08:24:01 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:50170) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1VYdoO-0004tL-gf (Exim 4.80_167-5a66dd3) (return-path ); Tue, 22 Oct 2013 16:24:00 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VYdoO-0002es-5p (Exim 4.72) (return-path ); Tue, 22 Oct 2013 16:24:00 +0100 Date: Tue, 22 Oct 2013 16:24:00 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Wouters In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-01.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 15:24:05 -0000 Paul Wouters wrote: > > But when you are hammering all imaginary zone cuts, and you really > needed .ca, that seems overly aggressive to me. Even though in the majority of cases you'll only make a couple of redundant queries? I thought we weren't trying to save bandwidth :-) > > > > I think the Last Known Query Name needs to be the First Unknown Query > > > > Name. > > > > > > I was avoiding that because the client does not know what it doesn't > > > know. There might not be zone cuts on every dot. Which is why I opted > > > for it to convey that it did know. > > > > If the client is querying for www.example.com and it knows com, and it > > knows it doesn't know example.com, it should put example.com in the > > option. It doesn't matter if that is a zone cut or not. > > What if it does know example.com, just not www.example.com. It puts in > www.example.com? Right, since www.example.com might be a zone cut. And if it knows www.example.com there is no need for the option. > And what is "knowing" with regard to RRtype? Not my choice of word! And we're concerned with the ability to validate any RRset at a name, which is independent of the RRtype. > It might not "know" something because it does not exist. It will either know nothing since it has nothing in the cache or know it has a negative cache entry or know it has a cached proof of insecurity. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From askuma@microsoft.com Wed Oct 23 02:01:17 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 EBB3D11E833C for ; Wed, 23 Oct 2013 02:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jvcd4oF5TKI6 for ; Wed, 23 Oct 2013 02:01:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0151.outbound.protection.outlook.com [207.46.163.151]) by ietfa.amsl.com (Postfix) with ESMTP id 34C0B11E832D for ; Wed, 23 Oct 2013 02:01:07 -0700 (PDT) Received: from BL2PR03CA017.namprd03.prod.outlook.com (10.141.66.25) by BL2PR03MB196.namprd03.prod.outlook.com (10.255.230.155) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 23 Oct 2013 09:01:01 +0000 Received: from BN1BFFO11FD021.protection.gbl (2a01:111:f400:7c10::145) by BL2PR03CA017.outlook.office365.com (2a01:111:e400:c1b::25) with Microsoft SMTP Server (TLS) id 15.0.800.7 via Frontend Transport; Wed, 23 Oct 2013 09:01:01 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD021.mail.protection.outlook.com (10.58.53.81) with Microsoft SMTP Server (TLS) id 15.0.805.12 via Frontend Transport; Wed, 23 Oct 2013 09:01:01 +0000 Received: from SINEX14HUBC502.southpacific.corp.microsoft.com (157.60.220.61) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.3.158.2; Wed, 23 Oct 2013 09:00:23 +0000 Received: from SINEX14MBXC415.southpacific.corp.microsoft.com ([169.254.15.60]) by SINEX14HUBC502.southpacific.corp.microsoft.com ([fe80::df3:7769:8d99:21e5%13]) with mapi id 14.03.0158.002; Wed, 23 Oct 2013 09:00:20 +0000 From: Kumar Ashutosh To: Dave Lawrence , Sourav Sain Thread-Topic: [dnsext] Naked domain resolution with DNSSEC Thread-Index: Ac7ATe9x4lHsizWeS1mIFJsSspLh5AACqA0AAJVIAtAANWgSgAMPK9eQ Date: Wed, 23 Oct 2013 09:00:20 +0000 Message-ID: References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> In-Reply-To: <21074.61535.976353.482373@gro.dd.org> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.3.97] 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:(189002)(199002)(13464003)(51914003)(377454003)(56776001)(6806004)(55846006)(4396001)(54316002)(69226001)(65816001)(74366001)(50466002)(80022001)(85306002)(74706001)(76482001)(23726002)(74876001)(46102001)(51856001)(47976001)(50986001)(19580395003)(83322001)(19580405001)(44976005)(47736001)(49866001)(81686001)(81816001)(53806001)(46406003)(47446002)(80976001)(56816003)(77096001)(33656001)(81342001)(59766001)(77982001)(1511001)(79102001)(54356001)(83072001)(74662001)(74502001)(31966008)(16796002)(76786001)(76796001)(81542001)(63696002)(20776003)(47776003); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB196; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; 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: 000800954F X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "dnsext@ietf.org Group" , Thirunadha Reddy Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 09:01:17 -0000 Hi Thanks for the responses.=20 We dug a little deeper and we found that the scenario was happening ONLY f= or the cases where the zones have a CNAME at the zone apex In Setup where Parent zone (.com) is Signed and Child zone (contoso.com) is= Unsigned. CNAME record is present at apex (.) of Child zone ( contoso.com = CNAME new_contoso.com) The Resolver responded with SERV_FAIL. The packet flow is in following order: - Query is sent from client for contoso.com of type A to the resolver. - Resolver asked the same from .com server. - .com server replied back with NS record (for delegation) with name serve= r as Child Server, NSEC3 record (to prove that DS does not exist) and A/AAA= A records for Child Server - Based on the delegation response above, Resolver asked Child Server for = contoso.com and got a reply for the same with CNAME pointing to new_contoso= .com.=20 - Now Resolver still asks for DS Record of contoso.com (probably because C= NAME record in the response overwrites everything else present at that node= ) and it could not get response as the zone is unsigned. - Resolver replied back to the client with server failure We have observed the same behaviour with BIND resolvers as well. Is this be= haviour correct? Coming back to the original question, the migration from contoso.com to new= _contoso.com is a fairly common scenario. Are there any guidance on how to = achieve such a migration. One argument can be that the authoritative server= for contoso.com should not keep CNAME records at (.) zone apex. In that ca= se how is the admin supposed to handle such migrations and still support Na= ked domain resolutions. Thanks Ashu -----Original Message----- From: Dave Lawrence [mailto:tale@dd.org]=20 Sent: Monday, October 7, 2013 11:03 PM To: Sourav Sain Cc: Kumar Ashutosh; dnsext@ietf.org Group Subject: RE: [dnsext] Naked domain resolution with DNSSEC Sourav Sain writes: > Presented below is a name resolution for "facebook.com, type=3DA". In=20 > the first name resolution against "218.248.240.179" we see that=20 > "69.171.239.12#53(a.ns.facebook.com)" ends up returning an A record=20 > for QName=3Dfacebook.com. Since COM is signed A record for facebook.com=20 > needs to have an RRSIG(A) in the response, which, obviously is missing=20 > as a.ns.facebook.com cannot return the signature for A using keys=20 > owned by COM. Our concern is, a security aware validating server,=20 > having root or COM's Trust Anchor, will expect an RRSIG in the=20 > response for facebook.com, type=3DA, not having which, will conclude the= =20 > response as BOGUS. To expand a little on the answer that Jim Reid gave, it is important to rem= ember the principle that for records at a zone cut, almost all records are = authoritatively owned by the delegated zone, not the delegator. The only e= xception to this is the DS record. Therefore this sentence from above, and= the crux of your problem, is not correct: > Since COM is signed A record for facebook.com needs to have an > RRSIG(A) in the response A properly written, standards-compliant validating resolver will recognize = that when it originally asked the GTLD servers for facebook.com it got a pr= ovably insecure delegation to the facebook.com nameservers. Therefore it w= ill know that all records within the zone, including those at the apex, wil= l not come with signatures. From ajs@anvilwalrusden.com Wed Oct 23 02:17:30 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 B604B11E8350 for ; Wed, 23 Oct 2013 02:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1qrWn1AE888 for ; Wed, 23 Oct 2013 02:17:26 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4278F11E834E for ; Wed, 23 Oct 2013 02:17:19 -0700 (PDT) Received: from mx1.yitter.info (unknown [203.83.33.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id DFE818A031; Wed, 23 Oct 2013 09:17:15 +0000 (UTC) Date: Wed, 23 Oct 2013 05:17:12 -0400 From: Andrew Sullivan To: Kumar Ashutosh Message-ID: <20131023091711.GB10681@mx1.yitter.info> References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Thirunadha Reddy , "dnsext@ietf.org Group" , Sourav Sain Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 09:17:30 -0000 On Wed, Oct 23, 2013 at 09:00:20AM +0000, Kumar Ashutosh wrote: > > In Setup where Parent zone (.com) is Signed and Child zone (contoso.com) is Unsigned. CNAME record is present at apex (.) of Child zone ( contoso.com CNAME new_contoso.com) The Resolver responded with SERV_FAIL. It should respond with SERVFAIL in that case. You have an invalid zone on the child side. You can't have a CNAME at the apex of a zone. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From marc.lampo.ietf@gmail.com Wed Oct 23 06:32: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 3DF1F11E8196 for ; Wed, 23 Oct 2013 06:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 fOm3BfT60I7R for ; Wed, 23 Oct 2013 06:32:10 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8F17F11E83AD for ; Wed, 23 Oct 2013 06:32:01 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id jx11so394174veb.7 for ; Wed, 23 Oct 2013 06:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gXM//Z6xZdmzR7ACWQB21ds9aNyobilhDzg5ONp3Sm4=; b=UmBOAGfg0z2LqMGhoDD2Byrid87ulTtRcVCREqrfqA4J5aPpSzxWjU5ZU3XF+MCgp2 ucP+V8j+id5YBhUU5KJc1xilsJURUrNG7MNIfvWFxyBJPOYSmMKK8LOHbLPwGst3wNc5 cvX+eyoXe+GOXgN2oN9mUch6AhiIZG2Qyw1HcyzYtY1FjpdNxL0cXsZCM6S+AhSJcVt8 3AhSb+LfvQnxgGwQlqIQjdv54mOU3kb2hLCd0bAS0+heYjzMLf+i9BJY6+iaEuwOAWQA oYnG7DAvLX5xISzDknuP+//oghEpaU8eCAnJtQ5LHhRx1K40ZtyaCcbFw87ooQWQsfWP 3tVg== MIME-Version: 1.0 X-Received: by 10.58.107.204 with SMTP id he12mr1143561veb.26.1382535119528; Wed, 23 Oct 2013 06:31:59 -0700 (PDT) Received: by 10.58.227.66 with HTTP; Wed, 23 Oct 2013 06:31:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Oct 2013 15:31:59 +0200 Message-ID: From: Marc Lampo To: Paul Wouters Content-Type: multipart/alternative; boundary=089e0116037ab0699304e9688acd Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-01.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 13:32:11 -0000 --089e0116037ab0699304e9688acd Content-Type: text/plain; charset=ISO-8859-1 Hello, excuse me if I am uneasy with this proposed way of working. I think there are several more aspects that need a more precise description. Some of the aspects listed hereafter, but I cannot claim completeness. Hopefully mentioning these points will allow to correct/complete the draft. First off : I remember a presentation of Cricket Liu, author of DNS & Bind, Infoblox, where the overhead of DNSSEC overall is not dramatic. The very first time, when a cache is emtpy, several queries are needed of course, but the answers are cached and may not need to be queried for afterwards (for as long as they live in the cache). So, probably the first DNS query with tcp-chain saves overhead/bytes/RTT, but does the gain persist afterwards ? Staying with the first example, 9.1, Simple query for example.com. Suppose this query, for www.example.com., is followed by a second query for the MX record of example.com. After the first query, with or without tcp-chain-query, the forwarder will have the DNSKEY(s) of example.com. loaded in its cache. So : with tcp-chain-query, the query for the MX records, would specify "example.com." as last known query name. without tcp-chain-query, the query for the MX records would not be followed by any subsequent query (because the required DNSKEY info is already there) I would propose that more examples are provided, not to focus exclusively on a "first query when the cache is empty". When calculating the gain, the numbers for a second query should be considered as well. With respect to proposal in the draft : 1) In its present version, there are several references about a forwarder that sends queries with this tcp-chain-query option, a recursive resolver that responds with the tcp-chain-query option. But what with a tcp-chain-query to an authoritative name server ? (or : a name server authoritative for some, caching for all others) What with a tcp-chain-query to a forwarder itself ? 2) Without the tcp-chain-query option, it is hardly possible to create a DNS query packet larger than 512 bytes. (at least I would not know how : header + 1 name to query for (max 256 bytes) + EDNS0 cannot be larger than 512 bytes, can it ?) But with the tcp-chain-query option, this changes. As the draft states, in 4 Option Format, that no compression is allowed in the Last Known Query Name, an attacker could create a query with two max length domain names, resulting in a "valid" query, > 512 bytes, to name servers that may not be tcp-chain-query aware and expecting no queries exceeding 512 bytes. I think this is worth mentioning in the security section of the draft. 3) I'm puzzled with the numerous records that can be returned and them being in the proper sections (no offense meant, Olafur, I just don't see it yet) Without tcp-chain-request, a query for www.example.com (assuming there is only an A RRset for it) will yield : Answer section : www.example.com. A RRset www.example.com. RRSIG over A RRset A second query is needed for the DNSKEy of example.com. It will yield : Answer section : example.com. DNSKEY RRset example.com. RRSIG over DNSKEY RRset A third query is needed for the DS record of example.com. Resulting in : Answer section : example.com. DS RRset example.com. RRSIG over DS RRset ... The first paragraph of 5.3 Generating a Response states : "It extends the Authority Section for the DNS answer packet with the required DNS RRSets resulting in an Authority Section that contains a complete chain of DNS RRsets that start with the first chain element below the received Last Known Query Name upto and including the NS and DS RRsets that represent the zone cut (authoritative servers) of the QNAME." ? does this mean that all DNSKEY and DS information and there RRSIGs are expected in the authority section of the answer ? (which is a different section than if queried for separately) Perhaps it is only a matter of rephrasing ... 4) The one before last paragraph of 5.3 Generating a Response addresses CNAMEs Without tcp-chain-request, when a forwarder asks a resolver, recursive query, for a name that is turns out to be a CNAME, the resolver returns both the CNAME and the address it points at : $ dig @<-resolver-ip-> www.hotmail.com. +recurse +short dispatch.kahuna.glbdns2.microsoft.com. 157.55.0.137 157.55.0.139 So, 1 query, 1 answer that has it all. But the one before last paragraph of 5.3 states : "It MUST NOT follow the CNAME ..." Thus this mean the forwarder will have to ask a second question, if using tcp-chain-request ? My feeling is this is an important change in the behaviour. (but I understand the author is hesitant as well, about this paragraph) (no comment of mine on DNAME, I am not qualified for that). Kind regards, Marc Lampo On Tue, Oct 15, 2013 at 10:24 PM, Paul Wouters wrote: > > This is the 01 version for edns-tcp-chain-query-01 > > - Moved TCP Keep-alive into a separate document > - Allow edns-tcp-chain-query discovery over UDP > - Clarify CNAME / DNAME - Cleanup of text. > > Paul > > > -------- Original Message -------- > From: internet-drafts@ietf.org > To: Paul Wouters > Subject: New Version Notification for draft-wouters-edns-tcp-chain-** > query-01.txt > Date: Tue, 15 Oct 2013 10:21:52 -0700 > > A new version of I-D, draft-wouters-edns-tcp-chain-**query-01.txt > has been successfully submitted by Paul Wouters and posted to the > IETF repository. > > Filename: draft-wouters-edns-tcp-chain-**query > Revision: 01 > Title: TCP chain query requests in DNS > Creation date: 2013-10-15 > Group: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-** > drafts/draft-wouters-edns-tcp-**chain-query-01.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-01 > Diff: http://www.ietf.org/rfcdiff?** > url2=draft-wouters-edns-tcp-**chain-query-01 > > 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. > > > > > 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 > > > ______________________________**_________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/**listinfo/dnsext > --089e0116037ab0699304e9688acd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

excuse me if I am uneasy with this prop= osed way of working.

I think there are several more aspects that nee= d a more precise description.
Some of the aspects listed hereafter, but = I cannot claim completeness.

Hopefully mentioning these points will allow to correct/complete the dr= aft.


First off :
I remember a presentation of Cricket Liu, au= thor of DNS & Bind, Infoblox,
where the overhead of DNSSEC overall i= s not dramatic.
The very first time, when a cache is emtpy, several queries are needed
o= f course, but the answers are cached and may not need to be queried for
= afterwards (for as long as they live in the cache).

So, probably the= first DNS query with tcp-chain saves overhead/bytes/RTT,
but does the gain persist afterwards ?
Staying with the first example, 9= .1, Simple query for example.com.
=A0Suppose this query, for www.example.= com.,
=A0is followed by a second query for the MX record of example.com.

=A0After the first query, with or without= tcp-chain-query, the forwarder
=A0will have the DNSKEY(s) of example.com. loaded in its cache.
=A0So :
=A0with tcp-chain-query, the query for the MX records, would spe= cify
=A0 "example.com." as = last known query name.
=A0without tcp-chain-query, the query for the MX = records would not be followed
=A0 by any subsequent query (because the required DNSKEY info is already th= ere)

I would propose that more examples are provided,
not to focu= s exclusively on a "first query when the cache is empty".

When calculating the gain, the numbers for a second query should be
cons= idered as well.


With respect to proposal in the draft :
1) In= its present version, there are several references about
=A0=A0 a forwar= der that sends queries with this tcp-chain-query option,
=A0=A0 a recursive resolver that responds with the tcp-chain-query option.<= br>
=A0=A0 But what with a tcp-chain-query to an authoritative name serv= er ?
=A0=A0=A0 (or : a name server authoritative for some, caching for a= ll others)
=A0=A0 What with a tcp-chain-query to a forwarder itself ?

2) Withou= t the tcp-chain-query option, it is hardly possible to
=A0=A0 create a D= NS query packet larger than 512 bytes.
=A0=A0 (at least I would not know= how :
=A0=A0=A0 header + 1 name to query for (max 256 bytes) + EDNS0
=A0=A0=A0= cannot be larger than 512 bytes, can it ?)

=A0=A0 But with the tcp-= chain-query option, this changes.
=A0=A0 As the draft states, in 4 Optio= n Format, that no compression is allowed
=A0=A0 in the Last Known Query Name,
=A0=A0 an attacker could create a q= uery with two max length domain names,
=A0=A0 resulting in a "valid= " query, > 512 bytes,
=A0=A0 to name servers that may not be tcp= -chain-query aware
=A0=A0 and expecting no queries exceeding 512 bytes.

=A0=A0 I think = this is worth mentioning in the security section of the draft.

3) I&= #39;m puzzled with the numerous records that can be returned
=A0=A0 and = them being in the proper sections
=A0=A0 (no offense meant, Olafur, I just don't see it yet)

=A0= =A0 Without tcp-chain-request, a query for www.example.com
=A0=A0 (assuming there is only an A RRset for it)=
=A0=A0 will yield :
=A0=A0 Answer section : www.example.com<= /a>. A RRset
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= a href=3D"http://www.example.com">www.example.com. RRSIG over A RRset=A0=A0 A second query is needed for the DNSKEy of example.com.
=A0=A0 It will yield :
=A0=A0 Answer section : example.com. DNSKEY RRset
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 example.com. RRSIG= over DNSKEY RRset
=A0=A0 A third query is needed for the DS record of <= a href=3D"http://example.com">example.com.
=A0=A0 Resulting in :
=A0=A0 Answer section : example.com. DS RRset
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 example.com. RRSIG ov= er DS RRset
=A0=A0 ...

=A0=A0 The first paragraph of 5.3 Generati= ng a Response states :
=A0=A0 "It extends the
=A0=A0 Authority Section for the DNS answer = packet with the required DNS
=A0=A0 RRSets resulting in an Authority Sec= tion that contains a complete
=A0=A0 chain of DNS RRsets that start with= the first chain element below the
=A0=A0 received Last Known Query Name upto and including the NS and DS
= =A0=A0 RRsets that represent the zone cut (authoritative servers) of the=A0=A0 QNAME."

=A0=A0 ? does this mean that all DNSKEY and DS = information and there RRSIGs
=A0=A0=A0=A0 are expected in the authority section of the answer ?
=A0= =A0=A0=A0 (which is a different section than if queried for separately)
=
=A0=A0 Perhaps it is only a matter of rephrasing ...

4) The one = before last paragraph of 5.3 Generating a Response
=A0=A0 addresses CNAMEs

=A0=A0 Without tcp-chain-request, when a for= warder asks a resolver,
=A0=A0 recursive query, for a name that is turns= out to be a CNAME,
=A0=A0 the resolver returns both the CNAME and the a= ddress it points at :
$ dig @<-resolver-ip-> www.hotmail= .com. +recurse +short
dispatch.kahuna.glbdns2.microsoft.com.
157.55.0.137
15= 7.55.0.139
=A0=A0 So, 1 query, 1 answer that has it all.

=A0=A0 But the one bef= ore last paragraph of 5.3 states :
=A0=A0 "It MUST NOT follow the C= NAME ..."
=A0=A0 Thus this mean the forwarder will have to ask a se= cond question,
=A0=A0 if using tcp-chain-request ?

=A0=A0 My feeling is this is an = important change in the behaviour.
=A0=A0 (but I understand the author i= s hesitant as well, about this paragraph)

=A0=A0 (no comment of mine= on DNAME, I am not qualified for that).

Kind regards,

Marc Lampo



On Tue, Oct 15, 2013 at 10:24 PM,= Paul Wouters <paul@nohats.ca> wrote:

This is the 01 version for edns-tcp-chain-query-01

- Moved TCP Keep-alive into a separate document
- Allow edns-tcp-chain-query discovery over UDP
- Clarify CNAME / DNAME - Cleanup of text.

Paul


-------- Original Message --------
From: interne= t-drafts@ietf.org
To: Paul Wouters <pwouters@redhat.com>
Subject: New Version Notification for draft-wouters-edns-tcp-chain-q= uery-01.txt
Date: Tue, 15 Oct 2013 10:21:52 -0700

A new version of I-D, draft-wouters-edns-tcp-chain-query-01.txt
has been successfully submitted by Paul Wouters and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-wouters-edns-tcp-chain-query
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 TCP chain query requests in DNS
Creation date: =A0 2013-10-15
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 15
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ie= tf.org/internet-drafts/draft-wouters-edns-tcp-chain-query-01.= txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.or= g/doc/draft-wouters-edns-tcp-chain-query
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/= draft-wouters-edns-tcp-chain-query-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.or= g/rfcdiff?url2=3Ddraft-wouters-edns-tcp-chain-query-01
Abstract:
=A0 =A0This document defines an EDNS0 extension that can be used by a DNSSE= C
=A0 =A0enabled Recursive Nameserver configured as a forwarder to send a
=A0 =A0single query over TCP requesting to receive a complete validation =A0 =A0path along with the regular query answer.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

--089e0116037ab0699304e9688acd-- From paul@nohats.ca Wed Oct 23 07:32:44 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 C40CD11E840D for ; Wed, 23 Oct 2013 07:32:44 -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 c7lZGp6isC0D for ; Wed, 23 Oct 2013 07:32:38 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6A06811E8399 for ; Wed, 23 Oct 2013 07:32:36 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d4YvR2VMnzB1f; Wed, 23 Oct 2013 10:32:19 -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 I_57OvLjekMP; Wed, 23 Oct 2013 10:32:18 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 23 Oct 2013 10:32:18 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 006C9807CA; Wed, 23 Oct 2013 10:32:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id ED8CA805BD; Wed, 23 Oct 2013 10:32:18 -0400 (EDT) Date: Wed, 23 Oct 2013 10:32:18 -0400 (EDT) From: Paul Wouters To: Marc Lampo 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-01.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 14:32:44 -0000 On Wed, 23 Oct 2013, Marc Lampo wrote: > First off : > I remember a presentation of Cricket Liu, author of DNS & Bind, Infoblox, > where the overhead of DNSSEC overall is not dramatic. > The very first time, when a cache is emtpy, several queries are needed > of course, but the answers are cached and may not need to be queried for > afterwards (for as long as they live in the cache). That is true for a dnssec resolver on the internet core, but not for a dnssec resolver on a handheld device where latency is very high. Organisation such as google don't like DNSSEC because of two reasons: 1) they dont trust port 53 is clean enough (they rolled out Google DNS) 2) Every RTT matters, and DNSSEC adds too many (google experiments with dnssec chains in X.509 attributes that come into the browser via TLS without extra RTTs) This draft is attempting to solve 2) by keeping DNS in DNS > So, probably the first DNS query with tcp-chain saves overhead/bytes/RTT, > but does the gain persist afterwards ? > Staying with the first example, 9.1, Simple query for example.com. > >  Suppose this query, for www.example.com., >  is followed by a second query for the MX record of example.com. > >  After the first query, with or without tcp-chain-query, the forwarder >  will have the DNSKEY(s) of example.com. loaded in its cache. >  So : >  with tcp-chain-query, the query for the MX records, would specify >   "example.com." as last known query name. >  without tcp-chain-query, the query for the MX records would not be followed >   by any subsequent query (because the required DNSKEY info is already there) It's not the gain so much for querying multiple records of the same QNAME. It's a web page with 20 different QNAMEs all using their own set of NS records, DNSKEY/DS records and A/AAAA records, where often the A/AAAA records are different from the NS/DS records, requiring a broad spectrum of queries to resolve. > I would propose that more examples are provided, > not to focus exclusively on a "first query when the cache is empty". Sure. I will look at making the examples section more clear. > When calculating the gain, the numbers for a second query should be > considered as well. I hope I explained above that it is not so much about queries for different RRtypes of the same QNAME. > With respect to proposal in the draft : > 1) In its present version, there are several references about >    a forwarder that sends queries with this tcp-chain-query option, >    a recursive resolver that responds with the tcp-chain-query option. > >    But what with a tcp-chain-query to an authoritative name server ? >     (or : a name server authoritative for some, caching for all others) >    What with a tcp-chain-query to a forwarder itself ? Authoritative servers do not contain the information to form query chains. They are expected to return REFUSED. I will clarify that in the text. > 2) Without the tcp-chain-query option, it is hardly possible to >    create a DNS query packet larger than 512 bytes. >    (at least I would not know how : >     header + 1 name to query for (max 256 bytes) + EDNS0 >     cannot be larger than 512 bytes, can it ?) > >    But with the tcp-chain-query option, this changes. >    As the draft states, in 4 Option Format, that no compression is allowed >    in the Last Known Query Name, >    an attacker could create a query with two max length domain names, >    resulting in a "valid" query, > 512 bytes, >    to name servers that may not be tcp-chain-query aware >    and expecting no queries exceeding 512 bytes. > >    I think this is worth mentioning in the security section of the draft. That's certainly worth mentioning. Perhaps we should state that a chain query should never exceed a certain length. > 3) I'm puzzled with the numerous records that can be returned >    and them being in the proper sections >    (no offense meant, Olafur, I just don't see it yet) > >    Without tcp-chain-request, a query for www.example.com >    (assuming there is only an A RRset for it) >    will yield : >    Answer section : www.example.com. A RRset >                     www.example.com. RRSIG over A RRset >    A second query is needed for the DNSKEy of example.com. >    It will yield : >    Answer section : example.com. DNSKEY RRset >                     example.com. RRSIG over DNSKEY RRset >    A third query is needed for the DS record of example.com. >    Resulting in : >    Answer section : example.com. DS RRset >                     example.com. RRSIG over DS RRset >    ... > >    The first paragraph of 5.3 Generating a Response states : >    "It extends the >    Authority Section for the DNS answer packet with the required DNS >    RRSets resulting in an Authority Section that contains a complete >    chain of DNS RRsets that start with the first chain element below the >    received Last Known Query Name upto and including the NS and DS >    RRsets that represent the zone cut (authoritative servers) of the >    QNAME." > >    ? does this mean that all DNSKEY and DS information and there RRSIGs >      are expected in the authority section of the answer ? >      (which is a different section than if queried for separately) Correct. Like traditional DNS queries, the answer to the QNAME/QTYPE appears in the Answer Section. Supporting records for that answer go into the Authority Section. (And possibly CNAME/DNAME following should go in the Additional Section) >    Perhaps it is only a matter of rephrasing ... I will see about clarifying it further. > 4) The one before last paragraph of 5.3 Generating a Response >    addresses CNAMEs > >    Without tcp-chain-request, when a forwarder asks a resolver, >    recursive query, for a name that is turns out to be a CNAME, >    the resolver returns both the CNAME and the address it points at : > $ dig @<-resolver-ip-> www.hotmail.com. +recurse +short > dispatch.kahuna.glbdns2.microsoft.com. > 157.55.0.137 > 157.55.0.139 >    So, 1 query, 1 answer that has it all. > >    But the one before last paragraph of 5.3 states : >    "It MUST NOT follow the CNAME ..." >    Thus this mean the forwarder will have to ask a second question, >    if using tcp-chain-request ? > >    My feeling is this is an important change in the behaviour. >    (but I understand the author is hesitant as well, about this paragraph) See the other thread regarding CNAMEs. We are still discussing what the best behaviour would be. The issue with returning anything about where the CNAME points to, is that it could be an entirely different branch in the DNS hierarchy - the answering server has no "Last Known Query Name" to know what part of that second chain to return. One suggestion has been to return it only when it falls within the requested chain. Regards, Paul From tale@dd.org Wed Oct 23 07:55:49 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D059111E841A for ; Wed, 23 Oct 2013 07:55:49 -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 MhfYx7YKuxdE for ; Wed, 23 Oct 2013 07:55:45 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by ietfa.amsl.com (Postfix) with ESMTP id D038311E83C8 for ; Wed, 23 Oct 2013 07:55:28 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id E9FFA3F438; Wed, 23 Oct 2013 10:55:27 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21095.58207.781300.353688@gro.dd.org> Date: Wed, 23 Oct 2013 10:55:27 -0400 From: Dave Lawrence To: Kumar Ashutosh In-Reply-To: References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> Cc: Thirunadha Reddy , "dnsext@ietf.org Group" , Sourav Sain Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 14:55:49 -0000 Kumar Ashutosh writes: > Coming back to the original question, the migration from contoso.com > to new_contoso.com is a fairly common scenario. Are there any guidance > on how to achieve such a migration. One argument can be that the > authoritative server for contoso.com should not keep CNAME records at > (.) zone apex. In that case how is the admin supposed to handle such > migrations and still support Naked domain resolutions. Unfortunately the best practice answer here is still to maintain the two zones in parallel. "Use DNAME!" should be the answer, but unfortunately there are a sufficient number of issues with operational deployment of DNAME that it can't really be relied upon, at least not during an active migration. As Andrew Sullivan said, CNAME is right out. Depending on the hosting server software, there are some easy ways to keep both zones absolutely in sync. I realize I'm replying to folks @microsoft.com right now, and unfortunately my knowledge of MS's auth DNS service is not current. However, with other servers (BIND for example) you can just point two different zone names at the same master file. Names in rdata that point within the zone can just be made to be fully qualified by the destination zone name. From derek@ihtfp.com Thu Oct 17 08:23: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 4EFD021F9EE0 for ; Thu, 17 Oct 2013 08:23:35 -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 cJTmN3hUksS0 for ; Thu, 17 Oct 2013 08:23:34 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id F0AE621F9EB5 for ; Thu, 17 Oct 2013 08:23:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id A3A55260298; Thu, 17 Oct 2013 11:23:13 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20908-06; Thu, 17 Oct 2013 11:23:11 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id F2F28260261; Thu, 17 Oct 2013 11:23:10 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.5/Submit) id r9HFN8g8007831; Thu, 17 Oct 2013 11:23:08 -0400 From: Derek Atkins To: Alex Bligh References: <1D9E3C41-0632-4FBE-9564-6CE8FB34AEA4@alex.org.uk> Date: Thu, 17 Oct 2013 11:23:08 -0400 In-Reply-To: <1D9E3C41-0632-4FBE-9564-6CE8FB34AEA4@alex.org.uk> (Alex Bligh's message of "Wed, 16 Oct 2013 19:17:50 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a X-Mailman-Approved-At: Wed, 23 Oct 2013 08:07:32 -0700 Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones 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, 17 Oct 2013 15:23:35 -0000 Alex Bligh writes: > On 16 Oct 2013, at 18:23, Derek Atkins wrote: > >> I admit I haven't read the whole draft, but my question is how do you >> authenticate and, more importantly, authorize the addition or (worse) >> deletion of zones? Imagine an attack vector where someone could get >> your domain's DNS servers to stop serving your domain(s)! >> >> I think the security of adding and (more importantly) removing zones >> should be carefully documented and discussed. > > I'm not sure why this would be different from someone doing an update > to remove the entire content of the zone served. Thus I don't really > see why it should need security any different from the existing > provisions for security. Well, if somone can add zones to my server it could be a DoS against my network provider. So how do you authorize the addition of new zones? This is something that's definitely a new feature and isn't effectively implementable using current UPDATE. As for deleting zones vs deleting records, you're right that the authorization required to remove all the records in a zone are effectively the same as the authZ to remove the zone itself. I believe, however, that authZ is usually on a record-by-record basis, generally providing for individuals to change the A record for their own devices. At least that's how I think it SHOULD be -- I've never deployed UPDATE. If that's the case then clearly one could have an AuthZ to remove the SOA (and thereby the whole zone). I still think it should be spelled out instead of "left for the reader to figure out." -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From muks@isc.org Wed Oct 23 09:16:08 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 4E95511E845E for ; Wed, 23 Oct 2013 09:16:08 -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 H4J-GKIl+3wm for ; Wed, 23 Oct 2013 09:16:07 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:141:43e5::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC2A11E843A for ; Wed, 23 Oct 2013 09:16:07 -0700 (PDT) Received: from totoro.home.mukund.org (unknown [115.118.71.47]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id CE44E1C00155; Wed, 23 Oct 2013 16:16:04 +0000 (GMT) Date: Wed, 23 Oct 2013 21:45:59 +0530 From: Mukund Sivaraman To: Paul Wouters Message-ID: <20131023161558.GA7710@totoro.home.mukund.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-keepalive-00.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:16:08 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Paul On Tue, Oct 15, 2013 at 04:21:34PM -0400, Paul Wouters wrote: > As discussed, I separated the EDNS TCP keep-alive option from the EDNS > chain-query document, and Joe Abley kindly offered his assistance in > (re)writing this document. >=20 > URL: http://www.ietf.org/internet-drafts/draft-wouters-edns-t= cp-keepalive-00.txt > Status: http://datatracker.ietf.org/doc/draft-wouters-edns-tcp-k= eepalive > Htmlized: http://tools.ietf.org/html/draft-wouters-edns-tcp-keepal= ive-00 This document does not cite RFC 5966. Have you read and considered everything in RFC 5966 in full when preparing this draft? Mukund --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQgcBAEBCgAGBQJSZ/Y7AAoJENJq4EOcI417LYs//jk/AHa+PZYja8bVQRJ1CdhF BfD9hTtGedanY+b4FwpWspUgtQvgxOH6FRPOjgvOpcLe7jiZX0VHTG1Wk0fALicb vSLHqk1Rcvg4IrTeyaLTX4bYFQvwN6xfzMS40OrcPkzIlT2BMDq9OKpuLFDIVOBC IOH+nvYpeFxRv5c4t6HQ1Aar6PbolXqrqSk0E+mwcV/9EwaK3hjdY4ZijyUCMuJn WphYt2lbnhALuK2K1Jf9e5aieZ9o8wmagRC0iplbwrdU9D/3OcpQto7tqAVNqSUs hOU2KJovWySnfWIdfW/f2syzVgGleVWRgjI2ni203YEyuYeBXgAKHVH/dan7pPqb SliKFsCOgGsiHYXn+27GR3J9Oi5ZXzUIlVu7+Osv5fWoAAXPIgc2ATIcpA17rKsz Bij/zh37PgHKelFNdv2gG4KjBj0qddLm2cH2GImUh2uQt0/O+/IHf1Qo+mUueTm5 xVKCuqCW10uEtrIOUgg1iddz5O3iZCfZoj6GZk6zGixFD2fBs1avgTpqpbQ05N+y RKA1ru7N59K7AY5kOmptL07kKDzWHgwA2jQ+TcJOgx3RudYSJBadtbJ4sfzAiKUC pBYyybHlHt3EW6Q8iwv3jNqN4GJNr0XH7cH+9zOnw5yZaxfoeftg6uWkW4KNuFYz kj3ZU6hdVD0muwzFTW4+cUDZy7LeyyV4hZLorFRQv0D0Oqvqnkh1iHSqMukCdo2x BWyHNp6luUb1CWmVlfzQVmnhTLfojEeCEm++bbq5LCoeFh3YZ3D3uP2IhLz1M2e0 pf5Ze5HsgCfHXEWJHyH0qh7rBYOKCH4oBj3VVTClkFpaioiDquYTUNEcCpngPdj4 GO3ErexGXBWw9N3E33eYt03PNA8GVv4A9szHP5YUjC3+cfhAumia23EFJna/UqPY 0T7OxNWtJ4lK2cXxYEMmt8fAVneFp5RMt/XoLGLc7S5W/ZMe0x4YRHCXebEgQPVF 4EZ4sMKQed+WHiO9inlMGAYUdh6Zo81owpKnb21++N0BnyiEO/VSUUgXInd4z/Jo g8xgVzpuJZs2GcMIgUu0xliZAIW2TltpsEelGzGa5GK0gU6rxU/Rj9oCS6ERV42r rtawsAepEJS/bo3zW23Xxqkp4SWxIaKQJFYU4oBun7UiGavRr7opyaylPf+7OtWo BAPhuOCo6MREFQUlnMWAJF1PWjixIEsE3VnDc3KouPkbTSzhxwyd2G9EeCZkYfZL Jx6YbvUcE/yOuKQjoKAityJD4N7mPzqJqwPvTumxoQ+ypvV3vN+k59cPp38+431m 5bXAxPR3X+OfMOrB9WsmlKqcrwgDZMhsfvkL0lSHo5vkRGJnjZ/vNiZZd8HWm8Rd xIJSm+rWF+HwA8j6467evK/8Pw7GMJ2VbNI4iK7/w7Q4VewB8ASun7dxiMBi0VAK FN5zkAO40BPRW7Pj5r95aYlHrPRtXix9uoSMsOjpbA9ReKeYYRmK9LpmLoQaNTUb GsXoMjMTgpeN8Lv/1wNQFXmrwSCIizYh4i6oLN5Qaps9L/Ad7fhdbiU0eiyN5rkE Kk1w1TLJ5BDtUEyjtcHMw3BTSgu7bD6af/aXxrMBLWhdeeDP0x0UMVYBEBoHvoQB osjRJpBRoBT947wNULqTwGKeqqKHYxbrddodERG/nbfe8+gxdnQJkI0JPRXQMaHH QWxPTg6B6nI/HsN645GSw7dTqxmOYuLdMlGJi4WakLiF2PPVEA9SN8diy7pM7Bo5 QLXUStwENukHxkAJhkUCcQAst2VPjWm1zqxQxh5RVFmjrCnbuxgl2T2AjNPUxX23 SDHyifAvFWtkgVy/WBhINM8HfhYKI4CR1ty/QD8htGG/Wi4nH3vOwiIgPTecq/90 WZEjenaX2gC4NgBtKVJNdRA/Jibq7TxtWUk9Q3INt9D3AFtc0BncnvIo2pdQXRkX /Zz42T2B9hqui6mrKMAttJ64G4DMOyBCwjwWc/WgLgpoozlDYZqF1dYtH2sUUB9J 9c7zXuHkHbDF9ws77/fchwe3JvX9z571AcsRGSXB0xB86vYGgvtjb7H6AQs67QxD 1yUbq5bZxPEvwaqVLQh4pHGP4jDKQMyNxMPNbMf4pV3L7ghJILRVbOktMSo2YOAk 9RXiY9E+chc32d5k76sDC8RGxMuI7obod6l71lajhLXPk0RQpFgAe0fmoeBocajK svTwcH9DCHyh5XiSArjnRFZfb1xPNIaQoH12VNVd/w6Bzm3Vt0rIaic7oETtITkX ZW06pt6wCCov/6B5cGM9tux6udsAaIMmHaOiOkioXzSCIOGCN+/1m0frFSxNj/Jn JlKVFzHvCPLobgJGk+E9QqZP3Qcpxp9XSH+WPUjvy0CcGEDEkkkiNw9yKw5S8ElC fou9RVTaA4Mr9S2jgH/CtInb4S3d9pCYS/GpuGsaQwyNNzgSLmGQioi3OUsuZ9Cu RCbGii+QOz92j9t05OAqvRPbK26ibVvfTy1SuwzUvwCGomiSK9I3ZZtW9ejKxD7c sj2NNvxliZyJrtP+S7DGPRSmC1jf1Pjh84wa7VIhQnn4SeC+hME5lXbDVi08cQ2I d3YM8eDNBejOz2dMl5A3/TvecTlblsqr5DmxmDqyR0UBAWjD1BgdFpbD6CB/+SSP wmIohdrXSOaPlSbqWe5l7h1IFyOOtloc1RbYQvCma/pC25oiy9i/w30vby4qPINy oJSqw7XlXG9FbLsYzJYf =s2FU -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From jabley@hopcount.ca Wed Oct 23 09:19:06 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 A818611E842A for ; Wed, 23 Oct 2013 09:19:06 -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 v44jTUUsQBUd for ; Wed, 23 Oct 2013 09:19:06 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F0CB611E81C4 for ; Wed, 23 Oct 2013 09:19:01 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id u16so1743143iet.32 for ; Wed, 23 Oct 2013 09:19:01 -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=XcvmLGxE8NjsqG20Qx+gn+LRvwFJlPrqXmVK2ooLNoE=; b=ZzfT0+Cpa9PzrLJsk4ZKq3lqQBiQeR6gGGQ4pKHQuQAyB97AsByPhuwnspUeVhr+QJ nIMs4ocJJRiG+val3eadggcZNTgC+DKzNBv4nC0tmDNmnyGB5TpktZwgEbhVS5wZBAqo qq1PiRGeiqlYUq2MHy9VD8SWEz+1EEYps73II= 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=XcvmLGxE8NjsqG20Qx+gn+LRvwFJlPrqXmVK2ooLNoE=; b=U6tqOrIhPlrtDiI67+qHR3LUgxisTdFUrhsQvrqNKsrx4rdDxoyTtx0+2t82dxJruI hW0eNpXzROoyVTERmmXliSz/UY3oMbuuYcqctSltlsvOIl1q9l+72vVlUPHI/vih8SOq nSts4nhTn4BoEzlL2lNHiYOiOZvZB041RSpfJFZ3b+vxU6tPPY9Sb/SerDzALgj3pGT1 x3XK4DpeBlRYJvYZb5jjIBhQgffY6F9X2FEN5mC1SyjwaIFU7qJLI8/6pr4xxslMzxRE jCDuHvg+6jbyIBiTyUiQ+qaqhUoJ9lzAB2c5enLTwIQxbXAh9gEKnZ85rC0G0yQUA1jp 2OBQ== X-Gm-Message-State: ALoCoQlLm2bkHJwZilJ8QNlhNp2OLliQwJhgsATwN2iXt+dZ6nroSF9xxFVY/ZWmC36yB6VD20co X-Received: by 10.42.61.147 with SMTP id u19mr1044763ich.36.1382545141540; Wed, 23 Oct 2013 09:19:01 -0700 (PDT) Received: from [199.212.90.58] (135-23-68-78.cpe.pppoe.ca. [135.23.68.78]) by mx.google.com with ESMTPSA id k6sm7799800igx.8.2013.10.23.09.18.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 09:19:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Joe Abley In-Reply-To: <21095.58207.781300.353688@gro.dd.org> Date: Wed, 23 Oct 2013 12:18:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <855AF2C1-14F4-45BF-850E-5141F08450F0@hopcount.ca> References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> <21095.58207.781300.353688@gro.dd.org> To: Dave Lawrence X-Mailer: Apple Mail (2.1816) Cc: Sourav Sain , "dnsext@ietf.org Group" , Thirunadha Reddy Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:19:06 -0000 Hey, On Oct 23, 2013, at 10:55, Dave Lawrence wrote: > Kumar Ashutosh writes: >> Coming back to the original question, the migration from contoso.com >> to new_contoso.com is a fairly common scenario. Are there any = guidance >> on how to achieve such a migration. One argument can be that the >> authoritative server for contoso.com should not keep CNAME records at >> (.) zone apex. In that case how is the admin supposed to handle such >> migrations and still support Naked domain resolutions.=20 >=20 > Unfortunately the best practice answer here is still to maintain the > two zones in parallel. "Use DNAME!" should be the answer, but > unfortunately there are a sufficient number of issues with operational > deployment of DNAME that it can't really be relied upon, at least not > during an active migration. Geoff Huston and George Michaelson did an experiment on this the other = week, and their findings were that DNAME support is as near universal as = they can measure. A description of the experiment can be found in an appendix to = draft-jabley-dnsop-as112-dname-01. Joe From askuma@microsoft.com Wed Oct 23 10:40:54 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 1DB9A11E81E4 for ; Wed, 23 Oct 2013 10:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04t-n936whaa for ; Wed, 23 Oct 2013 10:40:26 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id 82E8411E81E6 for ; Wed, 23 Oct 2013 10:39:54 -0700 (PDT) Received: from DM2PR03CA001.namprd03.prod.outlook.com (10.141.52.149) by BN1PR03MB265.namprd03.prod.outlook.com (10.255.200.12) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 23 Oct 2013 17:39:47 +0000 Received: from BN1AFFO11FD012.protection.gbl (2a01:111:f400:7c10::108) by DM2PR03CA001.outlook.office365.com (2a01:111:e400:2414::21) with Microsoft SMTP Server (TLS) id 15.0.800.7 via Frontend Transport; Wed, 23 Oct 2013 17:39:47 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD012.mail.protection.outlook.com (10.58.52.72) with Microsoft SMTP Server (TLS) id 15.0.805.12 via Frontend Transport; Wed, 23 Oct 2013 17:39:46 +0000 Received: from SINEX14HUBC503.southpacific.corp.microsoft.com (157.60.220.65) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.3.158.2; Wed, 23 Oct 2013 17:39:07 +0000 Received: from SINEX14MBXC415.southpacific.corp.microsoft.com ([169.254.15.60]) by SINEX14HUBC503.southpacific.corp.microsoft.com ([fe80::7c66:838:6c58:af59%12]) with mapi id 14.03.0158.002; Wed, 23 Oct 2013 17:39:04 +0000 From: Kumar Ashutosh To: Dave Lawrence Thread-Topic: [dnsext] Naked domain resolution with DNSSEC Thread-Index: Ac7ATe9x4lHsizWeS1mIFJsSspLh5AACqA0AAJVIAtAANWgSgAMPK9eQAA/6YIAAAx4eMA== Date: Wed, 23 Oct 2013 17:39:03 +0000 Message-ID: References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> <21095.58207.781300.353688@gro.dd.org> In-Reply-To: <21095.58207.781300.353688@gro.dd.org> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.3.90] 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:(51914003)(13464003)(199002)(189002)(377454003)(56776001)(54316002)(33656001)(79102001)(55846006)(80022001)(65816001)(47976001)(50986001)(74502001)(77982001)(47736001)(47776003)(63696002)(49866001)(31966008)(16796002)(20776003)(74662001)(59766001)(46406003)(47446002)(76786001)(15974865002)(76796001)(4396001)(51856001)(81342001)(54356001)(53806001)(76482001)(23726002)(81542001)(46102001)(77096001)(56816003)(69226001)(19580395003)(19580405001)(6806004)(83072001)(85306002)(81816001)(81686001)(50466002)(80976001)(74366001)(83322001)(44976005)(74876001)(74706001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB265; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; 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: 000800954F X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: Thirunadha Reddy , "dnsext@ietf.org Group" , Sourav Sain Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 17:40:54 -0000 Hi=20 Thanks for the quick responses. The Microsoft authoritative DNS servers prevent adding CNAMEs at the zone a= pex. But there may be other DNS servers which may be allowing this and the = validating resolvers are returning Serv_fail, As Andrew suggested. I agree that CNAME should not be used for such migrations and DNAME may be = used but *might* have deployment issues. But DNAME has a limitation that if= you add DNAME at zone apex then you cannot have any other record in the zo= ne, except at the zone apex (like NS records). One more scenario where naked domain issue becomes evident is when the auth= oritative servers try to point a few of their records at some third party D= NS hosting services Contoso.com { www CNAME contoso.dnsprovider.com (owned by a third party) internal A 1.1.1.1 } How does it set out to achieve the naked domain resolution. It cannot add C= NAME at the apex. Also it cannot add DNAME to the loadbalancer.net at the z= one apex as then it can't host internal records and also resolution for www= will point to www.dnsprovider.com How will such a customer ensure that both www.contoso.com and contoso.com g= et pointed to contoso.provider.com. Much appreciated! Thanks Ashu -----Original Message----- From: Dave Lawrence [mailto:tale@dd.org]=20 Sent: Wednesday, October 23, 2013 8:25 PM To: Kumar Ashutosh Cc: Sourav Sain; dnsext@ietf.org Group; Thirunadha Reddy Subject: RE: [dnsext] Naked domain resolution with DNSSEC Kumar Ashutosh writes: > Coming back to the original question, the migration from contoso.com=20 > to new_contoso.com is a fairly common scenario. Are there any guidance=20 > on how to achieve such a migration. One argument can be that the=20 > authoritative server for contoso.com should not keep CNAME records at > (.) zone apex. In that case how is the admin supposed to handle such=20 > migrations and still support Naked domain resolutions. Unfortunately the best practice answer here is still to maintain the two zo= nes in parallel. "Use DNAME!" should be the answer, but unfortunately ther= e are a sufficient number of issues with operational deployment of DNAME th= at it can't really be relied upon, at least not during an active migration.= As Andrew Sullivan said, CNAME is right out. Depending on the hosting server software, there are some easy ways to keep = both zones absolutely in sync. I realize I'm replying to folks @microsoft.= com right now, and unfortunately my knowledge of MS's auth DNS service is n= ot current. However, with other servers (BIND for example) you can just point two different zone names at the same master fil= e. Names in rdata that point within the zone can just be made to be fully = qualified by the destination zone name. From jim@rfc1035.com Wed Oct 23 11:05: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 05EC911E834D for ; Wed, 23 Oct 2013 11:05:34 -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 DfFxS6b3buBR for ; Wed, 23 Oct 2013 11:05:31 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id 9620511E813A for ; Wed, 23 Oct 2013 11:05:30 -0700 (PDT) Received: from [192.168.0.11] (97e0fe7a.skybroadband.com [151.224.254.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 98F94CBC41C; Wed, 23 Oct 2013 19:05:28 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jim Reid In-Reply-To: Date: Wed, 23 Oct 2013 19:05:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> <21095.58207.781300.353688@gro.dd.org> To: Kumar Ashutosh X-Mailer: Apple Mail (2.1510) Cc: Sourav Sain , "dnsext@ietf.org Group" , Thirunadha Reddy Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 18:05:34 -0000 On 23 Oct 2013, at 18:39, Kumar Ashutosh wrote: > The Microsoft authoritative DNS servers prevent adding CNAMEs at the = zone apex. But there may be other DNS servers which may be allowing this = and the validating resolvers are returning Serv_fail, As Andrew = suggested. This is how it should be. If a name exists as a CNAME, it cannot exist = as any other RRtype. Except of course for any RRSIGs and NSEC or NSEC3's = if the zone is signed. Adding a CNAME at the zone apex fails because = that name must at by definition already have at least a SOA and some NS = records. From askuma@microsoft.com Wed Oct 23 11:30: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 71CA111E81F5 for ; Wed, 23 Oct 2013 11:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfmIKF3goife for ; Wed, 23 Oct 2013 11:30:16 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id A31F811E81C1 for ; Wed, 23 Oct 2013 11:30:16 -0700 (PDT) Received: from DM2PR03CA008.namprd03.prod.outlook.com (10.141.52.156) by BLUPR03MB184.namprd03.prod.outlook.com (10.255.212.156) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 23 Oct 2013 18:30:15 +0000 Received: from BN1AFFO11FD012.protection.gbl (2a01:111:f400:7c10::101) by DM2PR03CA008.outlook.office365.com (2a01:111:e400:2414::28) with Microsoft SMTP Server (TLS) id 15.0.800.7 via Frontend Transport; Wed, 23 Oct 2013 18:30:15 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD012.mail.protection.outlook.com (10.58.52.72) with Microsoft SMTP Server (TLS) id 15.0.805.12 via Frontend Transport; Wed, 23 Oct 2013 18:30:14 +0000 Received: from SINEX14HUBC501.southpacific.corp.microsoft.com (157.60.220.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.3.158.2; Wed, 23 Oct 2013 18:29:29 +0000 Received: from SINEX14MBXC415.southpacific.corp.microsoft.com ([169.254.15.60]) by SINEX14HUBC501.southpacific.corp.microsoft.com ([fe80::58dd:5b00:bb08:9b24%11]) with mapi id 14.03.0158.002; Wed, 23 Oct 2013 18:29:27 +0000 From: Kumar Ashutosh To: Jim Reid Thread-Topic: [dnsext] Naked domain resolution with DNSSEC Thread-Index: Ac7ATe9x4lHsizWeS1mIFJsSspLh5AACqA0AAJVIAtAANWgSgAMPK9eQAA/6YIAAAx4eMAADhJ2AAAC4BQA= Date: Wed, 23 Oct 2013 18:29:26 +0000 Message-ID: References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> <21095.58207.781300.353688@gro.dd.org> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.3.87] 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:(24454002)(189002)(199002)(13464003)(377454003)(59766001)(77982001)(54356001)(53806001)(81816001)(81686001)(79102001)(76796001)(77096001)(63696002)(49866001)(50986001)(47976001)(47736001)(83322001)(47776003)(20776003)(80976001)(16796002)(4396001)(19580405001)(74366001)(46102001)(80022001)(65816001)(31966008)(51856001)(74876001)(56816003)(50466002)(74706001)(74662001)(74502001)(76786001)(69226001)(83072001)(6806004)(33656001)(81342001)(44976005)(56776001)(54316002)(76482001)(85306002)(81542001)(23726002)(15974865002)(19580395003)(47446002)(46406003)(55846006); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB184; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; 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: 000800954F X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: Sourav Sain , "dnsext@ietf.org Group" , Thirunadha Reddy Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 18:30:21 -0000 Hi Jim I agree on CNAME behaviour. My concern here is what option does the custome= r have in case he needs contoso.com and www.contoso.com both to be redirect= ed to say contoso.dnsprovider.com Recapturing this from my previous mail " One more scenario where naked domain issue becomes evident is when the au= thoritative servers try to point a few of their records at some third party= DNS hosting services Contoso.com { www CNAME contoso.dnsprovider.com (owned by a third party) internal A 1.1.1.1 } How does it set out to achieve the naked domain resolution. It cannot add C= NAME at the apex. Also it cannot add DNAME to the loadbalancer.net at the z= one apex as then it can't host internal records and also resolution for www= will point to www.dnsprovider.com How will such a customer ensure that both www.contoso.com and contoso.com g= et pointed to contoso.provider.com." Thanks Ashu -----Original Message----- From: Jim Reid [mailto:jim@rfc1035.com]=20 Sent: Wednesday, October 23, 2013 11:35 PM To: Kumar Ashutosh Cc: Dave Lawrence; Thirunadha Reddy; dnsext@ietf.org Group; Sourav Sain Subject: Re: [dnsext] Naked domain resolution with DNSSEC On 23 Oct 2013, at 18:39, Kumar Ashutosh wrote: > The Microsoft authoritative DNS servers prevent adding CNAMEs at the zone= apex. But there may be other DNS servers which may be allowing this and th= e validating resolvers are returning Serv_fail, As Andrew suggested. This is how it should be. If a name exists as a CNAME, it cannot exist as a= ny other RRtype. Except of course for any RRSIGs and NSEC or NSEC3's if the= zone is signed. Adding a CNAME at the zone apex fails because that name mu= st at by definition already have at least a SOA and some NS records. From tale@dd.org Wed Oct 23 12:03: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 20D1611E8346 for ; Wed, 23 Oct 2013 12:03: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 RwxrIMLMUpqh for ; Wed, 23 Oct 2013 12:03:07 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [209.198.103.200]) by ietfa.amsl.com (Postfix) with ESMTP id A765211E833A for ; Wed, 23 Oct 2013 12:03:01 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 180153F438; Wed, 23 Oct 2013 15:03:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21096.7524.908259.719737@gro.dd.org> Date: Wed, 23 Oct 2013 15:03:00 -0400 From: Dave Lawrence To: Kumar Ashutosh In-Reply-To: References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> <21095.58207.781300.353688@gro.dd.org> Cc: Sourav Sain , "dnsext@ietf.org Group" , Thirunadha Reddy Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:03:11 -0000 Kumar Ashutosh writes: > I agree on CNAME behaviour. My concern here is what option does the > customer have in case he needs contoso.com and www.contoso.com both to > be redirected to say contoso.dnsprovider.com The customer in this case needs special handling by the authoritative server to hand out address records at the apex instead. Several DNS providers handle this in their own software; for example, Akamai has a feature called "toplevel name redirection" to do it. DNS Made Easy has what they call an "ANAME record", described at http://www.dnsmadeeasy.com/services/aname-records/. It isn't really an IETF/IANA acknowledged DNS record, but rather just the way they describe how to configure it into their system. This is a fundamental limitation of the DNS protocol. To achieve the desired effect you must use some mechanism that is outside the scope of current DNS standards documents. From askuma@microsoft.com Wed Oct 23 12:20:33 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 1E58911E820A for ; Wed, 23 Oct 2013 12:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocFhrsTdVrf4 for ; Wed, 23 Oct 2013 12:20:28 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0150.outbound.protection.outlook.com [207.46.163.150]) by ietfa.amsl.com (Postfix) with ESMTP id 60C1A11E8203 for ; Wed, 23 Oct 2013 12:20:28 -0700 (PDT) Received: from BN1PR03MB251.namprd03.prod.outlook.com (10.255.200.18) by BN1PR03MB039.namprd03.prod.outlook.com (10.255.225.147) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 23 Oct 2013 19:20:26 +0000 Received: from DM2PR03CA001.namprd03.prod.outlook.com (10.141.52.149) by BN1PR03MB251.namprd03.prod.outlook.com (10.255.200.18) with Microsoft SMTP Server (TLS) id 15.0.785.10; Wed, 23 Oct 2013 19:20:26 +0000 Received: from BL2FFO11FD007.protection.gbl (2a01:111:f400:7c09::164) by DM2PR03CA001.outlook.office365.com (2a01:111:e400:2414::21) with Microsoft SMTP Server (TLS) id 15.0.800.7 via Frontend Transport; Wed, 23 Oct 2013 19:20:25 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD007.mail.protection.outlook.com (10.173.161.3) with Microsoft SMTP Server (TLS) id 15.0.805.12 via Frontend Transport; Wed, 23 Oct 2013 19:20:24 +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.158.2; Wed, 23 Oct 2013 19:19:22 +0000 Received: from SINEX14MBXC415.southpacific.corp.microsoft.com ([169.254.15.60]) by SINEX14HUBC402.southpacific.corp.microsoft.com ([157.60.220.216]) with mapi id 14.03.0146.002; Wed, 23 Oct 2013 19:19:19 +0000 From: Kumar Ashutosh To: Dave Lawrence Thread-Topic: [dnsext] Naked domain resolution with DNSSEC Thread-Index: Ac7ATe9x4lHsizWeS1mIFJsSspLh5AACqA0AAJVIAtAANWgSgAMPK9eQAA/6YIAAAx4eMAADhJ2AAAC4BQAAAUqFAAAAhIow Date: Wed, 23 Oct 2013 19:19:19 +0000 Message-ID: References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> <21095.58207.781300.353688@gro.dd.org> <21096.7524.908259.719737@gro.dd.org> In-Reply-To: <21096.7524.908259.719737@gro.dd.org> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.3.87] 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:(189002)(199002)(13464003)(377454003)(15974865002)(44976005)(83322001)(19580395003)(19580405001)(23726002)(6806004)(74502001)(81686001)(50466002)(33656001)(46102001)(80976001)(55846006)(50986001)(56816003)(74876001)(49866001)(47736001)(81816001)(77096001)(47976001)(83072001)(74662001)(59766001)(77982001)(16796002)(76796001)(31966008)(4396001)(47446002)(15975445006)(74366001)(76482001)(15202345003)(54356001)(80022001)(53806001)(56776001)(54316002)(65816001)(79102001)(76786001)(69226001)(81342001)(20776003)(46406003)(47776003)(63696002)(74706001)(51856001)(81542001)(85306002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB251; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; 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: 000800954F X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: Sourav Sain , "dnsext@ietf.org Group" , Thirunadha Reddy Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:20:33 -0000 Thanks Dave! -----Original Message----- From: Dave Lawrence [mailto:tale@dd.org]=20 Sent: Thursday, October 24, 2013 12:33 AM To: Kumar Ashutosh Cc: Jim Reid; Thirunadha Reddy; dnsext@ietf.org Group; Sourav Sain Subject: RE: [dnsext] Naked domain resolution with DNSSEC Kumar Ashutosh writes: > I agree on CNAME behaviour. My concern here is what option does the=20 > customer have in case he needs contoso.com and www.contoso.com both to=20 > be redirected to say contoso.dnsprovider.com The customer in this case needs special handling by the authoritative serve= r to hand out address records at the apex instead. Several DNS providers h= andle this in their own software; for example, Akamai has a feature called = "toplevel name redirection" to do it. DNS Made Easy has what they call an = "ANAME record", described at http://www.dnsmadeeasy.com/services/aname-reco= rds/. It isn't really an IETF/IANA acknowledged DNS record, but rather jus= t the way they describe how to configure it into their system. This is a fundamental limitation of the DNS protocol. To achieve the desir= ed effect you must use some mechanism that is outside the scope of current = DNS standards documents. From prvs=0001114fcb=johnl@iecc.com Wed Oct 23 12:55: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 77BEC11E820A for ; Wed, 23 Oct 2013 12:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 8jTu4B6PDzzv for ; Wed, 23 Oct 2013 12:55:14 -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 BD32C11E820C for ; Wed, 23 Oct 2013 12:55:10 -0700 (PDT) Received: (qmail 88323 invoked from network); 23 Oct 2013 19:55:09 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 23 Oct 2013 19:55:09 -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=5268299d.xn--3zv.k1310; i=johnl@user.iecc.com; bh=ssY17ur8Ldamt0R1GosMYfCP9gTxwjlq9DX2NHD/9uo=; b=zxRDVke67/XwBKmCZcX1oTLOENQQwz1AisMMe+f8XMadtr7zZqB9U5+kZLFxk7K+P2heqx5iCJv2Miv8ANajF2+eTwpA31DL5rL4BPcC/V4RYMUcpTUg/ghmxKp9V3TitlKODRflyQyQBBLQAEehevAMvvFk/dae5CzItqn2eFfmII4Ia4V5cw0L/KLmsdoo+IBfvw6hkm12omDkWn58lwkF7dVCKNHV3MLooQxuIFCOauEskwJDg26kEAyPW2YK 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=5268299d.xn--3zv.k1310; olt=johnl@user.iecc.com; bh=ssY17ur8Ldamt0R1GosMYfCP9gTxwjlq9DX2NHD/9uo=; b=Flt0FpdTHI7JLXixJ5KDFsJWywkdhGryS+e1B2b4nYZiuOSuhKq/sDeOkpTOT6Wn4n1dYP0nJH7dAekOLFrAXxwnfphEpZxAKkzJw6BXkF9yxUG2BLgoekRoqwuMBwbd68roWxE0c7q3pOlKtEqAAT8xV1dA88n6gO46i+t8HP/HY92jdqOzlcYmYOt07ZneVrUEgO0GnSUjTEgh/SYucA1V9qoqBtkxwXsCiuCaARk0VUvAsQQXkuSNW2eNc2Wv Date: 23 Oct 2013 19:54:47 -0000 Message-ID: <20131023195447.2775.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] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:55:18 -0000 >How will such a customer ensure that both www.contoso.com and >contoso.com get pointed to contoso.provider.com." I've done it by provisioning. My DNS management software has a hack that says that one name has the same A/AAAA as some other name. Every few hours a daemon runs down the list, and if the target address has changed, it updates the local name. This is a hack, but it's the least bad one I know in this situation. Note that this also makes it a lot easier handle the fairly common situation that the web server is hosted one place and the mail is hosted in another, and the web host has no way to install MX records that point anywhere other than itself. R's, John From askuma@microsoft.com Wed Oct 23 13:21:51 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 0AE5A11E81D0 for ; Wed, 23 Oct 2013 13:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX-WWWCONV4y for ; Wed, 23 Oct 2013 13:21:45 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id B981811E81FB for ; Wed, 23 Oct 2013 13:21:45 -0700 (PDT) Received: from BL2PR03CA015.namprd03.prod.outlook.com (10.141.66.23) by BL2PR03MB209.namprd03.prod.outlook.com (10.255.230.140) with Microsoft SMTP Server (TLS) id 15.0.800.7; Wed, 23 Oct 2013 20:21:42 +0000 Received: from BY2FFO11FD035.protection.gbl (2a01:111:f400:7c0c::183) by BL2PR03CA015.outlook.office365.com (2a01:111:e400:c1b::23) with Microsoft SMTP Server (TLS) id 15.0.800.7 via Frontend Transport; Wed, 23 Oct 2013 20:21:42 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD035.mail.protection.outlook.com (10.1.14.220) with Microsoft SMTP Server (TLS) id 15.0.805.12 via Frontend Transport; Wed, 23 Oct 2013 20:21:41 +0000 Received: from SINEX14HUBC503.southpacific.corp.microsoft.com (157.60.220.65) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.3.158.2; Wed, 23 Oct 2013 20:20:54 +0000 Received: from SINEX14MBXC415.southpacific.corp.microsoft.com ([169.254.15.60]) by SINEX14HUBC503.southpacific.corp.microsoft.com ([fe80::7c66:838:6c58:af59%12]) with mapi id 14.03.0158.002; Wed, 23 Oct 2013 20:20:50 +0000 From: Kumar Ashutosh To: John Levine , "dnsext@ietf.org" Thread-Topic: [dnsext] Naked domain resolution with DNSSEC Thread-Index: Ac7ATe9x4lHsizWeS1mIFJsSspLh5AACqA0AAJVIAtAANWgSgAMPK9eQAA/6YIAAAx4eMAADhJ2AAAC4BQAAAxl/gAAAuLcw Date: Wed, 23 Oct 2013 20:20:49 +0000 Message-ID: References: <20131023195447.2775.qmail@joyce.lan> In-Reply-To: <20131023195447.2775.qmail@joyce.lan> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.3.87] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464003)(377454003)(189002)(199002)(54356001)(50466002)(33656001)(47976001)(50986001)(49866001)(4396001)(47736001)(46102001)(23676002)(74876001)(53806001)(74706001)(51856001)(63696002)(79102001)(20776003)(81816001)(85306002)(47776003)(65816001)(31966008)(77982001)(47446002)(74662001)(15974865002)(16796002)(59766001)(74502001)(80022001)(69226001)(55846006)(19580405001)(83322001)(6806004)(80976001)(44976005)(19580395003)(54316002)(81542001)(81686001)(76482001)(83072001)(56776001)(74366001)(56816003)(77096001)(76786001)(81342001)(76796001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB209; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; 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: 000800954F X-OriginatorOrg: microsoft.com Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 20:21:51 -0000 VGhhbmtzIEpvaG4hDQpEYXZlIGhhcyBwb2ludGVkIGFib3V0IGNlcnRhaW4gJ3NwZWNpYWwnIHJl Y29yZHMgbGlrZSBBTkFNRS4gSSB0aGluayBBbWF6b24gcm91dGU1MyBhbHNvIGhhcyBzaW1pbGFy ICdhbGlhcycgcmVjb3Jkcy4NCkl0IHdvdWxkIGJlIGdyZWF0IGlmIHRoZSB3b3JraW5nIGdyb3Vw IGNvdWxkIGRyaXZlIGEgc3RhbmRhcmRpemVkIGhhbmRsaW5nIG9mIHRoaXMgc2NlbmFyaW8uDQoN ClRoYW5rcw0KQXNodQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9obiBM ZXZpbmUgW21haWx0bzpqb2hubEB0YXVnaC5jb21dIA0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIg MjQsIDIwMTMgMToyNSBBTQ0KVG86IGRuc2V4dEBpZXRmLm9yZw0KQ2M6IEt1bWFyIEFzaHV0b3No DQpTdWJqZWN0OiBSZTogW2Ruc2V4dF0gTmFrZWQgZG9tYWluIHJlc29sdXRpb24gd2l0aCBETlNT RUMNCg0KPkhvdyB3aWxsIHN1Y2ggYSBjdXN0b21lciBlbnN1cmUgdGhhdCBib3RoIHd3dy5jb250 b3NvLmNvbSBhbmQgDQo+Y29udG9zby5jb20gZ2V0IHBvaW50ZWQgdG8gY29udG9zby5wcm92aWRl ci5jb20uIg0KDQpJJ3ZlIGRvbmUgaXQgYnkgcHJvdmlzaW9uaW5nLiAgTXkgRE5TIG1hbmFnZW1l bnQgc29mdHdhcmUgaGFzIGEgaGFjayB0aGF0IHNheXMgdGhhdCBvbmUgbmFtZSBoYXMgdGhlIHNh bWUgQS9BQUFBIGFzIHNvbWUgb3RoZXIgbmFtZS4gIEV2ZXJ5IGZldyBob3VycyBhIGRhZW1vbiBy dW5zIGRvd24gdGhlIGxpc3QsIGFuZCBpZiB0aGUgdGFyZ2V0IGFkZHJlc3MgaGFzIGNoYW5nZWQs IGl0IHVwZGF0ZXMgdGhlIGxvY2FsIG5hbWUuDQoNClRoaXMgaXMgYSBoYWNrLCBidXQgaXQncyB0 aGUgbGVhc3QgYmFkIG9uZSBJIGtub3cgaW4gdGhpcyBzaXR1YXRpb24uDQoNCk5vdGUgdGhhdCB0 aGlzIGFsc28gbWFrZXMgaXQgYSBsb3QgZWFzaWVyIGhhbmRsZSB0aGUgZmFpcmx5IGNvbW1vbiBz aXR1YXRpb24gdGhhdCB0aGUgd2ViIHNlcnZlciBpcyBob3N0ZWQgb25lIHBsYWNlIGFuZCB0aGUg bWFpbCBpcyBob3N0ZWQgaW4gYW5vdGhlciwgYW5kIHRoZSB3ZWIgaG9zdCBoYXMgbm8gd2F5IHRv IGluc3RhbGwgTVggcmVjb3JkcyB0aGF0IHBvaW50IGFueXdoZXJlIG90aGVyIHRoYW4gaXRzZWxm Lg0KDQpSJ3MsDQpKb2huDQo= From bdickson@verisign.com Wed Oct 23 13:27:29 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 2FE0311E8222 for ; Wed, 23 Oct 2013 13:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 1b8hCHsyh111 for ; Wed, 23 Oct 2013 13:27:24 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id C16A311E823C for ; Wed, 23 Oct 2013 13:27:16 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKUmgxJFVvN4F6Pxo+EzZGPCHYO4c10/nw@postini.com; Wed, 23 Oct 2013 13:27:18 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r9NKRFDc029023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 16:27:15 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 23 Oct 2013 16:27:15 -0400 From: "Dickson, Brian" To: Kumar Ashutosh Thread-Topic: [dnsext] Naked domain resolution with DNSSEC Thread-Index: Ac7ATe9x4lHsizWeS1mIFJsSspLh5AALCdEAAJW3bYAANPingAMSvzoAAA+bcoA= Date: Wed, 23 Oct 2013 20:27:14 +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@ietf.org Group" Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 20:27:29 -0000 >Coming back to the original question, the migration from contoso.com to >new_contoso.com is a fairly common scenario. Are there any guidance on >how to achieve such a migration. I think _this_ question is the one that actually needs to be answered. There are relatively simple ways, which might need a bit more work if there is a need for DNSSEC signing of the zone in question. There are actually possibly two elements - moving DNS provider, and migrating from one domain to another. If you ignore the moving DNS provider, there is a fairly simple way of doing this. First, let's be sure you actually want the result to be: every query for something.old-name.com and for something.new-name.com must always return the same results. (And at some point in future, old-name will disappear.) Here's how you can achieve the desired result: Run old-name and new-name on the same set of DNS authority servers. Have the same zone file imported for both zones, with all names relative to the parent zone name. In BIND syntax, it would look something like: zone "new-name.com" { type master; file "master/db.old-name-new-name.com"; } zone "old-name.com" { type master; file "master/db.old-name-new-name.com"; } If you need to do signed zones, it becomes a bit more tricky, in that the name of the signer (in the RRSIG) would be different, and would also impact DS and RRSIG(DNSKEY) records. In this case, you could either have a "merged" zone file (one set of names, two sets of signatures, with the names in "relative" format), or you could have two signed zone files. Automating the signing of the zone files, via some kind of script, would make it automatic, whenever changes are made to the zone (e.g. it could also ensure the SOA serial number gets updated, among other things.) On the other hand, if you also need to move DNS providers, you would need to augment this with something like: - set up the above, on both the old DNS provider, and the new DNS provider - swing things from the old provider to the new provider (by doing changes on the registrar to update the delegation NS set). - keep things running in parallel for at least 2 x max-TTL - shut down the old DNS provider's stuff (and be SURE they remove all remnants, or anyone using them for resolution might get stale data). I think this is likely good enough for anyone doing what you are trying to do, and avoids messing with CNAME or DNAME or anything similar. Brian From marka@isc.org Wed Oct 23 13:32:29 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 D593C11E810A for ; Wed, 23 Oct 2013 13:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 6d1m-50hyJ87 for ; Wed, 23 Oct 2013 13:32:26 -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 9B2F811E8237 for ; Wed, 23 Oct 2013 13:32:25 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id AC8E7C94E1; Wed, 23 Oct 2013 20:32:10 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1382560344; bh=p4/sZL66MXWAWIJJJIoIxhoYAjR/aBH1kCj5eMJfVL0=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=JKg8nWtt9LOE2YAZVWVgluFLP0TLTbC37rbjLc211hMQZypJRRZWtfb+M/b9H/spc bBCH6dG318+mQPKuMGmIfRC/V2vHe2CvsVvmYJ0xH3dqpy+9GfmK4GFgCQdXPsu5/s xUBy+XbupWOzxZRiLTahTMkyhVcLZiG5rZTH4H48= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 23 Oct 2013 20:32:10 +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 B8079160475; Wed, 23 Oct 2013 20:36:57 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 77CF4160389; Wed, 23 Oct 2013 20:36:57 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 9258C893272; Thu, 24 Oct 2013 07:32:06 +1100 (EST) To: Kumar Ashutosh From: Mark Andrews References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> <21095.58207.781300.353688@gro.dd.org> <21096.7524.908259.719737@gro.dd.org> In-reply-to: Your message of "Wed, 23 Oct 2013 19:19:19 -0000." Date: Thu, 24 Oct 2013 07:32:06 +1100 Message-Id: <20131023203206.9258C893272@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Thirunadha Reddy , "dnsext@ietf.org Group" , Sourav Sain Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 20:32:30 -0000 This really should be handled by SRV or seperate MX like record. Unfortunately http server operators, http browser developer and http proxy developers misused/abused CNAME as it nearly provided what was needed and never asked a appropriate record to say "this site is hosted on this server" despite MX records existing to do exactly this for SMTP. Mark In message , Kumar Ashutosh writes: > Thanks Dave! > > > -----Original Message----- > From: Dave Lawrence [mailto:tale@dd.org] > Sent: Thursday, October 24, 2013 12:33 AM > To: Kumar Ashutosh > Cc: Jim Reid; Thirunadha Reddy; dnsext@ietf.org Group; Sourav Sain > Subject: RE: [dnsext] Naked domain resolution with DNSSEC > > Kumar Ashutosh writes: > > I agree on CNAME behaviour. My concern here is what option does the > > customer have in case he needs contoso.com and www.contoso.com both to > > be redirected to say contoso.dnsprovider.com > > The customer in this case needs special handling by the authoritative server > to hand out address records at the apex instead. Several DNS providers handl > e this in their own software; for example, Akamai has a feature called "tople > vel name redirection" to do it. DNS Made Easy has what they call an "ANAME r > ecord", described at http://www.dnsmadeeasy.com/services/aname-records/. It > isn't really an IETF/IANA acknowledged DNS record, but rather just the way th > ey describe how to configure it into their system. > > This is a fundamental limitation of the DNS protocol. To achieve the desired > effect you must use some mechanism that is outside the scope of current DNS > standards documents. > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mansaxel@besserwisser.org Wed Oct 23 14:03: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 EB6C611E81F8 for ; Wed, 23 Oct 2013 14:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0Kl5npnqGpM for ; Wed, 23 Oct 2013 14:03:27 -0700 (PDT) Received: from jaja.besserwisser.org (jaja.besserwisser.org [IPv6:2a01:298:4:0:211:43ff:fe36:1299]) by ietfa.amsl.com (Postfix) with ESMTP id 18B4911E8122 for ; Wed, 23 Oct 2013 14:03:27 -0700 (PDT) Received: by jaja.besserwisser.org (Postfix, from userid 1004) id C03649EA5; Wed, 23 Oct 2013 23:03:24 +0200 (CEST) Date: Wed, 23 Oct 2013 23:03:24 +0200 From: =?utf-8?B?TcOlbnM=?= Nilsson To: Kumar Ashutosh Message-ID: <20131023210324.GF11679@besserwisser.org> References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> <21095.58207.781300.353688@gro.dd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FoLtEtfbNGMjfgrs" Content-Disposition: inline In-Reply-To: X-URL: http://vvv.besserwisser.org X-Purpose: More of everything NOW! X-happyness: Life is good. User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Thirunadha Reddy , "dnsext@ietf.org Group" , Sourav Sain Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 21:03:28 -0000 --FoLtEtfbNGMjfgrs Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [dnsext] Naked domain resolution with DNSSEC Date: Wed, Oct 23= , 2013 at 06:29:26PM +0000 Quoting Kumar Ashutosh (askuma@microsoft.com): > Hi Jim > I agree on CNAME behaviour. My concern here is what option does the custo= mer have in case he needs contoso.com and www.contoso.com both to be redire= cted to say contoso.dnsprovider.com Done out of band is probably the only viable solution; traverse the DNS to find which IP address is pointed to by "contoso.dnsprovider.com" and add AAAA and/or A records to suit at the zone apex. (The following code is ugly and untested but should give an idea.=20 Please copy and use it if you're brave but don't blame me if it=20 eats your homework.) dig www.contoso.com CNAME +short | while read canon ; do=20 dig $canon A +short done | awk ' { printf "update add contoso.com. 84600 IN A %s\n\n",=20 $1;=20 }' | nsupdate -k verysecretkey.txt On a related[0]=C2=B8 note, when we've got people from Microsoft here, why = for crying out loud does AD require a number of A records at the AD zone apex pointing to the DC's for the AD? Wouldn't it be better to do that with a SRV record pointing to the host names of the DC's? --=20 M=C3=A5ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 HELLO, everybody, I'm a HUMAN!! [0] "related" as in dealing with apex A records in a Microsoft context..=20 --FoLtEtfbNGMjfgrs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlJoOZwACgkQ02/pMZDM1cUlyACdFEVILafCiWVX6/7d0jJod7V1 hVgAn2jgtRl+VloywZJpyapDOU+TZz71 =C1O8 -----END PGP SIGNATURE----- --FoLtEtfbNGMjfgrs-- From marka@isc.org Wed Oct 23 15:20:43 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 E728711E826E for ; Wed, 23 Oct 2013 15:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 a6TNw-AqPXuq for ; Wed, 23 Oct 2013 15:20:39 -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 B48CD11E826F for ; Wed, 23 Oct 2013 15:20:39 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 52425C9422; Wed, 23 Oct 2013 22:20:26 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1382566839; bh=vAmdWoy+ncn0nxm8L3P5VhAi8o/LoFFQarSz8lBqN5w=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=hS4/TkHPiYFwiUvt4wLR2FB/1WSYS7eFBq0PufPPTQJQd+eN01clb0ZDWymylce3N pFnrA3i2XHJ7qS430cIHecRcp43+NnxIW2bWA+k+XIavo8KchX1FIHPp9Z7ua6Kzg7 94d1n3Hn6eYx94v3VLbHUWo3p3Vpfa4HO9K849gA= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 23 Oct 2013 22:20:26 +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 C02C4160470; Wed, 23 Oct 2013 22:25:13 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 90DC6160389; Wed, 23 Oct 2013 22:25:13 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 4BE7B89456A; Thu, 24 Oct 2013 09:20:23 +1100 (EST) To: Derek Atkins From: Mark Andrews References: <1D9E3C41-0632-4FBE-9564-6CE8FB34AEA4@alex.org.uk> In-reply-to: Your message of "Thu, 17 Oct 2013 11:23:08 -0400." Date: Thu, 24 Oct 2013 09:20:23 +1100 Message-Id: <20131023222023.4BE7B89456A@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: "dnsext@ietf.org Group" Subject: Re: [dnsext] Extending UPDATE to add/remove zones X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 22:20:44 -0000 In message , Derek Atkins writes: > Alex Bligh writes: > > > On 16 Oct 2013, at 18:23, Derek Atkins wrote: > > > >> I admit I haven't read the whole draft, but my question is how do you > >> authenticate and, more importantly, authorize the addition or (worse) > >> deletion of zones? Imagine an attack vector where someone could get > >> your domain's DNS servers to stop serving your domain(s)! > >> > >> I think the security of adding and (more importantly) removing zones > >> should be carefully documented and discussed. > > > > I'm not sure why this would be different from someone doing an update > > to remove the entire content of the zone served. Thus I don't really > > see why it should need security any different from the existing > > provisions for security. > > Well, if somone can add zones to my server it could be a DoS against my > network provider. So how do you authorize the addition of new zones? RFC 3007. > This is something that's definitely a new feature and isn't effectively > implementable using current UPDATE. > > As for deleting zones vs deleting records, you're right that the > authorization required to remove all the records in a zone are > effectively the same as the authZ to remove the zone itself. I believe, > however, that authZ is usually on a record-by-record basis, generally > providing for individuals to change the A record for their own devices. > At least that's how I think it SHOULD be -- I've never deployed UPDATE. > If that's the case then clearly one could have an AuthZ to remove the > SOA (and thereby the whole zone). > > I still think it should be spelled out instead of "left for the reader > to figure out." > > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From ajs@anvilwalrusden.com Wed Oct 23 19:37: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 4B3E511E829D for ; Wed, 23 Oct 2013 19:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RCyA+i3swxT for ; Wed, 23 Oct 2013 19:37:49 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id D755021E808A for ; Wed, 23 Oct 2013 19:37:43 -0700 (PDT) Received: from mx1.yitter.info (unknown [203.83.33.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C46438A031 for ; Thu, 24 Oct 2013 02:37:26 +0000 (UTC) Date: Wed, 23 Oct 2013 22:37:25 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20131024023724.GC11361@mx1.yitter.info> References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> <21095.58207.781300.353688@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dnsext] Naked domain resolution with DNSSEC 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, 24 Oct 2013 02:37:55 -0000 On Wed, Oct 23, 2013 at 06:29:26PM +0000, Kumar Ashutosh wrote: > Hi Jim > I agree on CNAME behaviour. My concern here is what option does the customer have in case he needs contoso.com and www.contoso.com both to be redirected to say contoso.dnsprovider.com > You have to maintain the zones in parallel. There's no getting around this. DNAME, note, doesn't work because it doesn't redirect the name itself. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From jinmei.tatuya@gmail.com Thu Oct 24 13:18:13 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAC811E835C for ; Thu, 24 Oct 2013 13:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkxJzpoiQDNx for ; Thu, 24 Oct 2013 13:18:13 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id A060D11E8210 for ; Thu, 24 Oct 2013 13:17:36 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t61so2850264wes.41 for ; Thu, 24 Oct 2013 13:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0f9IQ49q26cjYyBWbuNnebnOqT/t+UyNb4kioCTB6zk=; b=C5/AinS0xCsDv6G4nZuMCCvEt9E21IptXl/8ZmGvFdnalmx4AeuuTu+pJD3a6onHNt G/W2hG1sV084lkg34czifLVcEAN2PjsvZSgRTxSDmCPKoTLrKiCiXF7btB9auTHQTMmD mPlTFpZGx/zrdC9+3xszrKHdXQw+v5EOclAEoLfO83swfo7FS7tEohE/zrU06mv8QKYb pN6dB79Xw5G/tqknIiJmAYnFfffd4ashQi/NwDT5H0ZxjqbzEvome923uWVb99162Xhv bmQqqkDysg8JJxPHrtipqe9gDLn31NfoM3TvsfDECJzm6RrLKmRCSf698qLe6imiTeen 4Q4A== MIME-Version: 1.0 X-Received: by 10.180.198.77 with SMTP id ja13mr3777364wic.34.1382645855830; Thu, 24 Oct 2013 13:17:35 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.120.167 with HTTP; Thu, 24 Oct 2013 13:17:35 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Oct 2013 13:17:35 -0700 X-Google-Sender-Auth: 1hO5gJVb0rIIuNKJ4bw1UQzyMxo Message-ID: From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: DNSEXT Group Working Subject: Re: [dnsext] Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-01.txt (fwd) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 20:18:13 -0000 At Tue, 15 Oct 2013 16:24:26 -0400 (EDT), Paul Wouters wrote: > This is the 01 version for edns-tcp-chain-query-01 I have a couple of minor comments: - In section 9.1, item #10: [...] If it is a DNSSEC validating resolver, it ensures that no unvalidated data or out of baliwick data is accepted into the cache without having proper DNSSEC validation. I'm afraid "out of ba(i)liwick" is a bit unclear in this context regarding bailiwick against what. - very minor nit: I suggest using "DNS message(s)" instead of DNS packet(s) throughout the draft, because "message" seems to be the more appropriate technical term per RFC 1035, and because "packet" can be ambiguous and in the general sense would normally be interpreted as individual IP packets. I don't think such possible confusion is critical for the discussion of this draft, but if we can avoid it by simply replacing a word with another one, it should be worthwhile. -- JINMEI, Tatuya From yaojk@cnnic.cn Fri Oct 25 02:26: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 3BC2D11E834F for ; Fri, 25 Oct 2013 02:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.356 X-Spam-Level: X-Spam-Status: No, score=-99.356 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 3A1RU4UOYuS8 for ; Fri, 25 Oct 2013 02:25:58 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 6B39B11E839F for ; Fri, 25 Oct 2013 02:25:52 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO healthyao-think) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 25 Oct 2013 17:25:46 +0800 Date: Fri, 25 Oct 2013 17:25:48 +0800 From: "Jiankang Yao" To: "Dave Lawrence" , "Kumar Ashutosh" References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> <21095.58207.781300.353688@gro.dd.org> , <21096.7524.908259.719737@gro.dd.org> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2013102517253369957870@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart705473253804_=----" Cc: Thirunadha Reddy , "dnsext@ietf.org Group" , Sourav Sain Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: yaojk List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 09:26:02 -0000 This is a multi-part message in MIME format. ------=_001_NextPart705473253804_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQoNCkZyb206IERhdmUgTGF3cmVuY2UNCkRhdGU6IDIwMTMtMTAtMjQgMDM6MDMNClRvOiBLdW1h ciBBc2h1dG9zaA0KQ0M6IFNvdXJhdiBTYWluOyBkbnNleHRAaWV0Zi5vcmcgR3JvdXA7IFRoaXJ1 bmFkaGEgUmVkZHkNClN1YmplY3Q6IFJlOiBbZG5zZXh0XSBOYWtlZCBkb21haW4gcmVzb2x1dGlv biB3aXRoIEROU1NFQw0KS3VtYXIgQXNodXRvc2ggd3JpdGVzOg0KPiBJIGFncmVlIG9uIENOQU1F IGJlaGF2aW91ci4gTXkgY29uY2VybiBoZXJlIGlzIHdoYXQgb3B0aW9uIGRvZXMgdGhlDQo+IGN1 c3RvbWVyIGhhdmUgaW4gY2FzZSBoZSBuZWVkcyBjb250b3NvLmNvbSBhbmQgd3d3LmNvbnRvc28u Y29tIGJvdGggdG8NCj4gYmUgcmVkaXJlY3RlZCB0byBzYXkgY29udG9zby5kbnNwcm92aWRlci5j b20gDQoNCkJOQU1FLCB3aGljaCBkaXJlY3RzIGJvdGggaXRzZWxmIGFuZCBpdHMgY2hpbGRyZW4s IG1heSBzb2x2ZSBpdC4gdGhlIGRyYWZ0IGFib3V0IEJOQU1FIHdhcyBkaXNjdXNzZWQgMyB5ZWFy cyBhZ28u ------=_001_NextPart705473253804_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
 
From: Dave Lawrence
Date: 2013-10-24 03:03
CC: Sourav Sain; dnsext@ietf.org Group; Thirunadha Reddy
Subject: Re: [dnsext] Naked domain resolution with=20 DNSSEC
Kumar Ashutosh writes:
> I agree on CNAME behaviour. My&nbs= p;concern here is what option does the
> customer have in case he needs&nbs= p;contoso.com and www.contoso.com both to
> be redirected to say contoso.dnsprovide= r.com 
 
BNAME, which directs both itself and its children, may solv= e it.=20 the draft about BNAME was discussed 3 years ago.
 
------=_001_NextPart705473253804_=------ From ajs@anvilwalrusden.com Fri Oct 25 02:37:25 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD5E11E83B3 for ; Fri, 25 Oct 2013 02:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.755 X-Spam-Level: X-Spam-Status: No, score=-0.755 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkW4r6ZVfcll for ; Fri, 25 Oct 2013 02:37:20 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 25F9E11E8396 for ; Fri, 25 Oct 2013 02:36:56 -0700 (PDT) Received: from mx1.yitter.info (unknown [203.83.33.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 914BC8A031; Fri, 25 Oct 2013 09:36:53 +0000 (UTC) Date: Fri, 25 Oct 2013 05:36:50 -0400 From: Andrew Sullivan To: Jiankang Yao Message-ID: <20131025093648.GB12997@mx1.yitter.info> References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> <21095.58207.781300.353688@gro.dd.org> <21096.7524.908259.719737@gro.dd.org> <2013102517253369957870@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2013102517253369957870@cnnic.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Sourav Sain , "dnsext@ietf.org Group" , Thirunadha Reddy Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 09:37:25 -0000 On Fri, Oct 25, 2013 at 05:25:48PM +0800, Jiankang Yao wrote: > > BNAME, which directs both itself and its children, may solve it. the draft about BNAME was discussed 3 years ago. > _______________________________________________ Yes, and if it were compatible with DNSSEC, perhaps people would have pursued it. But it won't work with DNSSEC. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From marka@isc.org Fri Oct 25 06:15:00 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 3426511E83EF for ; Fri, 25 Oct 2013 06:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 OVLYbIGGDZVm for ; Fri, 25 Oct 2013 06:14: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 6C2D211E8192 for ; Fri, 25 Oct 2013 06:14:49 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 098B9C9483; Fri, 25 Oct 2013 13:14:36 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1382706889; bh=Q9O0+NOOCIMZZvR1T8fKNpyljB0/JeoywK8GDqb9HEM=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=tvJnpyum/u0MlN1kB5lkn/ZKXVvoogl/LNYugTtpVBnFa8+YAoPp+kcAtVtk+rwVw lkKmFHcM0IxCaZaXzXbydXwFA7ZIHFGAwmYpMCV3NNKyrs1GN74RZdf441Xx31bbn3 ANRp18InBQSeefkmoVV4ob8RiGFms141IDdSFlfU= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 25 Oct 2013 13:14:36 +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 8FA81160470; Fri, 25 Oct 2013 13:19:30 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 5FD9816042E; Fri, 25 Oct 2013 13:19:30 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id EAAF48BEA92; Sat, 26 Oct 2013 00:14:31 +1100 (EST) To: Andrew Sullivan From: Mark Andrews References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> <21095.58207.781300.353688@gro.dd.org> <21096.7524.908259.719737@gro.dd.org> <2013102517253369957870@cnnic.cn> <20131025093648.GB12997@mx1.yitter.info> In-reply-to: Your message of "Fri, 25 Oct 2013 05:36:50 -0400." <20131025093648.GB12997@mx1.yitter.info> Date: Sat, 26 Oct 2013 00:14:31 +1100 Message-Id: <20131025131431.EAAF48BEA92@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Thirunadha Reddy , "dnsext@ietf.org Group" , Sourav Sain Subject: Re: [dnsext] Naked domain resolution with DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 13:15:01 -0000 In message <20131025093648.GB12997@mx1.yitter.info>, Andrew Sullivan writes: > On Fri, Oct 25, 2013 at 05:25:48PM +0800, Jiankang Yao wrote: > > > > BNAME, which directs both itself and its children, may solve it. the draft > about BNAME was discussed 3 years ago. > > > _______________________________________________ > > Yes, and if it were compatible with DNSSEC, perhaps people would have > pursued it. But it won't work with DNSSEC. And you know as well as I do that it can be made to work with DNSSEC the same way as NSEC3 was made to work with DNSSEC. > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From hallam@gmail.com Fri Oct 25 11:59:32 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 D170511E813A for ; Fri, 25 Oct 2013 11:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4mKg2EkTxdA for ; Fri, 25 Oct 2013 11:59:32 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2040811E8198 for ; Fri, 25 Oct 2013 11:59:30 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id eo20so3468541lab.12 for ; Fri, 25 Oct 2013 11:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fzBqkGXM8d6W2axUX8l2nx0VnXjdFzCNSSXRAkHcWM0=; b=N54GIUmsu8t5iVSOt9MFno/6ngj5Zlsru9UC7w8wd9iXUixLjKTW+ZOaXFaaJ8N5CO VYha8t95TqWYpalcCqzk+e7RzV46pGIlpClfd76bkpXi+rWzapC46u8sNpjNhBJb3gnC 58CX2YF3N2DLu/oR8KJwTXfQ38HyMarv09ewcZ2WPT28rcQaiDHKEM0iGpw6qPr4p0SW 5giz3667+feRj5YazZodWP9jS7gBTRjQ+ysNWe+c6DoCD66AUgqPF/O/nNyR4ehtJ9tz 8qjuBHp/2Zy5NE8LKngmY4W/OKDOHTJHiL6c/Ypc7D00AQzCYypqBFC8CJm6XsrpExLK E1+A== MIME-Version: 1.0 X-Received: by 10.112.64.7 with SMTP id k7mr2158391lbs.43.1382727569967; Fri, 25 Oct 2013 11:59:29 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Fri, 25 Oct 2013 11:59:29 -0700 (PDT) In-Reply-To: References: <20130826012857.GL8259@mx1.yitter.info> Date: Fri, 25 Oct 2013 14:59:29 -0400 Message-ID: From: Phillip Hallam-Baker To: "Dickson, Brian" Content-Type: multipart/alternative; boundary=001a11c3fba2a10fc004e995595d Cc: "dnsext@ietf.org" Subject: Re: [dnsext] The state of DNS support, was 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: Fri, 25 Oct 2013 18:59:32 -0000 --001a11c3fba2a10fc004e995595d Content-Type: text/plain; charset=ISO-8859-1 On Sun, Aug 25, 2013 at 11:36 PM, Dickson, Brian wrote: > At the risk of ridicule, and in the interest of potentially useful results: > > Why not deprecate TXT, or at least abandon the current TXT and introduce > a new TXT code point? And, as each iteration gets trashed, move on to the > next one? > I suggested allocating a dozen new TXT records for people to play with. Crickets... The DNS infrastructure world is far removed from the business world these days. -- Website: http://hallambaker.com/ --001a11c3fba2a10fc004e995595d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 25, 2013 at 11:36 PM, Dickson, Brian <bdi= ckson@verisign.com> wrote:
At the risk of ridicule, and in the interest= of potentially useful results:

Why not deprecate TXT, or at least abandon the current TXT and introduce a new TXT code point? And, as each iteration gets trashed, move on to the next one?

I suggested allocating a doze= n new TXT records for people to play with. Crickets...

=

The DNS infrastructure world is far removed from the bu= siness world these days.=A0

--
Website: ht= tp://hallambaker.com/
--001a11c3fba2a10fc004e995595d-- From ietf@rozanak.com Fri Oct 25 16:16: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 4ED2711E819C; Fri, 25 Oct 2013 16:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.302, 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 noJwGzxVHRLe; Fri, 25 Oct 2013 16:16:47 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id CC8D811E81C8; Fri, 25 Oct 2013 16:16:44 -0700 (PDT) Received: from kopoli (g231250140.adsl.alicedsl.de [92.231.250.140]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MO6zE-1VfKnG2J3U-006Jk7; Fri, 25 Oct 2013 19:16:39 -0400 From: "Hosnieh Rafiee" To: , Date: Sat, 26 Oct 2013 01:16:29 +0200 Message-ID: <008a01ced1d8$41885d40$c49917c0$@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: Ac7R2DwNYQlPTN4hQjS3upScfPISlg== Content-Language: en-us X-Provags-ID: V02:K0:wlRm8bpLHoeBBiKj7hwR74wI+jww0RHHQwR4kTMCw0+ JJ7wfvIOAbvE1F8nhejkbFGT9t9GEeb7xMRd8gXcSzfTzEyFLg EX6IXUCO4V+kG3t7cIcPvT8htr1Db+dUpUbfGJqBQK96N4sDdH DNVD+e9KiVNW3vhV4Qh8VI23K59A9Dsru/9vehRA20lpz6EFaM KAKGSaaib0+RwdEE277qRlJnWFbPo3ajl+dfAI+2LcKBkLztGo PlWxe/NlBiv1k93UeJmGTrOi64nT3vQgruMgPB1ecaGr/1ghJd 64B/vaHJUkvYuSH0XWHOJS95Z60zznp2NvoH1QxSYO7KBmnI8p TH8kulANF8CDnQ+kgEdY= Cc: Andrew Sullivan Subject: [dnsext] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 23:16:52 -0000 Hello, I have gathered some vulnerabilities in the current DNS security approaches such as DNSSEC and etc. We think it is useful to have a survey of existing vulnerabilities or any new vulnerabilities so that we can address those issues in other standard RFC. This is why we plan to write a new informational draft. There is currently one old RFC that address the DNS vulnerabilities: http://tools.ietf.org/html/rfc3833 So, we welcome any ideas about this work. Thanks, Best, Hosnieh From bmanning@karoshi.com Fri Oct 25 16:23: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 16F4911E81C8; Fri, 25 Oct 2013 16:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnY+DiXmla7d; Fri, 25 Oct 2013 16:23:08 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id DDB6C11E80F1; Fri, 25 Oct 2013 16:23:07 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id r9PNL3dr019205; Fri, 25 Oct 2013 23:21:03 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r9PNL3QP019204; Fri, 25 Oct 2013 23:21:03 GMT Date: Fri, 25 Oct 2013 23:21:03 +0000 From: bmanning@vacation.karoshi.com To: Hosnieh Rafiee Message-ID: <20131025232103.GA19151@vacation.karoshi.com.> References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> User-Agent: Mutt/1.4.1i Cc: Andrew Sullivan , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 23:23:12 -0000 are your new collection, DNS vulnerabilities, configuration mistakes, or implementation faults? /bill On Sat, Oct 26, 2013 at 01:16:29AM +0200, Hosnieh Rafiee wrote: > Hello, > > I have gathered some vulnerabilities in the current DNS security approaches > such as DNSSEC and etc. We think it is useful to have a survey of existing > vulnerabilities or any new vulnerabilities so that we can address those > issues in other standard RFC. This is why we plan to write a new > informational draft. > > > There is currently one old RFC that address the DNS vulnerabilities: > http://tools.ietf.org/html/rfc3833 > > So, we welcome any ideas about this work. > > Thanks, > Best, > Hosnieh > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext From ietf@rozanak.com Fri Oct 25 16:28:27 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 E6B7411E81C7; Fri, 25 Oct 2013 16:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.251, 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 W6gK5vp0G91w; Fri, 25 Oct 2013 16:28:22 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 065B611E819C; Fri, 25 Oct 2013 16:28:21 -0700 (PDT) Received: from kopoli (g231250140.adsl.alicedsl.de [92.231.250.140]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Lpcys-1WDpv93Y4k-00fVex; Fri, 25 Oct 2013 19:28:19 -0400 From: "Hosnieh Rafiee" To: References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <20131025232103.GA19151@vacation.karoshi.com.> In-Reply-To: <20131025232103.GA19151@vacation.karoshi.com.> Date: Sat, 26 Oct 2013 01:28:10 +0200 Message-ID: <008b01ced1d9$e27463b0$a75d2b10$@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: AQIm9wNy7tttPfl4fnCDTlUiOk5VlwM0Vf00mTwiA2A= Content-Language: en-us X-Provags-ID: V02:K0:sS3pfHUmB/C2B0p5ie9ztkLUY/6jtTlDGk2tJbs9IB6 8YbGz872GRAhZNamVHjdjJD9p2l1BPlnmG79LBSWTB8esjbDDp JiucVrHfYSeMtoDL831iX8ul9mp8cVY1hRBJNQAw3Mhy9t8zjw jMmrIdiOjFHql5fQttIWrw9YwwQdezd0yH4SyHY3Xa2rFW/Ac8 VVeVDF+rUj0Izrl4YVmiwXIDE5GgxDyvEeWh4Fmz3U2JVox8FZ TcZwm/A3SjWWUwJQWcf3e2R//0+cup34AkqDlI9jHKrwYTKzfj 0z4oACvOSxD/YL+uw4ItnDDx4+CgO3rQzyoKcpBPIfR82Pwep+ BAHSmnazjq+DVcIefws8= Cc: 'Andrew Sullivan' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 23:28:28 -0000 Hi Bill, Thanks for your message. > are your new collection, DNS vulnerabilities, configuration mistakes, or > implementation faults? Currently I collected some information regarding DNS vulnerabilities and some about configuration mistakes. But I haven't included anything regarding implementation faults yet. I guess it is also good to have a section about this. Any thought? -----------smile---------- Hosnieh . success is a journey, not a destination.. You cannot change your destination overnight, but you can change your direction ... Focus on the journey From bmanning@karoshi.com Fri Oct 25 17:32:44 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 9F3A111E81FD; Fri, 25 Oct 2013 17:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zLQZ1W9eGWO; Fri, 25 Oct 2013 17:32:39 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8A14311E81F8; Fri, 25 Oct 2013 17:32:39 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id r9Q0Wadr019425; Sat, 26 Oct 2013 00:32:36 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r9Q0WaQE019424; Sat, 26 Oct 2013 00:32:36 GMT Date: Sat, 26 Oct 2013 00:32:36 +0000 From: bmanning@vacation.karoshi.com To: Hosnieh Rafiee Message-ID: <20131026003236.GA19412@vacation.karoshi.com.> References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <20131025232103.GA19151@vacation.karoshi.com.> <008b01ced1d9$e27463b0$a75d2b10$@rozanak.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008b01ced1d9$e27463b0$a75d2b10$@rozanak.com> User-Agent: Mutt/1.4.1i Cc: DNSOP@ietf.org, 'Andrew Sullivan' , bmanning@vacation.karoshi.com, dnsext@ietf.org Subject: Re: [dnsext] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 00:32:44 -0000 its hard to distinguish an implementation error and a DNS protocol error, so yes, it might be a very good idea to triage your failures properly. /bill On Sat, Oct 26, 2013 at 01:28:10AM +0200, Hosnieh Rafiee wrote: > Hi Bill, > > Thanks for your message. > > > are your new collection, DNS vulnerabilities, configuration mistakes, or > > implementation faults? > > Currently I collected some information regarding DNS vulnerabilities and > some about configuration mistakes. But I haven't included anything regarding > implementation faults yet. I guess it is also good to have a section about > this. > Any thought? > > > > -----------smile---------- > Hosnieh > . success is a journey, not a destination.. > You cannot change your destination overnight, but you can change your > direction ... Focus on the journey > > > > From prvs=0004b5043f=johnl@iecc.com Fri Oct 25 19:56:56 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 6B90911E80FB for ; Fri, 25 Oct 2013 19:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 8UTxoRf7Y2nO for ; Fri, 25 Oct 2013 19:56:45 -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 1AD0F11E8122 for ; Fri, 25 Oct 2013 19:56:37 -0700 (PDT) Received: (qmail 73058 invoked from network); 26 Oct 2013 02:56:36 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 26 Oct 2013 02:56:36 -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=526b2f64.xn--30v786c.k1310; i=johnl@user.iecc.com; bh=+/BbWIQsMs/XIiLSAwBnk+RegLpuGhJkSgRy46Gm9eU=; b=SYRHkGAM9NusV1tSQ+/eOLMrSTmWgrPhne+kCuhM0XCnbVpPrx3erA5HqFCR4x1sqPzKX+sPGvIfBGhHcjYJhUo7UZcwJf0bz8hKEKsyXlwQJzbiOkRxCtIrGHENElAc1pBwflOr5FLUXA5ALwHbwJfldxHIlK+/475DHO/SmGYxudicIOvle60lnaGg2IZ/+gfccNwpy54F9xFguOIxcoixlGpFNLGIYyf2IQaoNW3XRcoOFbhN6exI8bW/o9PN 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=526b2f64.xn--30v786c.k1310; olt=johnl@user.iecc.com; bh=+/BbWIQsMs/XIiLSAwBnk+RegLpuGhJkSgRy46Gm9eU=; b=qRO0z19q7n3yAF6S+0sS82PXDvQ5JlvPWgqdDODrdXl72Ly4/HID1awslAtjxjb7Ljs2lv91PDVAEuRKm059tI6cMifTqCTryX4Jcl6GvjJTHVtcIIg9Q+zDjRC6yYoC0EO3UQDWlTR58h88emXSmd688F2WWIL7nMcb/rjiLbZZ3bRcuYqDfoROyf8ARyWTjO7FeEqoLjJsUG/RM+vvROFYsVwMOTvv1ason7C4GORLrQMWQcVwo3AJf6+35D7o Date: 26 Oct 2013 02:56:14 -0000 Message-ID: <20131026025614.3676.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] The state of DNS support, was 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: Sat, 26 Oct 2013 02:56:57 -0000 >> At the risk of ridicule, and in the interest of potentially useful results: >> >> Why not deprecate TXT, or at least abandon the current TXT and introduce >> a new TXT code point? And, as each iteration gets trashed, move on to the >> next one? >> > >I suggested allocating a dozen new TXT records for people to play with. >Crickets... I believe that solves a problem that doesn't actually exist. The real problem is that most provisioning software makes it too painful to support new RR types. A handful of TXT-like RRs that people will use insonsistently seems unlikely to fix that. From ietf@rozanak.com Sat Oct 26 03:12:33 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 186B221E808C; Sat, 26 Oct 2013 03:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSqQhY75yfZ4; Sat, 26 Oct 2013 03:12:27 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id D27D121E809A; Sat, 26 Oct 2013 03:12:26 -0700 (PDT) Received: from kopoli (g225045086.adsl.alicedsl.de [92.225.45.86]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MAg43-1VOET63sYl-00BYZh; Sat, 26 Oct 2013 06:12:21 -0400 From: "Hosnieh Rafiee" To: References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <20131025232103.GA19151@vacation.karoshi.com.> <008b01ced1d9$e27463b0$a75d2b10$@rozanak.com> <20131026003236.GA19412@vacation.karoshi.com.> In-Reply-To: <20131026003236.GA19412@vacation.karoshi.com.> Date: Sat, 26 Oct 2013 12:12:11 +0200 Message-ID: <002001ced233$daaed8e0$900c8aa0$@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: AQIm9wNy7tttPfl4fnCDTlUiOk5VlwM0Vf00Am5k3PcCnhrClZkUcjjA Content-Language: en-us X-Provags-ID: V02:K0:cbcql0cKwQS2ispTsqd0o9vSRM4Z3mr1mfkW+rn0pv9 c610LFyZpwgdobV+cK3eDfZ18WUP8GdhKLTJ034271bKMd2YHM wPcvH1Es/FI60ZdZ67uKm53qwZ63GB0E64mpOH2x2LWLPpgK4Q kir2Bk4853RIW2FKXUOcypy7qTa4T/sF7Ft644eYwb9R8WhBKx DGLcwvNWK71+RqqgemivmcnWtIGE2arwe6fs+AQR9P3SoaQwV9 8bkrPBj8lADQxQaftmvrwI9kaTMhTetDYvQvCU5LEKSxJ3tklx mj2f1/UsV7OEAAE8qmhO6xP352v0mD9bAvyk91CMbtG++1a8zF YSf3ZQXxcTeVW4Janvb0= Cc: 'Andrew Sullivan' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 10:12:33 -0000 Thank you again, Bill. > it's hard to distinguish an implementation error and a DNS protocol error, so > yes, it might be a very good idea to triage your failures properly. Yes I guess it's really a good comment to consider in this work. @list: Any other ideas? -----------smile---------- Hosnieh . success is a journey, not a destination.. You cannot change your destination overnight, but you can change your direction ... Focus on the journey From mohta@necom830.hpcl.titech.ac.jp Sat Oct 26 05:02:19 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 B144A11E812D for ; Sat, 26 Oct 2013 05:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayU2kJ+ii7IF for ; Sat, 26 Oct 2013 05:02:15 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 6AE0A11E8297 for ; Sat, 26 Oct 2013 05:02:11 -0700 (PDT) Received: (qmail 2387 invoked from network); 26 Oct 2013 11:56:24 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 26 Oct 2013 11:56:24 -0000 Message-ID: <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> Date: Sat, 26 Oct 2013 20:59:42 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Hosnieh Rafiee , dnsext@ietf.org, DNSOP@ietf.org References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> In-Reply-To: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Andrew Sullivan Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 12:02:19 -0000 Hosnieh Rafiee wrote: > I have gathered some vulnerabilities in the current DNS security approaches > such as DNSSEC and etc. We think it is useful to have a survey of existing > vulnerabilities or any new vulnerabilities so that we can address those > issues in other standard RFC. This is why we plan to write a new > informational draft. As was discussed recently in IETF ML, a serious vulnerability of, so called, DNSSEC is lack of secure time. In the discussion, there is no practical solution against it, though some security novices innocently believed GPS time were automagically secure. That is, so far, there is no way to have really secure DNSSEC. Masataka Ohta > > > There is currently one old RFC that address the DNS vulnerabilities: > http://tools.ietf.org/html/rfc3833 > > So, we welcome any ideas about this work. > > Thanks, > Best, > Hosnieh > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > From jim@rfc1035.com Sat Oct 26 05:11: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 452BB11E812D; Sat, 26 Oct 2013 05:11:34 -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 1HN4AYTxZiup; Sat, 26 Oct 2013 05:11:28 -0700 (PDT) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5F45321F9FA3; Sat, 26 Oct 2013 05:11:28 -0700 (PDT) Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id F0963CBC41C; Sat, 26 Oct 2013 13:11:26 +0100 (BST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jim Reid In-Reply-To: <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> Date: Sat, 26 Oct 2013 13:11:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2C9E8219-B2C6-4D03-B58C-B3BC509C6438@rfc1035.com> References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1510) Cc: Andrew Sullivan , DNSOP@ietf.org, dnsext@ietf.org Subject: [dnsext] timekeeping and DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 12:11:34 -0000 On 26 Oct 2013, at 12:59, Masataka Ohta = wrote: > a serious vulnerability of, so called, DNSSEC is lack of secure time. > some security novices innocently believed GPS time were automagically = secure. > That is, so far, there is no way to have really secure DNSSEC. Rubbish! If good timekeeping matters so much to DNSSEC, there are plenty of = sources of reliable time. For most people, NTP will be good enough. The = paranoid might choose Secure NTP. The really paranoid will have multiple = time sources other than GPS: eg the radio clocks operated by many = national standards institutes and/or the EU, Russian and Chinese(?) = equivalents of GPS. The really, really paranoid will operate their own = atomic clocks. From bmanning@karoshi.com Sat Oct 26 05:40:41 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 71E0011E824B; Sat, 26 Oct 2013 05:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFSIxIkNjssL; Sat, 26 Oct 2013 05:40:36 -0700 (PDT) Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by ietfa.amsl.com (Postfix) with ESMTP id A223811E8199; Sat, 26 Oct 2013 05:40:32 -0700 (PDT) Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id r9QCePdr021127; Sat, 26 Oct 2013 12:40:28 GMT Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id r9QCeO6T021126; Sat, 26 Oct 2013 12:40:24 GMT Date: Sat, 26 Oct 2013 12:40:24 +0000 From: bmanning@vacation.karoshi.com To: Jim Reid Message-ID: <20131026124024.GA18743@vacation.karoshi.com.> References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> <2C9E8219-B2C6-4D03-B58C-B3BC509C6438@rfc1035.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2C9E8219-B2C6-4D03-B58C-B3BC509C6438@rfc1035.com> User-Agent: Mutt/1.4.1i Cc: Andrew Sullivan , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] timekeeping and DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 12:40:41 -0000 On Sat, Oct 26, 2013 at 01:11:26PM +0100, Jim Reid wrote: > On 26 Oct 2013, at 12:59, Masataka Ohta wrote: > > > a serious vulnerability of, so called, DNSSEC is lack of secure time. > > some security novices innocently believed GPS time were automagically secure. > > That is, so far, there is no way to have really secure DNSSEC. > > Rubbish! > > If good timekeeping matters so much to DNSSEC, there are plenty of sources of reliable time. For most people, NTP will be good enough. The paranoid might choose Secure NTP. The really paranoid will have multiple time sources other than GPS: eg the radio clocks operated by many national standards institutes and/or the EU, Russian and Chinese(?) equivalents of GPS. The really, really paranoid will operate their own atomic clocks. > In Ohta-sans world, secure hinges on being idempotent from the silicon, the assembler, compiler, binaries and data. If any of these attributes is or can be compromised - its not secure. DNSSEC depends on time e.g. not idempotent == not secure. What really is happening is that DNSSEC is a risk management tool. DNSSEC can measureably reduce the risk of bad data. It does introduce new risk, in the form of timeing attacks, but the tradeoffs generally are presented as acceptable to most folk. /bill From Ted.Lemon@nominum.com Sat Oct 26 08:00: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 64ABA21E8092; Sat, 26 Oct 2013 08:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ+QTZXybsN9; Sat, 26 Oct 2013 08:00:12 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id A308621E809B; Sat, 26 Oct 2013 08:00:05 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUmvY8K+uSqW/oIm4CFt3nknzG6EktGi0@postini.com; Sat, 26 Oct 2013 08:00:08 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id D1DCD1B8280; Sat, 26 Oct 2013 07:59:59 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B5781190060; Sat, 26 Oct 2013 07:59:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Sat, 26 Oct 2013 07:59:59 -0700 From: Ted Lemon To: Jim Reid Thread-Topic: [DNSOP] timekeeping and DNSSEC Thread-Index: AQHO0kSKnf/AH7LHwUmAlIg0EBl0xZoHiOUA Date: Sat, 26 Oct 2013 14:59:59 +0000 Message-ID: <1FBB4607-3DDC-47C8-AF86-4058CB42E422@nominum.com> References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> <2C9E8219-B2C6-4D03-B58C-B3BC509C6438@rfc1035.com> In-Reply-To: <2C9E8219-B2C6-4D03-B58C-B3BC509C6438@rfc1035.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D91DBC1222A244F841CF8743EC8B03A@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "DNSOP@ietf.org" , " Group" Subject: Re: [dnsext] [DNSOP] timekeeping and DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 15:00:37 -0000 On Oct 26, 2013, at 8:11 AM, Jim Reid wrote: > If good timekeeping matters so much to DNSSEC, there are plenty of source= s of reliable time. For most people, NTP will be good enough. The paranoid = might choose Secure NTP. The really paranoid will have multiple time source= s other than GPS: eg the radio clocks operated by many national standards i= nstitutes and/or the EU, Russian and Chinese(?) equivalents of GPS. The rea= lly, really paranoid will operate their own atomic clocks. While I don't actually disagree with your basic point, I don't think you sh= ould gloss over the problem of the RTC-less home gateway that can't trust t= he network, or, similarly, the constrained device with the same issue. From marka@isc.org Sat Oct 26 13:56:20 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082E411E81C1; Sat, 26 Oct 2013 13:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 DzhU6-s31tk1; Sat, 26 Oct 2013 13:56:13 -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 6EF5611E81B5; Sat, 26 Oct 2013 13:56:07 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 55088C947E; Sat, 26 Oct 2013 20:55:53 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1382820966; bh=V+IPe2AnthGZgi3GOKAbNa860rjjVT4Bwar8o2xuU6I=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=IN53mcEaFbfsb5kqf5oK1ZyZMmzxeDKBSH6RfmE+mGTy0KmP4SNj4DT/lerJ7DL5q GJ80rb6Z4OkwAUb0zYljrCTwd6WYTAgYcEenpCCKa1L5afbYULpzWXgnAVBc32Wuer pgMsPUucVETN2jQt8s2LzEYiP6xfZCzSg6PVci9g= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Sat, 26 Oct 2013 20:55:53 +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 9638C160470; Sat, 26 Oct 2013 21:00:53 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 650B7160363; Sat, 26 Oct 2013 21:00:53 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B82668F895D; Sun, 27 Oct 2013 07:55:49 +1100 (EST) To: Masataka Ohta From: Mark Andrews References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Sat, 26 Oct 2013 20:59:42 +0900." <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> Date: Sun, 27 Oct 2013 07:55:49 +1100 Message-Id: <20131026205549.B82668F895D@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: Andrew Sullivan , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 20:56:20 -0000 In message <526BAEAE.6080806@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Hosnieh Rafiee wrote: > > > I have gathered some vulnerabilities in the current DNS security approaches > > such as DNSSEC and etc. We think it is useful to have a survey of existing > > vulnerabilities or any new vulnerabilities so that we can address those > > issues in other standard RFC. This is why we plan to write a new > > informational draft. > > As was discussed recently in IETF ML, a serious vulnerability of, > so called, DNSSEC is lack of secure time. > > In the discussion, there is no practical solution against it, > though some security novices innocently believed GPS time were > automagically secure. > > That is, so far, there is no way to have really secure DNSSEC. > > Masataka Ohta DNSSEC requires everyone to be using roughly the same concept of the current time. It doesn't have to be particularly accurately set. You don't need to run NTP or anything else to keep it in sync. Just set the clock on your validating resolver the way you would your wrist watch once a year/month and as long as it is has a battery backup you will be fine. Mark > > There is currently one old RFC that address the DNS vulnerabilities: > > http://tools.ietf.org/html/rfc3833 > > > > So, we welcome any ideas about this work. > > > > Thanks, > > Best, > > Hosnieh > > > > > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mohta@necom830.hpcl.titech.ac.jp Sat Oct 26 14:11: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 A9BE311E81F3 for ; Sat, 26 Oct 2013 14:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_63=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 g1jfnOJ+tym5 for ; Sat, 26 Oct 2013 14:10:56 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 5010311E81CC for ; Sat, 26 Oct 2013 14:10:50 -0700 (PDT) Received: (qmail 23755 invoked from network); 26 Oct 2013 21:05:03 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 26 Oct 2013 21:05:03 -0000 Message-ID: <526C2F40.1070003@necom830.hpcl.titech.ac.jp> Date: Sun, 27 Oct 2013 06:08:16 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Jim Reid References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> <2C9E8219-B2C6-4D03-B58C-B3BC509C6438@rfc1035.com> In-Reply-To: <2C9E8219-B2C6-4D03-B58C-B3BC509C6438@rfc1035.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Andrew Sullivan , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] timekeeping and DNSSEC X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 21:11:12 -0000 Jim Reid wrote: >> a serious vulnerability of, so called, DNSSEC is lack of secure time. >> some security novices innocently believed GPS time were automagically secure. >> That is, so far, there is no way to have really secure DNSSEC. > > Rubbish! > > If good timekeeping matters so much to DNSSEC, there are plenty of > sources of reliable time. For most people, NTP will be good enough. Very good point. Then, your problem is that for most people, plain DNS *IS* good enough and that DNSSEC+NTP does not make it any better. > The paranoid might choose Secure NTP. Secure NTP does not solve the operational problem of automatic key roll over for secure NTP itself. > The paranoid might choose Secure NTP. The really paranoid will > have multiple time sources other than GPS: eg the radio clocks > operated by many national standards institutes and/or the EU, > Russian and Chinese(?) equivalents of GPS. The problem is that a quartz clock combined with several transmiters is good enough to fake GPS data. > The really, really > paranoid will operate their own atomic clocks. While atomic clocks are not very expensive, they don't need them, because only the really, really, really paranoid use DNSSEC. Masataka Ohta From yaojk@cnnic.cn Sat Oct 26 19:23: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 1BA8011E8215 for ; Sat, 26 Oct 2013 19:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.389 X-Spam-Level: X-Spam-Status: No, score=-99.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 0apFFe+oIueO for ; Sat, 26 Oct 2013 19:23:31 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 64F7221F9E89 for ; Sat, 26 Oct 2013 19:23:29 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO smtpbg299.qq.com) (127.0.0.1) by 127.0.0.1 with SMTP; Sun, 27 Oct 2013 10:23:18 +0800 X-QQ-SSF: 0000000000000010000000000000000 X-HAS-ATTACH: no X-QQ-BUSINESS-ORIGIN: 2 X-Originating-IP: 125.33.225.40 In-Reply-To: <20131025093648.GB12997@mx1.yitter.info> References: <21069.41000.63116.736893@gro.dd.org> <21074.61535.976353.482373@gro.dd.org> <21095.58207.781300.353688@gro.dd.org> <21096.7524.908259.719737@gro.dd.org> <2013102517253369957870@cnnic.cn> <20131025093648.GB12997@mx1.yitter.info> X-QQ-STYLE: X-QQ-mid: webmail667t1382840588t2499544 From: "=?ISO-8859-1?B?SmlhbmthbmcgWWFv?=" To: "=?ISO-8859-1?B?QW5kcmV3IFN1bGxpdmFu?=" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_526C790C_08EC2A60_1EB31163" Content-Transfer-Encoding: 8Bit Date: Sun, 27 Oct 2013 10:23:08 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x X-QQ-ReplyHash: 904426643 X-QQ-SENDSIZE: 520 X-QQ-FName: 8396CE3ABEA64EB58E2FC8473FB3E5A1 X-QQ-LocalIP: 163.177.66.155 Cc: =?ISO-8859-1?B?U291cmF2IFNhaW4=?= , =?ISO-8859-1?B?ZG5zZXh0QGlldGYub3JnIEdyb3Vw?= , =?ISO-8859-1?B?VGhpcnVuYWRoYSBSZWRkeQ==?= Subject: Re: [dnsext] (BNAME) Naked domain resolution with DNSSEC 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, 27 Oct 2013 02:23:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_526C790C_08EC2A60_1EB31163 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IEJOQU1FIGlzIGNvbXBhdGlibGUgd2l0aCBETlNTRUMuIElmIHlvdSBz YXkgQk5BTUUgaXMgbm90IGNvbXBhdGlibGUgd2l0aCBETlNTRUMsIEkgdGhpbmsgdGhhdCBp dCBpcyBkdWUgdG8gcHJvdG9jb2wgb3ZlcmhlYWQuDQogSSBzdWdnZXN0IHRoZSBmb2xsb3dp bmcgdXBhZHRpbmcgdG8gQk5BTUUgdG8gcmVkdWNlIHRoZSBwcm90b2NvbCBvdmVyaGVhZDoN CiAgDQogIA0KSWYgdGhlIHF1ZXJ5IGlzIGEgRE5TU0VDIHF1ZXJ5LCB0aGUgQk5BTUUgZW5h YmxlZCByZXNvbHZlcnMgTVVTVCBzZXQgdGhlIFVCICh1bmRlcnN0YW5kIEJOQU1FKSBiaXQg aW4gdGhlIHF1ZXJ5LiBUaGUgc2VydmVyIHJlY2VpdmluZyB0aGUgVUIgYml0IE1VU1Qgbm90 IGlzc3VlIHN5bnRoZXNpemVkIENOQU1FcyBvciBETkFNRS4gU2VydmVycyBjb3B5IHRoZSBV QiBiaXQgdG8gdGhlIHJlc3BvbnNlLCBhbmQgc2hvdWxkIGRlbGV0ZSB0aGUgc3ludGhlc2l6 ZWQgQ05BTUVzIGFuZCBETkFNRSBmcm9tIHRoZSBhbnN3ZXIgaWYgdGhlcmUgaGFzIG9uZS4g SWYgdGhlIHF1ZXJ5IGlzIHRoZSBETlNTRUMgcXVlcnkgYnV0IHRoZSBVQiBiaXQgaXMgbm90 IHNldCwgdGhlIHNlcnZlciBzaG91bGQgZm9sbG93IHRoZSBydWxlcyBiZWxvdzoNCiANCmEu IElmIHRoZSBvd25lciBuYW1lIG9mIHRoZSBCTkFNRSBpcyBzYW1lIHdpdGggdGhlIG5hbWUg cXVlcmllZCwgd2hlbiBwcmVwYXJpbmcgYSByZXNwb25zZSwgYSBETlNTRUMgZW5hYmxlZCBz ZXJ2ZXIgcGVyZm9ybWluZyBhIEJOQU1FIHN1YnN0aXR1dGlvbiB3aWxsIG5vdCBpbmNsdWRl IHRoZSByZWxldmFudCBCTkFNRSAgUlIgYW5kIGl0cyBSUlNJRyBSUiBpbiB0aGUgYW5zd2Vy IHNlY3Rpb24gdW5sZXNzIHRoZSB0eXBlIHF1ZXJpZWQgaXMgQk5BTUUgLiBBIENOQU1FIFJS IHdpdGggVFRMPTAgYW5kIGl0cyBzaWduZWQgcmVjb3JkIHdpbGwgYmUgaW5jbHVkZWQgaW4g dGhlIGFuc3dlciBzZWN0aW9uIHVubGVzcyB0aGUgdHlwZSBxdWVyaWVkIGlzIEJOQU1FIC4N CiANCiBiLiBJZiB0aGUgb3duZXIgbmFtZSBvZiB0aGUgQk5BTUUgaXMgdGhlIHN1ZmZpeCBv ZiB0aGUgbmFtZSBxdWVyaWVkIGJ1dCBub3QgaWRlbnRpY2FsIHdpdGggdGhlIHN1ZmZpeCwg d2hlbiBwcmVwYXJpbmcgYSByZXNwb25zZSwgYSBzZXJ2ZXIgcGVyZm9ybWluZyBhIEJOQU1F IHN1YnN0aXR1dGlvbiB3aWxsIGluIGFsbCBjYXNlcyBpbmNsdWRlIHRoZSByZWxldmFudCBC TkFNRSBSUiBpbiB0aGUgYW5zd2VyIHNlY3Rpb24uIEEgRE5BTUUgUlIgc3ludGhlc2l6ZWQg d2l0aCBUVEw9MCBhbmQgaXRzIHNpZ25lZCBETkFNRSBSUiBhcmUgaW5jbHVkZWQgaW4gdGhl IGFuc3dlciBzZWN0aW9uLiBUaGlzIHdpbGwgaGVscCB0aGUgY2xpZW50IHRvIHJlYWNoIHRo ZSBjb3JyZWN0IEROUyBkYXRhLg0KDQogICANCiAgDQogSmlhbmthbmcgWWFvDQoNCiANCg0K IC0tLS0tLS0tLS0tLS0tLS0tLSBPcmlnaW5hbCAtLS0tLS0tLS0tLS0tLS0tLS0NCiAgRnJv bTogICJBbmRyZXcgU3VsbGl2YW4iOzxhanNAYW52aWx3YWxydXNkZW4uY29tPjsNCiBEYXRl OiAgRnJpLCBPY3QgMjUsIDIwMTMgMDU6MzYgUE0NCiBUbzogICJKaWFua2FuZyBZYW8iPHlh b2prQGNubmljLmNuPjsgDQogQ2M6ICAiRGF2ZSBMYXdyZW5jZSI8dGFsZUBkZC5vcmc+OyAi S3VtYXIgQXNodXRvc2giPGFza3VtYUBtaWNyb3NvZnQuY29tPjsgIlRoaXJ1bmFkaGEgUmVk ZHkiPHRoaXJ1bnJAbWljcm9zb2Z0LmNvbT47ICJkbnNleHRAaWV0Zi5vcmcgR3JvdXAiPGRu c2V4dEBpZXRmLm9yZz47ICJTb3VyYXYgU2FpbiI8c29zYWluQG1pY3Jvc29mdC5jb20+OyAN CiBTdWJqZWN0OiAgUmU6IFtkbnNleHRdIE5ha2VkIGRvbWFpbiByZXNvbHV0aW9uIHdpdGgg RE5TU0VDDQoNCiANCg0KT24gRnJpLCBPY3QgMjUsIDIwMTMgYXQgMDU6MjU6NDhQTSArMDgw MCwgSmlhbmthbmcgWWFvIHdyb3RlOg0KPiANCj4gQk5BTUUsIHdoaWNoIGRpcmVjdHMgYm90 aCBpdHNlbGYgYW5kIGl0cyBjaGlsZHJlbiwgbWF5IHNvbHZlIGl0LiB0aGUgZHJhZnQgYWJv dXQgQk5BTUUgd2FzIGRpc2N1c3NlZCAzIHllYXJzIGFnby4NCg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpZZXMsIGFuZCBpZiBpdCB3 ZXJlIGNvbXBhdGlibGUgd2l0aCBETlNTRUMsIHBlcmhhcHMgcGVvcGxlIHdvdWxkIGhhdmUN CnB1cnN1ZWQgaXQuICBCdXQgaXQgd29uJ3Qgd29yayB3aXRoIEROU1NFQy4NCg0KQmVzdCwN Cg0KQQ0KDQotLSANCkFuZHJldyBTdWxsaXZhbg0KYWpzQGFudmlsd2FscnVzZGVuLmNvbQ== ------=_NextPart_526C790C_08EC2A60_1EB31163 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+SSB0aGluayB0aGF0IEJOQU1FIGlzIGNvbXBhdGli bGUgd2l0aCBETlNTRUMuIElmJm5ic3A7eW91IHNheSBCTkFNRSBpcyBub3QgY29tcGF0aWJs ZSB3aXRoIEROU1NFQywgSSB0aGluayB0aGF0IGl0IGlzIGR1ZSB0byBwcm90b2NvbCBvdmVy aGVhZC48L0RJVj4NCjxESVY+SSBzdWdnZXN0IHRoZSBmb2xsb3dpbmcgdXBhZHRpbmcgdG8g Qk5BTUUgdG8gcmVkdWNlIHRoZSBwcm90b2NvbCBvdmVyaGVhZDo8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPg0KPFAgc3R5bGU9Ik1BUkdJTjogMGNtIDBjbSA2cHQiIGNsYXNz PU1zb0JvZHlUZXh0PjxGT05UIHNpemU9Mj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxTUEFOIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ01TIE1pbmNobyciIGxh bmc9RU4tVVM+SWYgdGhlIHF1ZXJ5IGlzIGEgRE5TU0VDIHF1ZXJ5LCB0aGUgQk5BTUUgPC9T UEFOPjxTUEFOIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ04iIGxhbmc9RU4t VVM+ZTwvU1BBTj48U1BBTiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICdNUyBN aW5jaG8nIiBsYW5nPUVOLVVTPm5hYmxlZCByZXNvbHZlcnMgTVVTVCBzZXQgdGhlIFVCPC9T UEFOPjxTUEFOIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTogWkgtQ04iIGxhbmc9RU4t VVM+ICh1bmRlcnN0YW5kIEJOQU1FKTwvU1BBTj48U1BBTiBzdHlsZT0ibXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6ICdNUyBNaW5jaG8nIiBsYW5nPUVOLVVTPiBiaXQgaW4gdGhlIHF1ZXJ5 LiBUaGUgc2VydmVyIHJlY2VpdmluZyB0aGUgVUIgYml0IE1VU1Qgbm90IGlzc3VlIHN5bnRo ZXNpemVkIENOQU1FczwvU1BBTj48U1BBTiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IFpILUNOIiBsYW5nPUVOLVVTPiBvciBETkFNRTwvU1BBTj48U1BBTiBzdHlsZT0ibXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6ICdNUyBNaW5jaG8nIiBsYW5nPUVOLVVTPi4gU2VydmVycyBj b3B5IHRoZSBVQiBiaXQgdG8gdGhlIHJlc3BvbnNlLCBhbmQgc2hvdWxkIGRlbGV0ZSB0aGUg c3ludGhlc2l6ZWQgQ05BTUVzPC9TUEFOPjxTUEFOIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTogWkgtQ04iIGxhbmc9RU4tVVM+IGFuZCA8L1NQQU4+PD94bWw6bmFtZXNwYWNlIHBy ZWZpeCA9IHN0MSBucyA9ICJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFy dHRhZ3MiIC8+PHN0MTpzdG9ja3RpY2tlcj48U1BBTiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6IFpILUNOIiBsYW5nPUVOLVVTPkROQTwvU1BBTj48L3N0MTpzdG9ja3RpY2tlcj48 U1BBTiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOIiBsYW5nPUVOLVVTPk1F PC9TUEFOPjxTUEFOIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ01TIE1pbmNo byciIGxhbmc9RU4tVVM+IGZyb20gdGhlIGFuc3dlciBpZiB0aGVyZSBoYXMgb25lLiBJZiB0 aGUgcXVlcnkgaXMgdGhlIEROU1NFQyBxdWVyeSBidXQgdGhlIFVCIGJpdCBpcyBub3Qgc2V0 LCB0aGUgc2VydmVyIHNob3VsZCBmb2xsb3cgdGhlIHJ1bGVzIGJlbG93Ojw/eG1sOm5hbWVz cGFjZSBwcmVmaXggPSBvIG5zID0gInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl Om9mZmljZSIgLz48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIHN0 eWxlPSJNQVJHSU46IDBjbSAwY20gNnB0IiBjbGFzcz1Nc29Cb2R5VGV4dD48U1BBTiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOIiBsYW5nPUVOLVVTPjxGT05UIHNpemU9 Mj48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmEuIElmIHRoZSBvd25lciBuYW1lIG9m IHRoZSBCTkFNRSBpcyBzYW1lIHdpdGggdGhlIG5hbWUgcXVlcmllZCwgd2hlbiBwcmVwYXJp bmcgYSByZXNwb25zZSwgYSBETlNTRUMgZW5hYmxlZCBzZXJ2ZXIgcGVyZm9ybWluZyBhIEJO QU1FIHN1YnN0aXR1dGlvbiB3aWxsIG5vdCBpbmNsdWRlIHRoZSByZWxldmFudCBCTkFNRSA8 U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvU1BBTj5SUiBhbmQgaXRz IFJSU0lHIFJSIGluIHRoZSBhbnN3ZXIgc2VjdGlvbiB1bmxlc3MgdGhlIHR5cGUgcXVlcmll ZCBpcyBCTkFNRSAuIEEgQ05BTUUgUlIgd2l0aCBUVEw9MCZuYnNwO2FuZCBpdHMgc2lnbmVk IHJlY29yZCB3aWxsIGJlIGluY2x1ZGVkIGluIHRoZSBhbnN3ZXIgc2VjdGlvbiB1bmxlc3Mg dGhlIHR5cGUgcXVlcmllZCBpcyBCTkFNRSAuPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwv U1BBTj48L1A+DQo8UCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDZwdCIgY2xhc3M9TXNvQm9k eVRleHQ+PEZPTlQgc2l6ZT0yPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PFNQQU4g c3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnTVMgTWluY2hvJyIgbGFuZz1FTi1V Uz48U1BBTiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvU1BBTj48L1NQQU4+ PFNQQU4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTiIgbGFuZz1FTi1VUz5i PC9TUEFOPjxTUEFOIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTogJ01TIE1pbmNo byciIGxhbmc9RU4tVVM+LiBJZiB0aGUgb3duZXIgbmFtZSBvZiB0aGUgQk5BTUUgaXMgdGhl IHN1ZmZpeCBvZiB0aGUgbmFtZSBxdWVyPC9TUEFOPjxTUEFOIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTogWkgtQ04iIGxhbmc9RU4tVVM+aTwvU1BBTj48U1BBTiBzdHlsZT0ibXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6ICdNUyBNaW5jaG8nIiBsYW5nPUVOLVVTPmVkIGJ1dCBu b3QgaWRlbnRpY2FsIHdpdGggdGhlIHN1ZmZpeCwgd2hlbiBwcmVwYXJpbmcgYSByZXNwb25z ZSwgYSBzZXJ2ZXIgcGVyZm9ybWluZyBhIEJOQU1FIHN1YnN0aXR1dGlvbiB3aWxsIGluIGFs bCBjYXNlcyBpbmNsdWRlIHRoZSByZWxldmFudCBCTkFNRSBSUiBpbiB0aGUgYW5zd2VyIHNl Y3Rpb24uIEE8L1NQQU4+PFNQQU4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1D TiIgbGFuZz1FTi1VUz4gRDwvU1BBTj48U1BBTiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6ICdNUyBNaW5jaG8nIiBsYW5nPUVOLVVTPk5BTUUgUlIgc3ludGhlc2l6ZWQgd2l0 aCBUVEw9MCZuYnNwO2FuZCA8L1NQQU4+PFNQQU4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOiBaSC1DTiIgbGFuZz1FTi1VUz5pdHMgc2lnbmVkIEROQU1FIFJSIGFyZSA8L1NQQU4+ PFNQQU4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnTVMgTWluY2hvJyIgbGFu Zz1FTi1VUz5pbmNsdWRlZCBpbiB0aGUgYW5zd2VyIHNlY3Rpb24uIFRoaXMgd2lsbCBoZWxw IHRoZSBjbGllbnQgdG8gcmVhY2ggdGhlIGNvcnJlY3QgRE5TIGRhdGEuPG86cD48L286cD48 L1NQQU4+PC9GT05UPjwvRk9OVD48L1A+PC9ESVY+DQo8RElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkppYW5rYW5nIFlhbzxCUj48L0RJVj4NCjxE SVY+PEJSPjwvRElWPg0KPERJViBzdHlsZT0iUEFERElORy1CT1RUT006IDJweDsgUEFERElO Ry1MRUZUOiAwcHg7IFBBRERJTkctUklHSFQ6IDBweDsgRk9OVC1GQU1JTFk6IEFyaWFsIE5h cnJvdzsgRk9OVC1TSVpFOiAxMnB4OyBQQURESU5HLVRPUDogMnB4Ij4tLS0tLS0tLS0tLS0t LS0tLS0mbmJzcDtPcmlnaW5hbCZuYnNwOy0tLS0tLS0tLS0tLS0tLS0tLTwvRElWPg0KPERJ ViBzdHlsZT0iUEFERElORy1CT1RUT006IDhweDsgUEFERElORy1MRUZUOiA4cHg7IFBBRERJ TkctUklHSFQ6IDhweDsgQkFDS0dST1VORDogI2VmZWZlZjsgRk9OVC1TSVpFOiAxMnB4OyBQ QURESU5HLVRPUDogOHB4Ij4NCjxESVY+PEI+RnJvbTogPC9CPiZuYnNwOyJBbmRyZXcgU3Vs bGl2YW4iOyZsdDthanNAYW52aWx3YWxydXNkZW4uY29tJmd0Ozs8L0RJVj4NCjxESVY+PEI+ RGF0ZTogPC9CPiZuYnNwO0ZyaSwgT2N0IDI1LCAyMDEzIDA1OjM2IFBNPC9ESVY+DQo8RElW PjxCPlRvOiA8L0I+Jm5ic3A7IkppYW5rYW5nIFlhbyImbHQ7eWFvamtAY25uaWMuY24mZ3Q7 OyA8V0JSPjwvRElWPg0KPERJVj48Qj5DYzogPC9CPiZuYnNwOyJEYXZlIExhd3JlbmNlIiZs dDt0YWxlQGRkLm9yZyZndDs7ICJLdW1hciBBc2h1dG9zaCImbHQ7YXNrdW1hQG1pY3Jvc29m dC5jb20mZ3Q7OyAiVGhpcnVuYWRoYSBSZWRkeSImbHQ7dGhpcnVuckBtaWNyb3NvZnQuY29t Jmd0OzsgImRuc2V4dEBpZXRmLm9yZyBHcm91cCImbHQ7ZG5zZXh0QGlldGYub3JnJmd0Ozsg IlNvdXJhdiBTYWluIiZsdDtzb3NhaW5AbWljcm9zb2Z0LmNvbSZndDs7IDxXQlI+PC9ESVY+ DQo8RElWPjxCPlN1YmplY3Q6IDwvQj4mbmJzcDtSZTogW2Ruc2V4dF0gTmFrZWQgZG9tYWlu IHJlc29sdXRpb24gd2l0aCBETlNTRUM8L0RJVj48L0RJVj4NCjxESVY+PEJSPjwvRElWPk9u IEZyaSwgT2N0IDI1LCAyMDEzIGF0IDA1OjI1OjQ4UE0gKzA4MDAsIEppYW5rYW5nIFlhbyB3 cm90ZTo8QlI+Jmd0OyA8QlI+Jmd0OyBCTkFNRSwgd2hpY2ggZGlyZWN0cyBib3RoIGl0c2Vs ZiBhbmQgaXRzIGNoaWxkcmVuLCBtYXkgc29sdmUgaXQuIHRoZSBkcmFmdCBhYm91dCBCTkFN RSB3YXMgZGlzY3Vzc2VkIDMgeWVhcnMgYWdvLjxCUj48QlI+Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj48QlI+WWVzLCBhbmQgaWYg aXQgd2VyZSBjb21wYXRpYmxlIHdpdGggRE5TU0VDLCBwZXJoYXBzIHBlb3BsZSB3b3VsZCBo YXZlPEJSPnB1cnN1ZWQgaXQuJm5ic3A7IEJ1dCBpdCB3b24ndCB3b3JrIHdpdGggRE5TU0VD LjxCUj48QlI+QmVzdCw8QlI+PEJSPkE8QlI+PEJSPi0tIDxCUj5BbmRyZXcgU3VsbGl2YW48 QlI+YWpzQGFudmlsd2FscnVzZGVuLmNvbTxCUj4NCjxESVY+PC9ESVY+PC9ESVY+ ------=_NextPart_526C790C_08EC2A60_1EB31163-- From mohta@necom830.hpcl.titech.ac.jp Sat Oct 26 23:30:51 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 23AB911E81C6 for ; Sat, 26 Oct 2013 23:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.023 X-Spam-Level: X-Spam-Status: No, score=-0.023 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+RiXdZl95UP for ; Sat, 26 Oct 2013 23:30:45 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 9FA5D11E819E for ; Sat, 26 Oct 2013 23:30:42 -0700 (PDT) Received: (qmail 27321 invoked from network); 27 Oct 2013 06:24:54 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 27 Oct 2013 06:24:54 -0000 Message-ID: <526CB30C.5040400@necom830.hpcl.titech.ac.jp> Date: Sun, 27 Oct 2013 15:30:36 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Ted Lemon , Jim Reid References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> <2C9E8219-B2C6-4D03-B58C-B3BC509C6438@rfc1035.com> <1FBB4607-3DDC-47C8-AF86-4058CB42E422@nominum.com> In-Reply-To: <1FBB4607-3DDC-47C8-AF86-4058CB42E422@nominum.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "DNSOP@ietf.org" , " Group" Subject: Re: [dnsext] [DNSOP] timekeeping and DNSSEC 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, 27 Oct 2013 06:30:51 -0000 Ted Lemon wrote: > While I don't actually disagree with your basic point, I don't > think you should gloss over the problem of the RTC-less > home gateway that can't trust the network, or, similarly, > the constrained device with the same issue. The constraint is in users. That is, most home users can't configure there home gateways. Thus, even if home gateways have their own RTCs, they must synchronize their RTCs with some factory configured external clocks, regardless of time differences between the RTCs and the external clocks. Otherwise, most home users can do nothing if the difference is large. Masataka Ohta From ietf@rozanak.com Sun Oct 27 02:34:20 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D552A11E813B; Sun, 27 Oct 2013 02:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiEupOuA435f; Sun, 27 Oct 2013 02:34:15 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id E0B2121E80AD; Sun, 27 Oct 2013 02:34:14 -0700 (PDT) Received: from kopoli (e179165039.adsl.alicedsl.de [85.179.165.39]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MH0Be-1VWXEC3LWs-00DWx6; Sun, 27 Oct 2013 05:33:49 -0400 From: "Hosnieh Rafiee" To: "'Masataka Ohta'" References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> <20131026205549.B82668F895D@rock.dv.isc.org> In-Reply-To: <20131026205549.B82668F895D@rock.dv.isc.org> Date: Sun, 27 Oct 2013 10:33:40 +0100 Message-ID: <001701ced2f7$a3efcd40$ebcf67c0$@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: AQIm9wNy7tttPfl4fnCDTlUiOk5VlwKx7n1vAlz9s6iZL4jVAA== Content-Language: en-us X-Provags-ID: V02:K0:7RdJcJhL8K8Nj0mAWWlUItxSxz6kVrVUaiP3HO+IQ8I j5myhfiaG6NXUXIftqBT1t4sYV5Nrle5jxk6DZDtw6aMMN8R2x A7J1lCZvgOHfdTcRQ0/q4d/LROs7fC4Li1w86WA7NoEu5+mtfJ o2EZNcONSNqUL+ixCX77kCLrq2liMepmmzhRMp8/4aFtv1Skzz v76J+bPfnK3RwWrWc0YHa8q0EozWxuRxgna+9LFEM8ghE1uKhF U1wTLBl1LwaZBXL8Dzf0TZNu6G61VEhwJFcU0VScSRYCl9P65O uDxrb53x0nDdA5X4luThci+s+y69y1leiB+Hjq/j84CgdS7cIf chBsYziymxkf5bLzc774= Cc: 'Andrew Sullivan' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities 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, 27 Oct 2013 09:34:20 -0000 > In message <526BAEAE.6080806@necom830.hpcl.titech.ac.jp>, Masataka > Ohta writes: > > Hosnieh Rafiee wrote: > > > > > I have gathered some vulnerabilities in the current DNS security > > > approaches such as DNSSEC and etc. We think it is useful to have a > > > survey of existing vulnerabilities or any new vulnerabilities so > > > that we can address those issues in other standard RFC. This is why > > > we plan to write a new informational draft. > > > > As was discussed recently in IETF ML, a serious vulnerability of, so > > called, DNSSEC is lack of secure time. > > > > In the discussion, there is no practical solution against it, though > > some security novices innocently believed GPS time were automagically > > secure. > > > > That is, so far, there is no way to have really secure DNSSEC. > > > > Masataka Ohta I guess this problem is also true for any protocol that uses timestamp in their signature and not DNSSEC specific. Because the nodes need to consider clock skew (for at least a few seconds) and this is actually where the attacker can attack the node (replay attack.... ) -----------smile---------- Hosnieh . success is a journey, not a destination.. You cannot change your destination overnight, but you can change your direction ... Focus on the journey From mohta@necom830.hpcl.titech.ac.jp Sun Oct 27 21:07: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 A00EF11E821F for ; Sun, 27 Oct 2013 21:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8G-eWu-91Co for ; Sun, 27 Oct 2013 21:07:47 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 2A21211E8304 for ; Sun, 27 Oct 2013 21:07:46 -0700 (PDT) Received: (qmail 55054 invoked from network); 28 Oct 2013 04:01:57 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 28 Oct 2013 04:01:57 -0000 Message-ID: <526DE2FF.3040400@necom830.hpcl.titech.ac.jp> Date: Mon, 28 Oct 2013 13:07:27 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Hosnieh Rafiee References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> <20131026205549.B82668F895D@rock.dv.isc.org> <001701ced2f7$a3efcd40$ebcf67c0$@rozanak.com> In-Reply-To: <001701ced2f7$a3efcd40$ebcf67c0$@rozanak.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: 'Andrew Sullivan' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities 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, 28 Oct 2013 04:07:52 -0000 Hosnieh Rafiee wrote: > I guess this problem is also true for any protocol that uses timestamp in > their signature and not DNSSEC specific. Not necessarily. Some security protocol can safely assume clocks of related equipments are manually managed by skilled operators, which is not the case with DNS clients. Then, plain DNS modified to have 32 (or 64?) bit messages ID is as secure as DNSSEC. > Because the nodes need to consider > clock skew (for at least a few seconds) and this is actually where the > attacker can attack the node (replay attack.... ) If the skew were few seconds, it is not a security problem for DNS. The problem is that, without human intervention by skilled operators, clocks can be very inaccurate. Then, a compromised and expired zone key can be used for arbitrary data of the zone, which is more serious than replay attack. Masataka Ohta From marka@isc.org Sun Oct 27 21:41:48 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 79E7C11E830D; Sun, 27 Oct 2013 21:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 QNSOqhNwXY9d; Sun, 27 Oct 2013 21:41:43 -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 6C5D111E8103; Sun, 27 Oct 2013 21:41:43 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 0E12BC94DA; Mon, 28 Oct 2013 04:41:31 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1382935302; bh=Wa/3EoJAOLAe06WsQRF7kF6mUXYkiZs9pRqbu3bI/SU=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=bLTujywfqqYuhzHhaYj57H6uKLHHlQ/ZAs3+SXP4E+CcKXEoL2IHqUYaWuQnUog6f h6S07ect5IfV0fmxpt3SxfaWe5NpOilN9Yf48AMZux8c4nolFP815JtQabXZPFTmum fCyrXcjd3CkUltIn5c3rRQb6MQorUSnm3BnTHNbw= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Mon, 28 Oct 2013 04:41:31 +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 2AFB6160435; Mon, 28 Oct 2013 04:46:37 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id EAC9616034E; Mon, 28 Oct 2013 04:46:36 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 72D4C8FEA38; Mon, 28 Oct 2013 15:41:31 +1100 (EST) To: Masataka Ohta From: Mark Andrews References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> <20131026205549.B82668F895D@rock.dv.isc.org> <001701ced2f7$a3efcd40$ebcf67c0$@rozanak.com> <526DE2FF.3040400@necom830.hpcl.titech.ac.jp> In-reply-to: Your message of "Mon, 28 Oct 2013 13:07:27 +0900." <526DE2FF.3040400@necom830.hpcl.titech.ac.jp> Date: Mon, 28 Oct 2013 15:41:31 +1100 Message-Id: <20131028044131.72D4C8FEA38@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: 'Andrew Sullivan' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities 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, 28 Oct 2013 04:41:48 -0000 In message <526DE2FF.3040400@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Hosnieh Rafiee wrote: > > > I guess this problem is also true for any protocol that uses timestamp in > > their signature and not DNSSEC specific. > > Not necessarily. Some security protocol can safely assume > clocks of related equipments are manually managed by skilled > operators, which is not the case with DNS clients. Most people are capable of setting the clocks on their laptops, phones and other portable equiment which all should be validating responses. Most people are capable of setting clocks on their desktop machines which should be validating responses. If the router takes a leap of faith w.r.t. time then it just shouldn't set AD on its responses though should still validate responses. This is significantly better than not validating responses and unless all the DNS responses are being compromised will result in lots of DNSSEC validation failures on responses. Downstream validators will not be able to get valid answers for the forged data (as the forged data will be cached) but will get valid answers for the unforged data (as this will not be cached but will be returned with cd=1) with a compromised time. This makes the attack visible. > Then, plain DNS modified to have 32 (or 64?) bit messages > ID is as secure as DNSSEC. No it is not as there is well known examples of ISP's and hotspots poisoning DNS responses. This is not to say we shouldn't be using larger id's as they will make it less important to randomise ports. > > Because the nodes need to consider > > clock skew (for at least a few seconds) and this is actually where the > > attacker can attack the node (replay attack.... ) > > If the skew were few seconds, it is not a security problem > for DNS. Nor even hours if signers set the inception time to more than a hour in the past. > The problem is that, without human intervention by skilled > operators, clocks can be very inaccurate. And the effects of bad clocks will be seen once stub resolvers routinely validate responses. > Then, a compromised and expired zone key can be used for > arbitrary data of the zone, which is more serious than > replay attack. > > > Masataka Ohta -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From drc@virtualized.org Mon Oct 28 05:24:32 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 E5C1911E817C; Mon, 28 Oct 2013 05:24:32 -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 zZPbOpZzhzcj; Mon, 28 Oct 2013 05:24:25 -0700 (PDT) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8C45811E8177; Mon, 28 Oct 2013 05:24:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id ECE7E8712B; Mon, 28 Oct 2013 08:24:20 -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 79458-08; Mon, 28 Oct 2013 08:24:20 -0400 (EDT) Received: from [10.0.1.3] (unknown [186.190.233.67]) (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 DEA5D868D4; Mon, 28 Oct 2013 08:24:19 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A0CCC24C-1075-4FB0-B555-74D9BD4CBAB0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: David Conrad In-Reply-To: <526DE2FF.3040400@necom830.hpcl.titech.ac.jp> Date: Mon, 28 Oct 2013 08:24:18 -0400 Message-Id: <4A8D974C-CE63-46A2-9505-1EC280F3A251@virtualized.org> References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> <20131026205549.B82668F895D@rock.dv.isc.org> <001701ced2f7$a3efcd40$ebcf67c0$@rozanak.com> <526DE2FF.3040400@necom830.hpcl.titech.ac.jp> To: Masataka Ohta X-Mailer: Apple Mail (2.1510) Cc: 'Andrew Sullivan' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities 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, 28 Oct 2013 12:24:34 -0000 --Apple-Mail=_A0CCC24C-1075-4FB0-B555-74D9BD4CBAB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 28, 2013, at 12:07 AM, Masataka Ohta = wrote: > Then, plain DNS modified to have 32 (or 64?) bit messages > ID is as secure as DNSSEC. How does a 32 or 64 bit message ID protect you from on-path = MITM/injection attacks? Protecting the communication channel does not equal protecting the data. Regards, -drc --Apple-Mail=_A0CCC24C-1075-4FB0-B555-74D9BD4CBAB0 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 iQEcBAEBAgAGBQJSbldyAAoJENV6ebf0/4rX6NAH/0iK7NnIaYGId8i++UFgzpDO 1+jFlw4SnJ/LAi7cru8Hz8TdC64oNQbuWgn6Vj/YbS76k6crD2A3Liunrmy1gCkh qfFFoeG44QDTw/VQ3ADzMfWKItOAHQ6NjO3yYR3+jm9jLV3PGkHUHvUK8IHRZLeo jIht8b3Bwus++LmAHYGbLa40mt6x+C30wDGYO86anT4JQ8342NLwJ4YOTeu/3hIw 8xBIllLnJpxykXxlKJN3EVECS9tVCOX5KS4QkaCGMf/gnunQ7UW17YSytNZEU/a9 7KsFqQBXTrT3+doATZVxvFRwBrPhZi7CIAwBCRS1oviNRDIXXogX1SxACJ71s6A= =1eBn -----END PGP SIGNATURE----- --Apple-Mail=_A0CCC24C-1075-4FB0-B555-74D9BD4CBAB0-- From marc.lampo.ietf@gmail.com Mon Oct 28 08:57:58 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A7D11E8160; Mon, 28 Oct 2013 08:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxZajrh0WoOb; Mon, 28 Oct 2013 08:57:57 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id CB12721E80A9; Mon, 28 Oct 2013 08:57:50 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id if17so619735vcb.13 for ; Mon, 28 Oct 2013 08:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ekoa06ZfsFG2PVmYh1Oo6ptE0pcKAesupToPKvARjl0=; b=QaFqthnnL1leM+MFyHS/5us88MOWzrlssXxtXU8k5lGIReMaezsauhwdrQomJF6K8n AUTFQcebmQvPEzB4AvpxPB8uLSvnh/9ZdBbUFss275XRqGxxjqVAC6pnwHqR9Zq9UDuh I8H170o/oMF84i0JMnrDzRw4jRv0JesxjIJEuv8QDTMAoODTBpXYYZsQPfIjH+Y8nsjz skzrqp4neiUhBX1rj0CjeVedY4oQPsR9UJxkkgj2tPCQeiTFXZkJBUNezRlH1WdbGQX3 /gHcT0xjd7ZYL1noqKSjnoYQhMsx9AKhp3TpaUbiJslECcBVvxeIB3iTyPm9VMfLu7ta +C+g== MIME-Version: 1.0 X-Received: by 10.58.107.204 with SMTP id he12mr1697884veb.26.1382975866968; Mon, 28 Oct 2013 08:57:46 -0700 (PDT) Received: by 10.58.227.66 with HTTP; Mon, 28 Oct 2013 08:57:46 -0700 (PDT) In-Reply-To: <526DE2FF.3040400@necom830.hpcl.titech.ac.jp> References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> <20131026205549.B82668F895D@rock.dv.isc.org> <001701ced2f7$a3efcd40$ebcf67c0$@rozanak.com> <526DE2FF.3040400@necom830.hpcl.titech.ac.jp> Date: Mon, 28 Oct 2013 16:57:46 +0100 Message-ID: From: Marc Lampo To: Masataka Ohta Content-Type: multipart/alternative; boundary=089e0116037a48a08504e9cf299b Cc: "dnsop@ietf.org WG" , DNSEXT Group Working Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities 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, 28 Oct 2013 15:57:58 -0000 --089e0116037a48a08504e9cf299b Content-Type: text/plain; charset=ISO-8859-1 How could a "local time problem" lead to using an "expired (zone) key" for arbitrary data of the zone ? ~ DNSKEY info itself does not expire - only signatures have expiration date ~ admitting a "local time problem" can allow for replay attacks in the sense of : "making a validating resolver believe the RRSIG is still within validity time". Do not overlook the fact that the public key is still required to perform the validation itself ! So, I think you actually make a case for not letting "no longer used" DNSKEY information linger in the zone file. Overall, assuming a DNS reply for www.example.com. with a signed but expired signature, would also need the no longer used zone signing key signed with the key signing key (possibly also expired) (and things get even more complicated if the key signing key has been rotated as well) So, there is still a lot of value in validating DNSSEC responses. Kind regards, Marc On Mon, Oct 28, 2013 at 5:07 AM, Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote: > (partly removed) > > The problem is that, without human intervention by skilled > operators, clocks can be very inaccurate. > > Then, a compromised and expired zone key can be used for > arbitrary data of the zone, which is more serious than > replay attack. > > Masataka Ohta > > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext > --089e0116037a48a08504e9cf299b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
How could a "local time problem&q= uot; lead to using an "expired (zone) key" for arbitrary data of = the zone ?
~ DNSKEY info itself does not expire - only signatures = have expiration date
~ admitting a "local time problem" can allow for replay att= acks
=A0=A0 in the sense of : "making a validating resolver b= elieve the RRSIG is still within validity time".
=A0=A0 = Do not overlook the fact that the public key is still required to perform t= he validation itself !

So, I think you actually make a case for not letting "n= o longer used" DNSKEY information linger in the zone file.


=
Overall, assuming a DNS reply for www.example.com. with a signed but expired signature,
would also need
=A0 the no longer used zone signing key
=A0 signed with the key signing key (possibly also expired)
(and things get even more complicated if the key signing key has be= en rotated as well)

So, there is still a lot of value in validating DNSSEC respo= nses.



Kind regards,

Marc


On Mon, Oct 28, 2013 at 5:07 AM, Masataka Ohta <mohta@necom= 830.hpcl.titech.ac.jp> wrote:
(partly removed)

The problem is that, without human intervention by skilled
operators, clocks can be very inaccurate.

Then, a compromised and expired zone key can be used for
arbitrary data of the zone, which is more serious than
replay attack.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Masataka Ohta

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

--089e0116037a48a08504e9cf299b-- From each@isc.org Mon Oct 28 11:40:41 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 BF1BB11E82BD; Mon, 28 Oct 2013 11:40:41 -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 c3igD-BAwQ8B; Mon, 28 Oct 2013 11:40:41 -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 7675011E8340; Mon, 28 Oct 2013 11:40:39 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id C45C3C94EC; Mon, 28 Oct 2013 18:40:28 +0000 (UTC) (envelope-from each@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1382985639; bh=Zg/ZRup80G8IB6QerVJT2vTFCWSiBiOM/qu8GSO7h7s=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=gj0IRnkZcWALM5BeU0VlQcX6ri+I2G+bJ/Y/T9jEcVAo06xeX7oKKe+GVYWvvlpRe 1d5q15ZEBzF4Oi+GHMrHeZU6MbEiGxUQpO1yCH85/IkVkhv5aiGjFxG9N3RPjBmxT2 vLqsWsIts/lGrFMM6lTiM4CvcccoEWiRjEfYkdB0= 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; Mon, 28 Oct 2013 18:40:28 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id B32FB216C25; Mon, 28 Oct 2013 18:40:28 +0000 (UTC) Date: Mon, 28 Oct 2013 18:40:28 +0000 From: Evan Hunt To: Marc Lampo Message-ID: <20131028184028.GA27088@isc.org> References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> <20131026205549.B82668F895D@rock.dv.isc.org> <001701ced2f7$a3efcd40$ebcf67c0$@rozanak.com> <526DE2FF.3040400@necom830.hpcl.titech.ac.jp> 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: "dnsop@ietf.org WG" , DNSEXT Group Working Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities 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, 28 Oct 2013 18:40:41 -0000 On Mon, Oct 28, 2013 at 04:57:46PM +0100, Marc Lampo wrote: > How could a "local time problem" lead to using an "expired (zone) key" for > arbitrary data of the zone ? There is a genuine theoretical concern here, but IMHO it's unrealistic. Imagine some shadowy omnipotent organization has tapped your connection to the internet and controls every packet you send and receive. Your router box (or other embedded device lacking an RTC battery) boots and requests the current time via NTP. The bad guys send a forged response indicating a time in the past, then they answer all DNS queries by replaying data that were captured at that time: the answers *used* to be valid, but they aren't anymore. Now suppose this no-longer-valid data includes a TLSA record for a certificate that's been compromised and revoked since then...? I can't see this as realistic for several reasons - among them, that it's easily detectable by anyone who happens to compare the clock on their router to what it says on their calendar, and I presume a shadowy omnipotent organization would have a strong preference for undetectability. I'd prefer "provably impossible" to "insanely impractical" if I had a choice in the matter, but the truth is, any adversary with the resources to pull this off would certainly have cheaper alternatives. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From mohta@necom830.hpcl.titech.ac.jp Mon Oct 28 23:23:30 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 D027021E80DC for ; Mon, 28 Oct 2013 23:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwWM8AZ1Etyr for ; Mon, 28 Oct 2013 23:23:25 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 68CE511E80FC for ; Mon, 28 Oct 2013 23:23:23 -0700 (PDT) Received: (qmail 64601 invoked from network); 29 Oct 2013 06:17:34 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 29 Oct 2013 06:17:34 -0000 Message-ID: <526F543F.5050704@necom830.hpcl.titech.ac.jp> Date: Tue, 29 Oct 2013 15:22:55 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Mark Andrews References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> <20131026205549.B82668F895D@rock.dv.isc.org> <001701ced2f7$a3efcd40$ebcf67c0$@rozanak.com> <526DE2FF.3040400@necom830.hpcl.titech.ac.jp> <20131028044131.72D4C8FEA38@rock.dv.isc.org> In-Reply-To: <20131028044131.72D4C8FEA38@rock.dv.isc.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: 'Andrew Sullivan' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities 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, 29 Oct 2013 06:23:30 -0000 Mark Andrews wrote: >> Not necessarily. Some security protocol can safely assume >> clocks of related equipments are manually managed by skilled >> operators, which is not the case with DNS clients. > > Most people are capable of setting the clocks on their laptops, > phones and other portable equiment which all should be validating > responses. Most people are capable of setting clocks on their > desktop machines which should be validating responses. Because they have buttons and displays to do so, which is not the case for a home router as a black box. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Mon Oct 28 23:25:00 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 AA8AC11E821F for ; Mon, 28 Oct 2013 23:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fL0MhU3b8hjP for ; Mon, 28 Oct 2013 23:24:53 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 36F8C11E80FC for ; Mon, 28 Oct 2013 23:24:53 -0700 (PDT) Received: (qmail 64618 invoked from network); 29 Oct 2013 06:19:05 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 29 Oct 2013 06:19:05 -0000 Message-ID: <526F549A.9070307@necom830.hpcl.titech.ac.jp> Date: Tue, 29 Oct 2013 15:24:26 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: David Conrad References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> <20131026205549.B82668F895D@rock.dv.isc.org> <001701ced2f7$a3efcd40$ebcf67c0$@rozanak.com> <526DE2FF.3040400@necom830.hpcl.titech.ac.jp> <4A8D974C-CE63-46A2-9505-1EC280F3A251@virtualized.org> In-Reply-To: <4A8D974C-CE63-46A2-9505-1EC280F3A251@virtualized.org> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: 'Andrew Sullivan' , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities 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, 29 Oct 2013 06:25:00 -0000 David Conrad wrote: >> Then, plain DNS modified to have 32 (or 64?) bit messages >> ID is as secure as DNSSEC. > > How does a 32 or 64 bit message ID protect you from on-path > MITM/injection attacks? Tell it to those who are asserting plain NTP were good enough for DNSSEC. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Wed Oct 30 00:49:42 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 D502521E8098 for ; Wed, 30 Oct 2013 00:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_71=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 NM-c76PloaYm for ; Wed, 30 Oct 2013 00:49:37 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id DEFEC11E8265 for ; Wed, 30 Oct 2013 00:49:32 -0700 (PDT) Received: (qmail 77667 invoked from network); 30 Oct 2013 07:43:41 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 30 Oct 2013 07:43:41 -0000 Message-ID: <5270B9E6.9040107@necom830.hpcl.titech.ac.jp> Date: Wed, 30 Oct 2013 16:48:54 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Hosnieh Rafiee , dnsext@ietf.org, DNSOP@ietf.org References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> In-Reply-To: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Andrew Sullivan Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities 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, 30 Oct 2013 07:49:43 -0000 Hosnieh Rafiee wrote: > I have gathered some vulnerabilities in the current DNS security approaches > such as DNSSEC and etc. We think it is useful to have a survey of existing > vulnerabilities or any new vulnerabilities so that we can address those > issues in other standard RFC. Another security problem is caused by a fundamental fallacy of PKI that CAs were trusted third parties. If a zone administrator is legally forced to disclose secret key of the zone or forge a certificate for a child zone of the zone, the zone is not secure at all. Thanks to Snowden,I can safely state such enforcement plausible without being called a paranoia. The problem can be avoided if we modify DNSSEC require multiple signatures from multiple organizations in several countries such as Russia, China etc. at least for root and TLD zones. Masataka Ohta From mohta@necom830.hpcl.titech.ac.jp Wed Oct 30 20:31:04 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 EE9AD11E81DD for ; Wed, 30 Oct 2013 20:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.027 X-Spam-Level: X-Spam-Status: No, score=-0.027 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZStDmXUhyw0 for ; Wed, 30 Oct 2013 20:30:55 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id EE06911E81F5 for ; Wed, 30 Oct 2013 20:30:50 -0700 (PDT) Received: (qmail 89002 invoked from network); 31 Oct 2013 03:24:59 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 31 Oct 2013 03:24:59 -0000 Message-ID: <5271CF93.8000908@necom830.hpcl.titech.ac.jp> Date: Thu, 31 Oct 2013 12:33:39 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Hosnieh Rafiee , dnsext@ietf.org, DNSOP@ietf.org References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> In-Reply-To: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Andrew Sullivan Subject: Re: [dnsext] DNS vulnerabilities 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, 31 Oct 2013 03:31:06 -0000 Hosnieh Rafiee wrote: > I have gathered some vulnerabilities in the current DNS security approaches > such as DNSSEC and etc. We think it is useful to have a survey of existing > vulnerabilities or any new vulnerabilities so that we can address those > issues in other standard RFC. This is why we plan to write a new > informational draft. While this is, in theory, a known vulnerability, it is still surprising that USG actively used it. Mocana Purges NSA-Compromised Key-Generation Scheme from Its Popular Nanocrypto Embedded Security Engine http://www.businesswire.com/news/home/20131016005500/en SAN FRANCISCO--(BUSINESS WIRE)--Mocana, the app security leader, issued a security advisory and announced an update to its NanoCrypto™ embedded security engine software (www.mocana.com/nanocrypto) that removes the Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG) algorithm, an algorithm that was previously promoted as a cryptographically secure key generation method by the National Institute of Standards and Technology (NIST). Mocana’s action is the result of recent Edward Snowden document revelations that the Dual_EC_DRBG algorithm contains a vulnerability that likely enables US intelligence agencies to easily decrypt communications protected with the algorithm. The algorithm was designated as a standard (SP 800-90A) by NIST in 2006, at least in part because of endorsement and promotion by the NSA. Masataka Ohta From ietf@rozanak.com Thu Oct 31 01:59:41 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 D3B2D21F9F2B; Thu, 31 Oct 2013 01:59:41 -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 lPpVfbTtfb3p; Thu, 31 Oct 2013 01:59:37 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 62DBE21F9D05; Thu, 31 Oct 2013 01:59:34 -0700 (PDT) Received: from kopoli (host-195-250-89-41.customer.arminco.com [195.250.89.41]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Mgsn2-1VFrMx0EPA-00MVGL; Thu, 31 Oct 2013 04:59:28 -0400 From: "Hosnieh Rafiee" To: "'Masataka Ohta'" , , References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <5271CF93.8000908@necom830.hpcl.titech.ac.jp> In-Reply-To: <5271CF93.8000908@necom830.hpcl.titech.ac.jp> Date: Thu, 31 Oct 2013 09:59:18 +0100 Message-ID: <001301ced617$8090fae0$81b2f0a0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIm9wNy7tttPfl4fnCDTlUiOk5VlwD4W05DmVZ7AGA= Content-Language: en-us X-Provags-ID: V02:K0:US6OUmlmALOHosc9Jp64YjtxjRzYwPUeEQFuLbvfqYH g7+j9NpCoGW5VGUaPkZ0j14zI4J3t26tb48Pn27AR6U3/bXQIN ZJqyvmPgHRdAiheWrpe940j2j1MdA5WxJQT8tDuqX49ZnzL0Id KVEdLYF5z86jiD3wsSR7zeKbtR+4bnxCPlnj1Y300uECWWkRxU e3IZrroH3UukThqPRVQ/brUMQbrRFT9te2FUsWOUnrrPR41JON BVbQICfAfLRSKBbzZ94L0hCiYWgkysNLFRfaT6+yVYiWNerK5H AL0GcsPkRdRbeFJTxG2rO2xaqVUblDdtoiKBkKLinamhyXvOUv +apZQM7OKho0EczAjMk8= Cc: 'Andrew Sullivan' Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities 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, 31 Oct 2013 08:59:42 -0000 Hi Masataka, Thank you for your useful inputs. =20 > While this is, in theory, a known vulnerability, it is still = surprising that USG > actively used it. >=20 > Mocana Purges NSA-Compromised Key-Generation Scheme from Its Popular > Nanocrypto Embedded Security Engine > http://www.businesswire.com/news/home/20131016005500/en > SAN FRANCISCO--(BUSINESS WIRE)--Mocana, the app security leader, = issued > a security advisory and announced an update to its NanoCrypto=E2=84=A2 = embedded > security engine software > (www.mocana.com/nanocrypto) that removes the Dual Elliptic Curve > Deterministic Random Bit Generator (Dual_EC_DRBG) algorithm, an > algorithm that was previously promoted as a cryptographically secure = key > generation method by the National Institute of Standards and = Technology > (NIST). Mocana=E2=80=99s action is the result of recent Edward Snowden = document > revelations that the Dual_EC_DRBG algorithm contains a vulnerability = that > likely enables US intelligence agencies to easily decrypt = communications > protected with the algorithm. The algorithm was designated as a = standard > (SP 800-90A) by NIST in 2006, at least in part because of endorsement = and > promotion by the NSA. >=20 Since hash functions are used in DNSSEC (NSEC3), I have a section about = the evaluation of hash functions (SHA1,...). But I guess what you = mentioned here is really important. So, do you think it is useful only = to focus on the algorithms used in DNS or just explain the known/found = vulnerabilities of all cryptographic algorithms because maybe for = encryption/decryption they might be used in future/ or are using? Do you = think it will be relevant to this document or it can be another = informational document only discuss about the vulnerabilities of = cryptographic algorithms?=20 Thanks again -----------smile---------- Hosnieh =E2=80=A6 success is a journey, not a destination=E2=80=A6. You cannot change your destination overnight, but you can change your = direction ... Focus on the journey From olaf@NLnetLabs.nl Thu Oct 31 06:03: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 BF80211E82FE for ; Thu, 31 Oct 2013 06:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 zBJrHnG12eBk for ; Thu, 31 Oct 2013 06:03:34 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2777211E826C for ; Thu, 31 Oct 2013 06:03:33 -0700 (PDT) Received: from [192.168.178.23] (peer.kolkman.org [82.95.132.144]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id r9VD3OOf027029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 31 Oct 2013 14:03:27 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl r9VD3OOf027029 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1383224612; bh=K28dao796vZSx2e/Ws0ZVcLmMRvYW9DrkizBHm6FRgY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=caJFP4KWnG7A49WbND3Vbp/4QsKxleYLo6e/yG/3NdlaSlegVPXnb654g152kCj7v sVSxUvF5va157nwpHgCO7PFNRhd9Gq+fdmMu0H5y7Ztfkmy9JTVzuLRDCxQU0T/gMB EIN8melduHDzhKOWbcvMwLvcXFyM8idlUXMCt648= X-Authentication-Warning: open.nlnetlabs.nl: Host peer.kolkman.org [82.95.132.144] claimed to be [192.168.178.23] Content-Type: multipart/signed; boundary="Apple-Mail=_15661FAB-1B49-435E-BF9D-E84D46B96D59"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Olaf Kolkman In-Reply-To: Date: Thu, 31 Oct 2013 14:03:23 +0100 Message-Id: <2330D393-9816-48C7-AA22-D1AC8F1032D0@NLnetLabs.nl> References: To: Paul Wouters X-Mailer: Apple Mail (2.1816) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [213.154.224.1]); Thu, 31 Oct 2013 14:03:28 +0100 (CET) Cc: DNSEXT Group Working Subject: [dnsext] EDNS exchanges in 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: Thu, 31 Oct 2013 13:03:34 -0000 --Apple-Mail=_15661FAB-1B49-435E-BF9D-E84D46B96D59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 11 sep. 2013, at 03:15, Paul Wouters wrote: >=20 > Filename: draft-wouters-edns-tcp-chain-query > Revision: 00 > Title: TCP chain query requests in DNS > Creation date: 2013-09-10 > Group: Individual Submission Thanks Paul,=20 Hereby a few responses after first review. In 3.3.2 you specify that you MAY include the ENDS option in responses. I am not sure if there are clients out there that get all nauseous from = OPT RRs in the responses and I am also not sure if this would be the = first EDNS exchange where a server sends back an OPT RR in the = additional section without first having received an EDNS packet from a = client. If conservatism is warranted I=92d suggest to only send back an OPT RR = to clients that have shown EDNS support by sending you a query first. NIT: if you are going to ignore the timeout anyway on the server then a = SHOULD set to 0 for clients is sufficient. Violating that MUST doesn=92t = lead to interoperability issues if the server ignores the value anyhow. =97Olaf --Apple-Mail=_15661FAB-1B49-435E-BF9D-E84D46B96D59 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: Signature creating using GPG Tools. iQIcBAEBAgAGBQJSclUbAAoJEFRqER47aqpkI7QP/RKFIuNHRtB1RhMPg7uIHGSe fjudM24ebP2JrREVc8gYTHt2ntqFQWmHQtBfh7iZUagEfNXupieAHY11yFksx9RE yrOpWz7B2IoqFz1EHIhmx8BrdmYlDGvKk6cMHvLr6NHxyLkQuge+mPIbdezYcslP WFcZpGbSC0rujP5k8MCsMU7VY0l2KQZpH13wSKlnAB0FGEMqOz9SJwuIbNhkQk1X x+ZZaX5EYicp+r1gBuJbhT1PQwRro0Mz2ZykPbHzm5edPZ7TFJgdDOcJkLDr26qJ U/GpYPHn8Vcd5vqd3mIE6nseuvyLbM1Gwau2YWIEO0yyugR6Ftj6FfnRAhjqmOHE WlY0XbYv90py6XGNdn0tSszJyRqG6ZdIMim88d4HDUCjZpg/PvheBMurWylYur2v Gdz2o+gqaV7jDu/PYBxl1tdwaU+//EHmbrYxz42NKxlmnM5xHInSmHzjimduFKjp yzb4UJ9ng1reurTWmBB1YL+hRDno8MQqt4C5xR4vFHyuKddM4yi01b7SXaNmgjVT CciAThJddyUqxJZ74ch1UK+yAhiBrLCteErfec5rexZ1f6ulK+4zZtAYkIGHiLLt xr3p36z85WzzTuYxcgHio2x/IzoSWp2QXqlkkiCjc0NCplVpg7743Dm4vakkFvrt Zq7Odn7K2N3/+oN1eYd3 =0T7p -----END PGP SIGNATURE----- --Apple-Mail=_15661FAB-1B49-435E-BF9D-E84D46B96D59-- From Ray.Bellis@nominet.org.uk Thu Oct 31 06:17:16 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 D567511E8121 for ; Thu, 31 Oct 2013 06:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNcT--bwHgN6 for ; Thu, 31 Oct 2013 06:17:11 -0700 (PDT) Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id E1DB311E8203 for ; Thu, 31 Oct 2013 06:17:04 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=QRU2dAG2g1Q99ONJfSb3O9tuYn39U3ldyyc9LW2rNjqGRxZOosCbt/wI SfQWpg5J/0J3xxxKvhFUr0Ev8z6kN0vFqeeB+GPwv+I8KpjQa/hV+A/CG 1FuNaW4yrHqjOHMJASFEa7YDOXmGiob1xh/4hYRAcgWWAf2HoHVJlQKCl xUZ+T4IeacMqh+K6KJ3zZKDSj0IikWQ60wZy6uwBTW3aQseH0u8mseHoB uuqmszbcRj429toVU2zDTVd8zN0gM; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1383225425; x=1414761425; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sN05gnqHhKmcwA2v27pBjebrOGQWQvtDT/HvEGLfs5k=; b=CBYU67Q5xHfjtLz7+6TMXQZuZiOBuncssOkMfAAU5c4e0Lj3Bqh4eduR Yyjq3uNAv0jo/CKARLtcRCYEqe0SijG54BbLHFTejzzRqOKiiX0vnNE7v VY4kr6TTFgpIaUPcLRI0cXbEsmFto+4sNryZLL39E/xLQJ4VX7AIr4GM9 wHRgCvOHNIdGUW/QcCRxk9wgTS+r84hL/C2HGCE8fnafggkFTlBeZrx77 V1xhMhNwLQ7sfX/mzn7A87syq7O8K; X-IronPort-AV: E=Sophos;i="4.93,609,1378854000"; d="scan'208";a="4454713" X-IPAS-Result: AgUFAOFXclLV+MWQ/2dsb2JhbABZgmYhgQy/aYEkFnSCJQEBAQECAVMmBQsCAQgiJDIlAgQOBQiHeQcDvDuPHAIxB4MggQ4DqhSDJoIq Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx1.nominet.org.uk with ESMTP; 31 Oct 2013 13:17:03 +0000 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%17]) with mapi id 14.02.0318.004; Thu, 31 Oct 2013 13:17:02 +0000 From: Ray Bellis To: Olaf Kolkman Thread-Topic: [dnsext] EDNS exchanges in draft-wouters-edns-tcp-chain-query-00.txt Thread-Index: AQHO1jmmHbqxIE3M9EOhQXgYfcky75oOypgA Date: Thu, 31 Oct 2013 13:17:02 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE7368551C8A@wds-exc2.okna.nominet.org.uk> References: <2330D393-9816-48C7-AA22-D1AC8F1032D0@NLnetLabs.nl> In-Reply-To: <2330D393-9816-48C7-AA22-D1AC8F1032D0@NLnetLabs.nl> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="Windows-1252" Content-ID: <467C03C4E94F9A45A31C8FF062E63E5F@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] EDNS exchanges in 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: Thu, 31 Oct 2013 13:17:17 -0000 On 31 Oct 2013, at 13:03, Olaf Kolkman wrote: > I am not sure if there are clients out there that get all nauseous from O= PT RRs in the responses=20 There are bound to be - I've certainly seen CPE that get nauseous (FORMERR)= with OPT RRs in the request, and I've no reason to believe they wouldn't d= o just the same for an unsolicited OPT RR in the response. Ray From fanf2@hermes.cam.ac.uk Thu Oct 31 12:37:48 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 33B5D11E8155; Thu, 31 Oct 2013 12:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 mkErfgfv1RFl; Thu, 31 Oct 2013 12:37:46 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f33]) by ietfa.amsl.com (Postfix) with ESMTP id E788511E823D; Thu, 31 Oct 2013 12:37:10 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44544) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Vby2w-00024z-hw (Exim 4.80_167-5a66dd3) (return-path ); Thu, 31 Oct 2013 19:36:46 +0000 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Vby2w-0005vY-IY (Exim 4.72) (return-path ); Thu, 31 Oct 2013 19:36:46 +0000 Date: Thu, 31 Oct 2013 19:36:46 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Masataka Ohta In-Reply-To: <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> Message-ID: References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Andrew Sullivan , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities 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, 31 Oct 2013 19:37:48 -0000 Masataka Ohta wrote: > > As was discussed recently in IETF ML, a serious vulnerability of, > so called, DNSSEC is lack of secure time. I have the beginnings of a solution to this problem. It is based on using tlsdate, which gets the time from a server with minimal risk of interference by a man-in-the-middle. If you get the time from several diverse servers you can be very sure you have the right time if enough of them agree. You can choose the size of a quorum according to your security and robustness requirements. Agreement is determined in a similar way to NTP's clock select algorithm, which separates falsetickers from truechimers. http://fanf.livejournal.com/128861.html - introductory article https://git.csx.cam.ac.uk/x/ucs/u/fanf2/temporum.git - rough proof of concept implementation Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From marka@isc.org Thu Oct 31 15:51: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 914C921E811A for ; Thu, 31 Oct 2013 15:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.706 X-Spam-Level: X-Spam-Status: No, score=-6.706 tagged_above=-999 required=5 tests=[AWL=3.893, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JoeyfE1eCi0 for ; Thu, 31 Oct 2013 15:50:57 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1679921E8119 for ; Thu, 31 Oct 2013 15:50:57 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 055F92383D5; Thu, 31 Oct 2013 22:50:44 +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 02C5C160470; Thu, 31 Oct 2013 22:55:36 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id C6229160459; Thu, 31 Oct 2013 22:55:35 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 4E416965551; Fri, 1 Nov 2013 09:50:11 +1100 (EST) To: Ray Bellis From: Mark Andrews References: <2330D393-9816-48C7-AA22-D1AC8F1032D0@NLnetLabs.nl> <53F00E5CD8B2E34C81C0C89EB0B4FE7368551C8A@wds-exc2.okna.nominet.org.uk> In-reply-to: Your message of "Thu, 31 Oct 2013 13:17:02 -0000." <53F00E5CD8B2E34C81C0C89EB0B4FE7368551C8A@wds-exc2.okna.nominet.org.uk> Date: Fri, 01 Nov 2013 09:50:11 +1100 Message-Id: <20131031225011.4E416965551@rock.dv.isc.org> Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] EDNS exchanges in 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: Thu, 31 Oct 2013 22:51:03 -0000 In message <53F00E5CD8B2E34C81C0C89EB0B4FE7368551C8A@wds-exc2.okna.nominet.org. uk>, Ray Bellis writes: > > On 31 Oct 2013, at 13:03, Olaf Kolkman wrote: > > > I am not sure if there are clients out there that get all nauseous from OPT > > RRs in the responses > > There are bound to be - I've certainly seen CPE that get nauseous (FORMERR) > with OPT RRs in the request, and I've no reason to believe they wouldn't do > just the same for an unsolicited OPT RR in the response. And such CPE are not RFC 103[45] compliant as the server can put anything it wants into a additional section of a query response that it believes will be useful to the client. e.g. NAPTR -> SRV records in the additional section -> A + AAAA in the additional section. Having a OPT record in a request is different as the additional section was expected to be empty in RFC 103[45] query requests. You can't draw conclusions on how a response will be treated based on how a query is treated. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jabley@hopcount.ca Thu Oct 31 17:38:49 2013 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4D211E827F for ; Thu, 31 Oct 2013 17:38:49 -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 KAA68-BtYMJy for ; Thu, 31 Oct 2013 17:38:48 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4C82A11E827E for ; Thu, 31 Oct 2013 17:38:46 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id i4so3883873oah.4 for ; Thu, 31 Oct 2013 17:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-type; bh=xqyvD52URf/fz6I2sqwHT7sTW2UcEOlvBC4Z+S7468M=; b=XV++gn4Yp7Xvv6+dnxtumsbXFB4eSSQu3/PZwAMmW5hpnKSJKRJ56yLzFVUy3x1dyb ZJtTkFHVbCrYhJkfh+raeS4Yiv4VfGPSEIedNeVoWIak7f32Xjs55VsQ3DscdysxzMBZ LLHARhMeMQpqLMMlLZvikesWxZqzZkpWm+OvE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-type; bh=xqyvD52URf/fz6I2sqwHT7sTW2UcEOlvBC4Z+S7468M=; b=CSoO+AuQxf30p7Vtwz1Mc2FM089asJqDYgAk6tejJJ4uykTzWwsxyKOh6AIPVjV9K1 ldXS+ZpRXJTmBe0rTMuf3vqGveZWFPnRLaP5EhgXikQ2OSKXU0jepf5ZXjlYPkAH0vCB ByEvIGSFDBsqe2SKUHOejoIJiarXneadR40796/OO2dc0IubATbaiIdz7La32Oimlbjv cytrV4mONeaxojM/vQ0rJKrZZwUFtne3TBtSVGl5bV4mut4IHwZxTw5IAbmghxfStb53 5aZuVcVQzhfhUSKfN5q3HqbnEDY6FE0Bgm2XwfiD8SBvkuQgqNMofzcBl1gH80vV4UAU V8yA== X-Gm-Message-State: ALoCoQmhh/fGFm08L13A7l0YuQQX7RlmQ+cIs3/LpHLGE9nB4tmAGLBGlwy2KwKpqqpKhUvMm+S9 X-Received: by 10.182.247.68 with SMTP id yc4mr348721obc.67.1383266325521; Thu, 31 Oct 2013 17:38:45 -0700 (PDT) From: Joe Abley Mime-Version: 1.0 (1.0) References: <2330D393-9816-48C7-AA22-D1AC8F1032D0@NLnetLabs.nl> <53F00E5CD8B2E34C81C0C89EB0B4FE7368551C8A@wds-exc2.okna.nominet.org.uk> In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE7368551C8A@wds-exc2.okna.nominet.org.uk> Date: Thu, 31 Oct 2013 20:38:44 -0400 Message-ID: <5359785363432515507@unknownmsgid> To: Ray Bellis Content-Type: text/plain; charset=ISO-8859-1 Cc: Paul Wouters , DNSEXT Group Working Subject: Re: [dnsext] EDNS exchanges in 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: Fri, 01 Nov 2013 00:38:49 -0000 On Oct 31, 2013, at 9:17, Ray Bellis wrote: > >> On 31 Oct 2013, at 13:03, Olaf Kolkman wrote: >> >> I am not sure if there are clients out there that get all nauseous from OPT RRs in the responses > > There are bound to be - I've certainly seen CPE that get nauseous (FORMERR) with OPT RRs in the request, and I've no reason to believe they wouldn't do just the same for an unsolicited OPT RR in the response. Geoff and George to the courtesy phone! From mohta@necom830.hpcl.titech.ac.jp Thu Oct 31 23:26:33 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 C8BA421E80A8 for ; Thu, 31 Oct 2013 23:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.033 X-Spam-Level: X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8IEU-ww1EQz for ; Thu, 31 Oct 2013 23:26:33 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 465A111E81CB for ; Thu, 31 Oct 2013 23:26:25 -0700 (PDT) Received: (qmail 4656 invoked from network); 1 Nov 2013 06:20:31 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 1 Nov 2013 06:20:31 -0000 Message-ID: <52734A38.9060708@necom830.hpcl.titech.ac.jp> Date: Fri, 01 Nov 2013 15:29:12 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Tony Finch References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Andrew Sullivan , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 06:26:34 -0000 Tony Finch wrote: > I have the beginnings of a solution to this problem. It is based on using > tlsdate, which gets the time from a server with minimal risk of > interference by a man-in-the-middle. TLS is another PKI and is inherently insecure as CAs can be compromised. As David Conrad wrote in this thread: > How does a 32 or 64 bit message ID protect you from on-path > MITM/injection attacks? we should assume local ISP can be compromised. Then, as compromising a CA is just as easy as compromising an ISP, PKIs, including but not limited to DNSSEC and TLS, are inherently insecure. Worse, tlsdate has a chicken and egg problem. Without secure clock, how can you be sure that certificate for tlsdate is still valid? > If you get the time from several > diverse servers you can be very sure you have the right time if enough > of them agree. It is not more secure than using multiple NTP servers with plain NTP. Masataka Ohta From each@isc.org Thu Oct 31 23:37: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 653F011E8268; Thu, 31 Oct 2013 23:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp+rpSmLFC7N; Thu, 31 Oct 2013 23:37:02 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9801211E81CB; Thu, 31 Oct 2013 23:36:49 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) by mx.ams1.isc.org (Postfix) with ESMTP id 9FCAD2383D8; Fri, 1 Nov 2013 06:36:35 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 77B42216C25; Fri, 1 Nov 2013 06:35:52 +0000 (UTC) Date: Fri, 1 Nov 2013 06:35:52 +0000 From: Evan Hunt To: Masataka Ohta Message-ID: <20131101063552.GB76903@isc.org> References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <526BAEAE.6080806@necom830.hpcl.titech.ac.jp> <52734A38.9060708@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52734A38.9060708@necom830.hpcl.titech.ac.jp> User-Agent: Mutt/1.4.2.3i Cc: Andrew Sullivan , DNSOP@ietf.org, dnsext@ietf.org Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 06:37:11 -0000 On Fri, Nov 01, 2013 at 03:29:12PM +0900, Masataka Ohta wrote: > TLS is another PKI and is inherently insecure as CAs can be > compromised. True, but Tony's quorum-based approach could be made exhaustive enough that the adversary would have to have compromised *every* CA. If they can do that, I'm not sure any realistic defense is possible anyway. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From mohta@necom830.hpcl.titech.ac.jp Thu Oct 31 23:37:17 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 9B68C11E8215 for ; Thu, 31 Oct 2013 23:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.038 X-Spam-Level: X-Spam-Status: No, score=-0.038 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LspcLYpu3nad for ; Thu, 31 Oct 2013 23:37:12 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 5C89421F8531 for ; Thu, 31 Oct 2013 23:37:02 -0700 (PDT) Received: (qmail 4755 invoked from network); 1 Nov 2013 06:31:03 -0000 Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 1 Nov 2013 06:31:03 -0000 Message-ID: <52734CB0.60506@necom830.hpcl.titech.ac.jp> Date: Fri, 01 Nov 2013 15:39:44 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Hosnieh Rafiee , dnsext@ietf.org, DNSOP@ietf.org References: <008a01ced1d8$41885d40$c49917c0$@rozanak.com> <5271CF93.8000908@necom830.hpcl.titech.ac.jp> <001301ced617$8090fae0$81b2f0a0$@rozanak.com> In-Reply-To: <001301ced617$8090fae0$81b2f0a0$@rozanak.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: 'Andrew Sullivan' Subject: Re: [dnsext] [DNSOP] DNS vulnerabilities X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 06:37:17 -0000 Hi, Hosnieh, > Do you think it will be relevant to this document or it can be > another informational document only discuss about the > vulnerabilities of cryptographic algorithms? As I said, it is a known vulnerability. That is, we don't need a generic new document very much. However, Snowden taught us that we must avoid any fancy cryptography strongly promoted by NIST, including all the EC related ones, which may be documented somewhere. Masataka Ohta