From riwhite@verisign.com Fri Jan 4 12:19:31 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0C521F8673 for ; Fri, 4 Jan 2013 12:19:31 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fzi83RIFQ4Am for ; Fri, 4 Jan 2013 12:19:27 -0800 (PST) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id B4E1E21F86E6 for ; Fri, 4 Jan 2013 12:19:23 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUOc5OpZzYETe8AWxZCUdyUbOJLQZNol9@postini.com; Fri, 04 Jan 2013 12:19:26 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r04KJ2HH002370 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jan 2013 15:19:02 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0318.004; Fri, 4 Jan 2013 15:18:21 -0500 From: "White, Russell" To: Jiankang YAO , "dnsop@ietf.org" , SM Thread-Topic: [DNSOP] IPR Disclosure: VeriSign, Inc.'s Statement about IPR related to draft-ietf-dnsop-rfc4641bis-13 and draft-koch-dnsop-dnssec-operator-change-04 Thread-Index: AQHN4YojQnfxpgAINUib67i6ZFJXApg5riS/ Date: Fri, 4 Jan 2013 20:19:02 +0000 Message-ID: <3F74C1962631E14292BBF1B1B5F7021E1E29FB92@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20121206172011.28125.12963.idtracker@ietfa.amsl.com> <6.2.5.6.2.20121206110336.09bf23a8@resistor.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 04 Jan 2013 13:47:05 -0800 Cc: "matthijs@nlnetlabs.nl" , "rbonica@juniper.net" , "pk@ISOC.DE" , "miek.gieben@sidn.nl" , "bclaise@cisco.com" , "sa.morris7@googlemail.com" Subject: Re: [DNSOP] IPR Disclosure: VeriSign, Inc.'s Statement about IPR related to draft-ietf-dnsop-rfc4641bis-13 and draft-koch-dnsop-dnssec-operator-change-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 20:19:31 -0000 =0A= We have reviewed and Verisign believes that no change to its IPR disclosure= is required at this time.=0A= =0A= Russ=0A= =0A= =0A= ________________________________________=0A= From: Jiankang YAO [yaojk@cnnic.cn]=0A= Sent: Sunday, December 23, 2012 10:55 PM=0A= To: dnsop@ietf.org; Patent Licensing; SM=0A= Cc: matthijs@nlnetlabs.nl; White, Russell; rbonica@juniper.net; dnsop@ietf.= org; pk@ISOC.DE; miek.gieben@sidn.nl; bclaise@cisco.com; sa.morris7@googlem= ail.com=0A= Subject: Re: [DNSOP] IPR Disclosure: VeriSign, Inc.'s Statement about IPR r= elated to draft-ietf-dnsop-rfc4641bis-13 and draft-koch-dnsop-dnssec-op= erator-change-04=0A= =0A= ----- Original Message -----=0A= From: "SM" =0A= To: ; =0A= Cc: ; ; ;= ; ; ; = ; =0A= Sent: Friday, December 07, 2012 3:13 AM=0A= Subject: Re: [DNSOP] IPR Disclosure: VeriSign, Inc.'s Statement about IPR r= elated to draft-ietf-dnsop-rfc4641bis-13 and draft-koch-dnsop-dnssec-operat= or-change-04=0A= =0A= =0A= > The IPR disclosure at https://datatracker.ietf.org/ipr/1924/ does not=0A= > mention RFC 4641. As draft-ietf-dnsop-rfc4641bis-13 is based on RFC=0A= > 4641, does the submitter believe that an IPR disclosure is required=0A= > for RFC 4641?=0A= >=0A= =0A= I am interested in this question too since rfc4641bis and rfc4641 share a l= ot of points.=0A= =0A= Jiankang Yao=0A= > Regards,=0A= > -sm=0A= >=0A= > _______________________________________________=0A= > DNSOP mailing list=0A= > DNSOP@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/dnsop=0A= From sm@resistor.net Fri Jan 4 16:33:45 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3EF21F8AF8 for ; Fri, 4 Jan 2013 16:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQ+PnL0z8PsZ for ; Fri, 4 Jan 2013 16:33:44 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A329821F8A6F for ; Fri, 4 Jan 2013 16:33:44 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r050XcII007887; Fri, 4 Jan 2013 16:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1357346024; bh=RZiDHO62arZdjYAM8ovA4ht3ih4Up/dNSnrEzifIjnE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=r/ZhLtkgKB5xQKFc72VeLMjWubbL8ZOVrLResvwdaLnVDEOOjjx/v8xOQ1BbCTziK FF+JShjAVpLbLHh70Z47MyJ6S8TIadwtawQV8wNoHYuKCMZ5JmTBPXHDT3Qg6um3Bv cKbzbKGWH2z0PD0ryOxC8w3Mus42eCm7cSuPeeLA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1357346024; i=@resistor.net; bh=RZiDHO62arZdjYAM8ovA4ht3ih4Up/dNSnrEzifIjnE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bpUa1+IgEUPxvwAkPBar0drNOy9FIVppOItSFeagAQmMO+YacyxU5lnzaWGzh5Xx1 qe45ZSYaX1ekfLxK/9KNPzHflrefDdYwvminI+IJEijJuQfvx14qP0fc3btELZIDGV X0xDUfxmbjATb+YLLXbGwtXWn64gUd6eKh6wHZbM= Message-Id: <6.2.5.6.2.20130104160239.0b19ed68@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 04 Jan 2013 16:11:23 -0800 To: "White, Russell" From: SM In-Reply-To: <3F74C1962631E14292BBF1B1B5F7021E1E29FB92@BRN1WNEXMBX01.vco rp.ad.vrsn.com> References: <20121206172011.28125.12963.idtracker@ietfa.amsl.com> <6.2.5.6.2.20121206110336.09bf23a8@resistor.net> <3F74C1962631E14292BBF1B1B5F7021E1E29FB92@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dnsop@ietf.org Subject: Re: [DNSOP] IPR Disclosure: VeriSign, Inc.'s Statement about IPR related to draft-ietf-dnsop-rfc4641bis-13 and draft-koch-dnsop-dnssec-operator-change-04 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 00:33:45 -0000 Hi Russ, At 12:19 04-01-2013, White, Russell wrote: >We have reviewed and Verisign believes that no change to its IPR >disclosure is required at this time. Thanks. Regards, -sm From wwwrun@rfc-editor.org Thu Jan 10 15:06:35 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA74C21F8566; Thu, 10 Jan 2013 15:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT7M2Is6kfdN; Thu, 10 Jan 2013 15:06:34 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2098121F8510; Thu, 10 Jan 2013 15:06:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 77EFDB1E002; Thu, 10 Jan 2013 14:56:06 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130110225606.77EFDB1E002@rfc-editor.org> Date: Thu, 10 Jan 2013 14:56:06 -0800 (PST) Cc: dnsop@ietf.org, rfc-editor@rfc-editor.org Subject: [DNSOP] RFC 6841 on A Framework for DNSSEC Policies and DNSSEC Practice Statements X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 23:06:35 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6841 Title: A Framework for DNSSEC Policies and DNSSEC Practice Statements Author: F. Ljunggren, AM. Eklund Lowinder, T. Okubo Status: Informational Stream: IETF Date: January 2013 Mailbox: fredrik@kirei.se, amel@iis.se, tomofumi.okubo@icann.org Pages: 27 Characters: 57936 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dnsop-dnssec-dps-framework-11.txt URL: http://www.rfc-editor.org/rfc/rfc6841.txt This document presents a framework to assist writers of DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone with Security Extensions implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Domain Name System Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jason_livingood@cable.comcast.com Fri Jan 18 08:03:07 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6702F21F845D for ; Fri, 18 Jan 2013 08:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.897 X-Spam-Level: X-Spam-Status: No, score=-100.897 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc-Bljaoz4NT for ; Fri, 18 Jan 2013 08:03:06 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 73C0021F8449 for ; Fri, 18 Jan 2013 08:03:06 -0800 (PST) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.40720253; Fri, 18 Jan 2013 10:52:07 -0500 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.96]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Fri, 18 Jan 2013 11:03:02 -0500 From: "Livingood, Jason" To: Emiliano Casalicchio , John Levine , "dnsop@ietf.org" Thread-Topic: [DNSOP] Models of DNS cache behavior? Thread-Index: AQHM7eC7hJB+PFj1KkaBjZzOOhgETJZGg02AggrLjgA= Date: Fri, 18 Jan 2013 16:03:01 +0000 Message-ID: <10229F86C86EB444898E629583FD41714EEAB5AC@PACDCEXMB06.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DNSOP] Models of DNS cache behavior? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 16:03:07 -0000 If there is anyone out there interested in doing research into DNS recursive resolvers and are seeking either (1) access to data (stripped of PII of course) and/or (2) modest funding support, please let me know off-list. - Jason On 2/20/12 2:27 PM, "Emiliano Casalicchio" wrote: >John, >may be the model described in this paper can be useful for you. > > Yakup Ko=E7, Almerima Jamakovic, Bart Gijsen, "A Global Reference Model o= f >the DNS" > >presented at DNS-EASY 2011. > >Here the proceedings: >http://www.gcsec.org/sites/default/files/files/dnseasy2011_final.pdf > >Best >Emiliano > > > > >On 18 Feb 2012, at 02:57, John Levine wrote: > >> Are there any models of DNS cache behavior, either analytic or >> simulations? What I have in mind is something that would help me see >> whether I should partition a cache among various kinds of traffic, or >> perhaps limit max TTLs, or experiment with replacement strategies. >>=20 >> For that matter, what's the state of DNS modelling in general? >>=20 >> I found a paper by Jung et al from 2003 on cache models which starts >> by asserting that caches are so big that entries only drop out due to >> TTL expiry, did a lot of analysis and simulation, and concluded that >> 15 minute TTLs got nearly the same cache benefit of 24 hr TTL. >>=20 >> A 2010 paper by Alexiou et al. models the Kaminsky DNS poisoning >> attack and the port randomizing fix, which is interesting but not what >> I'm looking for. (They conclude that the attack is real, and the fix >> works OK.) >>=20 >> Anything else I should be looking at? >>=20 >>=20 >> --=20 >> Regards, >> John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for >>Dummies", >> Please consider the environment before reading this e-mail. http://jl.ly >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >>=20 > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop From jason_livingood@cable.comcast.com Fri Jan 18 08:07:38 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E5921F89CB for ; Fri, 18 Jan 2013 08:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.064 X-Spam-Level: X-Spam-Status: No, score=-103.064 tagged_above=-999 required=5 tests=[AWL=2.167, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GACgCYuEsEnk for ; Fri, 18 Jan 2013 08:07:34 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id DCC1F21F89A3 for ; Fri, 18 Jan 2013 08:07:22 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.51762095; Fri, 18 Jan 2013 08:38:52 -0700 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.96]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Fri, 18 Jan 2013 11:07:16 -0500 From: "Livingood, Jason" To: Emiliano Casalicchio , John Levine , "dnsop@ietf.org" Thread-Topic: [DNSOP] Models of DNS cache behavior? Thread-Index: AQHM7eC7hJB+PFj1KkaBjZzOOhgETJZGg02AggrLjgCAAAEwgA== Date: Fri, 18 Jan 2013 16:07:16 +0000 Message-ID: <10229F86C86EB444898E629583FD41714EEAB5DA@PACDCEXMB06.cable.comcast.com> In-Reply-To: <10229F86C86EB444898E629583FD41714EEAB5AC@PACDCEXMB06.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.56.165] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0468EEAEB5880544A90F58CFDB135E27@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DNSOP] Models of DNS cache behavior? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 16:07:38 -0000 Oh, and some interesting questions may include a study of: - How are TTLs changing over time now that so much content is moving to CDNs - What are the recursive resolver effects due to more hyper-giants and CDNs - Study of large scale auth failures in CDN/content providers and the resulting effects on recursive resolvers (system shocks where QPS load may go up 100% - 200% in a few minutes) Jason On 1/18/13 11:03 AM, "Livingood, Jason" wrote: >If there is anyone out there interested in doing research into DNS >recursive resolvers and are seeking either (1) access to data (stripped of >PII of course) and/or (2) modest funding support, please let me know >off-list. > >- Jason > > > >On 2/20/12 2:27 PM, "Emiliano Casalicchio" > wrote: > >>John, >>may be the model described in this paper can be useful for you. >> >> Yakup Ko=E7, Almerima Jamakovic, Bart Gijsen, "A Global Reference Model = of >>the DNS" >> >>presented at DNS-EASY 2011. >> >>Here the proceedings: >>http://www.gcsec.org/sites/default/files/files/dnseasy2011_final.pdf >> >>Best >>Emiliano >> >> >> >> >>On 18 Feb 2012, at 02:57, John Levine wrote: >> >>> Are there any models of DNS cache behavior, either analytic or >>> simulations? What I have in mind is something that would help me see >>> whether I should partition a cache among various kinds of traffic, or >>> perhaps limit max TTLs, or experiment with replacement strategies. >>>=20 >>> For that matter, what's the state of DNS modelling in general? >>>=20 >>> I found a paper by Jung et al from 2003 on cache models which starts >>> by asserting that caches are so big that entries only drop out due to >>> TTL expiry, did a lot of analysis and simulation, and concluded that >>> 15 minute TTLs got nearly the same cache benefit of 24 hr TTL. >>>=20 >>> A 2010 paper by Alexiou et al. models the Kaminsky DNS poisoning >>> attack and the port randomizing fix, which is interesting but not what >>> I'm looking for. (They conclude that the attack is real, and the fix >>> works OK.) >>>=20 >>> Anything else I should be looking at? >>>=20 >>>=20 >>> --=20 >>> Regards, >>> John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for >>>Dummies", >>> Please consider the environment before reading this e-mail. >>>http://jl.ly >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>>=20 >> >>_______________________________________________ >>DNSOP mailing list >>DNSOP@ietf.org >>https://www.ietf.org/mailman/listinfo/dnsop > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop From dgq2011@gmail.com Sun Jan 20 16:59:56 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097B021F83EF for ; Sun, 20 Jan 2013 16:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRqlNZ6YoY+9 for ; Sun, 20 Jan 2013 16:59:54 -0800 (PST) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6132621F8414 for ; Sun, 20 Jan 2013 16:59:49 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id rp2so2999944pbb.29 for ; Sun, 20 Jan 2013 16:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:subject:references:x-priority:x-has-attach :x-mailer:mime-version:message-id:content-type; bh=DtnYM5za10YmVn+ipcoJtwTPuc3br5WSY7fwS0JXA00=; b=wTTBISQSoxA32JCPTNoCqFYWn1E2iw7fk72bVx7GEKKpIJlf1WEZD3oaL1L6UouRES VRWXxu/XUNIdnXUUZMOKwmYvtC5BET/hThQI8L2DbGZTAZAtWeuPcRWadI7gaW4hsqXv 50tGobPSsUzdlPNFLzERYLV1U6uxM/QwrJFhgfuVCWOyoWAap+Lp+Nu6aVxkWVg139FG RT7UWq1QJtrwxFv3CMV2ptnNb+HTrt+t2s5+42de2iYL+Xg/LCDypYG4qC0ZVa3EcOmZ 4/7SpsjrfTpEA/ccTw6pVCXjMJ3WQT7DsRqaQfJZAYbS5mk3etnJxDnYcb/ySZ+Pq9qf /OWg== X-Received: by 10.68.130.170 with SMTP id of10mr25406880pbb.131.1358729988916; Sun, 20 Jan 2013 16:59:48 -0800 (PST) Received: from user-THINK ([218.241.103.7]) by mx.google.com with ESMTPS id pl10sm7568232pbc.60.2013.01.20.16.59.45 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 20 Jan 2013 16:59:47 -0800 (PST) Date: Mon, 21 Jan 2013 08:59:43 +0800 From: "Guangqing Deng" To: dnsop References: <10229F86C86EB444898E629583FD41714EEAB5DA@PACDCEXMB06.cable.comcast.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[cn] Mime-Version: 1.0 Message-ID: <201301210859412006432@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart512176832415_=----" Subject: Re: [DNSOP] Models of DNS cache behavior? X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 00:59:56 -0000 This is a multi-part message in MIME format. ------=_001_NextPart512176832415_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VjaCB0b3BpYyAobmFtZWx5IG1vZGVsaW5nIEROUyBjYWNoZSBiZWhhdmlvcikgc291bmRzIGlu dGVyZXN0aW5nIGFuZCBJ4oCZZCBsaWtlIHRvIGhhdmUgYSB0cnkuIEJ5IHRoZSB3YXksIGlzIHRo aXMgdG9waWMgY2FyZWQgYWJvdXQgYnkgdGhpcyB3b3JrIGdyb3VwPyANCg0KDQoNCg0KR3Vhbmdx aW5nIERlbmcNCg0KRnJvbTogTGl2aW5nb29kLCBKYXNvbg0KRGF0ZTogMjAxMy0wMS0xOSAwMDow Nw0KVG86IEVtaWxpYW5vIENhc2FsaWNjaGlvOyBKb2huIExldmluZTsgZG5zb3BAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbRE5TT1BdIE1vZGVscyBvZiBETlMgY2FjaGUgYmVoYXZpb3I/DQpPaCwg YW5kIHNvbWUgaW50ZXJlc3RpbmcgcXVlc3Rpb25zIG1heSBpbmNsdWRlIGEgc3R1ZHkgb2Y6DQot IEhvdyBhcmUgVFRMcyBjaGFuZ2luZyBvdmVyIHRpbWUgbm93IHRoYXQgc28gbXVjaCBjb250ZW50 IGlzIG1vdmluZyB0bw0KQ0ROcw0KLSBXaGF0IGFyZSB0aGUgcmVjdXJzaXZlIHJlc29sdmVyIGVm ZmVjdHMgZHVlIHRvIG1vcmUgaHlwZXItZ2lhbnRzIGFuZCBDRE5zDQotIFN0dWR5IG9mIGxhcmdl IHNjYWxlIGF1dGggZmFpbHVyZXMgaW4gQ0ROL2NvbnRlbnQgcHJvdmlkZXJzIGFuZCB0aGUNCnJl c3VsdGluZyBlZmZlY3RzIG9uIHJlY3Vyc2l2ZSByZXNvbHZlcnMgKHN5c3RlbSBzaG9ja3Mgd2hl cmUgUVBTIGxvYWQgbWF5DQpnbyB1cCAxMDAlIC0gMjAwJSBpbiBhIGZldyBtaW51dGVzKQ0KDQpK YXNvbg0KDQoNCg0KT24gMS8xOC8xMyAxMTowMyBBTSwgIkxpdmluZ29vZCwgSmFzb24iDQo8SmFz b25fTGl2aW5nb29kQGNhYmxlLmNvbWNhc3QuY29tPiB3cm90ZToNCg0KPklmIHRoZXJlIGlzIGFu eW9uZSBvdXQgdGhlcmUgaW50ZXJlc3RlZCBpbiBkb2luZyByZXNlYXJjaCBpbnRvIEROUw0KPnJl Y3Vyc2l2ZSByZXNvbHZlcnMgYW5kIGFyZSBzZWVraW5nIGVpdGhlciAoMSkgYWNjZXNzIHRvIGRh dGEgKHN0cmlwcGVkIG9mDQo+UElJIG9mIGNvdXJzZSkgYW5kL29yICgyKSBtb2Rlc3QgZnVuZGlu ZyBzdXBwb3J0LCBwbGVhc2UgbGV0IG1lIGtub3cNCj5vZmYtbGlzdC4NCj4NCj4tIEphc29uDQo+ DQo+DQo+DQo+T24gMi8yMC8xMiAyOjI3IFBNLCAiRW1pbGlhbm8gQ2FzYWxpY2NoaW8iDQo+PGVt aWxpYW5vLmNhc2FsaWNjaGlvQHVuaXJvbWEyLml0PiB3cm90ZToNCj4NCj4+Sm9obiwNCj4+bWF5 IGJlIHRoZSBtb2RlbCBkZXNjcmliZWQgaW4gdGhpcyBwYXBlciBjYW4gYmUgdXNlZnVsIGZvciB5 b3UuDQo+Pg0KPj4gWWFrdXAgS2/DpywgQWxtZXJpbWEgSmFtYWtvdmljLCBCYXJ0IEdpanNlbiwg IkEgR2xvYmFsIFJlZmVyZW5jZSBNb2RlbCBvZg0KPj50aGUgRE5TIg0KPj4NCj4+cHJlc2VudGVk IGF0IEROUy1FQVNZIDIwMTEuDQo+Pg0KPj5IZXJlIHRoZSBwcm9jZWVkaW5nczoNCj4+aHR0cDov L3d3dy5nY3NlYy5vcmcvc2l0ZXMvZGVmYXVsdC9maWxlcy9maWxlcy9kbnNlYXN5MjAxMV9maW5h bC5wZGYNCj4+DQo+PkJlc3QNCj4+RW1pbGlhbm8NCj4+DQo+Pg0KPj4NCj4+DQo+Pk9uIDE4IEZl YiAyMDEyLCBhdCAwMjo1NywgSm9obiBMZXZpbmUgd3JvdGU6DQo+Pg0KPj4+IEFyZSB0aGVyZSBh bnkgbW9kZWxzIG9mIEROUyBjYWNoZSBiZWhhdmlvciwgZWl0aGVyIGFuYWx5dGljIG9yDQo+Pj4g c2ltdWxhdGlvbnM/ICBXaGF0IEkgaGF2ZSBpbiBtaW5kIGlzIHNvbWV0aGluZyB0aGF0IHdvdWxk IGhlbHAgbWUgc2VlDQo+Pj4gd2hldGhlciBJIHNob3VsZCBwYXJ0aXRpb24gYSBjYWNoZSBhbW9u ZyB2YXJpb3VzIGtpbmRzIG9mIHRyYWZmaWMsIG9yDQo+Pj4gcGVyaGFwcyBsaW1pdCBtYXggVFRM cywgb3IgZXhwZXJpbWVudCB3aXRoIHJlcGxhY2VtZW50IHN0cmF0ZWdpZXMuDQo+Pj4gDQo+Pj4g Rm9yIHRoYXQgbWF0dGVyLCB3aGF0J3MgdGhlIHN0YXRlIG9mIEROUyBtb2RlbGxpbmcgaW4gZ2Vu ZXJhbD8NCj4+PiANCj4+PiBJIGZvdW5kIGEgcGFwZXIgYnkgSnVuZyBldCBhbCBmcm9tIDIwMDMg b24gY2FjaGUgbW9kZWxzIHdoaWNoIHN0YXJ0cw0KPj4+IGJ5IGFzc2VydGluZyB0aGF0IGNhY2hl cyBhcmUgc28gYmlnIHRoYXQgZW50cmllcyBvbmx5IGRyb3Agb3V0IGR1ZSB0bw0KPj4+IFRUTCBl eHBpcnksIGRpZCBhIGxvdCBvZiBhbmFseXNpcyBhbmQgc2ltdWxhdGlvbiwgYW5kIGNvbmNsdWRl ZCB0aGF0DQo+Pj4gMTUgbWludXRlIFRUTHMgZ290IG5lYXJseSB0aGUgc2FtZSBjYWNoZSBiZW5l Zml0IG9mIDI0IGhyIFRUTC4NCj4+PiANCj4+PiBBIDIwMTAgcGFwZXIgYnkgQWxleGlvdSBldCBh bC4gIG1vZGVscyB0aGUgS2FtaW5za3kgRE5TIHBvaXNvbmluZw0KPj4+IGF0dGFjayBhbmQgdGhl IHBvcnQgcmFuZG9taXppbmcgZml4LCB3aGljaCBpcyBpbnRlcmVzdGluZyBidXQgbm90IHdoYXQN Cj4+PiBJJ20gbG9va2luZyBmb3IuICAoVGhleSBjb25jbHVkZSB0aGF0IHRoZSBhdHRhY2sgaXMg cmVhbCwgYW5kIHRoZSBmaXgNCj4+PiB3b3JrcyBPSy4pDQo+Pj4gDQo+Pj4gQW55dGhpbmcgZWxz ZSBJIHNob3VsZCBiZSBsb29raW5nIGF0Pw0KPj4+IA0KPj4+IA0KPj4+IC0tIA0KPj4+IFJlZ2Fy ZHMsDQo+Pj4gSm9obiBMZXZpbmUsIGpvaG5sQGllY2MuY29tLCBQcmltYXJ5IFBlcnBldHJhdG9y IG9mICJUaGUgSW50ZXJuZXQgZm9yDQo+Pj5EdW1taWVzIiwNCj4+PiBQbGVhc2UgY29uc2lkZXIg dGhlIGVudmlyb25tZW50IGJlZm9yZSByZWFkaW5nIHRoaXMgZS1tYWlsLg0KPj4+aHR0cDovL2ps Lmx5DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+PiBETlNPUCBtYWlsaW5nIGxpc3QNCj4+PiBETlNPUEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zb3ANCj4+PiANCj4+DQo+Pl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PkROU09QIG1haWxpbmcg bGlzdA0KPj5ETlNPUEBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Ruc29wDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj5ETlNPUCBtYWlsaW5nIGxpc3QNCj5ETlNPUEBpZXRmLm9yZw0KPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zb3ANCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkROU09QIG1haWxpbmcgbGlzdA0KRE5TT1BA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zb3A= ------=_001_NextPart512176832415_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Such topic (namely modeling DNS cache b= ehavior) sounds interesting and I=E2=80=99d like&= nbsp;to have a try. By the way, is = ;this topic cared about by this work gr= oup?=20
 
Guangqing Deng
 
From: Livingood, Jason
Date: 2013-01-19 00:07
Subject: Re: [DNSOP] Models of DNS cache=20 behavior?
Oh, and some interesting questions may = include a study of:
- How are TTLs changing over time = now that so much content is moving to
CDNs
- What are the recursive resolver effec= ts due to more hyper-giants and CDNs
- Study of large scale auth failures&nb= sp;in CDN/content providers and the
resulting effects on recursive resolvers (sy= stem shocks where QPS load may
go up 100% - 200% in a few mi= nutes)
 
Jason
 
 
 
On 1/18/13 11:03 AM, "Livingood, Jason"
<Jason_Livingood@cable.comcast.com> wrote:
 
>If there is anyone out there intere= sted in doing research into DNS
>recursive resolvers and are seeking eith= er (1) access to data (stripped of
>PII of course) and/or (2) modest fu= nding support, please let me know
>off-list.
>
>- Jason
>
>
>
>On 2/20/12 2:27 PM, "Emiliano Casalicchi= o"
><emiliano.casalicchio@uniroma2.it> wrote:
>
>>John,
>>may be the model described in t= his paper can be useful for you.
>>
>>=20 Yakup Ko=C3=A7, Almerima Jamakovic, Bart Gijsen,&= nbsp;"A Global Reference Model of
>>the DNS"
>>
>>presented at DNS-EASY 2011.
>>
>>Here the proceedings:
>>http://www.gcsec.org/sites/default/files/files/dnseasy2011_fi= nal.pdf
>>
>>Best
>>Emiliano
>>
>>
>>
>>
>>On 18 Feb 2012, at 02:57, John&= nbsp;Levine wrote:
>>
>>> Are there any models of DN= S cache behavior, either analytic or
>>> simulations?  What I have = in mind is something that would help me=  see
>>> whether I should partition a&nb= sp;cache among various kinds of traffic, or<= /DIV>
>>> perhaps limit max TTLs, or = ;experiment with replacement strategies.
>>> 
>>> For that matter, what's the&nbs= p;state of DNS modelling in general?
>>> 
>>> I found a paper by Jung&nb= sp;et al from 2003 on cache models whic= h starts
>>> by asserting that caches are&nb= sp;so big that entries only drop out du= e to
>>> TTL expiry, did a lot of&n= bsp;analysis and simulation, and concluded that
>>> 15 minute TTLs got nearly = the same cache benefit of 24 hr TTL.
>>> 
>>> A 2010 paper by Alexiou et=  al.  models the Kaminsky DNS poisoning=
>>> attack and the port randomizing=  fix, which is interesting but not what=
>>> I'm looking for.  (They co= nclude that the attack is real, and the=  fix
>>> works OK.)
>>> 
>>> Anything else I should be = looking at?
>>> 
>>> 
>>> -- 
>>> Regards,
>>> John Levine, johnl@iecc.com, Primary=  Perpetrator of "The Internet for
>>>Dummies",
>>> Please consider the environment = ;before reading this e-mail.
>>>http://jl.ly
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>> 
>>
>>_______________________________________________
>>DNSOP mailing list
>>DNSOP@ietf.org
>>https://www.ietf.org/mailman/listinfo/dnsop
>
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop
 
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
------=_001_NextPart512176832415_=------ From bortzmeyer@nic.fr Mon Jan 21 03:03:23 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB0421F84F3 for ; Mon, 21 Jan 2013 03:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.76 X-Spam-Level: X-Spam-Status: No, score=-100.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srh48EJQUBOq for ; Mon, 21 Jan 2013 03:03:22 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id 101E721F84DC for ; Mon, 21 Jan 2013 03:03:22 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 891062804B3 for ; Mon, 21 Jan 2013 12:02:50 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 85AA628048A for ; Mon, 21 Jan 2013 12:02:50 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay1.nic.fr (Postfix) with ESMTP id 7A1B34C00A6 for ; Mon, 21 Jan 2013 12:02:20 +0100 (CET) Date: Mon, 21 Jan 2013 12:02:20 +0100 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20130121110220.GA25497@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 7.0 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [DNSOP] Data format for DNS looking glasses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 11:03:23 -0000 I already mentioned this service here, but it is now officially in production: http://www.bortzmeyer.org/dns-lg.html What is of special interest for this WG is that the XML output format relies on two (expired) Internet-Drafts. The JSON format, on the other hand, is completely non-standard. An interesting work item? From paul.hoffman@vpnc.org Mon Jan 21 07:37:48 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106DD21F8712 for ; Mon, 21 Jan 2013 07:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC+WekaPDtuk for ; Mon, 21 Jan 2013 07:37:47 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE4021F86F4 for ; Mon, 21 Jan 2013 07:37:47 -0800 (PST) Received: from [10.20.30.101] (50-1-51-83.dsl.dynamic.fusionbroadband.com [50.1.51.83]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r0LFbhv3023589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Jan 2013 08:37:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <20130121110220.GA25497@nic.fr> Date: Mon, 21 Jan 2013 07:37:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130121110220.GA25497@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1499) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Data format for DNS looking glasses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 15:37:48 -0000 On Jan 21, 2013, at 3:02 AM, Stephane Bortzmeyer = wrote: > I already mentioned this service here, but it is now officially in > production: >=20 > http://www.bortzmeyer.org/dns-lg.html >=20 > What is of special interest for this WG is that the XML output format > relies on two (expired) Internet-Drafts. The JSON format, on the other > hand, is completely non-standard. An interesting work item? I would work on this. Having lots of looking glasses with a standard = output format would be useful to the Internet. --Paul Hoffman= From jason_livingood@cable.comcast.com Mon Jan 21 11:43:05 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBC321F856D for ; Mon, 21 Jan 2013 11:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.897 X-Spam-Level: X-Spam-Status: No, score=-100.897 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSiKwSXezQDf for ; Mon, 21 Jan 2013 11:43:04 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9F81E21F852C for ; Mon, 21 Jan 2013 11:43:04 -0800 (PST) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.40926016; Mon, 21 Jan 2013 14:31:58 -0500 Received: from PACDCEXMB06.cable.comcast.com ([169.254.8.96]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Mon, 21 Jan 2013 14:43:01 -0500 From: "Livingood, Jason" To: Paul Hoffman , Stephane Bortzmeyer Thread-Topic: [DNSOP] Data format for DNS looking glasses Thread-Index: AQHN98b+uQx3TLsi00azcCIvb0438JhUPsQA///wtwA= Date: Mon, 21 Jan 2013 19:43:00 +0000 Message-ID: <10229F86C86EB444898E629583FD41714EEB5691@PACDCEXMB06.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsop@ietf.org" Subject: Re: [DNSOP] Data format for DNS looking glasses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 19:43:05 -0000 Seems a really interesting idea. Jason On 1/21/13 10:37 AM, "Paul Hoffman" wrote: >On Jan 21, 2013, at 3:02 AM, Stephane Bortzmeyer >wrote: > >> I already mentioned this service here, but it is now officially in >> production: >>=20 >> http://www.bortzmeyer.org/dns-lg.html >>=20 >> What is of special interest for this WG is that the XML output format >> relies on two (expired) Internet-Drafts. The JSON format, on the other >> hand, is completely non-standard. An interesting work item? > >I would work on this. Having lots of looking glasses with a standard >output format would be useful to the Internet. > >--Paul Hoffman >_______________________________________________ >DNSOP mailing list >DNSOP@ietf.org >https://www.ietf.org/mailman/listinfo/dnsop From andreas.papst@univie.ac.at Tue Jan 22 00:37:42 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CE421F85C6 for ; Tue, 22 Jan 2013 00:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XL93LZOHrmbC for ; Tue, 22 Jan 2013 00:37:41 -0800 (PST) Received: from grace.univie.ac.at (grace.univie.ac.at [IPv6:2001:62a:4:25::25:115]) by ietfa.amsl.com (Postfix) with ESMTP id 3F34D21F8421 for ; Tue, 22 Jan 2013 00:37:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=univie.ac.at; s=rev2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=8t7UsPU+CC3liVyTvkmEo9zyN98UBvulj0LXXPp68d8=; b=oofXAwvnUYXY06p0fqCXWrVz9AuFUb9UhKJnLR+7ajEvyu8aZ4rk/ef6swHf0rDdI/lMo4AXgNatbL7Hxrzt/U++8cVYOTqUqCvnPiHWsjRMKpgXedRKDf8vIjUReQQS6mYFz8CZ9l2KV99tCnF383PEnBHjXLaUw0gnWMSSeHM=; Received: from joan.univie.ac.at ([131.130.3.110] helo=joan.univie.ac.at) by grace.univie.ac.at with esmtp (Exim 4.80) (envelope-from ) id 1TxZMQ-0002ff-0N for dnsop@ietf.org; Tue, 22 Jan 2013 09:37:38 +0100 Received: from wsap.cc.univie.ac.at ([131.130.249.17] helo=[10.0.2.15]) by joan.univie.ac.at with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1TxZMP-00030t-Rw; Tue, 22 Jan 2013 09:37:37 +0100 Message-ID: <50FE4FD1.6050302@univie.ac.at> Date: Tue, 22 Jan 2013 09:37:37 +0100 From: Andreas Papst User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130105 Thunderbird/17.0.2 MIME-Version: 1.0 To: dnsop@ietf.org References: <20130121110220.GA25497@nic.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Univie-Virus-Scan: scanned by ClamAV on joan.univie.ac.at Subject: Re: [DNSOP] Data format for DNS looking glasses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 08:37:42 -0000 I'm not sure if it is a good idea to deploy open recursive resolvers around the world again after having pushed so many people to close theirs. At least we should consider some reasonable precautions. A 2nd demur: what is the difference to RIPE Atlas? Ok it is not for free at the moment but maybe we can urge RIPE to offer a public service without charge. Andreas Papst On 01/21/2013 04:37 PM, Paul Hoffman wrote: > On Jan 21, 2013, at 3:02 AM, Stephane Bortzmeyer wrote: > >> I already mentioned this service here, but it is now officially in >> production: >> >> http://www.bortzmeyer.org/dns-lg.html >> >> What is of special interest for this WG is that the XML output format >> relies on two (expired) Internet-Drafts. The JSON format, on the other >> hand, is completely non-standard. An interesting work item? > > I would work on this. Having lots of looking glasses with a standard output format would be useful to the Internet. > > --Paul Hoffman > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > From paul.hoffman@vpnc.org Tue Jan 22 07:38:17 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE36321F8A0D for ; Tue, 22 Jan 2013 07:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1aZDxtDPQbQ for ; Tue, 22 Jan 2013 07:38:17 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F045521F85B2 for ; Tue, 22 Jan 2013 07:38:16 -0800 (PST) Received: from [10.20.30.101] (50-1-51-83.dsl.dynamic.fusionbroadband.com [50.1.51.83]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r0MFcA9Q081064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Jan 2013 08:38:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <50FE4FD1.6050302@univie.ac.at> Date: Tue, 22 Jan 2013 07:38:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6CCF28C7-13C8-40E3-A32A-975AB86A2D71@vpnc.org> References: <20130121110220.GA25497@nic.fr> <50FE4FD1.6050302@univie.ac.at> To: Andreas Papst X-Mailer: Apple Mail (2.1499) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Data format for DNS looking glasses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 15:38:17 -0000 On Jan 22, 2013, at 12:37 AM, Andreas Papst = wrote: > I'm not sure if it is a good idea to deploy open recursive > resolvers around the world again after having pushed so many people > to close theirs. At least we should consider some reasonable > precautions. An attacker has a huge overhead to using this service versus just = sending the queries directly. What would be the advantage of the = attacker to do so? > A 2nd demur: what is the difference to RIPE Atlas? > Ok it is not for free at the moment but maybe we can urge RIPE to > offer a public service without charge. The RIPE Atlas is focused on the RIPE service area, and is not focused = on DNS. --Paul Hoffman From bortzmeyer@nic.fr Tue Jan 22 08:10:03 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AD621F8ABD for ; Tue, 22 Jan 2013 08:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.505 X-Spam-Level: X-Spam-Status: No, score=-101.505 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_FR=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfhRKo4wZ5lv for ; Tue, 22 Jan 2013 08:10:03 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [192.134.4.12]) by ietfa.amsl.com (Postfix) with ESMTP id DAB7721F8951 for ; Tue, 22 Jan 2013 08:10:02 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 485532802D8; Tue, 22 Jan 2013 17:09:29 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 43B8C2802D6; Tue, 22 Jan 2013 17:09:29 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:2219:8::6:69]) by relay1.nic.fr (Postfix) with ESMTP id 4271A4C0081; Tue, 22 Jan 2013 17:08:59 +0100 (CET) Date: Tue, 22 Jan 2013 17:08:59 +0100 From: Stephane Bortzmeyer To: Andreas Papst Message-ID: <20130122160859.GA14535@nic.fr> References: <20130121110220.GA25497@nic.fr> <50FE4FD1.6050302@univie.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50FE4FD1.6050302@univie.ac.at> X-Operating-System: Debian GNU/Linux 7.0 X-Kernel: Linux 3.2.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dnsop@ietf.org Subject: Re: [DNSOP] Data format for DNS looking glasses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:10:03 -0000 On Tue, Jan 22, 2013 at 09:37:37AM +0100, Andreas Papst wrote a message of 36 lines which said: > I'm not sure if it is a good idea to deploy open recursive resolvers They are not open recursive DNS servers. Read the article > around the world again after having pushed so many people to close > theirs. ??? RFC 5358 was about DNS, not HTTP. It was about attacks using a spoofed IP address, something which is easy with UDP and very hard with TCP. I really do not see the problem. > At least we should consider some reasonable precautions. There is rate-limiting, as explicitely mentioned in the article. > A 2nd demur: what is the difference to RIPE Atlas? 1) Atlas is not publically open. 2) Atlas cannot be queried with a simple REST URL (there is no API yet) 3) Atlas does not parse the DNS responses for you, you get back a blob of wire-format DNS and you have to parse it. From dwessels@verisign.com Tue Jan 22 11:23:56 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B2F21F8A8E for ; Tue, 22 Jan 2013 11:23:56 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuCLAZzyA6Ps for ; Tue, 22 Jan 2013 11:23:55 -0800 (PST) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id D75D721F84F2 for ; Tue, 22 Jan 2013 11:23:52 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUP7nSAL+G0dXrwUi5rpFubkZ/H+zZjIw@postini.com; Tue, 22 Jan 2013 11:23:54 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r0MJNlxp022764; Tue, 22 Jan 2013 14:23:49 -0500 Received: from mail.labs.vrsn.com ([10.173.152.121]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jan 2013 14:23:37 -0500 Received: from [10.100.0.23] (unknown [10.100.0.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.labs.vrsn.com (Postfix) with ESMTP id 5A0021BC8B9; Tue, 22 Jan 2013 14:23:46 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: "Wessels, Duane" In-Reply-To: Date: Tue, 22 Jan 2013 11:23:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <221583F4-7E8D-4B24-A6D2-3BFA9AEEA184@verisign.com> References: <20130121110220.GA25497@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1283) X-OriginalArrivalTime: 22 Jan 2013 19:23:37.0486 (UTC) FILETIME=[FA4FAAE0:01CDF8D5] Cc: dnsop@ietf.org Subject: Re: [DNSOP] Data format for DNS looking glasses X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 19:23:56 -0000 On Jan 21, 2013, at 7:37 AM, Paul Hoffman wrote: > On Jan 21, 2013, at 3:02 AM, Stephane Bortzmeyer = wrote: >=20 >> I already mentioned this service here, but it is now officially in >> production: >>=20 >> http://www.bortzmeyer.org/dns-lg.html >>=20 >> What is of special interest for this WG is that the XML output format >> relies on two (expired) Internet-Drafts. The JSON format, on the = other >> hand, is completely non-standard. An interesting work item? >=20 > I would work on this. Having lots of looking glasses with a standard = output format would be useful to the Internet. I like this idea as well and am willing to work on it. DW= From patrik@frobbit.se Fri Jan 25 07:41:11 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5BF21F87B1 for ; Fri, 25 Jan 2013 07:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oia74spxJ3wQ for ; Fri, 25 Jan 2013 07:41:11 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5B321F87AD for ; Fri, 25 Jan 2013 07:41:11 -0800 (PST) Received: from [IPv6:2a02:80:3ffc::12] (unknown [IPv6:2a02:80:3ffc::12]) by mail.frobbit.se (Postfix) with ESMTPA id B2C96218A7; Fri, 25 Jan 2013 16:41:10 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <5102A4F8.50503@sidn.nl> Date: Fri, 25 Jan 2013 16:41:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <81907D77-B149-4C5D-A1D7-5441886D5C9A@frobbit.se> References: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> <5100EF14.4080203@sidn.nl> <51028CD5.6070407@sidn.nl> <9FA56598-181E-4686-B6E6-E3858C1E4A75@frobbit.se> <5102A4F8.50503@sidn.nl> To: Antoin Verschuren X-Mailer: Apple Mail (2.1499) Cc: IETF DNSOP WG Subject: Re: [DNSOP] [provreg] New Version Notification for draft-gieben-epp-keyrelay-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 15:41:11 -0000 Discussion moved from provreg mailing list to dnsop mailing list. The items discussed originally was draft-gieben-epp-keyrelay-00.txt but = we now agree it is draft-koch-dnsop-dnssec-operator-change-04 we are = discussing. And, it is me thinking we complicate things too much. I am asking questions like a devils advocate so that Antoin (and Peter) = convince me things must be this complicated. I made the claim that with double DS, both for old and new zone, we do = not have to move the ZSK from old to new zone. Antoin say I am wrong (which I absolutely do believe I can be), but I = want to understand. Antoin then wrote: > The problem is that a cache may have cached the DNSKEY RRset from the > old zone, and while that is still valid the NS RRset changes at the > parent and the resolver recieves a new NS (or other) RRset from the > new child zone with a new signature from the new ZSK that is not > present in the cached DNSKEY RRset thus failing validation. This can > only be solved if both DNSKEY RRsets contain both ZSK's from the new > and old child zone. Same as you would do with a pre-publish ZSK = rollover. So, what we talk about is the case when different RRSets in the same = zone are cached differently. Right? > Transferring and keeping the old zone data on the new nameserver does > not help, because at some point in time, at least the NS RRset needs > to change and a new signature needs to be generated over it by a new > ZSK that is not present in the DNSKEY RRset. A signature with the old > ZSK over this new NS RRset cannot be generated because the old private > ZSK is not available for signing by the new operator. Patrik From Antoin.Verschuren@sidn.nl Fri Jan 25 08:00:53 2013 Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9E421F869A for ; Fri, 25 Jan 2013 08:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.354 X-Spam-Level: X-Spam-Status: No, score=-4.354 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSgQk3rO01wo for ; Fri, 25 Jan 2013 08:00:52 -0800 (PST) Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [94.198.152.69]) by ietfa.amsl.com (Postfix) with ESMTP id 228F121F8614 for ; Fri, 25 Jan 2013 08:00:50 -0800 (PST) Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl with ESMTP id r0PG0mFs000487-r0PG0mFu000487 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Fri, 25 Jan 2013 17:00:48 +0100 Received: from KAHUBCAS1.SIDN.local (192.168.2.41) by kahubcasn01.SIDN.local (192.168.2.73) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 25 Jan 2013 17:00:48 +0100 Received: from [94.198.152.218] (94.198.152.218) by KAHUBCAS1.SIDN.local (192.168.2.41) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 25 Jan 2013 17:00:48 +0100 Message-ID: <5102AC2F.70403@sidn.nl> Date: Fri, 25 Jan 2013 17:00:47 +0100 From: Antoin Verschuren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= References: <20130120130151.24781.51801.idtracker@ietfa.amsl.com> <5100EF14.4080203@sidn.nl> <51028CD5.6070407@sidn.nl> <9FA56598-181E-4686-B6E6-E3858C1E4A75@frobbit.se> <5102A4F8.50503@sidn.nl> <81907D77-B149-4C5D-A1D7-5441886D5C9A@frobbit.se> In-Reply-To: <81907D77-B149-4C5D-A1D7-5441886D5C9A@frobbit.se> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [94.198.152.218] Cc: IETF DNSOP WG Subject: Re: [DNSOP] [provreg] New Version Notification for draft-gieben-epp-keyrelay-00.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 16:00:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 25-01-13 16:41, Patrik F￤ltstr￶m schreef: > I made the claim that with double DS, both for old and new zone, we > do not have to move the ZSK from old to new zone. You make the same mistake again :-) It has to move -from new- -to old- zone to be pre-published. - From old to new is not an issue. We can use DNS for that. > So, what we talk about is the case when different RRSets in the > same zone are cached differently. Right? Yes, some records may be cached from the old zone, some from the new zone, and neither zone can create signatures over those records with the ZSK of the other, so a double signature is impossible. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschuren@sidn.nl XMPP: antoin.verschuren@jabber.sidn.nl HTTP://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRAqwvAAoJEDqHrM883AgnYM4H/1kT889bM15Ga5DySRTXX/n0 hlqLWJKIS7a4FaNiwP8qg0VeMPbB7HSxm9Kap01emyQwrz2FzAks4IChY6DOgPMs 2flmT9gLh9uvhudhrvNyUBDLypQmBb9jCfb1As0DteugDFI4YkZnKw118Ny+6PvW vvd4XseuxWv3iPH0mssu7hWrEVqfcYQb0j5v89s+njti1oN6Tw2s/dpAndDJh1Vf dYEaRKMOxtlNQ4VHEDtK7mA2IbjX7daYgpHs1jUqzGYkPOhgYA8lFUw2HxDFTiJ7 x8NbJLWayXhSSZlnkuB56EKduYmaOHs6juY/JjYJ4ySXe44Wb5J7m4vbB4Bk9cY= =FcdN -----END PGP SIGNATURE-----