From owner-dnsop@cafax.se Sun Jun 15 14:20:45 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06684 for ; Sun, 15 Jun 2003 14:20:44 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5FHqRmb003643 for ; Sun, 15 Jun 2003 19:52:27 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5FHqRWX003642 for dnsop-outgoing; Sun, 15 Jun 2003 19:52:27 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5FHqPmb003637 for ; Sun, 15 Jun 2003 19:52:26 +0200 (MEST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 4B41C18EC; Sun, 15 Jun 2003 13:52:24 -0400 (EDT) Date: Sun, 15 Jun 2003 13:52:24 -0400 From: Rob Austein To: dnsop@cafax.se Subject: DNSOP minutes from IETF 56 References: <200303200004.h2K048km006816@sith.maoz.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030615175224.4B41C18EC@thrintun.hactrn.net> Sender: owner-dnsop@cafax.se Precedence: bulk It looks like the DNSOP minutes from IETF 56 were sent to the list but never arrived (sigh), so here they are (again). ======== Domain Name System Operations (DNSOP) Chairs: Dave Meyer and Rob Austein Minutes: Sean McCreary (with minor edits by by chairs) Dave introduced himself and Rob Austein, the new DNSOP chairs. Dave presented the agenda. Agenda very tight due to short meeting slot. Sean McCreary kindly volunteered to take notes. ======== Alain Durand presented draft-ietf-dnsop-ipv6-dns-issues-02.txt "IPv6 DNS transition issues" Rob Austein: Draft discusses two issues Dual stacking (we had consensus on coexistence plan in previous mtgs); Stuff about the reverse tree. Would it be useful to split these two into separate drafts? Rob asked for a hum. Clear consensus was for a split. Alain asked for ISPs to send comments to the mailing list. ======== Randy Bush presented DNS issues for 6to4 draft-moore-6to4-dns-03.txt 6to4 delegations should come from same place as IPv4 reverse delegations What if upstream refuses to deal w/v6? Then go up the tree towards the root until you reach someone who cares. This will force the registries to do direct delegations to end sites. draft-ymbk-6to-4-arpa-delegation-00.txt Alain Durand: What about delegations for dynamically allocated addresses? Randy "Let's not create problems for a simple hack that works." Dave called for a hum. No consensus in room for adopting these drafts as working group documents. Discussion to continue on mailing list. ================ Matt Larson asked if draft-ietf-dnsop-bad-dns-res-00.txt should be resubmitted, as it has expired. Rob: It should be if people are willing to work on it, and asked for a hum. Appeared to be consensus to continue work on this document. Matt will resubmit it. ============== Akira Kato presented draft-kato-dnsop-local-zones-00.txt, "Operational Guidelines For `Local' DNS Zones". The pseudo-TLDs ".local" and ".localhost" are generating significant load on the root servers. Rob Austein asked if Apple's "Rendezvous" uses port 53. Stuart Cheshire said rendezvous uses port 5353 for queries. Geoff Huston asked whether the proposal to "delegate" .local to AS112 servers means creating a new TLD. Paul Vixie: We propose to add a top level domain, but a useless one that always returns NXDOMAIN. The only purpose is to reduce the load on the root servers. Stuart: This can be solved in the resolver by filtering queries to the .local pseudo-TLD, or by changing the root infrastructure. Topic too new and complex for immediate hum on whether WG should take this on. Discussion to continue on mailing list. ============== Paul Vixie spoke on a proto-draft he had posted to the mailing list on size issues in DNS response messages. Paul's analysis suggests that the naming scheme used by the name servers for the root zone (x.root-servers.net) saves a lot of space in response packets, which increases the number of name name servers that can be listed for a zone. Paul suggests that we should encourage others to adopt this scheme. If the IDN effort increases the size of the A record, reducing the number that will fit in a response packet. How many A records are too few? Is only one too few? If one is an acceptable number, what kind of engineering changes can be made so that the A record returned is useful to the client. If this is relevant to the working group, we should adopt it and advance it as soon as possible. Discussion taken to mailing list. ======================== Johan Ihren presented draft-ihren-dnsext-threshold-validation-00.txt A discussion of how to use DNSSEC key signing keys (KSKs) to improve reliability in case some private keys are compromised, and during key rollovers. Johan then presented draft-ietf-dnsop-interim-signed-root-01.txt This is a clarification of the earlier draft. Johan asked if threshold validation should be taken as a work item for the working group (as a general topic, not just Johan's draft). Consensus was yes. ======================= Rob asked if the working group should produce a requirements draft for Autoconf/bootstrap/dynamic update/dns discovery with IPv6 clients. Rob believes the work group should work on this. Alain Durand: Does this make more sense to work on in a working group dedicated to finding a general solution to this problem? Rob: There are DNS-specific issues that need to be identified. Stuart Cheshire: Determining DNS parameters is a major hole in current IPv6 autoconfig protocols. Bob Hinden agreed with Stuart, and added that once a scheme is defined and deployed it will be possible to to a lot more with autoconfiguration for v6 clients . Erik Nordmark: I've tried to raise interest in solving the generic problem and not succeeded. There is interest in solving the specific part of the problem for DNS. Mike Patton: DNS itself is a leveraging thing that is really needed, other complications will produce a heavyweight solution. People will want a lightweight solution anyway. Rob called for a hum. Consensus was that the working group should work on this. =========================== Alain Durand presented draft-durand-dnsop-dynreverse-00.txt He asked that this be adopted as a working group document. No consensus for or against. Rob deferred a decision until there is more discussion on the mailing list. ============================= Jae-Hoon Jeong presented draft-jeong-hmipv6-dns-optimization-00.txt A scheme for supplying DNS services in a mobile IP environment. Rob deferred adoption of the document to a mailing list discussion. ============================= draft-warnicke-network-dns-resolution-00.txt An update for RFC1101, a scheme for finding the default gateway for a client's local LAN. Rob: This is a request for review of the propsal, not a request to for the working group to adopt the document as a work item. ============================ As the previous speakers had run over, Rob and Dave deferred the charter discussion that had been on the agenda. Charter discussion will take place on the mailing list. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jun 17 03:08:01 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01532 for ; Tue, 17 Jun 2003 03:08:00 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5H6cpmb024525 for ; Tue, 17 Jun 2003 08:38:51 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5H6cpXi024524 for dnsop-outgoing; Tue, 17 Jun 2003 08:38:51 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from naptop.autonomica.net ([192.71.228.254]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5H6cpmb024518 for ; Tue, 17 Jun 2003 08:38:51 +0200 (MEST) Received: from naptop.autonomica.net (localhost [127.0.0.1]) by naptop.autonomica.net (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5H6buCO010082 for ; Tue, 17 Jun 2003 08:37:56 +0200 (MEST) Received: (from liman@localhost) by naptop.autonomica.net (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5H6bu6i010081 for dnsop@cafax.se; Tue, 17 Jun 2003 08:37:56 +0200 (MEST) Received: from sa.vix.com (sa.vix.com [204.152.187.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5FFUpmb002981 for ; Sun, 15 Jun 2003 17:30:52 +0200 (MEST) Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id BFCC51396B for ; Sun, 15 Jun 2003 15:30:49 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: dnsop@cafax.se Subject: so how about that response size draft? X-Mailer: MH-E 7.3; nmh 1.0.4; GNU Emacs 21.3.1 Date: Sun, 15 Jun 2003 15:30:49 +0000 Message-Id: <20030615153049.BFCC51396B@sa.vix.com> Sender: owner-dnsop@cafax.se Precedence: bulk akira and i both hoped that it would be adopted as a DNSOP work item but the discussion of this in san francisco was inconclusive and there has been no subsequent discussion here on the mailing list. a draft cutoff date looms. should this i-d have "-dnsop-" in its name? note that we also showed this draft to some of icann/iana's people and they were happy to see it. therefore it may have some applicability to somebody. should DNSOP "adopt" it and do the fold-spindle-mutilate thing? #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jun 17 03:54:20 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02330 for ; Tue, 17 Jun 2003 03:54:19 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5H7Oomb025085 for ; Tue, 17 Jun 2003 09:24:50 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5H7Oo9q025084 for dnsop-outgoing; Tue, 17 Jun 2003 09:24:50 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from nic.crt.se (nic.crt.se [193.12.107.10]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5H7Oomb025079 for ; Tue, 17 Jun 2003 09:24:50 +0200 (MEST) Received: from mail.crt.se (postiljon.crt.se [193.12.115.230]) by nic.crt.se (Postfix) with ESMTP id E724F3516; Tue, 17 Jun 2003 09:24:49 +0200 (MEST) Received: from crt.se (stargate-i.crt.se [193.12.115.229]) by mail.crt.se (Postfix) with ESMTP id 9857A1D99; Tue, 17 Jun 2003 09:24:49 +0200 (MEST) Date: Tue, 17 Jun 2003 09:24:49 +0200 (CEST) From: Jakob Schlyter To: Paul Vixie Cc: dnsop@cafax.se Subject: Re: so how about that response size draft? In-Reply-To: <20030615153049.BFCC51396B@sa.vix.com> Message-ID: References: <20030615153049.BFCC51396B@sa.vix.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Sun, 15 Jun 2003, Paul Vixie wrote: > akira and i both hoped that it would be adopted as a DNSOP work item > but the discussion of this in san francisco was inconclusive and there > has been no subsequent discussion here on the mailing list. > > a draft cutoff date looms. should this i-d have "-dnsop-" in its name? I think the wg should adopt this document. jakob -- Jakob Schlyter Network Analyst Phone: +46 31 701 42 13, +46 70 595 07 94 Carlstedt Research & Technology #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jun 17 03:58:38 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02515 for ; Tue, 17 Jun 2003 03:58:38 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5H7WBmb025167 for ; Tue, 17 Jun 2003 09:32:11 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5H7WB4g025166 for dnsop-outgoing; Tue, 17 Jun 2003 09:32:11 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from garlic.apnic.net (garlic.apnic.net [202.12.29.224]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5H7W8mb025161 for ; Tue, 17 Jun 2003 09:32:10 +0200 (MEST) Received: from garlic.apnic.net (localhost [127.0.0.1]) by garlic.apnic.net (8.12.9/8.12.9) with ESMTP id h5H7VxWB002214; Tue, 17 Jun 2003 17:31:59 +1000 (EST) Received: (from ggm@localhost) by garlic.apnic.net (8.12.9/8.12.9/Submit) id h5H7Vumb002448; Tue, 17 Jun 2003 17:31:56 +1000 (EST) Date: Tue, 17 Jun 2003 17:31:56 +1000 From: George Michaelson To: Jakob Schlyter Cc: dnsop@cafax.se Subject: Re: so how about that response size draft? Message-Id: <20030617173156.7c9c4edc.ggm@apnic.net> In-Reply-To: References: <20030615153049.BFCC51396B@sa.vix.com> Organization: APNIC Pty Ltd X-Mailer: Sylpheed version 0.9.0claws38 (GTK+ 1.2.10; i386-pc-netbsdelf1.6T) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > On Sun, 15 Jun 2003, Paul Vixie wrote: > akira and i both hoped that it would be adopted as a DNSOP work item > but the discussion of this in san francisco was inconclusive and there > has been no subsequent discussion here on the mailing list. > > a draft cutoff date looms. should this i-d have "-dnsop-" in its name? > I would like to see this adopted and published as a dnsop work item. -George -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jun 17 05:40:55 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04939 for ; Tue, 17 Jun 2003 05:40:54 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5H9BEmb026279 for ; Tue, 17 Jun 2003 11:11:14 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5H9BE2l026278 for dnsop-outgoing; Tue, 17 Jun 2003 11:11:14 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5H9BCmb026273 for ; Tue, 17 Jun 2003 11:11:13 +0200 (MEST) Received: from [10.0.1.4] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h5H9B9tS036473; Tue, 17 Jun 2003 05:11:10 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <20030615153049.BFCC51396B@sa.vix.com> References: <20030615153049.BFCC51396B@sa.vix.com> Date: Tue, 17 Jun 2003 10:18:09 +0200 To: Paul Vixie From: Brad Knowles Subject: Re: so how about that response size draft? Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 3:30 PM +0000 2003/06/15, Paul Vixie wrote: > akira and i both hoped that it would be adopted as a DNSOP work item > but the discussion of this in san francisco was inconclusive and there > has been no subsequent discussion here on the mailing list. > > a draft cutoff date looms. should this i-d have "-dnsop-" in its name? I have not yet seen the draft itself, and I regret that I wasn't there for the discussion. However, this is a topic that I have been very concerned about since 95-96, back when we were trying to list all 45 IP addresses for the MXes for aol.com and we were blowing the DNS UDP packet size limits on responses, and then seeing all sorts of weirdness with people being unable to reach us. Out of curiosity, does anyone remember when the root servers switched to their current naming scheme? I'm interested to know who came up with that idea first.... > note that we also showed this draft to some of icann/iana's people and > they were happy to see it. therefore it may have some applicability to > somebody. should DNSOP "adopt" it and do the fold-spindle-mutilate thing? I believe that DNSOP should adopt this draft. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jun 17 07:50:42 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08009 for ; Tue, 17 Jun 2003 07:50:41 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5HBT5mb027498 for ; Tue, 17 Jun 2003 13:29:05 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5HBT5e4027497 for dnsop-outgoing; Tue, 17 Jun 2003 13:29:05 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5HBT4mb027492 for ; Tue, 17 Jun 2003 13:29:04 +0200 (MEST) Received: from barnacle (barnacle.antd.nist.gov [129.6.55.185]) by postmark.nist.gov (8.12.5/8.12.5) with SMTP id h5HBSpbd009874 for ; Tue, 17 Jun 2003 07:28:52 -0400 (EDT) Message-ID: <00a301c334c3$a1c400f0$b9370681@barnacle> From: "Scott Rose" To: References: <20030615153049.BFCC51396B@sa.vix.com> Subject: Re: so how about that response size draft? Date: Tue, 17 Jun 2003 07:28:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit I am in favor of this draft becoming a working group item. At least that way it will be (hopefully) read and discussed. Scott ----- Original Message ----- From: "Paul Vixie" To: Sent: Sunday, June 15, 2003 11:30 AM Subject: so how about that response size draft? > akira and i both hoped that it would be adopted as a DNSOP work item > but the discussion of this in san francisco was inconclusive and there > has been no subsequent discussion here on the mailing list. > > a draft cutoff date looms. should this i-d have "-dnsop-" in its name? > > note that we also showed this draft to some of icann/iana's people and > they were happy to see it. therefore it may have some applicability to > somebody. should DNSOP "adopt" it and do the fold-spindle-mutilate thing? > > > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jun 17 09:21:41 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13821 for ; Tue, 17 Jun 2003 09:21:39 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5HCxCmb028564 for ; Tue, 17 Jun 2003 14:59:12 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5HCxC30028563 for dnsop-outgoing; Tue, 17 Jun 2003 14:59:12 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5HCxBmb028558 for ; Tue, 17 Jun 2003 14:59:11 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19SG3J-000JFs-M4; Tue, 17 Jun 2003 05:59:09 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 17 Jun 2003 05:59:09 -0700 To: Paul Vixie Cc: dnsop@cafax.se Subject: Re: so how about that response size draft? References: <20030615153049.BFCC51396B@sa.vix.com> Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > akira and i both hoped that it would be adopted as a DNSOP work item > but the discussion of this in san francisco was inconclusive and there > has been no subsequent discussion here on the mailing list. > > a draft cutoff date looms. should this i-d have "-dnsop-" in its name? > > note that we also showed this draft to some of icann/iana's people and > they were happy to see it. therefore it may have some applicability to > somebody. should DNSOP "adopt" it and do the fold-spindle-mutilate thing? draft name? and is it protocol or practice? randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jun 17 18:39:49 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15065 for ; Tue, 17 Jun 2003 18:39:48 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5HMDFmb005902 for ; Wed, 18 Jun 2003 00:13:15 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5HMDFEY005901 for dnsop-outgoing; Wed, 18 Jun 2003 00:13:15 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from garlic.apnic.net (garlic.apnic.net [202.12.29.224]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5HMDCmb005896 for ; Wed, 18 Jun 2003 00:13:14 +0200 (MEST) Received: from garlic.apnic.net (localhost [127.0.0.1]) by garlic.apnic.net (8.12.9/8.12.9) with ESMTP id h5H7VxWB002214; Tue, 17 Jun 2003 17:31:59 +1000 (EST) Received: (from ggm@localhost) by garlic.apnic.net (8.12.9/8.12.9/Submit) id h5H7Vumb002448; Tue, 17 Jun 2003 17:31:56 +1000 (EST) Date: Tue, 17 Jun 2003 17:31:56 +1000 From: George Michaelson To: Jakob Schlyter Cc: dnsop@cafax.se Subject: Re: so how about that response size draft? Message-Id: <20030617173156.7c9c4edc.ggm@apnic.net> In-Reply-To: References: <20030615153049.BFCC51396B@sa.vix.com> Organization: APNIC Pty Ltd X-Mailer: Sylpheed version 0.9.0claws38 (GTK+ 1.2.10; i386-pc-netbsdelf1.6T) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > On Sun, 15 Jun 2003, Paul Vixie wrote: > akira and i both hoped that it would be adopted as a DNSOP work item > but the discussion of this in san francisco was inconclusive and there > has been no subsequent discussion here on the mailing list. > > a draft cutoff date looms. should this i-d have "-dnsop-" in its name? > I would like to see this adopted and published as a dnsop work item. -George -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jun 18 04:34:12 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24003 for ; Wed, 18 Jun 2003 04:34:11 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5I7xKmb011850 for ; Wed, 18 Jun 2003 09:59:20 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5I7xKhC011849 for dnsop-outgoing; Wed, 18 Jun 2003 09:59:20 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5I7xGmb011844 for ; Wed, 18 Jun 2003 09:59:18 +0200 (MEST) Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h5I8CI701365; Wed, 18 Jun 2003 17:12:19 +0900 (KST) Message-ID: <005a01c3356f$60dffd80$c470fe81@etri.re.kr> From: "Jaehoon Jeong" To: "DNSOP WG" Cc: "autonet" Subject: DNS Autoconfiguration in HMIPv6 Date: Wed, 18 Jun 2003 16:58:16 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0057_01C335BA.CFDC5B20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-dnsop@cafax.se Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0057_01C335BA.CFDC5B20 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 SGksIEROU09QIG1lbWJlcnMhDQoNCkkgd2lsbCBzdWJtaXQgYSByZXZpc2VkIGRyYWZ0IGZvciBE TlMgQXV0b2NvbmZpZ3VyYXRpb24gaW4gSE1JUHY2Lg0KICAgaHR0cDovL3d3dy5wYXVsLjZhbnRz Lm5ldC9kYXRhL2RyYWZ0LWplb25nLWhtaXB2Ni1kbnMtb3B0aW1pemF0aW9uLTAxLnR4dA0KDQpU aGlzIGRyYWZ0IHdhcyBwcmVzZW50ZWQgaW4gdGhlIGxhc3QgU0YgbWVldGluZy4NCiAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDNtYXIvc2xpZGVzL2Ruc29wLTEvc2xkMS5odG0N Cg0KQWZ0ZXIgdGhlIG1lZXRpbmcsIHRoZXJlIHdhcyBubyBhY3R1YWwgZGlzY3Vzc2lvbiBhYm91 dCB0aGlzIGRyYWZ0Lg0KSSBob3BlIHdlIGRpc2N1c3MgdGhpcyBpdGVtIGJlZm9yZSB0aGlzIFZp ZW5uYSBtZWV0aW5nLg0KVGhpcyBkcmFmdCBzaG93cyBhIGdvb2QgYXBwbGljYXRpb24gb2YgSVB2 NiBSQS1iYXNlZCBETlMgQXV0b2NvbmZpZ3VyYXRpb24NCnRvIHdpcmVsZXNzIG5ldHdvcmtzLCBz dWNoIGFzICBIaWVyYXJjaGljYWwgTW9iaWxlIElQdjYgYW5kIE1vYmlsZSBOZXR3b3JrIChORU1P KS4NClRoZSBnZW5lcmljIGRyYWZ0IGZvciBSQS1iYXNlZCBETlMgQXV0b2NvbmZpZ3VyYXRpb24g d2FzIHN1Ym1pdHRlZCBiZWZvcmUNCmFuZCB3aWxsIGJlIHByZXNlbnRlZCBpbiB0aGlzIFZpZW5u YSBtZWV0aW5nLg0KICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1q ZW9uZy1pcHY2LXJhLWRucy1hdXRvY29uZi0wMC50eHQNCg0KSW4gdGhpcyBtZWV0aW5nLCBJIHdv dWxkIGxpa2UgdG8gc3VnZ2VzdCBJUHY2IFJBLWJhc2VkIEROUyBBdXRvY29uZmlndXJhdGlvbg0K YXMgd29ya2luZyBnb3VycCBpdGVtLg0KSG93IGFib3V0IG15IHN1Z2dlc3Rpb24/DQpUaGFua3Mu DQoNClJlZ2FyZHMsDQpKYWVob29uDQo= ------=_NextPart_000_0057_01C335BA.CFDC5B20 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+DQo8TUVUQSBjb250ZW50PSJNU0hU TUwgNi4wMC4yODAwLjExMDYiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hF QUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PkhpLCBETlNPUCBtZW1iZXJzITwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5J IHdpbGwgc3VibWl0IGEgcmV2aXNlZCBkcmFmdCBmb3IgRE5TIA0KQXV0b2NvbmZpZ3VyYXRpb24g aW4gSE1JUHY2LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIGZhY2U9QXJp YWw+Jm5ic3A7Jm5ic3A7IDwvRk9OVD48QSANCmhyZWY9Imh0dHA6Ly93d3cucGF1bC42YW50cy5u ZXQvZGF0YS9kcmFmdC1qZW9uZy1obWlwdjYtZG5zLW9wdGltaXphdGlvbi0wMS50eHQiPjxGT05U IA0KZmFjZT1BcmlhbD5odHRwOi8vd3d3LnBhdWwuNmFudHMubmV0L2RhdGEvZHJhZnQtamVvbmct aG1pcHY2LWRucy1vcHRpbWl6YXRpb24tMDEudHh0PC9GT05UPjwvQT48L0ZPTlQ+PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+VGhpcyBkcmFmdCB3YXMgcHJlc2VudGVkIGluIHRoZSBsYXN0 IFNGIA0KbWVldGluZy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBmYWNl PUFyaWFsPiZuYnNwOyZuYnNwOyA8L0ZPTlQ+PEEgDQpocmVmPSJodHRwOi8vd3d3LmlldGYub3Jn L3Byb2NlZWRpbmdzLzAzbWFyL3NsaWRlcy9kbnNvcC0xL3NsZDEuaHRtIj48Rk9OVCANCmZhY2U9 QXJpYWw+aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wM21hci9zbGlkZXMvZG5zb3At MS9zbGQxLmh0bTwvRk9OVD48L0E+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PkFmdGVyIHRoZSBtZWV0aW5nLCB0aGVyZSB3YXMgDQpubyZuYnNwO2FjdHVhbCZuYnNwO2Rpc2N1 c3Npb24gYWJvdXQmbmJzcDt0aGlzIGRyYWZ0LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbCBzaXplPTI+SSBob3BlIHdlIGRpc2N1c3MgdGhpcyBpdGVtIGJlZm9yZSB0aGlzIFZp ZW5uYSANCm1lZXRpbmcuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9 Mj5UaGlzIGRyYWZ0Jm5ic3A7c2hvd3MgYSBnb29kIGFwcGxpY2F0aW9uIG9mIElQdjYgDQpSQS1i YXNlZCBETlMgQXV0b2NvbmZpZ3VyYXRpb248L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPnRvIHdpcmVsZXNzIG5ldHdvcmtzLCBzdWNoIGFzJm5ic3A7IEhpZXJhcmNo aWNhbCANCk1vYmlsZSBJUHY2IGFuZCZuYnNwO01vYmlsZSBOZXR3b3JrIChORU1PKS48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlRoZSBnZW5lcmljIGRyYWZ0IGZv ciBSQS1iYXNlZCBETlMgDQpBdXRvY29uZmlndXJhdGlvbiB3YXMgc3VibWl0dGVkIGJlZm9yZTwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+YW5kIHdpbGwgYmUgcHJl c2VudGVkIGluIHRoaXMgVmllbm5hIA0KbWVldGluZy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj48Rk9OVCBmYWNlPUFyaWFsPiZuYnNwOyA8L0ZPTlQ+PEEgDQpocmVmPSJodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qZW9uZy1pcHY2LXJhLWRucy1hdXRv Y29uZi0wMC50eHQiPjxGT05UIA0KZmFjZT1BcmlhbD5odHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1qZW9uZy1pcHY2LXJhLWRucy1hdXRvY29uZi0wMC50eHQ8L0ZPTlQ+ PC9BPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5JbiB0aGlzIG1lZXRpbmcs IEkgd291bGQgbGlrZSB0byBzdWdnZXN0IElQdjYgDQpSQS1iYXNlZCBETlMgQXV0b2NvbmZpZ3Vy YXRpb248L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPmFzIHdvcmtp bmcgZ291cnAgaXRlbS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PkhvdyBhYm91dCBteSBzdWdnZXN0aW9uPzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+VGhhbmtzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBz aXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5S ZWdhcmRzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+SmFlaG9v bjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48L0JP RFk+PC9IVE1MPg0K ------=_NextPart_000_0057_01C335BA.CFDC5B20-- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jun 18 14:47:48 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20797 for ; Wed, 18 Jun 2003 14:47:46 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5IIB1mb019147 for ; Wed, 18 Jun 2003 20:11:01 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5IIB1F8019146 for dnsop-outgoing; Wed, 18 Jun 2003 20:11:01 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5IIB0mb019141 for ; Wed, 18 Jun 2003 20:11:00 +0200 (MEST) Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id h5IIAAu91142194; Wed, 18 Jun 2003 20:10:10 +0200 (CEST) Received: (from souissi@localhost) by kerkenna.nic.fr (8.11.6/8.9.3) id h5IIA7q14572; Wed, 18 Jun 2003 20:10:07 +0200 Date: Wed, 18 Jun 2003 20:10:07 +0200 From: Mohsen Souissi To: Paul Vixie Cc: dnsop@cafax.se Subject: Re: so how about that response size draft? Message-ID: <20030618201007.D30113@kerkenna.nic.fr> References: <20030615153049.BFCC51396B@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030615153049.BFCC51396B@sa.vix.com>; from paul@vix.com on Sun, Jun 15, 2003 at 03:30:49PM +0000 Sender: owner-dnsop@cafax.se Precedence: bulk IMHO, this draft is and will be very useful for the DNSv6 community. As far as AFNIC (the French Registry) is concerned, this draft is directly applicable. It has already helped us to prove to IANA's people that there were no technical issues in putting glue AAAA records in root zone (for ns3.nic.fr for instance, serving fr zone). We are waiting for further layer-9 processing ;-) In one word, dnsop should adopt this document. Thank you Akira and Paul for that work. Mohsen. On 15 Jun, Paul Vixie wrote: | akira and i both hoped that it would be adopted as a DNSOP work item | but the discussion of this in san francisco was inconclusive and there | has been no subsequent discussion here on the mailing list. | | a draft cutoff date looms. should this i-d have "-dnsop-" in its name? | | note that we also showed this draft to some of icann/iana's people and | they were happy to see it. therefore it may have some applicability to | somebody. should DNSOP "adopt" it and do the fold-spindle-mutilate thing? | | | #---------------------------------------------------------------------- | # To unsubscribe, send a message to . #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jun 18 15:11:15 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23135 for ; Wed, 18 Jun 2003 15:11:14 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5IIarmb019424 for ; Wed, 18 Jun 2003 20:36:53 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5IIar84019423 for dnsop-outgoing; Wed, 18 Jun 2003 20:36:53 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5IIaqmb019418 for ; Wed, 18 Jun 2003 20:36:52 +0200 (MEST) Received: by smtp2.arin.net (Postfix, from userid 5003) id A0B27230; Wed, 18 Jun 2003 14:36:51 -0400 (EDT) Received: from arin.net (mta [192.136.136.126]) by smtp2.arin.net (Postfix) with ESMTP id 3DF9FB3; Wed, 18 Jun 2003 14:36:51 -0400 (EDT) Received: from [127.0.0.1] (HELO [192.149.252.108]) by arin.net (CommuniGate Pro SMTP 4.1b8) with ESMTP id 407376; Wed, 18 Jun 2003 14:33:33 -0400 Mime-Version: 1.0 X-Sender: edlewis@127.0.0.1 Message-Id: In-Reply-To: References: <20030615153049.BFCC51396B@sa.vix.com> Date: Wed, 18 Jun 2003 14:36:45 -0400 To: Randy Bush From: Edward Lewis Subject: Re: so how about that response size draft? Cc: Paul Vixie , dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-2.6 required=5.0 tests=IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_00_01 version=2.43-arin1 Sender: owner-dnsop@cafax.se Precedence: bulk At 5:59 -0700 6/17/03, Randy Bush wrote: >and is it protocol or practice? It's an observation about the protocol that has an impact on the practice. The protocol definition cares not how long the messages are (up to some big limit), the protocol is indifferent about whether the end user waits for out a TC-induced retry and is also indifferent about the size of the server needed to keep this down. The observations will help drive the policies regarding when glue records are admitted to a zone, when a AAAA replaces a A, etc. (E.g., what Mohsen Souissi said.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer ...as graceful as a blindfolded bull in a china shop... #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jun 19 08:03:58 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11120 for ; Thu, 19 Jun 2003 08:03:57 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5JBWNmb001135 for ; Thu, 19 Jun 2003 13:32:23 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5JBWNcM001134 for dnsop-outgoing; Thu, 19 Jun 2003 13:32:23 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5JBWLmb001129 for ; Thu, 19 Jun 2003 13:32:22 +0200 (MEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09532; Thu, 19 Jun 2003 07:32:20 -0400 (EDT) Message-Id: <200306191132.HAA09532@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dnsop@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsop-respsize-00.txt Date: Thu, 19 Jun 2003 07:32:20 -0400 Sender: owner-dnsop@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNS Response Size Issues Author(s) : P. Vixie, A. Kato Filename : draft-ietf-dnsop-respsize-00.txt Pages : 8 Date : 2003-6-18 With a mandated default minimum maximum message size of 512 octets, the DNS protocol presents some special problems for zones wishing to expose a moderate or high number of authority servers (NS RRs). This document explains the operational issues caused by, or related to this response size limit. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-respsize-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsop-respsize-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsop-respsize-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-18124436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsop-respsize-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsop-respsize-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-18124436.I-D@ietf.org> --OtherAccess-- --NextPart-- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jun 19 08:04:00 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11136 for ; Thu, 19 Jun 2003 08:04:00 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5JBUkmb001116 for ; Thu, 19 Jun 2003 13:30:46 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5JBUkf2001115 for dnsop-outgoing; Thu, 19 Jun 2003 13:30:46 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5JBUimb001109 for ; Thu, 19 Jun 2003 13:30:44 +0200 (MEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09173; Thu, 19 Jun 2003 07:30:42 -0400 (EDT) Message-Id: <200306191130.HAA09173@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: dnsop@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-jeong-hmipv6-dns-optimization-01.txt Date: Thu, 19 Jun 2003 07:30:42 -0400 Sender: owner-dnsop@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Autoconfiguration of Recursive DNS Server and the Optimization of DNS Name Resolution in Hierarchical Mobile IPv6 Author(s) : J. Jeong et al. Filename : draft-jeong-hmipv6-dns-optimization-01.txt Pages : 8 Date : 2003-6-18 This document provides the mechanism for the autoconfiguration of recursive DNS server in mobile node and the optimization of DNS name resolution in the hierarchical mobile IPv6 network. Whenever the mobile node moves into a new MAP domain, the region managed by another MAP, in the hierarchical mobile IPv6 network, it detects the addresses of recursive DNS servers which are placed in the region and replaces the old ones with the new ones for DNS name resolution. This allows the time for DNS name resolution much reduced by using the nearest recursive DNS server which exists in the region. Therefore, the mechanism of this document can optimize the DNS name resolution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeong-hmipv6-dns-optimization-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jeong-hmipv6-dns-optimization-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jeong-hmipv6-dns-optimization-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-18121927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jeong-hmipv6-dns-optimization-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-jeong-hmipv6-dns-optimization-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-18121927.I-D@ietf.org> --OtherAccess-- --NextPart-- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jun 19 12:35:54 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29719 for ; Thu, 19 Jun 2003 12:35:54 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5JG2Zmb005306 for ; Thu, 19 Jun 2003 18:02:35 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5JG2ZpJ005305 for dnsop-outgoing; Thu, 19 Jun 2003 18:02:35 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from localhost.localdomain (adsl-67-116-36-254.dsl.sntc01.pacbell.net [67.116.36.254]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5JG2Xmb005299 for ; Thu, 19 Jun 2003 18:02:33 +0200 (MEST) Received: (from kent@localhost) by localhost.localdomain (8.11.6/8.11.6) id h5JG2aU16998 for dnsop@cafax.se; Thu, 19 Jun 2003 09:02:36 -0700 From: kent@songbird.com Date: Thu, 19 Jun 2003 09:02:36 -0700 To: dnsop@cafax.se Subject: Re: so how about that response size draft? Message-ID: <20030619160236.GF11756@owl.songbird.com> Mail-Followup-To: dnsop@cafax.se References: <20030615153049.BFCC51396B@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030615153049.BFCC51396B@sa.vix.com> User-Agent: Mutt/1.4.1i Sender: owner-dnsop@cafax.se Precedence: bulk On Sun, Jun 15, 2003 at 03:30:49PM +0000, Paul Vixie wrote: > akira and i both hoped that it would be adopted as a DNSOP work item > but the discussion of this in san francisco was inconclusive and there > has been no subsequent discussion here on the mailing list. > > a draft cutoff date looms. should this i-d have "-dnsop-" in its name? > > note that we also showed this draft to some of icann/iana's people and > they were happy to see it. therefore it may have some applicability to > somebody. should DNSOP "adopt" it and do the fold-spindle-mutilate thing? As one of the icann/iana people who found the draft extremely helpful, and would like to cite it, by all means... Kent -- Kent Crispin "Be good, and you will be Manager of Technical Operations, ICANN lonesome." crispin@icann.org,kent@songbird.com -- Mark Twain p: +1 310 823 9358 f: +1 310 823 8649 #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jun 19 13:48:03 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04335 for ; Thu, 19 Jun 2003 13:48:02 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5JHKXmb006508 for ; Thu, 19 Jun 2003 19:20:33 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5JHKXSK006507 for dnsop-outgoing; Thu, 19 Jun 2003 19:20:33 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5JHKVmb006502 for ; Thu, 19 Jun 2003 19:20:31 +0200 (MEST) Received: from ocean.jinmei.org (unknown [3ffe:501:100f:f::6]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 1994C15248; Fri, 20 Jun 2003 02:20:22 +0900 (JST) Date: Fri, 20 Jun 2003 02:20:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dnsop@cafax.se Cc: v6ops@ops.ietf.org Subject: a new draft on AAAA queries User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. In-Reply-To: <200306181151.HAA27829@ietf.org> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: multipart/mixed; boundary="Multipart_Fri_Jun_20_02:20:18_2003-1" Sender: owner-dnsop@cafax.se Precedence: bulk --Multipart_Fri_Jun_20_02:20:18_2003-1 Content-Type: text/plain; charset=US-ASCII In response to a discussion in the v6ops wg, we submitted a new individual draft (see below) that discusses problematics issues wrt AAAA queries. Though the background of the draft is a v6ops discussion, we authors believe we can get nice feedback from dnsop because the issues are basically general DNS topics. The draft may still be incomplete or even be incorrect in some points, so any comments, corrections, or additional cases would be highly appreciated. Thanks in advance, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Fri_Jun_20_02:20:18_2003-1 Content-Type: message/rfc822 Return-Path: X-Mail-Format-Warning: Bad RFC2822 header formatting in >From jinmei Wed Jun 18 21:31:38 2003 Return-Path: X-Original-To: jinmei@shuttle.wide.toshiba.co.jp Delivered-To: jinmei@shuttle.wide.toshiba.co.jp Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-6.1.0) for jinmei@localhost (single-drop); Wed, 18 Jun 2003 22:30:45 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 160DB1525C for ; Wed, 18 Jun 2003 21:31:38 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.12.9/8.12.9) with ESMTP id h5ICVbfP018068; Wed, 18 Jun 2003 21:31:37 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id VAA08513; Wed, 18 Jun 2003 21:31:37 +0900 (JST) Received: from mx2.toshiba.co.jp (mx2.toshiba.co.jp [133.199.160.163]) by isl.rdc.toshiba.co.jp (8.11.7/8.11.6/1.4) with ESMTP id h5ICVab09037; Wed, 18 Jun 2003 21:31:36 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id VAA16647; Wed, 18 Jun 2003 21:31:35 +0900 (JST) Received: from inet-tsb5.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id h5ICVYBF028987; Wed, 18 Jun 2003 21:31:34 +0900 (JST) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by inet-tsb5.toshiba.co.jp with ESMTP id h5ICVOhW025180; Wed, 18 Jun 2003 21:31:25 +0900 (JST) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19SbZN-0005yR-8W for ietf-announce-list@asgard.ietf.org; Wed, 18 Jun 2003 07:57:41 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19SbTV-0005jo-JE for all-ietf@asgard.ietf.org; Wed, 18 Jun 2003 07:51:37 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27829 for ; Wed, 18 Jun 2003 07:51:36 -0400 (EDT) Message-Id: <200306181151.HAA27829@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-morishita-dnsop-misbehavior-against-aaaa-00.txt Date: Wed, 18 Jun 2003 07:51:36 -0400 Sender: owner-ietf-announce@ietf.org Precedence: bulk X-UIDL: "H""!d~?"!"G3"!NpK!! X-Spam-Status: No, hits=2.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART,NO_REAL_NAME,TO_MALFORMED version=2.55 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Common Misbehavior against DNS Queries for IPv6 Addresses Author(s) : Y. Morishita, T. Jinmei Filename : draft-morishita-dnsop-misbehavior-against-aaaa-00.txt Pages : 7 Date : 2003-6-17 There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can block IPv4 communication which should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of the known cases and discusses the effect. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-morishita-dnsop-misbehavior-against-aaaa-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-morishita-dnsop-misbehavior-against-aaaa-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-morishita-dnsop-misbehavior-against-aaaa-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-17144214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-morishita-dnsop-misbehavior-against-aaaa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-morishita-dnsop-misbehavior-against-aaaa-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-17144214.I-D@ietf.org> --OtherAccess-- --NextPart-- --Multipart_Fri_Jun_20_02:20:18_2003-1-- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Jun 20 08:08:21 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00950 for ; Fri, 20 Jun 2003 08:08:16 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5KBXAmb017145 for ; Fri, 20 Jun 2003 13:33:10 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5KBXAKC017144 for dnsop-outgoing; Fri, 20 Jun 2003 13:33:10 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5KBX5mb017139 for ; Fri, 20 Jun 2003 13:33:06 +0200 (MEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25693; Fri, 20 Jun 2003 07:33:03 -0400 (EDT) Message-Id: <200306201133.HAA25693@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dnsop@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsop-ipv6-transport-guidelines-00.txt Date: Fri, 20 Jun 2003 07:33:03 -0400 Sender: owner-dnsop@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : DNS IPv6 transport operational guidelines Author(s) : A. Durand, J. Ihren Filename : draft-ietf-dnsop-ipv6-transport-guidelines-00.txt Pages : 0 Date : 2003-6-19 This memo provides guidelines and best common practice to operate DNS in a mixed world of IPv4 and IPv6 transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-transport-guidelines-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsop-ipv6-transport-guidelines-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsop-ipv6-transport-guidelines-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-19153933.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsop-ipv6-transport-guidelines-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsop-ipv6-transport-guidelines-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-19153933.I-D@ietf.org> --OtherAccess-- --NextPart-- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jun 24 01:27:50 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21856 for ; Tue, 24 Jun 2003 01:26:44 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5O53Rmb028105 for ; Tue, 24 Jun 2003 07:03:27 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5O53RAv028104 for dnsop-outgoing; Tue, 24 Jun 2003 07:03:27 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5O53Omb028096 for ; Tue, 24 Jun 2003 07:03:25 +0200 (MEST) Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h5O5GM917832; Tue, 24 Jun 2003 14:16:22 +0900 (KST) Message-ID: <005401c33a0d$ca92ccb0$c470fe81@etri.re.kr> From: "Jaehoon Jeong" To: "Scott Rose" Cc: "DNSOP WG" References: <015601c3398f$c375f520$b9370681@barnacle> Subject: Re: Comment on draft-jeong-hmipv6-dns-optimization-01.txt Date: Tue, 24 Jun 2003 14:02:18 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nic.cafax.se id h5O53Qmb028100 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Scott. Thanks for your good comments. Look at the inlines. ----- Original Message ----- From: "Scott Rose" To: Sent: Monday, June 23, 2003 11:00 PM Subject: Comment on draft-jeong-hmipv6-dns-optimization-01.txt > > I was reading over the draft and had a question regarding section 7 > Detection of RDNSS Failure: > > Why does the MAP need to check the state of the recursive DNS servers? If > they are all part of the same administrative domain, an operator will make > sure the DNS servers are up and running. > The reason MAP checks recursive DNS servers' state is to let MAP announce only the living or reachable DNS servers. As you say, network operator can make sure the DNS servers within the managed domain are working in order. But until some DNS servers are down or out of order and the network administrator handles the problem, MAP will continue to announce the invalid DNS servers. > A client can also choose to ignore a recursive DNS server that it believes > to be down. If it sends out a DNS query, but does not recieve a reply, it > can mark the server as "bad" or delete the server from its list of recursive > servers to query. > Though a client can detect some DNS server, it will take a time to detect. I intended to reducing the detection time by MAP polling DNS servers regularly. > I think it adds complexity for the MAP to ping every recursive DNS server > unless there are a number of unstable DNS servers on a network. > Yes, you are right when MAP often checks the DNS servers. If MAP pings every DNS server at appropriate intervals, I think, there is not much complexity. I'd like to listen to other opinions. Thanks :-) Regards, Jaehoon > Scott > ================================= > Scott Rose > Adv. Network Technology Div., NIST > http://www.antd.nist.gov/proj/dnssec > > ph - 301-975-8439 > ================================== > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jun 24 04:51:23 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07507 for ; Tue, 24 Jun 2003 04:50:17 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5O8Fxmb029778 for ; Tue, 24 Jun 2003 10:15:59 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5O8Fx7d029777 for dnsop-outgoing; Tue, 24 Jun 2003 10:15:59 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h5O8Fwmb029772 for ; Tue, 24 Jun 2003 10:15:58 +0200 (MEST) Received: from parsmtp2.rd.francetelecom.com ([10.193.117.129]) by p-mail2 with InterScan Messaging Security Suite; Tue, 24 Jun 2003 10:13:28 +0200 Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 24 Jun 2003 10:12:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Comments on draft-jeong-***-dns-***.txt Date: Tue, 24 Jun 2003 10:12:52 +0200 Message-ID: Thread-Topic: Comment on draft-jeong-hmipv6-dns-optimization-01.txt Thread-Index: AcM6EqDRy7mk4H8uRQ+e7bem3CcmpQADmu+Q From: "BELOEIL Luc FTRD/DMI/CAE" To: "Jaehoon Jeong" Cc: "DNSOP WG" X-OriginalArrivalTime: 24 Jun 2003 08:12:53.0376 (UTC) FILETIME=[6926D000:01C33A28] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h5O8Fxmb029773 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, Those drafts are really interesting, and I have also several comments. 1- Concerning http://www.paul.6ants.net/data/draft-jeong-hmipv6-dns-optimization-01.txt - RDNSS Failure detection, I do think that is necessary but I do not think that is a job for a MAP. IMHO, it should be simpler to have several "recursive DNS resolvers". If one fails the client will try the next resolver in its list. 2- Concerning http://www.ietf.org/internet-drafts/draft-jeong-ipv6-ra-dns-autoconf-00.txt - I would prefer not to send "DNS option message" in all RA so as to minimize exchanged information. - If a DNS server accepts Dynamic DNS update, I would prefer that it does not performs recursive resolution at the same time. IMHO those are different functions that must be separated. I would prefer an option for advertising "Dynamic DNS update capable DNS server" and another one for "recursive DNS resolvers". - It's a good idea to advertise DNS zone suffix. Should'nt it be better to advertise that in a seperate option or more likely in a sub-option ? - Dynamic DNS update seems not to be an autoconfiguration mechanism as someone need to configure "user identifier". Did I miss sthg ? - I would not like to run a DNS server that accepts Dynamic DNS update from untrusted nodes, even if that could help autoconfiguration... We need a secure mechanism but that is really not simple. - in section 7, I do not understand clearly your point "Like this, DNS server MAY discard some or all DNS messages when being filled with the messages. " To my mind, if DNS server acts like this, it may not answers to some requests, thus that is a DoS attack !? I hope that could help, Luc #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jun 24 18:06:13 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13132 for ; Tue, 24 Jun 2003 18:05:07 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5OLfVmb007817 for ; Tue, 24 Jun 2003 23:41:31 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5OLfVBL007816 for dnsop-outgoing; Tue, 24 Jun 2003 23:41:31 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5OLfSmb007811 for ; Tue, 24 Jun 2003 23:41:29 +0200 (MEST) Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h5OLsN928363; Wed, 25 Jun 2003 06:54:24 +0900 (KST) Message-ID: <000e01c33a99$385bbf50$c470fe81@etri.re.kr> From: "Jaehoon Jeong" To: "BELOEIL Luc FTRD/DMI/CAE" Cc: "DNSOP WG" References: Subject: Re: Comments on draft-jeong-***-dns-***.txt Date: Wed, 25 Jun 2003 06:40:19 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nic.cafax.se id h5OLfVmb007812 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Thanks, Luc, for your important comments. I'll think over your comments. ----- Original Message ----- From: "BELOEIL Luc FTRD/DMI/CAE" To: "Jaehoon Jeong" Cc: "DNSOP WG" Sent: Tuesday, June 24, 2003 5:12 PM Subject: Comments on draft-jeong-***-dns-***.txt > > Hi all, > > Those drafts are really interesting, and I have also several comments. > > 1- Concerning http://www.paul.6ants.net/data/draft-jeong-hmipv6-dns-optimization-01.txt > - RDNSS Failure detection, I do think that is necessary but I do not think that is a job for a MAP. IMHO, it should be simpler to have several "recursive DNS resolvers". If one fails the client will try the next resolver in its list. > RDNSS failure detection refered to the detection of MAP failure in HMIPv6. Luc and Scott suggested that the detection in MAP is not helpful. I'll consider how to modify the part of RDNSS failure detection. > > 2- Concerning http://www.ietf.org/internet-drafts/draft-jeong-ipv6-ra-dns-autoconf-00.txt > > - I would prefer not to send "DNS option message" in all RA so as to minimize exchanged information. Yes, I agree. > - If a DNS server accepts Dynamic DNS update, I would prefer that it does not performs recursive resolution at the same time. IMHO those are different functions that must be separated. I would prefer an option for advertising "Dynamic DNS update capable DNS server" and another one for "recursive DNS resolvers". In order to allow the DNS updates only to trusted nodes, I think, there is some mechanism to identify the nodes. It is very difficult to apply the identification mechanism to DNS update operation. > - It's a good idea to advertise DNS zone suffix. Should'nt it be better to advertise that in a seperate option or more likely in a sub-option ? Yes, your suggestion is appropriate. > - Dynamic DNS update seems not to be an autoconfiguration mechanism as someone need to configure "user identifier". Did I miss sthg ? I intended to include the automatic registration of host DNS name into the DNS autoconfiguration. > - I would not like to run a DNS server that accepts Dynamic DNS update from untrusted nodes, even if that could help autoconfiguration... We need a secure mechanism but that is really not simple. Yes, I agree, that is difficult. I am trying to find out some ways. I need DNSOP fellows' help. > - in section 7, I do not understand clearly your point "Like this, DNS server MAY discard some or all DNS messages when being filled with the messages. " To my mind, if DNS server acts like this, it may not answers to some requests, thus that is a DoS attack !? > What do you think about, in order to cope with the DoS attack, it is to apply the discard only to DNS update messages? Thanks. /Jaehoon > I hope that could help, > > Luc > > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jun 25 20:36:18 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14856 for ; Wed, 25 Jun 2003 20:35:13 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5Q05tmb023971 for ; Thu, 26 Jun 2003 02:05:55 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5Q05tL6023970 for dnsop-outgoing; Thu, 26 Jun 2003 02:05:55 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5Q05qmb023965 for ; Thu, 26 Jun 2003 02:05:53 +0200 (MEST) Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h5Q0It914496; Thu, 26 Jun 2003 09:18:55 +0900 (KST) Message-ID: <001001c33b76$8fe512c0$c470fe81@etri.re.kr> From: "Jaehoon Jeong" To: "Scott Rose" Cc: "DNSOP WG" References: <015601c3398f$c375f520$b9370681@barnacle> <005401c33a0d$ca92ccb0$c470fe81@etri.re.kr> <007c01c33a4f$d0dd5760$b9370681@barnacle> Subject: Re: Comment on draft-jeong-hmipv6-dns-optimization-01.txt Date: Thu, 26 Jun 2003 09:04:48 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nic.cafax.se id h5Q05smb023966 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit After thinking about your comments, I became to agree with you. Right, I'll let it a part of network admin to maintain the list of RDNSS. I will modify my draft, reflecting Scott's and Luc's comments. Thanks a lot. Jaehoon ----- Original Message ----- From: "Scott Rose" To: "Jaehoon Jeong" Sent: Tuesday, June 24, 2003 9:54 PM Subject: Re: Comment on draft-jeong-hmipv6-dns-optimization-01.txt > > My main concern is that maintaining the list of RDNSS seems to be an > operational concern, and not really a part of the protocol extensions the > draft describes. It is not really important how a network keeps the list > of DNS servers current, there are many options for a network admin to use > depending on how the network is configured. > > It would be enough to say that the MAP should take action to keep the list > of RDNSS up to date, but not mandate how that is done. That can be left as > an operational concern for an individual network. > > Scott > > ----- Original Message ----- > From: "Jaehoon Jeong" > To: "Scott Rose" > Cc: "DNSOP WG" > Sent: Tuesday, June 24, 2003 1:02 AM > Subject: Re: Comment on draft-jeong-hmipv6-dns-optimization-01.txt > > > > Hi, Scott. > > Thanks for your good comments. > > Look at the inlines. > > > > ----- Original Message ----- > > From: "Scott Rose" > > To: > > Sent: Monday, June 23, 2003 11:00 PM > > Subject: Comment on draft-jeong-hmipv6-dns-optimization-01.txt > > > > > > > > > > I was reading over the draft and had a question regarding section 7 > > > Detection of RDNSS Failure: > > > > > > Why does the MAP need to check the state of the recursive DNS servers? > If > > > they are all part of the same administrative domain, an operator will > make > > > sure the DNS servers are up and running. > > > > > The reason MAP checks recursive DNS servers' state is to let MAP > announce > > only the living or reachable DNS servers. > > As you say, network operator can make sure the DNS servers within the > managed domain > > are working in order. But until some DNS servers are down or out of > order and > > the network administrator handles the problem, MAP will continue to > announce the invalid DNS servers. > > > > > A client can also choose to ignore a recursive DNS server that it > believes > > > to be down. If it sends out a DNS query, but does not recieve a reply, > it > > > can mark the server as "bad" or delete the server from its list of > recursive > > > servers to query. > > > > > Though a client can detect some DNS server, it will take a time to > detect. > > I intended to reducing the detection time by MAP polling DNS servers > regularly. > > > > > I think it adds complexity for the MAP to ping every recursive DNS > server > > > unless there are a number of unstable DNS servers on a network. > > > > > Yes, you are right when MAP often checks the DNS servers. > > If MAP pings every DNS server at appropriate intervals, I think, > > there is not much complexity. > > > > I'd like to listen to other opinions. > > Thanks :-) > > > > Regards, > > Jaehoon > > > > > Scott > > > ================================= > > > Scott Rose > > > Adv. Network Technology Div., NIST > > > http://www.antd.nist.gov/proj/dnssec > > > > > > ph - 301-975-8439 > > > ================================== > > > > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jun 26 08:30:31 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19102 for ; Thu, 26 Jun 2003 08:29:21 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5QC3vmb001731 for ; Thu, 26 Jun 2003 14:03:57 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5QC3v57001730 for dnsop-outgoing; Thu, 26 Jun 2003 14:03:57 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5QC3smb001725 for ; Thu, 26 Jun 2003 14:03:55 +0200 (MEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16513; Thu, 26 Jun 2003 08:03:46 -0400 (EDT) Message-Id: <200306261203.IAA16513@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dnsop@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsop-bad-dns-res-01.txt Date: Thu, 26 Jun 2003 08:02:42 -0400 Sender: owner-dnsop@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : Observed DNS Resolution Misbehavior Author(s) : M. Larson, P. Barber Filename : draft-ietf-dnsop-bad-dns-res-01.txt Pages : 14 Date : 2003-6-25 This Internet-Draft describes DNS name server and stub resolver behavior that results in a significant query volume sent to the root and top-level domain (TLD) name servers. In some cases we recommend minor additions to the DNS protocol specification and corresponding changes in name server implementations to alleviate these unnecessary queries. In one case, we have highlighted behavior of a popular name server implementation that does not conform to the DNS specification. The recommendations made in this document are a direct byproduct of observation and analysis of abnormal query traffic patterns seen at two of the thirteen root name servers and all thirteen com/net TLD name servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-bad-dns-res-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsop-bad-dns-res-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsop-bad-dns-res-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-26080105.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsop-bad-dns-res-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsop-bad-dns-res-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-26080105.I-D@ietf.org> --OtherAccess-- --NextPart-- #---------------------------------------------------------------------- # To unsubscribe, send a message to .