From owner-namedroppers@ops.ietf.org Sun Apr 1 07:41:43 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16830 for ; Sun, 1 Apr 2001 07:41:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14jfdt-00071W-00 for namedroppers-data@psg.com; Sun, 01 Apr 2001 04:03:33 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14jfdr-00071P-00 for namedroppers@ops.ietf.org; Sun, 01 Apr 2001 04:03:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14jfdr-0008BL-00 for namedroppers@ops.ietf.org; Sun, 01 Apr 2001 04:03:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: list policy Message-Id: From: Randy Bush Date: Sun, 01 Apr 2001 03:00:03 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit namedroppers@ops.ietf.org is the mailing list for the ietf dnsext wg. see for the wg charter. messages should be on topics appropriate to the dnsext wg, which are various discussion of the dns protocols or administrivia of the wg itself. the list is moderated. calls for papers, announcements of events not directly relevant to the dns protocols, etc. are not appropriate. discussion of problems with particular implementations, announcements of releases, sites' misconfigurations, etc. should be done on mailing lists for the particular implementations. there is a wg for dns operational practice, dnsop, whose charter can be found at . there is a mailing list for discussion of whose implementation is better, and why someone else's is broken. it is weenie-war@ops.ietf.org. all discussions of such nature should occur there or on /dev/null. unlike the namedroppers list, weenie-war@ops.ietf.org is not archived. discussion of this policy is a topic for the poisson wg. poisson's charter can be found at . to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 2 01:50:19 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07827 for ; Mon, 2 Apr 2001 01:50:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14jwsI-000BOm-00 for namedroppers-data@psg.com; Sun, 01 Apr 2001 22:27:34 -0700 Received: from 64-214-53-107.dhcp.arin.gblx.net ([64.214.53.107] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14jwsH-000BOg-00 for namedroppers@ops.ietf.org; Sun, 01 Apr 2001 22:27:33 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14jwsO-0003mo-00 for namedroppers@ops.ietf.org; Sun, 01 Apr 2001 22:27:40 -0700 Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 1 Apr 2001 07:42:39 -0400 To: Brian Wellington From: Edward Lewis Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Cc: Edward Lewis , , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 4:28 PM -0400 3/30/01, Brian Wellington wrote: >Because that's what you said. "There is [sic] a few reasons to have the >data in the parent.", followed by said reasons. Oh. I meant that "there is [sic ;)] a few reasons to have the data in the child." >... But I'm not convinced that operation experience has shown that the >decision was wrong. The argument now is that it's somehow easier to store >keys in the parent. This is not true. In both cases, the key must be >sent from the child to the parent. In both cases, something must be sent >from the parent back to the child, whether this something may either be a >signed keyset or a confirmation doesn't change the fact that it's still a >message. >From what I've garnered from discussions, the issue is this: When the parent needs to change its keys, it will need to resign all of the children's keys and make the new signatures available. (More on this in a minute.) The issue of passing information back and forth at the delegation point is equal whether the existing signature-at-the-child is used or the new proposal. I consider that issue somewhat of a red herring in this discussion. Now, about the re-signing of the parent. In Sweden last fall the workshop changed the parent's key in the afternoon one of the days. Stepping backwards, the children had submitted keys via an HTTP interface and retrieved the signatures via another page. I forget if the parent explicitly retained the keys, but I do know that if a child submitted multiple keys sets (ie one for Monday, another for Tuesday), the later key set overwrote the first in the parent's system. What happened when the parent went to resign its zone, it turned out that one of two things happened. A child's key could either not be resigned (the parent no longer had it) or the child neglected to take the action to get the new key. Eventually, the parent marked unresponsive children as unsecured. (A few children did notice and were kept secured. Those children happened to be those sitting closest to the parent. Draw from that what you will.) The upshot is that there is a requirement that the parent keep a copy of all the children keys in order to make the resigning of the parent work - at least in my view. Now, this requirement could be met in two ways - the parent places the children keys in a database off-line where the signer can get to them or the parent keeps the keys in DNS. Personally, I don't care which is which (...this is an issue I'd like to get input from TLDs on - and NLnet is providing this input). Now, the issue is where the signature goes. This is a related question - recall that there were children who didn't grab the new signatures (because they weren't aware of them). So, does the delegator just cut the middleman and publish the signatures that it generated, or does the child need to be notified by (push) or need to poll the (pull) parent. NLnet is proposing cutting out the middleman... Yet another question...this proposal helps keep the parent-child relationship going, but is it secure? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 2 12:43:32 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19726 for ; Mon, 2 Apr 2001 12:43:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14k71W-000Fr5-00 for namedroppers-data@psg.com; Mon, 02 Apr 2001 09:17:46 -0700 Received: from 64-214-53-107.dhcp.arin.gblx.net ([64.214.53.107] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14k71V-000Fqz-00 for namedroppers@ops.ietf.org; Mon, 02 Apr 2001 09:17:45 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14k71V-0003wA-00 for namedroppers@ops.ietf.org; Mon, 02 Apr 2001 09:17:45 -0700 Message-Id: <200104021118.HAA00515@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-parent-stores-zone-keys-00.txt Date: Mon, 02 Apr 2001 07:18:01 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Parent stores the child's zone KEYs Author(s) : R. Gieben, T. Lindgreen Filename : draft-ietf-dnsext-parent-stores-zone-keys-00.txt Pages : Date : 30-Mar-01 When dealing with large amounts of keys the procedures to update a zone and to sign a zone need to be clearly defined and practically possible. The current idea is to have the zone KEY RR and the parent's SIG to reside in the child's zone and perhaps also in the parent's zone. Operational experiences have prompted us to develop an alternative scheme in which the parent zone stores the parent's signature over the child's key and also the child's key itself. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-parent-stores-zone-keys-00.txt 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-dnsext-parent-stores-zone-keys-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-dnsext-parent-stores-zone-keys-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: <20010330142052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-parent-stores-zone-keys-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-parent-stores-zone-keys-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010330142052.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 2 12:43:36 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19742 for ; Mon, 2 Apr 2001 12:43:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14k6zk-000Fmw-00 for namedroppers-data@psg.com; Mon, 02 Apr 2001 09:15:56 -0700 Received: from 64-214-53-107.dhcp.arin.gblx.net ([64.214.53.107] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14k6zk-000Fmq-00 for namedroppers@ops.ietf.org; Mon, 02 Apr 2001 09:15:56 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14k6zj-0003vo-00 for namedroppers@ops.ietf.org; Mon, 02 Apr 2001 09:15:55 -0700 Message-Id: <200104021115.HAA29858@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-parent-sig-00.txt Date: Mon, 02 Apr 2001 07:15:04 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Parent's SIG over child's KEY Author(s) : R. Gieben, T. Lindgreen Filename : draft-ietf-dnsext-parent-sig-00.txt Pages : 7 Date : 30-Mar-01 When dealing with large amounts of keys the procedures to update a zone and to sign a zone need to be clearly defined and practically possible. The current idea is to have the KEY RR and the parent's SIG to reside in the child's zone and perhaps also in the parent's zone. We feel that this would lead to very complicated procedures for large TLDs. We propose an alternative scheme in which the parent zone stores the parent's signature over the child's key and also a copy of the child's key itself. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-parent-sig-00.txt 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-dnsext-parent-sig-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-dnsext-parent-sig-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: <20010330135619.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-parent-sig-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-parent-sig-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010330135619.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 2 12:49:08 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20037 for ; Mon, 2 Apr 2001 12:49:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14k78q-000GDc-00 for namedroppers-data@psg.com; Mon, 02 Apr 2001 09:25:20 -0700 Received: from 64-214-53-107.dhcp.arin.gblx.net ([64.214.53.107] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14k78q-000GDV-00 for namedroppers@ops.ietf.org; Mon, 02 Apr 2001 09:25:20 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14k78p-0003wq-00 for namedroppers@ops.ietf.org; Mon, 02 Apr 2001 09:25:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104021303.f32D3ac81962@open.nlnetlabs.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Mon, 2 Apr 2001 15:03:36 +0200 In-Reply-To: "Edward Lewis's message as of Apr 2, 8:17" Reply-To: Ted.Lindgreen@tednet.nl To: Edward Lewis , Brian Wellington Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Cc: team@nlnetlabs.nl, Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Edward Lewis, on Apr 2, 8:17, in "Re: Signature at par ..."] > Now, the issue is where the signature goes. This is a related question - > recall that there were children who didn't grab the new signatures (because > they weren't aware of them). So, does the delegator just cut the middleman > and publish the signatures that it generated, or does the child need to be > notified by (push) or need to poll the (pull) parent. NLnet is proposing > cutting out the middleman... Yes, you can say it like that. > Yet another question...this proposal helps keep the parent-child > relationship going, but is it secure? Of course that's the main point! Perhaps it is instructive to look at it from the point of view "what can go wrong" instead of the usual "how to do it right". Let us discuss: - What can go wong, and how easy is that? - What is the damage if it goes wrong? - Is it noticed quickly, and will it be picked up? - Can it be fixed quickly, and if so who is involved and what and how long does it take? - If it can not be fixed quickly, what to do in the mean time? - Can someone be blamed, made liable (or better said: can someone be encouraged to not make the same mistake in future again)? But, first thing to review is Ed's question above: is it secure? To discuss that, we first have to know where the vulnarabilities are. As far as I see, there is one and only one real security issue at the delegation point: A valid parental SIG over a KEY RR, from which the private part is (also) known to someone else than the legitimate administrator of the child zone. (Note: see NOTE below) How can it happen? 1. The private key at the child has been compromised. 2. The parent has been fooled and thus insuffiently checked whether the KEY RR is really from the child. The first one is child-problem, where it needs help from its parent. It's discussed further on in this mail. The second one is a delegation-administration-problem and is discussed first: When the initial KEY RR is sent to the parent, this is always a difficult point. At TLDs even more complicated by the existence of the 4 orgs involved: Registry, Registrant, Holder, and ZoneAdministrator. Some kind of out-of-band procedure must be used, and it will most likely involve written and signed statements and contracts with (non-)liability clauses. Let us not discuss this here further, because again it is insensitive to the issue at hand. It becomes interesting when a parent resigns. First question is: "when" is the parent re-signing? We (NLnet Labs) think: as often as practically possible, because when (not if ;-) something bad happens, the child is vulnarable for as long as the parental SIG is valid. ===> Therefore, we re-sign our test-TLD currently daily, and we do not sign in advance. Next question is: "what" is the parent re-signing? When the parent keeps the childs-KEY in hand (either in the zonefile or a database) it is probably OK as long as the child does not scream "My KEY is compromised". Also can this KEY then be used to verify a new KEY at a keyrollover. On the other hand, if the child must resubmit its KEY RR to get re-signed every time this is an invitation for a spoofing attack every time. Bad idea we think. ===> For security sake, the parent (TLD) better holds on to the KEY RRs from its children. Third question: does it matter where the parental SIG resides? At first one might think: yes, if the child can re-check that the right KEY is signed before putting the SIG in its zone, it is save. But.... if the bad guy has setup a fake zone, and has fooled the parent to sign his (fake) KEY, the bad guy will have little problems to put this (valid) SIG in his fake zone. ===> So, from a security point of view the answer is: NO. Now, over to discussing what happens when a parental SIG over a child KEY expires. This, in contrast to above, is completely different when the SIG resides @parent of @child. 1. Parental SIG @ parent. What might have happened? - For this to happen, the (parents) zoneadministrator must have "forgotten" to re-sign the zone in time. As we think this is not a administrators-job, but a crontab-job, it's an unlikely event. - But if it happens anyway, chances are that if one is expired more SIGs are expired, likely all of them in the zone. What's the damage? - The parent and the whole tree below drop of the Internet for secure aware resolvers. Who will notice and make some noise? - A number of people will start screaming, and because of the damage, the zoneadministrator will probably give some attention to the problem. How to fix it? - He/she types "make" in the zone directory (at least, that's how we set it up at NLnet Labs) to refresh all SIGs and sigHUP named. Who is to blame, and how to prevent it in future? - The parents zoneadministrator, and he/she better puts in a working crontab job to re-signs the zone regularly. 2. Parental SIG @ child. There are now a lot more possibilities of things that could have gone wrong: - The child has not asked for a new SIG in time. - The net was down when the child asked. - The parent did not sign or did not provide the new SIG. - The net was down when the parent did. - The child could not put the new SIG in its zone for any other reason. What's the damage? - Depends on what happened, but probably just one of a few children drop of the Internet. Who will notice and make some noise? - The affected children and or its customers will notice. - A few helpdesks may be passed through to get to the attention of the parents zoneadministrator for a new SIG. - If the parent is a large TLD, chances are that when it is one or a few children, he/she is not too interested, but when it's many, he/she is overwhelmed. How to fix it? - Depending on how it is set it up (stored the KEY at parent?), the TLDs zoneadministrator must re-establish the authenticity of the childs zoneadministrator before signing the KEY. - The new SIG must get from parent to child. - Child must put it in and sigHUP named. Who is to blame, and how to prevent it in future? - Difficult, probably every one will point to another, - As it is difficut to pinpoint the cause, it is also difficult to prevent it from happening again. Let us look now at another bad event: - A child gets its key compromised. - Let's pick a large TLD, with - most children not very sensitive to security, but some (still hundreds of thousands) are, - and a few (say a hundredthousand) secure subtrees (next to the millions of end-zones). Let's go through the questions: What might have happened? - The TLDs key got compromised. What's the damage? - The TLDs and all zones thereunder are vulnarable. Who will notice and make some noise? - Hopefully someone finds out before misuse has really started... How to fix it? This now depends on what the TLD chooses to do, and where its SIGs over the childs KEY RRs reside. 2 x 2 posibilities: 1A. TLD becomes unsecure immediately, SIG @ parent 1B. TLD rolls over its KEY immediately, SIG @ parent 2A. TLD becomes unsecure immediately, SIG @ child 2B. TLD rolls over its KEY immediately, SIG @ child So, again, how to fix it? 1A. TLD becomes unsecure immediately, SIG @ parent. - TLD goes to root with a request to become unsecure immediately. - Root's zone administrator needs to establish authenticity of request and requester out-of-band. - Root's zone administrator puts in a null-KEY for TLD into rootzone, re-signs, and sigHUPs. - Where the old KEY and old SIGs are cached (or spoofed into the cache!!!) they remain valid intil the SIGs expire. Nothing we can do about that. - Once the old SIG expires, the TLD and all zones below are now verifyably unsecure, and therefore: - secure transactions will know that they cannot trust DNS info. - do not drop of the Internet - TLD starts investigating what went wrong, fix that and gets more or less into the state of "becoming first-time secure": once it has signed its own zone with a new KEY and got the new KEY also signed at the root everything is back to normal. 1B. TLD rolls over its KEY immediately, SIG @ parent. - TLD goes to root with an immergency KEY rollover request. - Root's zone administrator needs to establish authenticity of request and requester out-of-band. - Root's zone administrator puts in the new TLD-KEY into rootzone, re-signs, and sigHUPs. - The TLD puts the new KEY in its zone and re-signs. - Where the old KEY and old SIGs are cached (or spoofed into the cache!!!) they remain valid intil the SIGs expire. Nothing we can do about that. - As soon as the old SIG expires, everything is back to normal. 2A. TLD becomes unsecure immediately, SIG @ child - TLD goes to root with a request to become unsecure immediately. - Root's zone administrator needs to establish authenticity of request and requester out-of-band. - Root's zone administrator puts in a null-KEY for TLD into rootzone, re-signs, and sigHUPs. - Where the old KEY and old SIGs are cached (or spoofed into the cache!!!) they remain valid intil the SIGs expire. Nothing we can do about that. - Once the old SIG expires, the TLD and all zones below are now verifyably unsecure (see above). - TLD starts investigating what went wrong, fix that. - TLD can not get into "becoming first-time secure", because it has SIGs from the compromised KEY out there at all its children, they MUST be replaced before the TLD can become secure again with a new KEY. This may take some time for a large TLD. 2B. TLD rolls over its KEY immediately, SIG @ child. We tried several scenarios, but we have not found an acceptable way. The possible choices are: 1. Allow secure children to be exposed. 2. Allow secure children to drop from the Internet. 3. Use scenario 2A to become unsecured for a reasonably long time to clean up, and then become secure again. We have worked out several more scenarios (I admit, they are all "horror scenarios", but nontheless likely to happen sooner or later), but I think this e-mail got too long already :-) Regards, -- Ted. NOTE: Someone said: what if the parent puts in a wrong or mistyped childs KEY in its zone, isn't that a security risk? This is IMHO not a security issue, it is "just" bad zoneadministration and similar to mistyped or wrong NS or glue RRs at the parent zone. Also, it does not expose the child, the parent "just" disables the child, unless, of course, the "mistyped" KEY happens to be the KEY from mr. Bad Guy, but then we are back to the security issue already mentioned. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 2 17:55:18 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02469 for ; Mon, 2 Apr 2001 17:55:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14kBv7-0005dr-00 for namedroppers-data@psg.com; Mon, 02 Apr 2001 14:31:29 -0700 Received: from 64-214-53-107.dhcp.arin.gblx.net ([64.214.53.107] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14kBv7-0005dl-00 for namedroppers@ops.ietf.org; Mon, 02 Apr 2001 14:31:29 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14kBv6-00049e-00 for namedroppers@ops.ietf.org; Mon, 02 Apr 2001 14:31:28 -0700 Message-Id: In-Reply-To: <200104021303.f32D3ac81962@open.nlnetlabs.nl> References: "Edward Lewis's message as of Apr 2, 8:17" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Apr 2001 16:16:22 -0400 To: Ted.Lindgreen@tednet.nl From: Edward Lewis Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Cc: Edward Lewis , Brian Wellington , team@nlnetlabs.nl, Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:03 AM -0400 4/2/01, Ted Lindgreen wrote: >But, first thing to review is Ed's question above: is it secure? >To discuss that, we first have to know where the vulnarabilities >are. This material (perhaps in a shortened form) would be good in the security considerations section of the ID! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 2 18:17:08 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02807 for ; Mon, 2 Apr 2001 18:17:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14kCKr-0006yO-00 for namedroppers-data@psg.com; Mon, 02 Apr 2001 14:58:05 -0700 Received: from 64-214-53-107.dhcp.arin.gblx.net ([64.214.53.107] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14kCKq-0006yI-00 for namedroppers@ops.ietf.org; Mon, 02 Apr 2001 14:58:04 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14kCKp-0004Af-00 for namedroppers@ops.ietf.org; Mon, 02 Apr 2001 14:58:03 -0700 Date: Mon, 2 Apr 2001 14:47:59 -0700 (PDT) From: Brian Wellington X-Sender: To: Edward Lewis cc: , Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Sun, 1 Apr 2001, Edward Lewis wrote: > At 4:28 PM -0400 3/30/01, Brian Wellington wrote: > >Because that's what you said. "There is [sic] a few reasons to have the > >data in the parent.", followed by said reasons. > > Oh. > > I meant that "there is [sic ;)] a few reasons to have the data in the child." That does make your argument clearer :) > >From what I've garnered from discussions, the issue is this: > > When the parent needs to change its keys, it will need to resign all of the > children's keys and make the new signatures available. (More on this in a > minute.) The issue of passing information back and forth at the delegation > point is equal whether the existing signature-at-the-child is used or the > new proposal. I consider that issue somewhat of a red herring in this > discussion. OK. > Now, about the re-signing of the parent. In Sweden last fall the workshop > changed the parent's key in the afternoon one of the days. Stepping > backwards, the children had submitted keys via an HTTP interface and > retrieved the signatures via another page. I forget if the parent > explicitly retained the keys, but I do know that if a child submitted > multiple keys sets (ie one for Monday, another for Tuesday), the later key > set overwrote the first in the parent's system. Right. But this shouldn't really be relevant, since no matter where the signatures are store, the parent needs to be notified when the child's key set is changed. > What happened when the parent went to resign its zone, it turned out that > one of two things happened. A child's key could either not be resigned > (the parent no longer had it) or the child neglected to take the action to > get the new key. Eventually, the parent marked unresponsive children as > unsecured. (A few children did notice and were kept secured. Those > children happened to be those sitting closest to the parent. Draw from > that what you will.) Given the lack of a defined parent-child communication mechanism, this is a problem. At the workshop, that mechanism was voice, if I recall. It could also be something like NOTIFY, though, which would allow the child to take an action and fetch the signed key from the parent. > The upshot is that there is a requirement that the parent keep a copy of > all the children keys in order to make the resigning of the parent work - > at least in my view. Now, this requirement could be met in two ways - the > parent places the children keys in a database off-line where the signer can > get to them or the parent keeps the keys in DNS. Personally, I don't care > which is which (...this is an issue I'd like to get input from TLDs on - > and NLnet is providing this input). Or the parent could fetch the key from the child and resign it. This is DNS after all; we might as well take advantage of it. Even assuming an offline signing process, the parent could obtain (by DNS) all of its childrens' keys before the resigning process. > Now, the issue is where the signature goes. This is a related question - > recall that there were children who didn't grab the new signatures (because > they weren't aware of them). So, does the delegator just cut the middleman > and publish the signatures that it generated, or does the child need to be > notified by (push) or need to poll the (pull) parent. NLnet is proposing > cutting out the middleman... Polling is definitely not the right solution. Notifying should work. The client shouldn't necessarily needs to have a dynamic zone - the response to a notification could be a simple as sending an email to the zone administrator indicating that a new signed key set should be obtained from the parent. > Yet another question...this proposal helps keep the parent-child > relationship going, but is it secure? Does it need to be? When the parent sends key sets to the child, they are signed. The parent's key can be verified through the DNS. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 3 12:57:36 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07971 for ; Tue, 3 Apr 2001 12:57:34 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14kTjS-0003dQ-00 for namedroppers-data@psg.com; Tue, 03 Apr 2001 09:32:38 -0700 Received: from 64-214-53-171.dhcp.arin.gblx.net ([64.214.53.171] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14kTjR-0003dH-00 for namedroppers@ops.ietf.org; Tue, 03 Apr 2001 09:32:37 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14kTjQ-0004dg-00 for namedroppers@ops.ietf.org; Tue, 03 Apr 2001 09:32:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104030807.KAA25811@omval.tednet.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Tue, 3 Apr 2001 10:07:15 +0200 In-Reply-To: "Brian Wellington's message as of Apr 2, 22:47" Reply-To: Ted.Lindgreen@tednet.nl To: Brian Wellington , Edward Lewis Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Cc: , Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Quoting Brian Wellington, on Apr 2, 22:47, in "Re: Signature at par ..."] > Given the lack of a defined parent-child communication mechanism, this is > a problem. At the workshop, that mechanism was voice, if I recall. It > could also be something like NOTIFY, though, which would allow the child > to take an action and fetch the signed key from the parent. The issue here is scaling, which already in the workshop (with only a handfull of children) turned out to be a problem. At CAIRN, this problem also surfaces. Please give it some thought when a parent must deal with hundreds of thousands (the average ccTLD) or even millions (the larger ccTLD and .com for instance) of children. Suppose the parent want to renew its KEY, and the children hold the SIGs. After the parent has notified (be it by voice, telephone, e-mail, or NOTIFY) its children, these children need to react. It is clear, that some of them will not react for several reasons: network problem, sysadm on holiday, server problem, workoverload, etc. etc. So, our poor TLD zoneadministrator must make a choice: 1. Wait for all of them (but he... perhaps the new SIG expires before..). 2. Wait for some percentage of its children to have reacted. 3. Just continue after a specified timeout. Not only a difficult choice, also non of them is fair (3. perhaps looks fair "they should have done their thing, if not, it's their problem"; however, what if none/some of the NOTIFY's reached their destination due to TLDs fault or a network failure?). In our opinion, this is not going to work. However, if we turn it around: the child notifies the parent that it wants a new KEY: For ONE key, there is now only ONE notify and only ONE parent-child relation in play. If the parent does not react, there is ONE sysadm to complain to ONE other sysadm. This scales. Regards, -- Ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 3 13:50:01 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10173 for ; Tue, 3 Apr 2001 13:49:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14kUdO-00070H-00 for namedroppers-data@psg.com; Tue, 03 Apr 2001 10:30:26 -0700 Received: from 64-214-53-171.dhcp.arin.gblx.net ([64.214.53.171] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14kUdO-00070B-00 for namedroppers@ops.ietf.org; Tue, 03 Apr 2001 10:30:26 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14kUdN-0004gj-00 for namedroppers@ops.ietf.org; Tue, 03 Apr 2001 10:30:25 -0700 Message-Id: In-Reply-To: <200103301002.MAA07885@kantoor.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Apr 2001 13:00:08 -0400 To: Olaf Kolkman From: Edward Lewis Subject: Re: QST: opt-in draft and resolver behaviour Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 6:02 AM -0400 3/30/01, Olaf Kolkman wrote: >In the case a resolvers is RETRY-NO-SEC-AWARE compliant it will go >back and try the non-secure tree. But that opens the possibility for a >a spoof and there is no way I can authenticate denial of a domain. Yes, but this (the possibility of a spoof) is no worse than where we are today. >My interpretation is that in the context of your draft NXT indicates >which children are secured and not which labels exist. In other words >authenicated denial will be broken. A name that does not exist in .com (are there some left?) needs no protection. So if first the authenticated denial arrives and the retry that should yield an unauthenticated NXDOMAIN is spoofed out to say the domain does exist, this is no different from today. A name that is unsecured in .com is protected under this just as it is today - the query in the secured view is just "spurious traffic" and doesn't impact the outcome. A name that is secured will be protected as if there is no unsecured .com - in the eyes of a secured resolver. (If the resolver is unsecured, we have the same situation as today.) Basically, Mark's draft offers a higher "QOS" for some names in his zone by adding security. The benefit to the community is that this will allow a secured .com to appear sooner as the proposal lowers the start-up cost. However, there is a danger in this proposal. If the proposed set up is transitional, this works, but what if this becomes the norm? Will we have .com, .com(-sec), .com(-v6), .com(-v6-sec)? This would be a split-brain DNS, something we really don't want. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 3 14:02:50 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10874 for ; Tue, 3 Apr 2001 14:02:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14kUc1-0006ss-00 for namedroppers-data@psg.com; Tue, 03 Apr 2001 10:29:01 -0700 Received: from 64-214-53-171.dhcp.arin.gblx.net ([64.214.53.171] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14kUc0-0006sa-00 for namedroppers@ops.ietf.org; Tue, 03 Apr 2001 10:29:00 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14kUc0-0004gd-00 for namedroppers@ops.ietf.org; Tue, 03 Apr 2001 10:29:00 -0700 Date: Tue, 3 Apr 2001 12:54:14 -0400 From: Dan Massey To: Ted Lindgreen Cc: Brian Wellington , namedroppers@ops.ietf.org, fmeshd@east.isi.edu Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Message-ID: <20010403125414.A10897@snarl.east.isi.edu> Mail-Followup-To: Ted Lindgreen , Brian Wellington , namedroppers@ops.ietf.org, fmeshd@east.isi.edu References: <200103301035.MAA20499@omval.tednet.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200103301035.MAA20499@omval.tednet.nl>; from ted@tednet.nl on Fri, Mar 30, 2001 at 12:35:04PM +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Friday, March 30, 2001 at 12:35PM, Ted Lindgreen wrote: | | But, perhaps you refer to registry testbeds? I know of two | implementations: one at CAIRN and one over here at NLnet Labs. | | The former uses the KEY+parentalSIG @child scheme. From private | communication during the last IETF (50th) with the | authors/zoneadministrators I know that most, of not all, of their | test child zones are currently BAD. They told me that they consider | their setup as very difficult, if not impossible, to maintain, and | that they are considering to adopt the parental-SIG@parent scheme. | First, I'd like to follow up on the above comment. In CAIRN, we have found that the SIG at child approach makes changing parent keys operationally difficult and we are testing the NLnet Labs approach. Currently we have some people working out the operation guidelines and revising our key registration and rollover procedures appropriately. The switch should be complete soon. With respect to the latest sig@parent draft, I think this a good idea but I have some questions/comments. Section 2.1 describes the TTL at the parent but it does not specify anything about the lifetime of the SIG at the parent. Note that an attacker can continue replaying an expired or compromised key until the parent's SIG expires. You want to avoid scenarios where the child plans to change keys once a month, but the parent creates SIGs with a lifetime of one year. Perhaps you need something like the following: The parent and child should agree upon an expiration date for the child's key. Any SIGs generated by the parent must not exceed this expiration date. In CAIRN, our current plan is that the child will send a self-signed key and the expiration date on that (self-signed) SIG is taken as the key's expiration date. Section 4 describes a scheduled key rollover. Should there be a transition period where both keys are valid? The old cairn.net plan had a short transition period where both the old and new key were active. After the transition, the zone moved to only the new key. The current draft seems to disallow this. Section 8 seems to push a lot of complexity into the resolver. To lookup the non-zone (ipsec/ssh/whatever) key for host bar.foo.com, the resolver just requests the keyset for bar.foo.com, verifies the set signed by the foo.com zone key, and returns the result. But to lookup a non-zone key for foo.com, the resolver requests the keyset for foo.com and gets only the zone keys. At this point, the resolver must be smart enough to know that the requestor wants something besides zone keys and the resovler must be smart enough to send a query for the keyset of f.i.keys.foo.com. Shouldn't the query just say keyset for foo.com, not this particular type of KEY record? Will this work for recursive queries? If the foo.com zone chooses a name other f.i.keys.foo.com, how will the resolver know what to ask for? Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 3 20:06:47 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20713 for ; Tue, 3 Apr 2001 20:06:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14kaNb-000MwN-00 for namedroppers-data@psg.com; Tue, 03 Apr 2001 16:38:31 -0700 Received: from 64-214-53-171.dhcp.arin.gblx.net ([64.214.53.171] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14kaNa-000MwH-00 for namedroppers@ops.ietf.org; Tue, 03 Apr 2001 16:38:30 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14kaNZ-0004t5-00 for namedroppers@ops.ietf.org; Tue, 03 Apr 2001 16:38:29 -0700 Date: Tue, 3 Apr 2001 19:05:52 -0400 From: Mark Kosters To: Edward Lewis Cc: Olaf Kolkman , namedroppers@ops.ietf.org Subject: Re: QST: opt-in draft and resolver behaviour Message-ID: <20010403190552.T936@netsol.com> References: <200103301002.MAA07885@kantoor.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from lewis@tislabs.com on Tue, Apr 03, 2001 at 01:00:08PM -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Tue, Apr 03, 2001 at 01:00:08PM -0400, Edward Lewis wrote: > However, there is a danger in this proposal. If the proposed set up is > transitional, this works, but what if this becomes the norm? Will we have > .com, .com(-sec), .com(-v6), .com(-v6-sec)? This would be a split-brain > DNS, something we really don't want. Your forgetting international dns. Actually, EDNS0 coupled with the okbit draft actually have forged the tools to make this happen. I'm sure more will follow. Split-brain dns seems a bit harsh. IMHO, we are starting to see that dns needs a drastic overhaul to enforce single-brain dns technically. However, today's DNS could mitigate the fracture with policy. Mark -- Mark Kosters markk@netsol.com Verisign Applied Research PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 4 06:06:47 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12590 for ; Wed, 4 Apr 2001 06:06:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14kjN1-0000hG-00 for namedroppers-data@psg.com; Wed, 04 Apr 2001 02:14:31 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14kjMz-0000h7-00 for namedroppers@ops.ietf.org; Wed, 04 Apr 2001 02:14:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14kj9u-000GQI-00 for namedroppers@ops.ietf.org; Wed, 04 Apr 2001 02:00:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104040737.JAA17863@x50.ripe.net> To: Mark Kosters , Edward Lewis cc: namedroppers@ops.ietf.org Subject: Re: QST: opt-in draft and resolver behaviour In-reply-to: Your message of Tue, 03 Apr 2001 19:05:52 EDT. <20010403190552.T936@netsol.com> References: <20010403190552.T936@netsol.com> From: Olaf Kolkman Date: Wed, 04 Apr 2001 09:37:33 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mark, Ed, others, Ed wrote: > Basically, Mark's draft offers a higher "QOS" for some names in his zone by > adding security. The benefit to the community is that this will allow a > secured .com to appear sooner as the proposal lowers the start-up cost. I can see the benefit of that... I still wonder what a secured resolver that is not RETRY-NO-SEC-AWARE (i.e. the tools we have today) should do with: RCODE=NOERROR Answer Section: 5 NS Authority Section: 3 NXT (6), SIG NXT Additional Section KEY, SIG KEY I've tried to get the answer from 2535 but in section 5.4 the RFC only addresses the case that the authority section is consistent with the answer i.e. NXDOMAIN with appropriate NXT and SIG NXT. I'm puzzled, what should a secure resolver believe, the possibly spoofed, answer section or the signed authority section? Depending on the answer to that question a not RETRY-NO-SEC-AWARE resolver might see major parts of .com. --Olaf ----------------------------------------------------- Olaf M. Kolkman | RIPE NCC ----------- | --------------- RIPE NCC | Phone: +31 20 535 4444 Singel 258 | Fax: +31 20 535 4445 1016 AB Amsterdam | http://www.ripe.net The Netherlands | OKolkman@ripe.net to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 4 14:16:20 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27971 for ; Wed, 4 Apr 2001 14:16:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14krIP-000LKG-00 for namedroppers-data@psg.com; Wed, 04 Apr 2001 10:42:17 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14krIP-000LK8-00 for namedroppers@ops.ietf.org; Wed, 04 Apr 2001 10:42:17 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14krIP-0006hV-00 for namedroppers@ops.ietf.org; Wed, 04 Apr 2001 10:42:17 -0700 Date: Wed, 4 Apr 2001 13:41:54 -0400 From: Mark Kosters To: Olaf Kolkman Cc: Edward Lewis , namedroppers@ops.ietf.org Subject: Re: QST: opt-in draft and resolver behaviour Message-ID: <20010404134154.H1988@netsol.com> References: <20010403190552.T936@netsol.com> <200104040737.JAA17863@x50.ripe.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200104040737.JAA17863@x50.ripe.net>; from OKolkman@ripe.net on Wed, Apr 04, 2001 at 09:37:33AM +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Wed, Apr 04, 2001 at 09:37:33AM +0200, Olaf Kolkman wrote: > I still wonder what a secured resolver that is not RETRY-NO-SEC-AWARE > (i.e. the tools we have today) should do with: > > RCODE=NOERROR > Answer Section: > 5 NS > Authority Section: > 3 NXT (6), SIG NXT > Additional Section > KEY, SIG KEY > > > > I've tried to get the answer from 2535 but in section 5.4 the RFC only > addresses the case that the authority section is consistent with the > answer i.e. NXDOMAIN with appropriate NXT and SIG NXT. > > I'm puzzled, what should a secure resolver believe, the possibly > spoofed, answer section or the signed authority section? Depending on > the answer to that question a not RETRY-NO-SEC-AWARE resolver might > see major parts of .com. Since 5 is not secure, it is no worse than it is today since spoofing could happen at lower levels as well. The NXT and accompaying SIG assure the resolver that the answer could not be a spoofed delegation that was secure. Mark -- Mark Kosters markk@netsol.com Verisign Applied Research PGP Key fingerprint = 1A 2A 92 F8 8E D3 47 F9 15 65 80 87 68 13 F6 48 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 5 01:09:00 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10340 for ; Thu, 5 Apr 2001 01:08:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14l1jX-000PL7-00 for namedroppers-data@psg.com; Wed, 04 Apr 2001 21:50:59 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14l1jX-000PL0-00 for namedroppers@ops.ietf.org; Wed, 04 Apr 2001 21:50:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14l1jX-000P3O-00 for namedroppers@ops.ietf.org; Wed, 04 Apr 2001 21:50:59 -0700 Message-Id: <5.0.2.1.0.20010404180931.04c92080@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 18:11:28 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNSSEC WGLC Summary: AD is secure Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The Working Group last call has completed, the working group consensus is to advance the document once one minor clarification about when AD covers Authority section has been addressed. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 5 01:09:20 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10407 for ; Thu, 5 Apr 2001 01:09:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14l1jS-000PKC-00 for namedroppers-data@psg.com; Wed, 04 Apr 2001 21:50:54 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14l1jS-000PK1-00 for namedroppers@ops.ietf.org; Wed, 04 Apr 2001 21:50:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14l1jS-000P3E-00 for namedroppers@ops.ietf.org; Wed, 04 Apr 2001 21:50:54 -0700 Message-Id: <5.0.2.1.0.20010404180638.04cfaaa0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 18:08:36 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNSSEC WGLC Sumary: DNSSEC roadmap Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The Working Group Last call has concluded. The working group consensus is to advance the document, once the author addressed few minor editorial issues raised in the last call. WG Chair is to forward document to IESG as soon as editor updates document. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 5 01:13:22 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10911 for ; Thu, 5 Apr 2001 01:13:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14l1jd-000PLy-00 for namedroppers-data@psg.com; Wed, 04 Apr 2001 21:51:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14l1jc-000PLs-00 for namedroppers@ops.ietf.org; Wed, 04 Apr 2001 21:51:04 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14l1jc-000P3Y-00 for namedroppers@ops.ietf.org; Wed, 04 Apr 2001 21:51:04 -0700 Message-Id: <5.0.2.1.0.20010404182005.04d061d0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 04 Apr 2001 18:23:21 -0400 To: namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: DNSEXT WGLC Summary: AXFR Clarify Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk This working group last call has completed. Some issues where raised during the Last Call that document editor needs to address, Better definition of "glue" as suggested by Peter Koch. few minor edits proposed by others. The working group consensus is to advance the document once these issues have been addressed. Olafur to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 5 12:39:48 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07492 for ; Thu, 5 Apr 2001 12:39:46 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lCPC-0006RY-00 for namedroppers-data@psg.com; Thu, 05 Apr 2001 09:14:42 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14lCPB-0006RS-00 for namedroppers@ops.ietf.org; Thu, 05 Apr 2001 09:14:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14lCPB-000H6K-00 for namedroppers@ops.ietf.org; Thu, 05 Apr 2001 09:14:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Miek Gieben Date: Thu, 5 Apr 2001 15:49:08 +0200 To: Dan Massey Cc: namedroppers@ops.ietf.org Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Message-ID: <20010405154908.A92004@open.nlnetlabs.nl> References: <200103301035.MAA20499@omval.tednet.nl> <20010403125414.A10897@snarl.east.isi.edu> In-Reply-To: <20010403125414.A10897@snarl.east.isi.edu>; from masseyd@isi.edu on Tue, Apr 03, 2001 at 12:54:14PM -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, Apr 03, 2001 at 12:54:14PM -0400, Dan Massey wrote: > Section 2.1 describes the TTL at the parent but it does not specify > anything about the lifetime of the SIG at the parent. Note that an > attacker can continue replaying an expired or compromised key until the > parent's SIG expires. You want to avoid scenarios where the child plans > to change keys once a month, but the parent creates SIGs with a lifetime > of one year. Perhaps you need something like the following: > > The parent and child should agree upon an expiration date for the child's > key. Any SIGs generated by the parent must not exceed this expiration date. > > In CAIRN, our current plan is that the child will send a self-signed key > and the expiration date on that (self-signed) SIG is taken as the key's > expiration date. we've added: 2.2. SIG expiration considerations The expiration lifetime of the parental SIG over the child's zone KEY MUST be kept as short as possible. A good value is one day. If there is a child KEY compromise, the SIGs for that zone are only valid for as long as the parental SIG is valid. The selfsigned zone KEY stored in the child's zone can have a much longer expiration lifetime. The SIG at the child does not serve any purpose, a lifetime measured in years is not uncommon. ----------- I don't (yet) know if it matters if a child has a shorter lifetime on the sig than the parent. > Section 4 describes a scheduled key rollover. Should there be a transition > period where both keys are valid? The old cairn.net plan had a short > transition period where both the old and new key were active. After the > transition, the zone moved to only the new key. The current draft seems > to disallow this. We are not sure how or why you come to this conclusion from section 4. The idea was, and still is, to have a short transition period where both the old and new key are active. The actions are: Child Parent Comments add new key Old key is still valid. get, check, and sign new set. Both old and new key are valid. use new key and remove old key. get, check, and sign new set. Only the new key is valid. Perhaps confusing is that from the parent point of view, both actions look (and are) identical. This is done on purpose to help automating the parent's actions. > Section 8 seems to push a lot of complexity into the resolver. To lookup > the non-zone (ipsec/ssh/whatever) key for host bar.foo.com, the resolver > just requests the keyset for bar.foo.com, verifies the set signed by the > foo.com zone key, and returns the result. But to lookup a non-zone key Not sure whether this is really true. In this example, if I were to look (without any knowledge) for an ipsec/ssh/whatever key for the host "bar.foo.com" I'd look for a key-set with the name "bar.foo.com" and not for the key-set "foo.com" (which contains the zone-key for the domain where "bar.foo.com" resides). With proper knowledge about what I want from "bar.foo.com" (ipsec/ssh/whatever) I would very likely also know the name of the key. For host with an A RR that points to the zone-name (instead of a hostname under the zone-name) and without any knowledge, this clash could happen, but then two unlikely things are happening (a system administrator putting his "ipsec/ssh" host at the top of his zone and a user whois aware of ipsec/ssh but unaware of where to look for the ipsec/ssh key-RR). So, we don't think this is a resolver problem, its a user problem, and should not by adding complexity to the resolver. Regards, Ted & Miek to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 6 08:00:27 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07834 for ; Fri, 6 Apr 2001 08:00:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lUUp-000KF5-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 04:33:43 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14lUUo-000KEz-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 04:33:42 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14lUUo-000FsD-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 04:33:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104060317.UAA13324@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Miek Gieben cc: Dan Massey , namedroppers@ops.ietf.org, gnu@toad.com Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) In-reply-to: <20010405154908.A92004@open.nlnetlabs.nl> Date: Thu, 05 Apr 2001 20:17:14 -0700 From: John Gilmore Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > For host with an A RR that points to the zone-name (instead of > a hostname under the zone-name) and without any knowledge, this > clash could happen, but then two unlikely things are happening > (a system administrator putting his "ipsec/ssh" host at the > top of his zone and a user whois aware of ipsec/ssh but unaware > of where to look for the ipsec/ssh key-RR). There's nothing wrong with putting an IPSEC KEY record at the top of a zone, along with the zone keys. That's why the keys have flags and protocol fields in them, to differentiate the various sorts that a domain name or host might have. The parent that signs the KEY records at a zone top should be prepared to sign any number of KEY records in the RRset, with any flags desired by the zone owner. The signature is defined to be on the entire RRset, there is no way for the parent to "just sign the zone key". My zone, toad.com, will one day have both a zone key and an IPSEC key. That RRset will be signed by the parent zone, assuming it isn't VeriSign. (VeriSign will probably try to charge big bucks for signing your zone, since they currently charge big bucks for signing your SSL key, and signed DNS keys could easily obsolete SSL certificates. I think they bought NSI to be able to make money either way.) Many SLDs have a web server at the SLD (e.g. slashdot.org as well as www.slashdot.org). If it supports IPSEC, its key will be there; if it supports SSL, its key could be there in the DNS, etc. There is no reason for TLD DNSSEC automation to refuse to sign RRsets that contain keys like this. And many reasons, generality and non-discrimination being the most obvious, to sign whatever keys the lower zone wants to put at its top label. It does own its zone, and should be able to control its contents... John Gilmore PS: The last few releases of the FreeS/WAN software (www.freeswan.org) contain support for fetching keys out of the DNS, and the current snapshot contains prototype code for attempting opportunistic encryption using such keys. (Opportunistic encryptors see if an IPSEC key is published for any destination IP address, and if so, attempt to negotiate a tunnel before sending any packets to it.) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 6 08:56:08 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08402 for ; Fri, 6 Apr 2001 08:56:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lVYP-000Mrm-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 05:41:29 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14lVYP-000Mrc-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 05:41:29 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14lVYP-000Hgb-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 05:41:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: namedroppers@ops.ietf.org Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) References: <20010405154908.A92004@open.nlnetlabs.nl> <200104060317.UAA13324@toad.com> Message-Id: Date: Fri, 06 Apr 2001 05:40:31 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit in general, we discourage storing non-dns data in the dns. also, it would be inadvisable to equate dns trust with trust for other things, such as sessions with hosts/services you happened to find through the dns. but i think we discussed all these things before. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 6 12:18:27 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13557 for ; Fri, 6 Apr 2001 12:18:25 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lYZC-0004YT-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 08:54:30 -0700 Received: from [63.218.17.194] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14lYZB-0004YM-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 08:54:30 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f36EwTr01751 for namedroppers@ops.ietf.org; Fri, 6 Apr 2001 10:58:29 -0400 Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.16 #1) id 14lVv2-000Nqk-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 06:04:53 -0700 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id PAA18181; Fri, 6 Apr 2001 15:04:16 +0200 (CEST) Received: from ripe.net (localhost.ripe.net [127.0.0.1]) by x50.ripe.net (8.8.8/8.8.5) with ESMTP id PAA00200; Fri, 6 Apr 2001 15:04:16 +0200 (CEST) Message-Id: <200104061304.PAA00200@x50.ripe.net> To: Miek Gieben cc: Dan Massey , namedroppers@ops.ietf.org Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) In-reply-to: Your message of Thu, 05 Apr 2001 15:49:08 +0200. <20010405154908.A92004@open.nlnetlabs.nl> References: <20010405154908.A92004@open.nlnetlabs.nl> From: Olaf Kolkman X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Fri, 06 Apr 2001 15:04:16 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi Miek, Ted, Dan and others. * 2.2. SIG expiration considerations * The expiration lifetime of the parental SIG over the * child's zone KEY MUST be kept as short as possible. A good * value is one day. Detail: Since this not only applies to TLDs, where the terminology may be a little stronger, I think above line should read be 'SHOULD be kept as'. * If there is a child KEY compromise, the * SIGs for that zone are only valid for as long as the * parental SIG is valid. The selfsigned zone KEY stored in the * child's zone can have a much longer expiration lifetime. * The SIG at the child does not serve any purpose, a lifetime * measured in years is not uncommon. * * ----------- * I don't (yet) know if it matters if a child has a shorter * lifetime on the sig than the parent. Except for key compromise I can't see a reason for very short signature validity. If there is a reason other than key compromise then the child can put a short validity period on the SIGs in its zone and sign it's zone more often. The validity period of a parental SIG is bound to a minimum set by operational parameters. That is SLA material, hence the suggested SHOULD above. * We are not sure how or why you come to this conclusion from section * 4. The idea was, and still is, to have a short transition period * where both the old and new key are active. * The actions are: * Child Parent Comments * add new key Old key is still valid. * get, check, and * sign new set. Both old and new key are valid. * use new key and * remove old key. * get, check, and * sign new set. Only the new key is valid. * * Perhaps confusing is that from the parent point of view, both * actions look (and are) identical. This is done on purpose to help * automating the parent's actions. This confusion got me to the following thought. Since the idea is more relevant to dnsops. I will post it there starting a new thread with subject "One Interaction KEY exchange", please continue the discussion on this part of the mail there. Using the ideas from draft-ietf-dnsext-parent-stores-zone-keys-00.txt this is an alternative to the key exchange mechanism described in section 4 of that draft (which is the same as in draft-ietf-dnsop-parent-sig-00.txt) I think one can restrict the parent-child interaction even more. I get to only 1 child parent interaction and an optional parent child interaction. During the rollover the parent only needs to sign keys once instead of twice. Consider the following 1. To initiate a key rollover the child replaces the KEYold by the KEYnew, signs KEYnew and the rest of the zone using the old and new KEY. Then the child signals the parent to initiate the rollover. 2. The parent fetches the new key with the double signature and verifies the SIG made with the old KEY with the old child KEY that the parent is authoritative for. If the SIG is correct the Parent publishes the new KEY with parental signature. Since all child zone data is already signed with the new key that data is also validated against the now signed KEYnew. 3. Once the child notices (or receives the optional signal by the parent) that KEYnew has been signed the child can remove the SIG made with KEYold. This is not a resigning exercise. A simple 'grep -v' will do. To put this in a hopefully readable table: __________________________________________________ KEYold is the child's old key RR KEYnew is the child's new key RR SIGparent(RR) is the parental signature over RR SIGkeyold(RR) is the child signature over RR using keyold SIGkeyold(RR) is the child signature over RR using keynew (At all times the child has signed the complete zone with the same keys as it signed the KEY record with.) _______________________________________________________________________________ Time Parent state Child state Comment _______________________________________________________________________________ 0 KEYold KEYold Before key rollover SIGparent(KEYold) SIGkeyold(KEYold) 1 KEYold KEYnew Shortly before SIGparent(KEYold) SIGkeyold(KEYnew) rollover SIGkeynew(KEYnew) This works because parent is authoritative. 2a SIGNAL to parent parent fetches KEYnew with the two sigs. It can verify SIGkeyold(KEYnew) against the data it holds itself. then replaces KEYold by KEYnew and signs 2b KEYnew KEYnew SIGparent(KEYnew) SIGkeyold(KEYnew) SIGkeynew(KEYnew) 3a SIGNAL from parent to child. Child checks signature over KEYnew and knows it can dispose of SIGkeyold(KEYnew) 3b KEYnew KEYnew SIGparent(KEYnew) SIGkeynew(KEYnew) _______________________________________________________________________________ In the mentioned draft the child always publishes one KEY RR in its KEY RRset that is signed by the parent. This is not the case in this model still all arguments in paragraph 7 apply. Paragraph 7: " There are two reasons to have of the child's zone KEY not only at the parent but also in the child's own zonefile: 1. to facilitate a key rollover 2. to prevent local lookups for local information to suffer from possible loss of access to its outside parent To cope with 1, secure aware resolvers MUST be aware that during a key-rollover there may be a conflict, and that in that case the parent always holds the active KEY set. To cope with 2, the local resolver/caching forwarder should be pre-configured with the zone-KEY and thus looks at its own zone as were it a secure entry-point. For both things to work, the zone-KEY set must be selfsigned in the child zonefile. " As far as I can tell this scheme is still immune for fake signals since the Parent will only update if it finds another key at the child then the key in it's own zone. Besides, a spoofed new keyset will not validate since it is not signed with the verifiable SIG made with the old key. To cope with point 2 from par 7 the zone administrator should configure the local resolvers and forwarding caches with the KEYnew somewhere between step 1. and step 2a. in the table I welcome your merciless responses :-) --Olaf ----------------------------------------------------- Olaf M. Kolkman | RIPE NCC ----------- | --------------- RIPE NCC | Phone: +31 20 535 4444 Singel 258 | Fax: +31 20 535 4445 1016 AB Amsterdam | http://www.ripe.net The Netherlands | OKolkman@ripe.net to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 6 12:18:45 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13587 for ; Fri, 6 Apr 2001 12:18:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lYYe-0004Y1-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 08:53:56 -0700 Received: from [63.218.17.194] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14lYYc-0004Xs-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 08:53:55 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f36EvrF01739 for namedroppers@ops.ietf.org; Fri, 6 Apr 2001 10:57:53 -0400 Received: from open.nlnetlabs.nl ([213.53.69.1]) by psg.com with esmtp (Exim 3.16 #1) id 14lVrX-000Nhg-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 06:01:16 -0700 Received: (from ted@localhost) by open.nlnetlabs.nl (8.11.2/8.11.1) id f36D14s95349; Fri, 6 Apr 2001 15:01:04 +0200 (CEST) (envelope-from ted) Message-Id: <200104061301.f36D14s95349@open.nlnetlabs.nl> From: ted@tednet.nl (Ted Lindgreen) Date: Fri, 6 Apr 2001 15:01:04 +0200 In-Reply-To: "John Gilmore's message as of Apr 6, 14:12" Reply-To: Ted.Lindgreen@tednet.nl X-Organization: TedNet BV X-Address: Omval 56, 1096HV Amsterdam, The Netherlands X-Phone: +31 20 6631060 Fax: +31 20 4684462 X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: John Gilmore , Miek Gieben Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Cc: Dan Massey , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [Quoting John Gilmore, on Apr 6, 14:12, in "Re: Signature at par ..."] > There's nothing wrong with putting an IPSEC KEY record at the top > of a zone, along with the zone keys. The problems with it are: 1. Inflexibility: Any change, update, addition, or removal of such a KEY needs the involvement of the parent. 2. Cost: It will be pretty likely, that TLDs will charge for signing KEYs, and probably more when lots of non-zone-KEYs are involved. 3. Liability: He, who signs, must make sure that he knows he is signing, and must accept some responsibility for it (otherwise the signature is worthless). I think a TLD should accept the responsibility for a proper delegation of a domain, but I don't think the TLD will accept the responsibility for local stuff like IPSEC-KEYS under those already delegated domains. I think that smart zone-administrators keep their local KEYs out of the apex' KEYset. But some education may help to get them smart. So, the question is: in a to be written "Best Current Practice document" should we be silent about this, or just make a note or remark, or discourage it, or make it a SHOULD NOT, or perhaps even a MUST NOT? I agree with Brian Wellington, that a "SHOULD NOT" will do fine. Regards, -- Ted. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 6 14:07:14 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15951 for ; Fri, 6 Apr 2001 14:07:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14la50-0008kU-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 10:31:26 -0700 Received: from [63.218.17.194] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14la4z-0008kO-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 10:31:25 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f36GZPd01114 for namedroppers@ops.ietf.org; Fri, 6 Apr 2001 12:35:25 -0400 Received: from gemma.techfak.uni-bielefeld.de ([129.70.136.103]) by psg.com with esmtp (Exim 3.16 #1) id 14lZ9Z-0006Cx-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 09:32:05 -0700 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by gemma.TechFak.Uni-Bielefeld.DE (8.9.1/8.9.1/TechFak/pk+ro20000427) with SMTP id SAA15605; Fri, 6 Apr 2001 18:32:03 +0200 (MET DST) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id SAA23547; Fri, 6 Apr 2001 18:32:03 +0200 Message-Id: <200104061632.SAA23547@grimsvotn.TechFak.Uni-Bielefeld.DE> To: Ted.Lindgreen@tednet.nl Cc: namedroppers@ops.ietf.org Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) In-reply-to: Your message of "Fri, 06 Apr 2001 15:01:04 +0200." <200104061301.f36D14s95349@open.nlnetlabs.nl> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Fri, 06 Apr 2001 18:32:03 +0200 From: Peter Koch Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The problems with it are: > > 1. Inflexibility: [...] > 2. Cost: [...] > 3. Liability: > He, who signs, must make sure that he knows he is signing, and > must accept some responsibility for it (otherwise the signature > is worthless). I think a TLD should accept the responsibility for > a proper delegation of a domain, but I don't think the TLD will > accept the responsibility for local stuff like IPSEC-KEYS under > those already delegated domains. While I agree with (1) and (2), this statement sounds dangerous. SIG RRs have a purpose defined and restricted by the "protocol" octet in the corresponding KEY RR. SIGnatures for DNSSEC purposes provide for data origin authentication. They do not say anything about applicability or correctness of the signed data. So, a child's non-zone KEY RR SIGned by the DNSSEC key of the parent zone is not 'certified' w.r.t. the protocol it is made for. The normal resolution/verification process would only accept the child's SIG for the KEY RR, wouldn't it? -Peter to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 6 14:08:20 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16004 for ; Fri, 6 Apr 2001 14:08:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14laC6-00092X-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 10:38:46 -0700 Received: from [63.218.17.194] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14laC4-00091v-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 10:38:45 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f36GgiN01215 for namedroppers@ops.ietf.org; Fri, 6 Apr 2001 12:42:44 -0400 Received: from shell.nominum.com ([204.152.187.59]) by psg.com with esmtp (Exim 3.16 #1) id 14la9L-0008w0-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 10:35:55 -0700 Received: from localhost (shell.nominum.com [204.152.187.59]) by shell.nominum.com (Postfix) with ESMTP id A7E9731914; Fri, 6 Apr 2001 10:35:39 -0700 (PDT) Date: Fri, 6 Apr 2001 19:38:29 +0200 (CEST) From: Roy Arends To: John Gilmore Cc: Miek Gieben , Dan Massey , namedroppers@ops.ietf.org, Randy Bush Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) In-Reply-To: <200104060317.UAA13324@toad.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Thu, 5 Apr 2001, John Gilmore wrote: > > For host with an A RR that points to the zone-name (instead of > > a hostname under the zone-name) and without any knowledge, this > > clash could happen, but then two unlikely things are happening > > (a system administrator putting his "ipsec/ssh" host at the > > top of his zone and a user whois aware of ipsec/ssh but unaware > > of where to look for the ipsec/ssh key-RR). > > There's nothing wrong with putting an IPSEC KEY record at the top > of a zone, along with the zone keys. That's why the keys have flags > and protocol fields in them, to differentiate the various sorts that > a domain name or host might have. There is nothing wrong with putting IPSEC KEY's in a zone. Just not at the apex. I rather want the zone to be responsible for the SIG(IPSEC KEY) than the Parent zone, which is out of my control. Next to that, a ZONE key is responsible for the whole zone, while IPSEC KEY's are associated with individual hostnames or numbers. I agree with Randy's statement that "in general, we discourage storing non-dns data in the dns.", but thats in my view unrelated to this matter. The DNS is an excellent place to store IPSEC Keys. I strongly encourage using DNS as a PKI (which DNSSEC is), when it comes to these DNS related matters. If one uses DNSSEC to authenticate data which is responsible for mapping hostnames to numbers, why not authenticate data which is responsible for mapping hostkeys to numbers (or vice versa). If I think about it a little further, I can see those as strongly related: DNSSEC for authentication, IPSEC for encryption. Where is IPSEC without DNSSEC. And what else is there to use for IPSEC key distribution ? Where is the redundant, globally distributed and widely used X-509 PKI scheme for that matter ? Regards, Roy Arends Nominum. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 6 14:09:12 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16028 for ; Fri, 6 Apr 2001 14:09:11 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14la0T-0008Yo-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 10:26:45 -0700 Received: from [63.218.17.194] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14la0R-0008WR-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 10:26:44 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f36GUOf01072 for namedroppers@ops.ietf.org; Fri, 6 Apr 2001 12:30:24 -0400 Received: from gemma.techfak.uni-bielefeld.de ([129.70.136.103]) by psg.com with esmtp (Exim 3.16 #1) id 14lYsg-0005RQ-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 09:14:38 -0700 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by gemma.TechFak.Uni-Bielefeld.DE (8.9.1/8.9.1/TechFak/pk+ro20000427) with SMTP id SAA15255; Fri, 6 Apr 2001 18:14:35 +0200 (MET DST) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id SAA23487; Fri, 6 Apr 2001 18:14:34 +0200 Message-Id: <200104061614.SAA23487@grimsvotn.TechFak.Uni-Bielefeld.DE> To: Simon Josefsson Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: NO record In-reply-to: Your message of "16 Mar 2001 21:33:05 +0100." X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Fri, 06 Apr 2001 18:14:34 +0200 From: Peter Koch Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > What I thought about was that some of the problems with NXT might not > be visible at the registry level -- like the zone walking problem. > Registries won't consider it to be an issue, they don't store SSH host > keys, personal PGP keys etc in DNS. Registries aren't the "end-users" > of DNS data. Once the registries (the infrastructure) use DNSSEC, Do you want to say that preventing zone-walking is not important for TLD registries? From what I've heard it's the other way round. While for most of the other zones it is a matter of server load, security by obscurity or even phantasy, they have blocked access to "their" zones to avoid a whole lot of non-technical problems. So, any backdoor, like in NXT, will delay deployment. -Peter to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 6 17:22:54 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20710 for ; Fri, 6 Apr 2001 17:22:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ldMk-000Hcg-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 14:01:58 -0700 Received: from [216.168.245.55] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14ldMc-000HY9-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 14:01:56 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f36L1GR01499 for namedroppers@ops.ietf.org; Fri, 6 Apr 2001 17:01:16 -0400 Received: from artemas.reachin.com ([64.14.214.33]) by psg.com with smtp (Exim 3.16 #1) id 14ld7t-000GvB-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 13:46:37 -0700 Received: (qmail 8450 invoked by uid 1233); 6 Apr 2001 13:46:01 -0700 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Apr 2001 13:46:01 -0700 Date: Fri, 6 Apr 2001 13:46:01 -0700 (PDT) From: Sam Trenholme X-Sender: To: Olafur Gudmundsson cc: Subject: Re: DNSEXT WGLC Summary: AXFR Clarify In-Reply-To: <5.0.2.1.0.20010404182005.04d061d0@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > This working group last call has completed. > Some issues where raised during the Last Call that document editor needs to > address, > Better definition of "glue" as suggested by Peter Koch. > few minor edits proposed by others. > > The working group consensus is to advance the document once these issues > have been addressed. > > Olafur I feel that section three should be rewritten. It currently says: 3. The zone transfer response If the master server is unable or unwilling to provide a zone transfer, it MUST respond with a single DNS message containing an appropriate RCODE other than NOERROR. If a zone transfer can be provided, the master server sends one or more DNS messages containing the zone data as described below. I would change this to say: 3. The zone transfer response If the master server is unable or unwilling to provide a zone transfer, it SHOULD respond with a single DNS message containing an appropriate RCODE other than NOERROR. Some master servers will prematurably disconnect an unauthoirized tcp connection to the master server. Slaves SHOULD interpret such a premature disconnect as a "Query refused" (equvalent to RCODE 5 in RFC1035 section 4.1.1). If a zone transfer can be provided, the master server sends one or more DNS messages containing the zone data as described below. This will better reflect the reality of AXFR servers which restrict access by promptly disconnecting any unauthorized third parties. - Sam to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 6 17:25:41 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20788 for ; Fri, 6 Apr 2001 17:25:39 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ldOs-000HiY-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 14:04:10 -0700 Received: from [216.168.245.55] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14ldOn-000Hhv-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 14:04:09 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f36L3VS01539 for namedroppers@ops.ietf.org; Fri, 6 Apr 2001 17:03:31 -0400 Received: from fxodpr10.extra.daimlerchrysler.com ([204.189.94.74] helo=fxodpr10.is.chrysler.com ident=firewall-user) by psg.com with esmtp (Exim 3.16 #1) id 14lccM-000FYC-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 13:14:02 -0700 Received: (from uucp@localhost) by fxodpr10.is.chrysler.com (8.9.0/8.9.0) id QAA14853 for ; Fri, 6 Apr 2001 16:10:30 -0400 (EDT) Received: from nodnsquery(129.9.202.19) by fwodpr10.is.chrysler.com via smap (V5.5) id xma014812; Fri, 6 Apr 01 16:10:26 -0400 Received: from daimlerchrysler.com (clkcdts1.is.chrysler.com [129.9.209.47]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id f36KDo621051 for ; Fri, 6 Apr 2001 16:13:50 -0400 (EDT) Message-ID: <3ACE2367.32018AA0@daimlerchrysler.com> Date: Fri, 06 Apr 2001 16:13:27 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) References: <20010405154908.A92004@open.nlnetlabs.nl> <200104060317.UAA13324@toad.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush wrote: > in general, we discourage storing non-dns data in the dns. What is the definition of "DNS data", actually? In a strict definition, even MX records and PTRs are "non-DNS data", i.e. they are not necessary to hold the DNS infrastructure together. By such a strict definition, all of DNSSEC is "non-DNS data". Does that mean it should be deprecated? Or, is "DNS data" to be defined loosely as "whatever one can legally store in the DNS"? In that case, the principle enunciated by Randy above is totally circular. A reasonable definition should lay somewhere between those two extremes. It should delineate *why* it is acceptable to e.g. store in DNS data about how an SMTP client should deliver a piece of email, whereas it is, _arguendo_, *not* acceptable to store in DNS data about how an IPSec client should encrypt and/or sign/verify packets. I wish someone would clarify this, so that whenever a new record type is shot down because it supposedly puts "non-DNS data" into the DNS, or a new use for an existing record type -- like storing IPSec keys in DNS -- is shot down for essentially the same reason, it doesn't look so much like a capricious exercise of power. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 7 01:14:39 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28816 for ; Sat, 7 Apr 2001 01:14:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lklr-0009Jy-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 21:56:23 -0700 Received: from [216.168.245.71] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14lklj-0009HT-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 21:56:18 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f373xSG01408 for namedroppers@ops.ietf.org; Fri, 6 Apr 2001 23:59:28 -0400 Received: from fxodpr10.extra.daimlerchrysler.com ([204.189.94.74] helo=fxodpr10.is.chrysler.com ident=firewall-user) by psg.com with esmtp (Exim 3.16 #1) id 14leps-000Ke2-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 15:36:09 -0700 Received: (from uucp@localhost) by fxodpr10.is.chrysler.com (8.9.0/8.9.0) id SAA28426 for ; Fri, 6 Apr 2001 18:32:41 -0400 (EDT) Received: from nodnsquery(129.9.202.19) by fwodpr10.is.chrysler.com via smap (V5.5) id xma028416; Fri, 6 Apr 01 18:32:15 -0400 Received: from daimlerchrysler.com (clkcdts1.is.chrysler.com [129.9.209.47]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id f36MZf605038 for ; Fri, 6 Apr 2001 18:35:41 -0400 (EDT) Message-ID: <3ACE44A5.B1AE79F4@daimlerchrysler.com> Date: Fri, 06 Apr 2001 18:35:17 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: AXFR Clarify References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sam Trenholme wrote: > > This working group last call has completed. > > Some issues where raised during the Last Call that document editor needs to > > address, > > Better definition of "glue" as suggested by Peter Koch. > > few minor edits proposed by others. > > > > The working group consensus is to advance the document once these issues > > have been addressed. > > > > Olafur > > I feel that section three should be rewritten. It currently says: > > 3. The zone transfer response > > If the master server is unable or unwilling to provide a zone > transfer, it MUST respond with a single DNS message containing an > appropriate RCODE other than NOERROR. > > If a zone transfer can be provided, the master server sends one or > more DNS messages containing the zone data as described below. > > I would change this to say: > > 3. The zone transfer response > > If the master server is unable or unwilling to provide a zone > transfer, it SHOULD respond with a single DNS message containing an > appropriate RCODE other than NOERROR. Some master servers will > prematurably disconnect an unauthoirized tcp connection to the master > server. Slaves SHOULD interpret such a premature disconnect as a > "Query refused" (equvalent to RCODE 5 in RFC1035 section 4.1.1). > > If a zone transfer can be provided, the master server sends one or > more DNS messages containing the zone data as described below. > > This will better reflect the reality of AXFR servers which restrict access > by promptly disconnecting any unauthorized third parties. I'd rather not reflect a *broken* reality. A premature disconnect is ambiguous: it could have been a refusal, but on the other hand, it might have been some sort of mundane networking problem. If the master refuses the zone transfer, the client has a right to unambiguously know that fact. Similarly (reiterating my previous message on the subject), if the master declines the zone transfer because it is not authoritative for the zone, the client has the right to unambiguously know it. Unambiguous behavior facilitates troubleshooting for us DNS admins in the trenches. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 7 01:14:40 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28815 for ; Sat, 7 Apr 2001 01:14:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lkkL-0009Gi-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 21:54:49 -0700 Received: from [216.168.245.71] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14lkk4-0009Ct-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 21:54:46 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f373va101313 for namedroppers@ops.ietf.org; Fri, 6 Apr 2001 23:57:36 -0400 Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14leOT-000JxK-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 15:07:49 -0700 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 702; Fri, 6 Apr 2001 15:07:45 -0700 Message-ID: <3ACE3E31.1230A53A@ehsco.com> Date: Fri, 06 Apr 2001 15:07:45 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Darcy CC: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) References: <20010405154908.A92004@open.nlnetlabs.nl> <200104060317.UAA13324@toad.com> <3ACE2367.32018AA0@daimlerchrysler.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > in general, we discourage storing non-dns data in the dns. > > What is the definition of "DNS data", actually? Actually, it's probably a good idea to develop a concept consensus. My definition is that the DNS is a lookup service similar to ARP. It just happens to be distributed across a collection of interconnected partitions in a hierarchical structure -- and there's a bunch of referral stuff to make sure queries are sent to the right place -- but in the end devices just issue targetted lookups for named resources and they expect an unambiguous and consistent answer. In that model, www.ehsco.com., mail.daimlerchrysler.com and ops.ietf.org are all peer entries in a massive *FLAT* database (they happen to be stored in separate partitions represented by a namespace but the global database itself is flat). Stuff that belongs in DNS is stuff that benefits from being used in a non-authenticated, unambiguous, lightweight lookup service which is backed by a global hierarchy of independent partitions. Stuff that doesn't belong is anything that requires authentication, is ambiguous, can be served by a standalone lookup, or consumes more valuable resources than it provides. MX RRs work okay in that model. SRV RRs work okay (if they are picked up and used to refer to richer or low-commodity-value services). Application configuration does not belong (local only). User data does not belong (requires authentication). or was your question rhetorical -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 7 01:14:41 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28840 for ; Sat, 7 Apr 2001 01:14:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lkjG-0009Cq-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 21:53:42 -0700 Received: from [216.168.245.71] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14lkil-00099p-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 21:53:37 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f373uMn01253 for namedroppers@ops.ietf.org; Fri, 6 Apr 2001 23:56:22 -0400 Received: from orchard.hamachi.org ([4.255.0.98] helo=orchard.arlington.ma.us) by psg.com with esmtp (Exim 3.16 #1) id 14le2R-000JZq-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 14:45:03 -0700 Received: by orchard.arlington.ma.us (Postfix, from userid 587) id C72572A2A; Fri, 6 Apr 2001 17:45:01 -0400 (EDT) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id BB61E1FDA; Fri, 6 Apr 2001 17:45:01 -0400 (EDT) From: Bill Sommerfeld To: Sam Trenholme Cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: AXFR Clarify In-Reply-To: Message from Sam Trenholme of "Fri, 06 Apr 2001 13:46:01 PDT." Reply-To: sommerfeld@orchard.arlington.ma.us Date: Fri, 06 Apr 2001 17:44:56 -0400 Message-Id: <20010406214501.C72572A2A@orchard.arlington.ma.us> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If the master server is unable or unwilling to provide a zone > transfer, it SHOULD respond with a single DNS message containing an > appropriate RCODE other than NOERROR. Some master servers will > prematurably disconnect an unauthoirized tcp connection to the master > server. Slaves SHOULD interpret such a premature disconnect as a > "Query refused" (equvalent to RCODE 5 in RFC1035 section 4.1.1). > > If a zone transfer can be provided, the master server sends one or > more DNS messages containing the zone data as described below. > > This will better reflect the reality of AXFR servers which restrict access > by promptly disconnecting any unauthorized third parties. A dropped connection can also occur as a result of a transient glitch (e.g., temporary server shutdown, resource shortages, etc., ), for which an appropriate action is for the client to retry in the near future (with clamped exponential backoff). - Bill to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 7 01:14:51 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28861 for ; Sat, 7 Apr 2001 01:14:50 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lkoT-0009Pz-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 21:59:05 -0700 Received: from [216.168.245.71] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14lkoN-0009NY-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 21:59:02 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f374wO801546 for namedroppers@ops.ietf.org; Sat, 7 Apr 2001 00:58:24 -0400 Received: from munnari.oz.au ([128.250.1.21]) by psg.com with smtp (Exim 3.16 #1) id 14ljgL-0006Qo-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 20:46:38 -0700 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id DA10694; Sat, 7 Apr 2001 13:45:08 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Sam Trenholme Cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: AXFR Clarify In-Reply-To: Your message of "Fri, 06 Apr 2001 13:46:01 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Apr 2001 13:44:57 +1000 Message-Id: <18054.986615097@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 6 Apr 2001 13:46:01 -0700 (PDT) From: Sam Trenholme Message-ID: | I would change this to say: I know what you're getting at, and why, but that isn't the best solution. Better would be... 3. The zone transfer response If the master server is unable or unwilling to provide a zone transfer, it MUST respond with a single DNS message containing an appropriate RCODE other than NOERROR. Slave servers should note however, that there are some implementations where a master server will simply close the connection when no access to the zone is to be provided to the slave. Slaves SHOULD interpret a premature graceful close of a TCP connection as "Query Refused" (equvalent to RCODE 5 in RFC1035 section 4.1.1). If a zone transfer can be provided, the master server sends one or more DNS messages containing the zone data as described below. Aside from formatting, there are two differences there from your text. First, only "graceful close" is to be treated as "refused" - TCP connections can be reset for all kinds of other reasons (master rebooted at just the wrong time, etc) - none of that usually means "refused". And second, there's no need to make it seem that there's ever a rational reason for the master to do this (by changing MUST to SHOULD) - keep the requirement that the server respond properly - just add the advise to implementors that there are broken servers, and how they should be treated. kre ps: I wish we could get back to 1034/1035 terminology - servers are primary and secondary, not master & slave, "master" applies to the zone file held by the primary server. (Unfortunately, there are a few places where the text slipped, and "master" is used where "primary" would really have been better). 1034/1035 don't mention "slave" at all, for anything. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 7 01:14:56 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28878 for ; Sat, 7 Apr 2001 01:14:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lkpm-0009Vr-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 22:00:26 -0700 Received: from [216.168.245.71] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14lkph-0009Sa-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 22:00:24 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f374xle01572 for namedroppers@ops.ietf.org; Sat, 7 Apr 2001 00:59:47 -0400 Received: from munnari.oz.au ([128.250.1.21]) by psg.com with smtp (Exim 3.16 #1) id 14ljWm-00061z-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 20:37:24 -0700 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id DA12038; Sat, 7 Apr 2001 13:33:35 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Kevin Darcy Cc: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) In-Reply-To: Your message of "Fri, 06 Apr 2001 16:13:27 -0400." <3ACE2367.32018AA0@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Apr 2001 13:33:24 +1000 Message-Id: <18008.986614404@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 06 Apr 2001 16:13:27 -0400 From: Kevin Darcy Message-ID: <3ACE2367.32018AA0@daimlerchrysler.com> | What is the definition of "DNS data", actually? When I saw Randy's message, I was going to send almost an identical reply. Personally, I have no problem with storing almost any kind of data in the DNS, provided that it makes technical sense to put it there (that is, given the limited available space for RDATA, so for example, storing images in the DNS wouldn't be rational) and provided that the DNS is the sane mechanism for the data and the way it is to be retrieved (so anything that you want to be able to find based upon an imprecise query, or a query that isn't easily mapped into a domain name, should go someplace else). Also the data needs to be of unrestricted access (DNS data is available to the universe, despite the misguided efforts of some to provide implementation defined access restrictions). But where it makes sense to use a domain name to fetch a small amount of public data, then I don't mind defining an RR code for the thing. About all that is left is to decide whether the definition of the object is precise enough that we know what is really being fetched and how to use it, and whether it is realistically going to be used enough to make it worth the bother of doing the assignment (there have been cases proposed where I though the thing being defined so useless that it just wasn't worth the effort). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 7 01:15:18 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28913 for ; Sat, 7 Apr 2001 01:15:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lkp6-0009Rn-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 21:59:44 -0700 Received: from [216.168.245.71] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14lkp0-0009Q7-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 21:59:41 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f374x2T01560 for namedroppers@ops.ietf.org; Sat, 7 Apr 2001 00:59:02 -0400 Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.16 #1) id 14ljft-0006QX-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 20:46:09 -0700 Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.2/8.11.2) with ESMTP id f373jnT70045; Sat, 7 Apr 2001 13:45:49 +1000 (EST) (envelope-from marka@nominum.com) Message-Id: <200104070345.f373jnT70045@drugs.dv.isc.org> To: Sam Trenholme Cc: Olafur Gudmundsson , namedroppers@ops.ietf.org From: Mark.Andrews@nominum.com Subject: Re: DNSEXT WGLC Summary: AXFR Clarify In-reply-to: Your message of "Fri, 06 Apr 2001 13:46:01 MST." Date: Sat, 07 Apr 2001 13:45:49 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > > This working group last call has completed. > > Some issues where raised during the Last Call that document editor needs to > > address, > > Better definition of "glue" as suggested by Peter Koch. > > few minor edits proposed by others. > > > > The working group consensus is to advance the document once these issues > > have been addressed. > > > > Olafur > > I feel that section three should be rewritten. It currently says: > > 3. The zone transfer response > > If the master server is unable or unwilling to provide a zone > transfer, it MUST respond with a single DNS message containing an > appropriate RCODE other than NOERROR. > > If a zone transfer can be provided, the master server sends one or > more DNS messages containing the zone data as described below. > > I would change this to say: > > 3. The zone transfer response > > If the master server is unable or unwilling to provide a zone > transfer, it SHOULD respond with a single DNS message containing an > appropriate RCODE other than NOERROR. Some master servers will > prematurably disconnect an unauthoirized tcp connection to the master > server. Slaves SHOULD interpret such a premature disconnect as a > "Query refused" (equvalent to RCODE 5 in RFC1035 section 4.1.1). > > If a zone transfer can be provided, the master server sends one or > more DNS messages containing the zone data as described below. > > This will better reflect the reality of AXFR servers which restrict access > by promptly disconnecting any unauthorized third parties. > Such nameservers already violate the spirit of 103[45], make debugging configurations harder and are just plain rude. We don't need to encode bad behaviour. If existing configurations don't meet this document, that is fine. It's no different that what it is today. However we don't want new nameservers to have the same problems. Conformance to this doc should be a MUST. This document is doing two things: 1 stating what you should be doing. 2 stating what potential problems you can have interoperating with old servers which are not conforming to this document. The quoted paragraph falls into category 1. Mark > - Sam > > > > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 7 01:16:13 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29008 for ; Sat, 7 Apr 2001 01:16:12 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lkqt-0009ZZ-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 22:01:35 -0700 Received: from [216.168.245.71] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14lkqm-0009Yw-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 22:01:32 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3750sB01598 for namedroppers@ops.ietf.org; Sat, 7 Apr 2001 01:00:54 -0400 Received: from shell.nominum.com ([204.152.187.59]) by psg.com with esmtp (Exim 3.16 #1) id 14lij9-0003pA-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 19:45:27 -0700 Received: from localhost (shell.nominum.com [204.152.187.59]) by shell.nominum.com (Postfix) with ESMTP id 408343190E; Fri, 6 Apr 2001 19:45:13 -0700 (PDT) Date: Sat, 7 Apr 2001 04:48:02 +0200 (CEST) From: Roy Arends To: Sam Trenholme Cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: AXFR Clarify In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On Fri, 6 Apr 2001, Sam Trenholme wrote: > > This working group last call has completed. > > Some issues where raised during the Last Call that document editor needs to > > address, > > Better definition of "glue" as suggested by Peter Koch. > > few minor edits proposed by others. > > > > The working group consensus is to advance the document once these issues > > have been addressed. > > > > Olafur > > I feel that section three should be rewritten. It currently says: > > 3. The zone transfer response > > If the master server is unable or unwilling to provide a zone > transfer, it MUST respond with a single DNS message containing an > appropriate RCODE other than NOERROR. > > If a zone transfer can be provided, the master server sends one or > more DNS messages containing the zone data as described below. > > I would change this to say: > > 3. The zone transfer response > > If the master server is unable or unwilling to provide a zone > transfer, it SHOULD respond with a single DNS message containing an > appropriate RCODE other than NOERROR. Some master servers will > prematurably disconnect an unauthoirized tcp connection to the master > server. Slaves SHOULD interpret such a premature disconnect as a > "Query refused" (equvalent to RCODE 5 in RFC1035 section 4.1.1). > > If a zone transfer can be provided, the master server sends one or > more DNS messages containing the zone data as described below. > > This will better reflect the reality of AXFR servers which restrict access > by promptly disconnecting any unauthorized third parties. I strongly disagree, If a nameserver stumbles upon a query-type (for instance 252 (axfr)) that it can (or will) not compute, it must answer with an appropriate RCODE other than NOERROR. Note that AXFR request responses may not be TCP bound at all, if the amount of data is within the 512 byte UDP boundary. If some master servers will premature disconnect an unauthorized tcp connection to itself, the "timeout" will take care of the issue. IMHO not a valid protocol change. Regards, Roy Arends Nominum to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 7 01:19:52 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29419 for ; Sat, 7 Apr 2001 01:19:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lksf-0009eo-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 22:03:25 -0700 Received: from [216.168.245.71] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14lksZ-0009e6-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 22:03:23 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3752jO01632 for namedroppers@ops.ietf.org; Sat, 7 Apr 2001 01:02:45 -0400 Received: from fxshpr06.extra.daimlerchrysler.com ([208.154.80.165] helo=fxshpr06.is.chrysler.com ident=firewall-user) by psg.com with esmtp (Exim 3.16 #1) id 14lhjU-00015I-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 18:41:44 -0700 Received: (from uucp@localhost) by fxshpr06.is.chrysler.com (8.9.0/8.9.0) id VAA23536 for ; Fri, 6 Apr 2001 21:36:44 -0400 (EDT) Received: from nodnsquery(129.9.202.19) by fwshpr06.is.chrysler.com via smap (V5.5) id xma023528; Fri, 6 Apr 01 21:36:07 -0400 Received: from daimlerchrysler.com (clkcdts1.is.chrysler.com [129.9.209.47]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id f371f4611969 for ; Fri, 6 Apr 2001 21:41:04 -0400 (EDT) Message-ID: <3ACE7019.7CFE8F72@daimlerchrysler.com> Date: Fri, 06 Apr 2001 21:40:41 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) References: <20010405154908.A92004@open.nlnetlabs.nl> <200104060317.UAA13324@toad.com> <3ACE2367.32018AA0@daimlerchrysler.com> <3ACE3E31.1230A53A@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eric A. Hall wrote: > > > in general, we discourage storing non-dns data in the dns. > > > > What is the definition of "DNS data", actually? > > Actually, it's probably a good idea to develop a concept consensus. > > My definition is that the DNS is a lookup service similar to ARP. It just > happens to be distributed across a collection of interconnected partitions > in a hierarchical structure -- and there's a bunch of referral stuff to > make sure queries are sent to the right place -- but in the end devices > just issue targetted lookups for named resources and they expect an > unambiguous and consistent answer. > > In that model, www.ehsco.com., mail.daimlerchrysler.com and ops.ietf.org > are all peer entries in a massive *FLAT* database (they happen to be > stored in separate partitions represented by a namespace but the global > database itself is flat). > > Stuff that belongs in DNS is stuff that benefits from being used in a > non-authenticated, unambiguous, lightweight lookup service which is backed > by a global hierarchy of independent partitions. Stuff that doesn't belong > is anything that requires authentication, is ambiguous, can be served by a > standalone lookup, or consumes more valuable resources than it provides. This is possibly too narrow a definition. With DNSSEC, authentication of queries is possible and perhaps even desirable. As for "ambiguous", what exactly do you mean by that term? It is perfectly normal and acceptable for different clients to get different answers to the same DNS question (depending on their source address and/or which DNS server they ask, when they ask it, etc.). Does that constitute "ambiguity"? As for "consumes more valuable resources than it provides", we'll wait to see how efficient DNSSEC proves to be :-) > MX RRs work okay in that model. SRV RRs work okay (if they are picked up > and used to refer to richer or low-commodity-value services). Application > configuration does not belong (local only). User data does not belong > (requires authentication). > > or was your question rhetorical Would I ask a rhetorical question? :-) No, actually, it wasn't rhetorical. I'm looking for a *principled* standard by which to judge what kinds of data should go into DNS and what kinds of data shouldn't. Seems to me the determinations have been pretty much _ad_hoc_ thusfar. I should perhaps point out that I have no vested interest here. I have no proposals in mind for new resource-record types, or new uses for existing types, that could reasonably be considered "non-DNS data". I just don't like arbitrariness or even the appearance of same. Question: wasn't it the whole *point* of DNSSEC to offer a secure key repository to applications? It's hard to believe that so much time and effort would be expended just to secure DNS *itself*... - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 7 01:21:58 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29657 for ; Sat, 7 Apr 2001 01:21:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lkuT-0009mA-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 22:05:17 -0700 Received: from [216.168.245.71] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14lktz-0009i5-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 22:05:05 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3754Dg01653 for namedroppers@ops.ietf.org; Sat, 7 Apr 2001 01:04:13 -0400 Received: from df-inet1.exchange.microsoft.com ([131.107.8.8]) by psg.com with esmtp (Exim 3.16 #1) id 14lha8-0000dS-00 for namedroppers@psg.com; Fri, 06 Apr 2001 18:32:04 -0700 Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831); Fri, 6 Apr 2001 18:32:50 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 06 Apr 2001 17:31:59 -0700 (Pacific Daylight Time) Received: from df-max.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Fri, 6 Apr 2001 18:31:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4683.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: comments on mnds-00 Date: Fri, 6 Apr 2001 18:31:58 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C0762657405146FDC@DF-BOWWOW.platinum.corp.microsoft.com> Thread-Topic: comments on mnds-00 Thread-Index: AcC3GHUD9Cw6ohy9Q2uKZba7zzrvFgH3iRNg From: "Levon Esibov" To: "Erik Guttman" , Cc: , "Dave Thaler" , "Bernard Aboba" , X-OriginalArrivalTime: 07 Apr 2001 01:31:59.0265 (UTC) FILETIME=[8A02C110:01C0BF02] Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA29657 Erik, Thanks for very thoughtful comments! I encourage namedroppers readers to review my responses below, since in many cases Eric suggests modifications that once already were rejected by the meeting that took place in Adelaide last year, but I don't have arguments against some of the Eric's suggestions, in fact, I support some of them. To ensure that we are not circling around the same arguments, those of you, who participated in the Adelaide's meeting and had strong opinion about the issues discussed below, please, make sure that you send your comments. > >A sender sends multicast DNS query for any legal Type of > resource record > >(e.g. A, PTR, etcà) for a name within the ".local.arpa." > domain to the > ^ > word cruft > >LINKLOCAL address. Sure. I'll fix this. > If the name is in .local.arpa that indicates it MUST be multicast. > That is, there is no sense in unicasting this request elsewhere > since it will have only local significance. > > The converse is not true: Why can't a host multicast a request for > a host name which is not qualified with '.local.arpa'? If this is > not allowed, it severely limits the utility of mdns. FQDNs > are present > in many protocols, configuration files, documents... If these cannot > be resolved locally, what is the point of mdns? I don't see any problems with sending multicast queries for the names that don't end with ".local.arpa". In fact my original proposal didn't have such limitation, but then the draft was updated according to recommendations of the initiative group that met in Adelaide a year ago. I suggest that proponents of that recommendation should speak up. > >In this example (unless this > >limitation introduced) the multicast query for an A record > for the name > >"child.host.example.com.local.arpa." would cause two authoritative > >responses: name error received from > "host.example.com.local.arpa.", and > >requested A record - from "child.host.example.com.local.arpa.". > > 1. Multicast DNS servers should not send error replies - these > should be dropped. > > Multicast discovery protocols which require all listeners to > respond with a unicast error reply cause broadcast storms. > This is undesirable on a link-local network. If mdns were > ever to be defined at a larger scope (say administrative > scope) in the future, this would be completely unacceptable. > The protocol has to return correct replies to correct > requests, that's all. I agree with you. Probably this part of the draft is not written clear enough. The draft : "Responders MUST respond to multicast queries to those and only those names for which they are authoritative. ... ... In conventional DNS terminology a DNS server authoritative for a zone is authoritative for all the domain names under the zone root except for the branches delegated into separate zones. Contrary to conventional DNS terminology, a responder is authoritative only for the zone root. For example the host "host.example.com.local.arpa." is not authoritative for the name "child.host.example.com.local.arpa."" Please, feel free to suggest clarifications to the text. > >The responder includes in the additional and authority section of the > >response the same records, as a DNS server would insert in > the response > >to the unicast DNS query. > > Please reword: > > The responder SHOULD include an NS record for itself in the authority > section and an A record in the additional section of the response. > This is behavior is consistent with existing DNS server > implementations. I don't agree with your suggestion. It is not the purpose of this draft to specify which records should be included in the additional and authority sections of the response to a query. The set of records that should be included in the additional and authority sections is specified elsewhere. > > >Sender MUST anticipate receiving no replies to some > multicasted queries, > >in the event that no responders are available within the multicast > >scope, or in the event that no positive non-null responses > exist to the > >transmitted query. > > A responder must not send anything except a positive non-null > response. > That is, a null response or a negative response MUST NOT be sent. The > argument for this is given above. Agree. As I mentioned above, the draft is probably not very about this. Suggestions on how to improve the text are welcome. > >If no positive response is received, a resolver treats it as > a response > >that no records of the specified type and class for the > specified name > >exist (NXRRSET), which SHOULD be cached for a period that SHOULD NOT > >exceed 5 seconds. > > Why define this behavior? This is complicated and will make little > difference when a single mdns request is already takes a few seconds > to complete. This behavior will prevent poorly written application from resending the same query after it receives NXRRSET. I agree with your comment that if sender resends the same query 5 times, with exponentially increasing interval between them, then the mdsn query resolution may take a few seconds, what makes negative caching not that useful. May be we should recommend less number retries (e.g. 3 instead of 5)? In this case we'll suppress larger number of useless multicast queries. > >Sender MUST anticipate receiving multiple replies to the same > >multicasted query, in the event that several multicast DNS enabled > >computers receive the query and respond with valid answers. > When this > >occurs, the responses MAY first be concatenated, and then > treated in the > >same manner that multiple RRs received from the same DNS > server would, > >ordinarily. > > With 'MAY' an existing resolver can simply use the mdns address and > accept the first result, where an enhanced resolver would do something > slicker. The problem here is you don't get back the same info as you > would from a DNS server. Collecting the duplicates and collating > them requires additional code, but perhaps it 'SHOULD' be done. Sounds reasonable. > > >Any device whose domain search configuration contains ".local.arpa." > >domain is configured to behave as "responder". > > Why should this behavior be configured using the search path? > Why should the resolver search path IN ANY CASE determine the > multicast dns server behavior? I don't have any argument in favor of using the search path to enable/disable device to use mDNS. Original version of the draft suggested use of a new parameter, but the initiative group that met in Adelaide a year ago recommended to use the search path. > I suggest that, just as other zeroconf protocols, a host may either > run this zeroconf protocol service or not. This need not be something > that can be turned off by DHCP, nor should it be - any more than v4LL > autoconfiguration. I don't agree. There must be a way to disable mDNS through DHCP, to prevent mDNS traffic in well managed (i.e. non-zero-conf) corporate environments, where the last thing users need is more network traffic. > >It is not expected that a device "host.example.com." will be manually > >configured to have additional name > "host.example.com.local.arpa." when > >it is configured to use multicast DNS. Instead, a responder > with a name > >"host.example.com." configured with ".local.arpa." suffix in > its domain > >search configuration is authoritative for the name > >"host.example.com.local.arpa.". I.e. when responder with the name > >"host.example.com." receives an A type query for the name > >"host.example.com.local.arpa." it authoritatively responds > to the query. > > Why attache the suffix '.local.arpa' stuff? Why not just multicast > a request for 'host.example.com'? As I mentioned above, I don't see any problems with sending multicast queries for the names that don't end with ".local.arpa". > >The same device may use multicast DNS queries for the name > resolution of > >the names ending with ".local.arpa.", and unicast DNS > queries for name > >resolution of all other names. > > Why can't a resolver multicast *any* request as a last resort. For > example if no DNS server responds. This would be the effect of > putting if the link-local mdns address as the last nameserver entry > in /etc/resolv.conf. I think this makes tremendous sense and provides > the primary benefit of using mdns: reliability. I don't mind using your proposal as long as there is a way to disable such behavior through DHCP in the corp environment to reduce unnecessary traffic. > > >It is required to verify the uniqueness of the host DNS name > when a host > >boots, when its name is changed, or when it is configured to use > >multicast DNS (such as when the domain search option is changed to > >include ".local.arpa."). > > Why is it required? I could desire to have multiple devices respond > to the same name for some conceivable application (the devices are > all redundent identical stateless doodads, for example.) > > This may be desirable, but at most a SHOULD. Agree. > > >A gratuitous name resolution query SHOULD be done to check for a name > >conflict. This is done by having the resolver send a > multicast query for > >a SOA type query for its own name (i.e. for the name it is > authoritative > >for). > > Why not just look for an A or PTR RR. The original version of the draft suggested use of A type query to detect name conflict, but the initiative group that met in Adelaide a year ago recommended to use the SOA type query. I don't see much of a benefit in SOA, since it doesn't solve the problem and if the sender receives a response to the SOA query, it doesn't know whether the response was sent by the sender's another network connection or by another device that has name in conflict. The sender will have to issue additional A type query (if A record is not included in the additional section in the response to the SOA query) to detect whether there is a device with conflicting name. Said this I agree with your comment to change this section to use A query. If there are any opponents to make this modification, please, speak up. > If another mdns server > respondes to > the request, there's a conflict. Do mdns servers need to > support SOA RR > requests? Multicast DNS specification should not make any assumptions about the type of records that could be queried over mDNS, but it doesn't mean that multiple devices can't respond to the same query. Name conflict (which this section of the draft attempts to prevent) refers to the device hostnames only. > The zeroconf requirements only state A and PTRs > are required. > > >A host that has detected a name conflict MUST NOT use the name. > > SHOULD NOT agree > > >Note that this name conflict detection mechanism doesn't prevent name > >conflicts when previously separate networks are connected by > a bridge. > >Name conflict in such situation is detected when a sender > receives more > >than one response to its multicasted DNS query. > > This is not catastrophic. This is like getting back multiple results. agree > > > >8. Acknowledgements > > > >The authors would like to thank Stuart Cheshire, Michael Patton, Erik > >Guttman, Olafur Gudmundsson, Thomas Narten, Mark Andrews, > Erik Nordmark, > >Myrong Hattig, Bill Manning and James Gilroy for comments on > this draft. > > I believe that this section should read: > > This work builds upon original work done on multicast DNS by > Bill Manning > and Bill Woodcock. The authors gratefully acknowledge their > contribution > to the current specification. Constructive input has also > been received > from Mark Andrews, Stuart Cheshire, James Gilroy, Olafur Gudmundsson, > Erik Guttman, Myron Hattig, Thomas Narten and Erik Nordmark. Sure. I'll update the Acknowledgements section in the next version of the draft. Thanks, Levon. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 7 01:50:48 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02959 for ; Sat, 7 Apr 2001 01:50:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14lkoT-0009Pz-00 for namedroppers-data@psg.com; Fri, 06 Apr 2001 21:59:05 -0700 Received: from [216.168.245.71] (helo=h236.s254.netsol.com) by psg.com with esmtp (Exim 3.16 #1) id 14lkoN-0009NY-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 21:59:02 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f374wO801546 for namedroppers@ops.ietf.org; Sat, 7 Apr 2001 00:58:24 -0400 Received: from munnari.oz.au ([128.250.1.21]) by psg.com with smtp (Exim 3.16 #1) id 14ljgL-0006Qo-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 20:46:38 -0700 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id DA10694; Sat, 7 Apr 2001 13:45:08 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Sam Trenholme Cc: Olafur Gudmundsson , namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: AXFR Clarify In-Reply-To: Your message of "Fri, 06 Apr 2001 13:46:01 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 07 Apr 2001 13:44:57 +1000 Message-Id: <18054.986615097@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 6 Apr 2001 13:46:01 -0700 (PDT) From: Sam Trenholme Message-ID: | I would change this to say: I know what you're getting at, and why, but that isn't the best solution. Better would be... 3. The zone transfer response If the master server is unable or unwilling to provide a zone transfer, it MUST respond with a single DNS message containing an appropriate RCODE other than NOERROR. Slave servers should note however, that there are some implementations where a master server will simply close the connection when no access to the zone is to be provided to the slave. Slaves SHOULD interpret a premature graceful close of a TCP connection as "Query Refused" (equvalent to RCODE 5 in RFC1035 section 4.1.1). If a zone transfer can be provided, the master server sends one or more DNS messages containing the zone data as described below. Aside from formatting, there are two differences there from your text. First, only "graceful close" is to be treated as "refused" - TCP connections can be reset for all kinds of other reasons (master rebooted at just the wrong time, etc) - none of that usually means "refused". And second, there's no need to make it seem that there's ever a rational reason for the master to do this (by changing MUST to SHOULD) - keep the requirement that the server respond properly - just add the advise to implementors that there are broken servers, and how they should be treated. kre ps: I wish we could get back to 1034/1035 terminology - servers are primary and secondary, not master & slave, "master" applies to the zone file held by the primary server. (Unfortunately, there are a few places where the text slipped, and "master" is used where "primary" would really have been better). 1034/1035 don't mention "slave" at all, for anything. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 7 10:52:49 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14866 for ; Sat, 7 Apr 2001 10:52:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ltgH-00099T-00 for namedroppers-data@psg.com; Sat, 07 Apr 2001 07:27:13 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14ltgG-00096J-00 for namedroppers@ops.ietf.org; Sat, 07 Apr 2001 07:27:12 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f37EICI12982 for namedroppers@ops.ietf.org; Sat, 7 Apr 2001 10:18:12 -0400 (EDT) Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14llxE-000D5Q-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 23:12:12 -0700 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 525 for ; Fri, 6 Apr 2001 23:12:09 -0700 Message-ID: <3ACEAFB9.3CC3D1E9@ehsco.com> Date: Fri, 06 Apr 2001 23:12:09 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) References: <20010405154908.A92004@open.nlnetlabs.nl> <200104060317.UAA13324@toad.com> <3ACE2367.32018AA0@daimlerchrysler.com> <3ACE3E31.1230A53A@ehsco.com> <3ACE7019.7CFE8F72@daimlerchrysler.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Stuff that doesn't belong is anything that requires authentication, >> is ambiguous, can be served by a standalone lookup, or consumes more >> valuable resources than it provides. > As for "ambiguous", what exactly do you mean by that term? I mean multiple things but essentially I mean that DNS shouldn't be viewed as a cheap distributed database (eg, "lets make an Internet filesystem of MIME objects, stored in DNS!"). The usage of a specific RR should be unambiguous. The usage of A RRs is pretty much unambiguous. The usage of WKS tends to be somewhat ambiguous due to system-specific implementation issues (some have used it as a supplement for /etc/services). The multiple usages of TXT makes it extremely ambiguous. The datatypes should also be unambiguous. Free text is ambiguous; typed-data (like IPv4 Addresses) is unambiguous. Some free text usages are okay as long as the usage is unambiguous ("display only" as a rule is unambiguous). There should never be a general purpose "8-bit-binary" RR or data-type defined as that would be ambiguous, which is counter purpose to a lookup protocol. The EDNS kitchen-sink datatype is a good example. In essence, the data returned from a lookup should be used for automated processes like fetching an IP address or the list of mail servers for a host, and not for reading the of MP3 song titles and artists that are stored in a specified path on a specified host (no this is not a proposal for the My-MP3-Files RR). > It is perfectly normal and acceptable for different clients to get > different answers to the same DNS question (depending on their source > address and/or which DNS server they ask, when they ask it, etc.). > Does that constitute "ambiguity"? Not by my definition. But since you brought it up, clients should expect to get the same answer set from the same server, within reason. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Apr 8 08:37:19 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08560 for ; Sun, 8 Apr 2001 08:37:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mE11-0004QJ-00 for namedroppers-data@psg.com; Sun, 08 Apr 2001 05:09:59 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mE0x-0004QB-00 for namedroppers@ops.ietf.org; Sun, 08 Apr 2001 05:09:55 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f38C0sc00710 for namedroppers@ops.ietf.org; Sun, 8 Apr 2001 08:00:54 -0400 (EDT) Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14m4YY-000E2T-00 for namedroppers@ops.ietf.org; Sat, 07 Apr 2001 19:04:00 -0700 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 689 for ; Sat, 7 Apr 2001 19:03:44 -0700 Message-ID: <3ACFC6FF.42237B18@ehsco.com> Date: Sat, 07 Apr 2001 19:03:43 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) References: <18008.986614404@mundamutti.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > Personally, I have no problem with storing almost any kind of data in > the DNS I'm sure you didn't mean the example I'm about to give but I am taking the bait anyway. :) The problem with being too liberal wrt DNS data is that it dillutes the effectiveness of the lookup service. If for example under the "anything goes" principle somebody defines the dreaded My-MP3-Files RR which returns records for every MP3 cataloged on a specific server, it is possible for thousands of RRs to be returned. However, those answers will also get returned whenever the associated domain name is queried with a qtype=* Ergo, everytime sendmail tries to enumerate the RRs for a destination domain name, it would get overloaded with My-MP3-Files RRs, which would either dillute or completely destroy the usability of DNS for simple lookup functions. That's maybe an exaggeration, but maybe it isn't, and really it will all depend on how liberal the line is drawn. I advocate hard-liner positioning in this matter. Heck it might even be worth a policy thing, no RRs get approved without passing through DNSEXT first. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Apr 8 08:37:45 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08571 for ; Sun, 8 Apr 2001 08:37:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mE28-0004SM-00 for namedroppers-data@psg.com; Sun, 08 Apr 2001 05:11:08 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mE1z-0004RZ-00 for namedroppers@ops.ietf.org; Sun, 08 Apr 2001 05:10:59 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f38C1uA00724 for namedroppers@ops.ietf.org; Sun, 8 Apr 2001 08:01:56 -0400 (EDT) Received: from nordic.cisco.com ([64.103.48.45] helo=cisco.com) by psg.com with esmtp (Exim 3.16 #1) id 14lmT9-000EPW-00 for namedroppers@ops.ietf.org; Fri, 06 Apr 2001 23:45:12 -0700 Received: from [192.168.1.29] (ssh-ams1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id IAA03656; Sat, 7 Apr 2001 08:37:26 +0200 (MET DST) Date: Sat, 07 Apr 2001 08:37:26 +0200 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Robert Elz , Kevin Darcy cc: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) Message-ID: <2324804.986632646@[192.168.1.29]> In-Reply-To: <18008.986614404@mundamutti.cs.mu.OZ.AU> References: <18008.986614404@mundamutti.cs.mu.OZ.AU> X-Mailer: Mulberry/2.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On 01-04-07 13.33 +1000 Robert Elz wrote: > Personally, I have no problem with storing almost any kind of data in the > DNS, provided that it makes technical sense to put it there (that is, > given the limited available space for RDATA, so for example, storing > images in the DNS wouldn't be rational) and provided that the DNS is the > sane mechanism for the data and the way it is to be retrieved (so > anything that you want to be able to find based upon an imprecise query, > or a query that isn't easily mapped into a domain name, should go > someplace else). Also the data needs to be of unrestricted access (DNS > data is available to the universe, despite the misguided efforts of some > to provide implementation defined access restrictions). > > But where it makes sense to use a domain name to fetch a small amount of > public data, then I don't mind defining an RR code for the thing. About > all that is left is to decide whether the definition of the object is > precise enough that we know what is really being fetched and how to use > it, and whether it is realistically going to be used enough to make it > worth the bother of doing the assignment (there have been cases proposed > where I though the thing being defined so useless that it just wasn't > worth the effort). I agree completely. I just want to let you DNS people know that I try to tell the wg's in my (Applications) area that it is ok to store references to data in the DNS if the references are to be looked up given the unique name of the owner. Searches is a nono, and storing actual data is also a nono. That kre above accepts some small amount of data which is tied to the zone in DNS is something which I also think is ok, but I don't tell people in the beginning of the "negotiation" :-) paf to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Apr 8 08:38:06 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08593 for ; Sun, 8 Apr 2001 08:38:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mE06-0004Ow-00 for namedroppers-data@psg.com; Sun, 08 Apr 2001 05:09:02 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mE03-0004OW-00 for namedroppers@ops.ietf.org; Sun, 08 Apr 2001 05:08:59 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f38Bxvo00697 for namedroppers@ops.ietf.org; Sun, 8 Apr 2001 07:59:57 -0400 (EDT) Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14lo8O-000Jm0-00 for namedroppers@ops.ietf.org; Sat, 07 Apr 2001 01:31:53 -0700 Received: (qmail 4911 invoked by uid 1001); 7 Apr 2001 08:26:44 -0000 Date: 7 Apr 2001 08:26:44 -0000 Message-ID: <20010407082644.2890.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: AXFR Clarify References: <3ACE44A5.B1AE79F4@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I am a DNS implementor. My DNS implementation is used at thousands of sites, including the third-largest and fourth-largest domain hosting companies on the Internet. I have raised several objections to this document, including an undisputed claim that the document violates RFC 2119 section 6. (One of my messages was discarded by Randy Bush, the namedroppers censor, but is available through http://cr.yp.to/djbdns/namedroppers.html#2001-03-17.) There have been a few responses to my objections. I am not at all satisfied with the responses. Sam Trenholme is another DNS implementor, and he has stated elsewhere that he isn't satisfied either. Gudmundsson claims that this document is, with minor changes, the WG consensus. I don't see any justification for that claim. I would like to see a rational discussion of this document by the WG. Kevin Darcy writes: > If the master refuses the zone transfer, the client has a right to > unambiguously know that fact. Wrong. Zone transfers are between a master and its authorized slaves. Unauthorized clients have no rights. > A premature disconnect is ambiguous: Irrelevant. If the AXFR fails, for whatever reason, the client tries again later. The reason doesn't matter. Yes, there are protocols with permanent errors. (``Bounce this mail immediately; I will never accept it.'') But AXFR is not one of those protocols. In particular, it would be silly for an AXFR client to treat REFUSED as a permanent error. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Apr 8 15:23:56 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11960 for ; Sun, 8 Apr 2001 15:23:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mKMD-000FOT-00 for namedroppers-data@psg.com; Sun, 08 Apr 2001 11:56:17 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mKMC-000FNH-00 for namedroppers@ops.ietf.org; Sun, 08 Apr 2001 11:56:17 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f38IlEY01729 for namedroppers@ops.ietf.org; Sun, 8 Apr 2001 14:47:15 -0400 (EDT) Received: from egyptian-gods.mit.edu ([18.101.0.162]) by psg.com with esmtp (Exim 3.16 #1) id 14mGDP-0008H6-00 for namedroppers@ops.ietf.org; Sun, 08 Apr 2001 07:30:55 -0700 Received: (from ghudson@localhost) by egyptian-gods.MIT.EDU (8.9.3) id KAA07676; Sun, 8 Apr 2001 10:30:15 -0400 Message-Id: <200104081430.KAA07676@egyptian-gods.MIT.EDU> To: "D. J. Bernstein" cc: namedroppers@ops.ietf.org Subject: Refusing zone transfers (was Re: DNSEXT WGLC Summary: AXFR Clarify) In-Reply-To: Your message of "07 Apr 2001 08:26:44 -0000." <20010407082644.2890.qmail@cr.yp.to> Date: Sun, 08 Apr 2001 10:30:14 -0400 From: Greg Hudson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I don't have a strong opinion on this topic, but at the moment I think the arguments are stronger for explicit refusals of disallowed zone transfers. Specifically: >> If the master refuses the zone transfer, the client has a right to >> unambiguously know that fact. > Wrong. Zone transfers are between a master and its authorized > slaves. Unauthorized clients have no rights. [...] > Irrelevant. If the AXFR fails, for whatever reason, the client tries > again later. The reason doesn't matter. If a master is misconfigured and is rejecting zone transfers from a slave, or if a slave is misconfigured and is asking the wrong master, it is useful to be able to distinguish this behavior from a software or network fault for debugging purposes. Moreover, an AXFR client might want to know whether to raise a red flag to the administrator ("you have a misconfiguration here") or just silently retry. So while the AXFR client's appropriate network behavior may be the same in both cases, its appropriate user-visible behavior may not be. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Apr 8 15:24:05 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11972 for ; Sun, 8 Apr 2001 15:24:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mKMz-000FPN-00 for namedroppers-data@psg.com; Sun, 08 Apr 2001 11:57:05 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mKMy-000FP9-00 for namedroppers@ops.ietf.org; Sun, 08 Apr 2001 11:57:04 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f38Im3U01740 for namedroppers@ops.ietf.org; Sun, 8 Apr 2001 14:48:03 -0400 (EDT) Received: from munnari.oz.au ([128.250.1.21]) by psg.com with smtp (Exim 3.16 #1) id 14mEiJ-0005jJ-00 for namedroppers@ops.ietf.org; Sun, 08 Apr 2001 05:54:43 -0700 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id MA15731; Sun, 8 Apr 2001 22:54:37 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: "Eric A. Hall" Cc: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) In-Reply-To: Your message of "Sat, 07 Apr 2001 19:03:43 MST." <3ACFC6FF.42237B18@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 08 Apr 2001 22:54:36 +1000 Message-Id: <26300.986734476@mundamutti.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Sat, 07 Apr 2001 19:03:43 -0700 From: "Eric A. Hall" Message-ID: <3ACFC6FF.42237B18@ehsco.com> | I'm sure you didn't mean the example I'm about to give but I am taking the | bait anyway. :) It is actually not a bad example to analyse. | The problem with being too liberal wrt DNS data is that it dillutes the | effectiveness of the lookup service. Not necessarily. | If for example under the "anything goes" principle somebody defines the | dreaded My-MP3-Files RR which returns records for every MP3 cataloged on a | specific server, it is possible for thousands of RRs to be returned. Yes, and for that reason (the RRset would not be expected to fit in any rational packet), that wouldn't be a sane thing to store, technically. | However, those answers will also get returned whenever the associated | domain name is queried with a qtype=* Yes, though qtype=* (ANY) as a reason for dropping something doesn't concern me greatly - if there was no better reason not to do it, I'd hesitate to refuse on those grounds alone. | Ergo, everytime sendmail tries to enumerate the RRs for a destination | domain name, it would get overloaded with My-MP3-Files RRs, which would | either dillute or completely destroy the usability of DNS for simple | lookup functions. I won't debate whether the way sendmail chooses its lookups is sane or not, it certainly isn't required that it operate that way. But anyone who chose to load up thousands of RR's at the kind of domain label that would be used for other purposes (like mail) would deserve to have all kinds of things start failing. Inventing a new name for such things (say mp3.my.dom.ain) is not difficult to achieve (assuming it was rational to use the DNS for a purpose like this - which it isn't). | That's maybe an exaggeration, but maybe it isn't, and really it will all | depend on how liberal the line is drawn. I advocate hard-liner positioning | in this matter. Heck it might even be worth a policy thing, no RRs get | approved without passing through DNSEXT first. I think we already have that policy - the philosphical question being asked is when and why should new RR records get approved by DNSEXT, and when should they be rejected. Eg: if you were to take music (mp3s or anything else), it (just might possibly be reasonable to encode the aritsi/title (or just title) (of is music has anything equivalent to an ISBN, perhaps that identifier) as a domain name, and then define a few RR's to allow a server for that particular music to be located (then again, perhaps SRV is already that). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Apr 8 22:24:17 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14615 for ; Sun, 8 Apr 2001 22:24:16 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mQsi-0001Nq-00 for namedroppers-data@psg.com; Sun, 08 Apr 2001 18:54:16 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mQsh-0001N6-00 for namedroppers@ops.ietf.org; Sun, 08 Apr 2001 18:54:15 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f391jDo02711 for namedroppers@ops.ietf.org; Sun, 8 Apr 2001 21:45:13 -0400 (EDT) Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14mLAL-000H2E-00 for namedroppers@ops.ietf.org; Sun, 08 Apr 2001 12:48:06 -0700 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 645; Sun, 8 Apr 2001 12:48:04 -0700 Message-ID: <3AD0C072.61DF46D1@ehsco.com> Date: Sun, 08 Apr 2001 12:48:03 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Elz CC: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) References: <26300.986734476@mundamutti.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | If for example under the "anything goes" principle somebody defines > | the dreaded My-MP3-Files RR which returns records for every MP3 > | cataloged on a specific server, it is possible for thousands of RRs > | to be returned. > > Yes, and for that reason (the RRset would not be expected to fit in any > rational packet), that wouldn't be a sane thing to store, technically. Of all the reasons to limit, message size probably isn't one of them. There are lots of valid reasons to have very large answer sets. I think it is better to define filters which are based on content/context. > anyone who chose to load up thousands of RR's at the kind of domain > label that would be used for other purposes (like mail) would deserve > to have all kinds of things start failing. Inventing a new name for > such things (say mp3.my.dom.ain) is not difficult to achieve > (assuming it was rational to use the DNS for a purpose like this - > which it isn't). But then somebody publishes their email address (user@mp3...) and mail is broken again. Or a user puts their MP3 collection on their rent-a-domain redirector box, the same box/domain that they use for mail, the same box they use for web pages, etc. The use of qtype=* is probably going to become more common over time, what with there being A, A6 and AAAA RRs in the field now. Since DNS doesn't provide a way to enumerate the RRs that it wants, it has to use qtype=* if it will pick and choose. The key point in my argument is that data in the DNS should only be used for lookups. It should provide a critical piece of information which is necessary for some other application process to complete, and nothing more. It should not provide any application data whatsoever. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 9 10:50:00 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08275 for ; Mon, 9 Apr 2001 10:49:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mcao-000O5t-00 for namedroppers-data@psg.com; Mon, 09 Apr 2001 07:24:34 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mcak-000O4y-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 07:24:34 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f39EFIE04772 for namedroppers@ops.ietf.org; Mon, 9 Apr 2001 10:15:18 -0400 (EDT) Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61]) by psg.com with esmtp (Exim 3.16 #1) id 14mScP-0005Sn-00; Sun, 08 Apr 2001 20:45:33 -0700 Received: from 207-172-148-202.s11.as3.anp.md.dialup.rcn.com ([207.172.148.202]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14mScM-0000AV-00 ; Sun, 08 Apr 2001 23:45:30 -0400 X-Sender: lewis@pop.tislabs.com Message-Id: In-Reply-To: References: <20010405154908.A92004@open.nlnetlabs.nl> <200104060317.UAA13324@toad.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Apr 2001 19:55:48 -0400 To: Randy Bush From: Edward Lewis Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Cc: namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 8:40 AM -0400 4/6/01, Randy Bush wrote: >in general, we discourage storing non-dns data in the dns. "We?" I disagee that we should be trying to limit the data held in DNS. I believe that volume is not an issue and should not be artificially limited. OTOH, I feel that we should limit the impact on DNS by the data held in DNS. (E.g., the A6 record impacts the DNS more so than the A record. Not that this makes the A6 evil, but it is less desirable than an A.) ...the ensuing arguement is off the topic at hand though... >also, it would be inadvisable to equate dns trust with trust for other >things, such as sessions with hosts/services you happened to find through >the dns. > >but i think we discussed all these things before. If we did, we did so with less operational input. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 9 10:50:01 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08274 for ; Mon, 9 Apr 2001 10:49:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mcdk-000OB6-00 for namedroppers-data@psg.com; Mon, 09 Apr 2001 07:27:36 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mcdQ-000O9s-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 07:27:35 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f39EIDY04816 for namedroppers@ops.ietf.org; Mon, 9 Apr 2001 10:18:13 -0400 (EDT) Received: from artemas.reachin.com ([64.14.214.33]) by psg.com with smtp (Exim 3.16 #1) id 14mV78-000Au0-00 for namedroppers@ops.ietf.org; Sun, 08 Apr 2001 23:25:26 -0700 Received: (qmail 12999 invoked by uid 1233); 8 Apr 2001 23:24:51 -0700 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Apr 2001 23:24:51 -0700 Date: Sun, 8 Apr 2001 23:24:51 -0700 (PDT) From: Sam Trenholme X-Sender: To: Greg Hudson cc: "D. J. Bernstein" , Subject: Re: Refusing zone transfers (was Re: DNSEXT WGLC Summary: AXFR Clarify) In-Reply-To: <200104081430.KAA07676@egyptian-gods.MIT.EDU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If a master is misconfigured and is rejecting zone transfers from a > slave, or if a slave is misconfigured and is asking the wrong master, > it is useful to be able to distinguish this behavior from a software > or network fault for debugging purposes. I think the fundamental debate here is what balance between security and convenience one should have. Those who find convenience more important than security do not mind that a potentially unauthorized client uses resources and can potentially exploit securiy via TCP port 53. Since a verbose "query refused" error message requires the unauthorized client to connect to port 53, giving the unauthorized client some (albeit small) level of privledge with the name server, I can see where a security-conscious person would not want this. A security-consious person also does not mind the fact that the small number of standard DNS queries that need more than 512 bytes in the reply can not be properly processed. There are ways of shaving most of these queries down to a reasonable size (the abuse of DNS in the z.zoy.org domain notwithstanding) [1]. On the other hand, we have the fact that immediately dropping the TCP connection is a bit "rude", and can make it more difficult to troublshoot problems. I feel that the balance between security and convenience here is an engineering one that the implementor of a DNS server should make. I do not find it appropriate for an IETF RFC to make that decision for the implementor. This is why I oppose the wording of "it MUST respond with a single DNS message containing an appropriate RCODE other than NOERROR" (when the server does not want to perform an AXFR) in section three of the AXFR clarify document. - Sam (Just my two cents) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 9 10:50:24 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08385 for ; Mon, 9 Apr 2001 10:50:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mccY-000O7z-00 for namedroppers-data@psg.com; Mon, 09 Apr 2001 07:26:22 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mccX-000O7D-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 07:26:21 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f39EHIg04793 for namedroppers@ops.ietf.org; Mon, 9 Apr 2001 10:17:18 -0400 (EDT) Received: from smtp02.mrf.mail.rcn.net ([207.172.4.61]) by psg.com with esmtp (Exim 3.16 #1) id 14mScR-0005Sy-00 for namedroppers@ops.ietf.org; Sun, 08 Apr 2001 20:45:35 -0700 Received: from 207-172-148-202.s11.as3.anp.md.dialup.rcn.com ([207.172.148.202]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.16 #5) id 14mScO-0000AV-00 ; Sun, 08 Apr 2001 23:45:33 -0400 X-Sender: lewis@pop.tislabs.com Message-Id: In-Reply-To: <20010405154908.A92004@open.nlnetlabs.nl> References: <20010403125414.A10897@snarl.east.isi.edu>; from masseyd@isi.edu on Tue, Apr 03, 2001 at 12:54:14PM -0400 <200103301035.MAA20499@omval.tednet.nl> <20010403125414.A10897@snarl.east.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Apr 2001 20:05:42 -0400 To: Miek Gieben From: Edward Lewis Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) Cc: Dan Massey , namedroppers@ops.ietf.org Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 9:49 AM -0400 4/5/01, Miek Gieben wrote: >2.2. SIG expiration considerations > The expiration lifetime of the parental SIG over the >child's zone KEY MUST be kept as short as possible. A good >value is one day. If there is a child KEY compromise, the >SIGs for that zone are only valid for as long as the >parental SIG is valid. The selfsigned zone KEY stored in the >child's zone can have a much longer expiration lifetime. >The SIG at the child does not serve any purpose, a lifetime >measured in years is not uncommon. "MUST be kept as short as possible" is poorly worded. The use of the subjective "as possible" makes the use of MUST incorrect, a SHOULD would be more appropriate. I don't know if a hard requirement can be placed here. Ultimately, it's up to the registry to decide how often they will resign the keys. Technically, it is good to limit the lifetime of a SIG, but this incurs a staffing cost. (Ya' know, this discussion borders on dnsop quite frequently.) > >----------- >I don't (yet) know if it matters if a child has a shorter >lifetime on the sig than the parent. The meanings of the SIG by the parent and the SIG by the child are almost unrelated. The parent says "this key is good" and the child says "I have the private key for this." Because of this, I can't justify tying the two SIG durations in a specification. >We are not sure how or why you come to this conclusion from section >4. The idea was, and still is, to have a short transition period >where both the old and new key are active. One of the smokdering debates is why there is the need for roll over. On the one hand, old SIGs might still be fine if the old key is around. On the other hand, isn't the fact that a new key is available mean you should forget the old data? Now, the desire to use the old key to sign the new key set is the first requirement I have heard that justifies the continued use of the old key once the new key is present. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 9 11:28:06 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09303 for ; Mon, 9 Apr 2001 11:28:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mdLC-000PQl-00 for namedroppers-data@psg.com; Mon, 09 Apr 2001 08:12:30 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mdLC-000PPu-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 08:12:30 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f39F3Qo05196 for namedroppers@ops.ietf.org; Mon, 9 Apr 2001 11:03:26 -0400 (EDT) Received: from birch.ripe.net ([193.0.1.96]) by psg.com with esmtp (Exim 3.16 #1) id 14mdH1-000PJ5-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 08:08:12 -0700 Received: from x50.ripe.net (x50.ripe.net [193.0.1.50]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id RAA20655; Mon, 9 Apr 2001 17:07:39 +0200 (CEST) Received: from ripe.net (localhost.ripe.net [127.0.0.1]) by x50.ripe.net (8.8.8/8.8.5) with ESMTP id RAA14574; Mon, 9 Apr 2001 17:07:39 +0200 (CEST) Message-Id: <200104091507.RAA14574@x50.ripe.net> To: Edward Lewis cc: Miek Gieben , Dan Massey , namedroppers@ops.ietf.org Subject: Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt) In-reply-to: Your message of Fri, 06 Apr 2001 20:05:42 EDT. References: From: Olaf Kolkman X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 535 4444 X-Fax: +31 20 535 4445 Date: Mon, 09 Apr 2001 17:07:39 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Edward Lewis responding to Miek: * >We are not sure how or why you come to this conclusion from section * >4. The idea was, and still is, to have a short transition period * >where both the old and new key are active. * * One of the smokdering debates is why there is the need for roll over. On * the one hand, old SIGs might still be fine if the old key is around. On * the other hand, isn't the fact that a new key is available mean you should * forget the old data? * * Now, the desire to use the old key to sign the new key set is the first * requirement I have heard that justifies the continued use of the old key * once the new key is present. * FYI: The scheme I posted on Friday drops the requirement to have the old KEY around. Actually it requires the old key NOT to be around. (If you would keep the key in the keyset, and the parent would not keep state, you might be able to trigger keyrollovers by spoofed notifies.) "Isn't the fact that a new key is available mean you should forget the old data?" seems to be an important question to answer... --Olaf to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 9 11:28:38 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09317 for ; Mon, 9 Apr 2001 11:28:36 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mdKW-000PPr-00 for namedroppers-data@psg.com; Mon, 09 Apr 2001 08:11:48 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mdKV-000POW-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 08:11:48 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f39F2io05188 for namedroppers@ops.ietf.org; Mon, 9 Apr 2001 11:02:44 -0400 (EDT) Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.16 #1) id 14mdIC-000PLj-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 08:09:24 -0700 Received: from localhost (ogud@localhost) by ogud.com (8.11.2/8.11.2) with ESMTP id f39F8v914132 for ; Mon, 9 Apr 2001 11:08:58 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Mon, 9 Apr 2001 11:08:57 -0400 (EDT) From: Olafur Gudmundsson X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list Subject: draft IETF-50 DNSEXT meeting notes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk please send in comments by 2001/4/13 presenters please send in your slides ASAP if you have not done that thanks Olafur (DNSEXT WG co-chair) IETF 50 DNSEXT minutes Note-takers: Matt Larson, and Donald Eastlake Editor: Olafur Gudmundsson Agenda bashing Working Group status: OG (Olafur Gudmundsson) - Lots of documents: two in RFC editors queue, one in author editing cycle, IESG sitting on four, OG sitting on one, one waiting for IXFR interop report. - 20 I-Ds: 5 new, 4 last call, 6 on IESG/RFC plate Next steps: - Write Dynamic Update implementation report and update RFC. - Rewrite DNSSEC - DNS clarifications - Update charter New charter: - No major changes, new milestones WG consensus is that this is ready to be forwarded to the IESG. - New model for advancing RFC's a person or an organization will adopt an RFC and be responsible for interoperabilty testing. DNSSEC core editing: - RFC 2535: difficult to read, split into: - architecture and design goals - terminology - protocol - Many updates make it hard to follow - Impossible to generate test plan from the document - Collaborate with DNSOP WG on operational guidelines RFC2535bis editors - WG chair recruited Dan Massey and Scott Rose - Need small number of people to be on Editors list to review drafts - Charter: combine RFC2535 and subsequent updates - Only include updates from existing RFCs or I-Ds - Donald Eastlake to edit KEY documents - Brian Wellington to edit secure Dynamic Update document - Time line for DNSSEC editing 2001/04/15 Outline of new documents posted to namedroppers 2001/05/15 First drafts posted 2001/06/15 Revised drafts posted 2001/07/15 First WG last call on documents 2001/10/15 Documents advanced to IESG 2002/06/15 Documents and Interop report sent to IESG for advancement to draft standard. Eric Nordmark (AD) questioned if all specs are currently (or soon) proposed standard the need to recycle at proposed rather than go directly to. AD and WG-chars are to address this once the revised specs are close to completion. Working group documents: DNSSEC Roadmap: Scott Rose Latest version is out. Only comments are typos or editing things. Still being pushed through last call unless anyone has any objections. AXFR Clarify: Mark Andrews impersonating Andreas Gustafsson Chair commented that discussions on mailing list going from technical to insults. Mark Andrews conducted three straw-polls on the document. Do we want a negative answer returned if refusing an AXFR? Resounding yes, (hum yes) Preservation of zone content? What you load in the zone is what is transferred in the AXFR? (or the difference between bind-8 and bind-9). Bind-9 (preserve content has more support) Where should AXFR records go? Entire packet or answer section only? Answer section only is supported. (hum for answer section only) AD is secure: Olafur Gudmundsson No comments on mailing list on this document. One comment from off-line: AD is secure should reflect first non-empty section. (Right now says answer and authority) Border case is negative answer, but there are certain problems dealing with CNAME or DNAME chains--any chains. How about: should cover the answer section, if answer section is empty covers authority. (hum in agreement) NO record: Simon Josefsson OG: Simon is not here. Minor discussion on this on the mailing list, which is interesting, because this is a big question in front of us. NO has certain properties that some people and organizations don't like. NXT is disliked, NO is not as universally disliked. Main argument against changing is we have some experience with NXT and no chance for interoperabilty with NO any time soon. The question in front of the working group is to - Go with NO, - go with NXT, - drop authenticated denial completely? Lively discussion resulted, pointing out that even if NO sucks less than NXT the cost of deploying it is higher (no software, longer names) and there is no real experience either way. Rob Austein proposed that the working group try on the mailing list to come to a consensus on if authenticated denial is needed. Some questions if NO should be published as experimental, and there is support for that and to try to get some operational measures on how NXT and NO compare. Inverse query obsoleted: David Lawrence The consensus of the meeting was that it is a good idea to document that IQUERY is a bad idea and why. Further more that implementors should remove it from any future releases. DNSSEC Opt IN: Mark Kosters DNSSEC has scaling problems. What is the best way to sign large zones? Want to give a low cost of entry. There's a big bang now for DNSSEC: NXT records and NULL keys for unsecured subzones. This is an idea of how to do it in incremental fashion. Has low cost of entry. An opt-in idea. Somewhat controversial--I realize that. One way of solving the big bang dilemma. Read the draft to find out more. Some discussion on how this proposal and the proposal about storing signatures for child keys in parent zone interact. GSS-TSIG: Levon Esibov LE (Levon Esibov): Quick status report on progress with GSS-TSIG. Submitted second draft in March 2001. Made technical updates to clarify ambiguities. No outstanding issues that we're aware of. Currently two independent implementations: Microsoft and Lucent. Foresee question on interoperabilty. Few bugs to fix, few more to fix before claiming interoperabilty. OG: Are those implementations in release products or products in testing? LE: Lucent's is in beta testing Micorsoft is in a released product, but there are some bugs. Unknown RR types: Andreas Gustafsson MA: Never saw this as a controversial draft. Do people think we should continue to go forward as standards track? OG: This is standardizing a presentation format of unknown types, forcing implementations to support unknown types in the future and load them. It's surprising this is not specified in the original spec. OG: Sense for last call? (positive hum) Zone and View options Two drafts now, used to be one, Zone allows specific data from one side of a zone cut, VIEW is specific to BIND 9. Zone goes standards track, VIEW would be informational. OG: I don't think either one is controversial. Should move ahead to last call. NO objections. EDNS handling unknown: Mark Andrews EDNS0 didn't specify default handling of unknown options. This splits the option space so that a server has a better chance of proceeding forward if an option is really optional vs. the server has to do something special with it. Olafur: Trying to do something that EDNS0.5 was trying to address in a much more narrow manner. Harald Alvestrand (HA): I'd like to check the sense of the room on whether or not something in this space is needed? I think that it is. We are currently fielding about between 5 and 20 DNS extensions with various flavors, we need something Does the group agree? (positive hum) Mark: Want some way to sort out the option space, just which way to do it. One or other of these (this or 0.5) has to die. DHCID RR: Mark Strapp MS: DHCID RR drafted for a little while now. Specifies information for of use with one population of DNS clients that are important users of the DNS update protocol, in particular, in many DHCP environments, more than one DHCP server allowed to make updates on behalf of clients. May also be clients allowed to do their own updates. Need to coordinate useful information among some population of updaters. Would need some out of band mechanism. Only reasonable place for data to go is in the DNS. This is a hash of the identifier and the FQDN. Haven't seen any response since most recent publication. OG: Is the doc ready for last call in your opinion? MS: Yes, it's stable. OG: I'll issue a last call after the meeting. NIST DNSSEC implementation testing: Scott Rose SR: NIST is starting a performance test of DNSSEC. Hoping to get a large repository of statistics and a set of tools: workload generation, stress testing. Have email drop point and ask for anybody's help. Interested in number of queries and types of queries. Generate traffic and feed it to various implementations. Please contact Scott if you have statistics and want to share them. If you have implementations that do DNSSEC, we'll take those, too, if you want us to beat on them with the workload generation tools. We won't issue any certification, but we'll test interop. Tools will be made available. Child SIG at the parent: Miek Gieben (MK) These advantages: - Makes key roll-over scale - Reduces involvement of child zone DNS admin - Make an unscheduled key roll over possible DNSSEC resolver must be aware of this change. Have somebody working on that right now. Some discussion on the protocol and authority implications if SIG data (and possibly KEY RRs) are stored in parent. Miek is to update his draft and submit it to dnsext for discussion, possibly trying to eliminate the NULL KEY definition in parent. NGTRANS requirements/IPv6 DNS operational needs: Alain Durand AD: Follow up to what happened in DNSOP. Started in San Diego at IETF 49. NGTRANS asked by Area Director to specify some needs. Yesterday, RB asked would this partition the DNS? Now I'm presenting this update, which is just an example. Need a IPv6/IPv4 translator. Fall back translator: "last resort" solution when an IPv6 record is not available to an IPv6-only DNS server - Only accept IPv6 queries - Would force RD bit off - Forward queries in IPv4 - Fallback translator discovery? - Integration of fallback mechanism in IPv6 DNS resolver? IPv6 DNS transition and deployment: Rob Austein - Problems: two complete IPv6 DNS Address record solutions - One standard, other deprecated - Known implementations using deprecated one - Becoming issue for IPv6 deployment - Concern about complexity and scalability - In untenable place. Need to have something, rough consensus. - Haven't made a strong case for the need for advanced features. - Simple stuff "optimized for reads"--assume people look things up more often than writing. New stuff looks like it's optimized for writes. - Proposed approach - Already got AAAA deployed. Can wave magic wand and make it go away. Vendors seem to care about stub resolvers, don't want to replace the stub resolvers. - Need to have transition plan to get from AAAA to A6. Will require protocol things, like synthesizing AAAA records. - Need to make a case for A6 ("Case for A6" document) - Need to do this soon, try to get it done by London - Why A6 is worth keeping - Provides features that AAAA can't do: nice to split the address in two pieces - Other issues like rapid renumbering - If we find we need A6, it will be too late. - Rob recommends using "degenerate" case (no chaining) form of A6. - It's a paranoid thing to implement now in case we might need it. - Overview of A6 transition plan - Use A6 in zone files - Anything that needs AAAA is assumed to be stub resolvers and we synthesize it - No AAAA in root or TLD zones - Binary labels - Proposal: punt 'em - Get a FORMERR if any implementations it passes through don't understand it - Doesn't provide any fundamental new features - Have DNAME to assist - DNAME - DNAME provides ways to do things that would be difficult to do things otherwise - For example, moving the entire ip6.int to ip6.arpa - Write strong text to say only use this if nothing else will work Discussion on if there is need for the the case for AAAA as well, conclusion was that the case for A6 should compare both. Discussion if it is reasonable to expect AAAA to die or if we will end up with both forever, some comments about the capabilities or lack there off in stub resolvers, AAAA might be retained as a meta query forever. Chair to send out message about transition plan to all relevant mailing lists. (missing name) from FRNIC requested show on hands on the question how many people thought killing A6 would speed up deployment of IPv6, few hands raised. Some discussion on that existing base has not found any problems in using AAAA, rebuttal was that IPv6 is not yet deployed in the large networks using DNSSEC that motivated A6. Consensus was that there was need for a study and report on this issue, chair is to facilitate that by next IETF. IPNG DDDT/DNS Discovery Discussion: Dave Thaler - Problem is to enable a host to do name resolution in the absence of a DNS server, i.e., a zero-conf environment. - Need to know: - 1 or more DNS server addresses, domain name, search list - Scope of discussion - Only discover information you need to know within the local site - Goal of team: discuss pros and cons and provide an analysis and recommendation Bill Manning: I've done anycast service discovery and found OPCODE QUERY problem. Made proposal for a new OPCODE called DISCOVERY. We're re-casting the I-D we wrote about it. Consider looking at DISCOVER: supports many answers better than QUERY. Long discussion on the assumption that DHCP server is not needed, given that hosts need more information about their information. Final document will live in IPng unless there are DNS protocol changes needed, authors want to avoid protocol changes if possible. ECC KEY record type: Donald Eastlake - Describes new KEY and how to do an ECC SIG. Gives specific format for a SIG for ECC. Since SIGs specify a DNSSEC thing and not a general thing, Olafur will recommend that it be removed. We also recommend text to discourage implementation in DNSSEC. OG: This draft is explicitly requesting to be an official WG item. I have a problem with defining a SIG format: people will start using it and lead to interoperabilty problems. Have strongly recommended anything expect no signature format is defined. What is consensus of the room on adopting this draft ? (strong hum, no against) OG: Should we adopt without signature definition? (no consensus) Suggestion to advance the document for experimental status. Do not update TLD's,Levon Esibov draft-esibov-dnsext-dynupdtld-00.txt Esibov: Don't send any updates to root or TLDs since they are being inundated with updates from some software. Discussion: What about com.au. and other third level zones with the same problem? How about a special label "_no-update" whose presence would indicate that no updates are accepted by a zone? More discussion of alternatives on list needed. Top Level private label name Levon Esibov draft-coffeystrain-dnsext-privatednstld-00.txt Proposes .pri as a private zone. Discssuion: mixed. Narten: Must co-ordinate with IANA. Conclusion: Further discussion and bureaucratic steps needed. Label management proposal Michael L. Macgowan Jr. draft-macgowan-dnsext-label-intel-manage-00.txt Not discussed due to lack of time. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 9 12:26:07 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10820 for ; Mon, 9 Apr 2001 12:26:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14me7y-0000jE-00 for namedroppers-data@psg.com; Mon, 09 Apr 2001 09:02:54 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14me7x-0000j0-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 09:02:54 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f39FroI05666 for namedroppers@ops.ietf.org; Mon, 9 Apr 2001 11:53:50 -0400 (EDT) Received: from egyptian-gods.mit.edu ([18.101.0.162]) by psg.com with esmtp (Exim 3.16 #1) id 14mdyW-0000XW-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 08:53:09 -0700 Received: (from ghudson@localhost) by egyptian-gods.MIT.EDU (8.9.3) id LAA06941; Mon, 9 Apr 2001 11:52:28 -0400 Message-Id: <200104091552.LAA06941@egyptian-gods.MIT.EDU> To: Sam Trenholme cc: namedroppers@ops.ietf.org Subject: Re: Refusing zone transfers (was Re: DNSEXT WGLC Summary: AXFR Clarify) In-Reply-To: Your message of "Sun, 08 Apr 2001 23:24:51 PDT." Date: Mon, 09 Apr 2001 11:52:28 -0400 From: Greg Hudson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sam Trenholme wrote: > Those who find convenience more important than security do not mind > that a potentially unauthorized client uses resources and can > potentially exploit securiy via TCP port 53. Since a verbose "query > refused" error message requires the unauthorized client to connect > to port 53, giving the unauthorized client some (albeit small) level > of privledge with the name server, I can see where a > security-conscious person would not want this. Unless I'm missing an important detail here, this argument doesn't seem to follow. There are two viewpoints: * The architect wants a verbose error for easier diagnosis and debugging. * The security officer doesn't want to allow connections on port 53 from unauthorized IP addresses, in case there is an exploit. I don't think the current draft disallows either approach; you're not required to accept connections on port 53 if you don't want to. But what you and Dan seem to be advocating is a worst-of-both-worlds possibility: accept a connection on port 53 and then drop it suddenly. How does this improve security? If you have to read the request in order to decide whether the client is authorized, then that's where your exploit will be; writing out an error response is not an error-prone operation. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 9 21:02:48 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20463 for ; Mon, 9 Apr 2001 21:02:47 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mmCd-000Bzu-00 for namedroppers-data@psg.com; Mon, 09 Apr 2001 17:40:15 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mmCZ-000Byt-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 17:40:15 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3A0V7A07462 for namedroppers@ops.ietf.org; Mon, 9 Apr 2001 20:31:07 -0400 (EDT) Received: from adsl-63-197-0-204.dsl.snfc21.pacbell.net ([63.197.0.204] helo=gulag.araneus.fi) by psg.com with esmtp (Exim 3.16 #1) id 14mfno-0003D9-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 10:50:12 -0700 Received: (from gson@localhost) by gulag.araneus.fi (8.9.3/8.6.12) id KAA23146; Mon, 9 Apr 2001 10:51:01 -0700 (PDT) Date: Mon, 9 Apr 2001 10:51:01 -0700 (PDT) Message-Id: <200104091751.KAA23146@gulag.araneus.fi> To: Sam Trenholme Cc: Greg Hudson , "D. J. Bernstein" , Subject: Re: Refusing zone transfers (was Re: DNSEXT WGLC Summary: AXFR Clarify) In-Reply-To: Re: References: <200104081430.KAA07676@egyptian-gods.MIT.EDU> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sam Trenholme writes: > I think the fundamental debate here is what balance between security and > convenience one should have. > > Those who find convenience more important than security do not mind that a > potentially unauthorized client uses resources and can potentially exploit > securiy via TCP port 53. Since a verbose "query refused" error message > requires the unauthorized client to connect to port 53, giving the > unauthorized client some (albeit small) level of privledge with the name > server, I can see where a security-conscious person would not want this. If a server refuses all TCP connections to port 53, or immediately drops all such connections, it is exercising access control at the transport level, not at the the level of the AXFR protocol. The TCP connection attempt may have been for a non-AXFR (or even non-query) request. Therefore, I would argue that this issue is outside the scope of a draft dealing specifically with AXFR. This is similar to how people use tools like "tcpwrappers" to deny access to other protocols such as telnet, FTP, or SMTP, even though the specifications of those protocols do not explicitly specify that closing the TCP connection is a valid way of indicating unwillingness to provide service. Only when the DNS server accepts the connection, receives and decodes a request, identifies it as an AXFR request, and decides to deny it in that capacity, does the draft require the server to send an error response. -- Andreas Gustafsson, gson@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 9 21:02:51 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20474 for ; Mon, 9 Apr 2001 21:02:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mmBl-000Bxk-00 for namedroppers-data@psg.com; Mon, 09 Apr 2001 17:39:21 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mmBk-000BxY-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 17:39:20 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3A0UGI07447 for namedroppers@ops.ietf.org; Mon, 9 Apr 2001 20:30:16 -0400 (EDT) Received: from sentry.gw.tislabs.com ([192.94.214.100] ident=firewall-user) by psg.com with esmtp (Exim 3.16 #1) id 14mhns-00063l-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 12:58:24 -0700 Received: by sentry.gw.tislabs.com; id QAA25406; Mon, 9 Apr 2001 16:01:58 -0400 (EDT) Received: from dyn145.gw.tislabs.com(10.33.10.145) by sentry.gw.tislabs.com via smap (V5.5) id xmaa25400; Mon, 9 Apr 01 16:01:52 -0400 X-Sender: lewis@pop.tislabs.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Apr 2001 15:57:48 -0400 To: namedroppers@ops.ietf.org From: Edward Lewis Subject: plug for a DNSSEC mailing list on namedroppers Cc: lewis@tislabs.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk I'd like to raise a DNSSEC issue that borders between DNSOP and DNSEXT. Instead of polluting this mailing list with the discussion - which may be somewhat BIND-centric at times, I will use the so-far little used mailing list "dnssec@cafax.se" for the thread. I'm sending this message as a plug for this list. There have been other DNSOP/DNSEXT bordering issues recently that might be more appropriately discussed in a DNSSEC forum - then protocol issues brought to DNSEXT and operational to DNSOP. Information about the list is at http://www.crt.se/dnssec/sigz/. On that page is the line: There is also a mailing-list availible, - write to if you want to subscribe. In a day or two I plan to summarize a discussion concerning DNSSEC and lwresd. I would like to give folks who haven't subscribed to the cafax.se list a day or two to (remember to) get on the list. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Dilbert is an optimist. Opinions expressed are property of my evil twin, not my employer. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 9 21:02:53 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20486 for ; Mon, 9 Apr 2001 21:02:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mmAq-000Bw0-00 for namedroppers-data@psg.com; Mon, 09 Apr 2001 17:38:24 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mmAp-000Bvc-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 17:38:24 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3A0TJI07429 for namedroppers@ops.ietf.org; Mon, 9 Apr 2001 20:29:19 -0400 (EDT) Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14miwt-0007cK-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 14:11:47 -0700 Received: (qmail 17092 invoked by uid 1001); 9 Apr 2001 21:08:00 -0000 Date: 9 Apr 2001 21:08:00 -0000 Message-ID: <20010409210800.25738.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: How to parse an AXFR response packet References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk djbdns grabs every record in the packet. BIND grabs every record in the answer section. Both of these approaches work. There's no dispute about this. The server doesn't provide any authority records or additional records. (TSIG is an exception, but the server doesn't use it except upon request.) The BIND company is trying, through its ``AXFR clarification,'' to prohibit the working djbdns behavior: ``Slaves MUST ignore any authority section contents [and] any unexpected RRs in the additional section.'' This draft is in clear violation of RFC 2119, section 6, which says that words such as MUST and SHOULD ``must not be used to try to impose a particular method on implementors where the method is not required for interoperability.'' The BIND company is misrepresenting the issue by asking ``Where should AXFR records go? Entire packet or answer section only?'' Everyone agrees that the _server_ is broken, and is violating the protocol, if there are records in the authority section; but that's not the issue. The draft is imposing unjustified restrictions on the _client_ behavior. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 9 21:03:30 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20520 for ; Mon, 9 Apr 2001 21:03:29 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mm86-000BtE-00 for namedroppers-data@psg.com; Mon, 09 Apr 2001 17:35:34 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mm85-000BsH-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 17:35:33 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3A0QTs07399 for namedroppers@ops.ietf.org; Mon, 9 Apr 2001 20:26:29 -0400 (EDT) Received: from fxshpr06.extra.daimlerchrysler.com ([208.154.80.165] helo=fxshpr06.is.chrysler.com ident=firewall-user) by psg.com with esmtp (Exim 3.16 #1) id 14mjzx-00090e-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 15:19:01 -0700 Received: (from uucp@localhost) by fxshpr06.is.chrysler.com (8.9.0/8.9.0) id SAA00107 for ; Mon, 9 Apr 2001 18:14:00 -0400 (EDT) Received: from nodnsquery(129.9.202.19) by fwshpr06.is.chrysler.com via smap (V5.5) id xma000090; Mon, 9 Apr 01 18:13:17 -0400 Received: from daimlerchrysler.com (clkcdts1.is.chrysler.com [129.9.209.47]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id f39MIGl16450 for ; Mon, 9 Apr 2001 18:18:16 -0400 (EDT) Message-ID: <3AD23515.E8B4952B@daimlerchrysler.com> Date: Mon, 09 Apr 2001 18:17:57 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC Summary: AXFR Clarify References: <3ACE44A5.B1AE79F4@daimlerchrysler.com> <20010407082644.2890.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: > I am a DNS implementor. My DNS implementation is used at thousands of > sites, including the third-largest and fourth-largest domain hosting > companies on the Internet. > > I have raised several objections to this document, including an > undisputed claim that the document violates RFC 2119 section 6. (One of > my messages was discarded by Randy Bush, the namedroppers censor, but is > available through http://cr.yp.to/djbdns/namedroppers.html#2001-03-17.) > > There have been a few responses to my objections. I am not at all > satisfied with the responses. Sam Trenholme is another DNS implementor, > and he has stated elsewhere that he isn't satisfied either. > > Gudmundsson claims that this document is, with minor changes, the WG > consensus. I don't see any justification for that claim. I would like to > see a rational discussion of this document by the WG. > > Kevin Darcy writes: > > If the master refuses the zone transfer, the client has a right to > > unambiguously know that fact. > > Wrong. Zone transfers are between a master and its authorized slaves. > Unauthorized clients have no rights. I apologize for anthromorphizing; obviously it doesn't make sense, strictly speaking, to say that a client has "rights" or doesn't have "rights". But the *administrators* of those clients, I think, have a right for their jobs to not be unduly complicated and burdened by enshrining broken behavior into an RFC. Why should anyone have to chase their tails trying to nail down what *looks* like a networking problem, only to discover that the idiot DNS admin forgot to modify a zone transfer ACL? As I said in my original message, unambiguous behavior makes things easier for us DNS admins in the trenches. And how much code could it be, really, to have the server send a proper REFUSED response instead of just abruptly closing the connection? Do we really value the time and effort of a handful of DNS developers -- i.e. to code the proper behavior -- over the time and effort of thousands of DNS administrators, i.e. to troubleshoot client problems? I just don't see how the alleged benefits of this proposal could possibly be worth the undeniable costs (but of course I'm biased, being primarily a DNS admin rather than a developer)... > > A premature disconnect is ambiguous: > > Irrelevant. If the AXFR fails, for whatever reason, the client tries > again later. The reason doesn't matter. > > Yes, there are protocols with permanent errors. (``Bounce this mail > immediately; I will never accept it.'') But AXFR is not one of those > protocols. Well, who *says* AXFR is not a protocol where "persistent" (not necessarily *permanent*) errors might be treated differently than transient ones? Maybe an AXFR client would want to log a disconnect differently than a refusal, or maybe it would adopt a different retry strategy. Hell, in some contexts, maybe the client wouldn't even bother retrying between the hours of, say, 9am and 5pm because it simply *knows* that there are no DNS administrators who are available outside of those hours to fix a DNS misconfiguration. We can't predict every possible feature that a DNS implementation might want to include; we can only specify that behavior be as informative as unambiguous as possible, and then let the implementations build on that. By allowing premature disconnects to be considered equivalent to REFUSED responses, the amount of information available to the application as to the cause of the failure is obscured, and the ability for it to make intelligent decisions about further actions is consequently impaired. I am therefore against the proposal. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 9 21:04:22 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20563 for ; Mon, 9 Apr 2001 21:04:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mm6l-000Br8-00 for namedroppers-data@psg.com; Mon, 09 Apr 2001 17:34:11 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mm6l-000Bqt-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 17:34:11 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3A0P6I07384 for namedroppers@ops.ietf.org; Mon, 9 Apr 2001 20:25:06 -0400 (EDT) Received: from fxodpr10.extra.daimlerchrysler.com ([204.189.94.74] helo=fxodpr10.is.chrysler.com ident=firewall-user) by psg.com with esmtp (Exim 3.16 #1) id 14mkKx-0009SU-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 15:40:43 -0700 Received: (from uucp@localhost) by fxodpr10.is.chrysler.com (8.9.0/8.9.0) id SAA05017 for ; Mon, 9 Apr 2001 18:37:14 -0400 (EDT) Received: from nodnsquery(129.9.202.19) by fwodpr10.is.chrysler.com via smap (V5.5) id xma005004; Mon, 9 Apr 01 18:36:15 -0400 Received: from daimlerchrysler.com (clkcdts1.is.chrysler.com [129.9.209.47]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id f39Mdfl20389 for ; Mon, 9 Apr 2001 18:39:42 -0400 (EDT) Message-ID: <3AD23A1A.651C76C8@daimlerchrysler.com> Date: Mon, 09 Apr 2001 18:39:22 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: Refusing zone transfers (was Re: DNSEXT WGLC Summary: AXFR Clarify) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Sam Trenholme wrote: > > If a master is misconfigured and is rejecting zone transfers from a > > slave, or if a slave is misconfigured and is asking the wrong master, > > it is useful to be able to distinguish this behavior from a software > > or network fault for debugging purposes. > > I think the fundamental debate here is what balance between security and > convenience one should have. > > Those who find convenience more important than security do not mind that a > potentially unauthorized client uses resources and can potentially exploit > securiy via TCP port 53. Since a verbose "query refused" error message > requires the unauthorized client to connect to port 53, giving the > unauthorized client some (albeit small) level of privledge with the name > server, I can see where a security-conscious person would not want this. > > A security-consious person also does not mind the fact that the small > number of standard DNS queries that need more than 512 bytes in the reply > can not be properly processed. There are ways of shaving most of these > queries down to a reasonable size (the abuse of DNS in the z.zoy.org > domain notwithstanding) [1]. > > On the other hand, we have the fact that immediately dropping the TCP > connection is a bit "rude", and can make it more difficult to troublshoot > problems. > > I feel that the balance between security and convenience here is an > engineering one that the implementor of a DNS server should make. I do > not find it appropriate for an IETF RFC to make that decision for the > implementor. > > This is why I oppose the wording of "it MUST respond with a single DNS > message containing an appropriate RCODE other than NOERROR" (when the > server does not want to perform an AXFR) in section three of the AXFR > clarify document. I'm doubtful that there is much DoS exposure here, if any -- it's just one packet in, one REFUSED response packet back, no recursion, no DoS amplification. How is anyone going to exploit this any more than, say, DoS'ing an HTTP server or an SMTP server or an FTP server or ...? Anyone who cares about the DoS risk is going to have some sort of IDR in place anyway. Having said that, however, I wouldn't be averse to watering down the language such that a nameserver could ignore AXFR requests -- simply tearing down the connection without sending a REFUSED response -- as long as it behaved that same way for *all* requests with the same credentials, including ordinary DNS queries. In other words, if a nameserver wants to "blacklist" a certain client or set of clients (possibly DoS suspects), then it can do so, but it should not *discriminate* against AXFR requests in particular. I'm using "credentials" in a very broad sense here -- a client's source IP address could, for instance, be considered its "credentials" by a nameserver; or, a more strict server might insist on some sort of crypto-signature as a way of determining a client's credentials. In this way, I would hope to remove any incentive for DNS implementors to be lazy about how they deal with unauthorized client requests, while still retaining intact their ability to implement proper safeguards against certain forms of DNS DoS attacks. I think it would be a reasonable compromise... - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 9 21:51:14 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20487 for ; Mon, 9 Apr 2001 21:02:53 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mm9H-000BuX-00 for namedroppers-data@psg.com; Mon, 09 Apr 2001 17:36:47 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mm9G-000BtV-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 17:36:46 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3A0Rgg07410 for namedroppers@ops.ietf.org; Mon, 9 Apr 2001 20:27:42 -0400 (EDT) Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14mjNk-0008A8-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 14:39:32 -0700 Received: (qmail 23851 invoked by uid 1001); 9 Apr 2001 21:32:33 -0000 Date: 9 Apr 2001 21:32:33 -0000 Message-ID: <20010409213233.19331.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: Refusing zone transfers (was Re: DNSEXT WGLC Summary: AXFR Clarify) References: <200104091552.LAA06941@egyptian-gods.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Clients aren't authorized to ask me about aol.com. Clients aren't authorized to send me TCP queries about cr.yp.to---my UDP responses aren't truncated. Even if I do authorize normal TCP queries someday, clients won't be authorized to send me AXFR requests. djbdns doesn't answer queries for unknown domains by default. It refuses TCP queries by default. Even if it does answer TCP queries, it drops AXFR connections by default. This behavior does not create interoperability problems. Prohibiting it with MUST NOT, or discouraging it with SHOULD NOT, is in violation of RFC 2119 section 6. Would it be terribly difficult for djbdns to talk to unauthorized clients? Of course not. But those clients have no rights. I reject the notion that I should go to even the slightest effort on their behalf. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 10 09:24:24 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14279 for ; Tue, 10 Apr 2001 09:24:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mxpR-000Bze-00 for namedroppers-data@psg.com; Tue, 10 Apr 2001 06:05:05 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mxpR-000ByQ-00 for namedroppers@ops.ietf.org; Tue, 10 Apr 2001 06:05:05 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3ACtxo09709 for namedroppers@ops.ietf.org; Tue, 10 Apr 2001 08:55:59 -0400 (EDT) Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mqNz-000J3W-00 for namedroppers@ops.ietf.org; Mon, 09 Apr 2001 22:08:16 -0700 Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.2/8.11.2) with ESMTP id f3A57pT87624; Tue, 10 Apr 2001 15:08:01 +1000 (EST) (envelope-from marka@nominum.com) Message-Id: <200104100508.f3A57pT87624@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@nominum.com Subject: Re: How to parse an AXFR response packet In-reply-to: Your message of "09 Apr 2001 21:08:00 GMT." <20010409210800.25738.qmail@cr.yp.to> Date: Tue, 10 Apr 2001 15:07:51 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk The reason for saying to ignore the authority and additional sections is to allow the protocol to be expanded in the future without breaking things. Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 10 09:24:25 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14278 for ; Tue, 10 Apr 2001 09:24:23 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14mxnE-000BwU-00 for namedroppers-data@psg.com; Tue, 10 Apr 2001 06:02:48 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14mxnC-000BtF-00 for namedroppers@ops.ietf.org; Tue, 10 Apr 2001 06:02:47 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3ACrfM09685 for namedroppers@ops.ietf.org; Tue, 10 Apr 2001 08:53:41 -0400 (EDT) Received: from mgw-x1.nokia.com ([131.228.20.21]) by psg.com with esmtp (Exim 3.16 #1) id 14mv5P-0003lY-00 for namedroppers@psg.com; Tue, 10 Apr 2001 03:09:23 -0700 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3A9KO221350 for ; Tue, 10 Apr 2001 12:20:25 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 10 Apr 2001 12:20:42 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 10 Apr 2001 12:20:42 +0300 Message-ID: From: sander.van-valkenburg@nokia.com To: namedroppers@psg.com Cc: levone@Exchange.Microsoft.com, erikg@efra05-home.Germany.Sun.COM Subject: RE: comments on mnds-00 Date: Tue, 10 Apr 2001 12:20:33 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Hi Levon, Erik, All, See my response to one point of discussion below. > > I suggest that, just as other zeroconf protocols, a host may either > > run this zeroconf protocol service or not. This need not > be something > > that can be turned off by DHCP, nor should it be - any more > than v4LL > > autoconfiguration. > > I don't agree. There must be a way to disable mDNS through DHCP, to > prevent mDNS traffic in well managed (i.e. non-zero-conf) corporate > environments, where the last thing users need is more network traffic. > > > >It is not expected that a device "host.example.com." will > be manually > > >configured to have additional name > > "host.example.com.local.arpa." when > > >it is configured to use multicast DNS. Instead, a responder > > with a name > > >"host.example.com." configured with ".local.arpa." suffix in > > its domain > > >search configuration is authoritative for the name > > >"host.example.com.local.arpa.". I.e. when responder with the name > > >"host.example.com." receives an A type query for the name > > >"host.example.com.local.arpa." it authoritatively responds > > to the query. > > > > Why attache the suffix '.local.arpa' stuff? Why not just multicast > > a request for 'host.example.com'? > > As I mentioned above, I don't see any problems with sending multicast > queries for the names that don't end with ".local.arpa". > I think that, if hosts may respond to a query for any name, so also those not ending with .local.arpa, there should be a specified way to turn off the mDNS behavior. As Levon mentioned, in managed networks it would be undesirable to have nodes sending mDNS queries for any name e.g. as last resort for resolving a host name. I am not against responding to queries for any name, but it may complicate things in case of a zeroconf-to-non-zeroconf transition takes place. If I am using a non-FQDN initially in the zeroconf network, then after the transistion the DNS will return an error/not resolve queries positively, if mDNS was turned off by a DHCP server in the non-zeroconf network that the zeroconf network just connected to. I'd then like to see that a responder may respond to *any* name ending with .local.arpa (or other, nicer suffixes), *and* to any FQDN that I may use in non-zeroconf environments as well (so that name is also registered on soem DNS server). Alternatively, my smart (m)DNS resolver could try, after faliure to resolve a FQDN (no DNS server present) try to resolve FQDN.local.arpa automatically, without me having to type in the prefix. Regards, Sander to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 10 17:03:19 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26079 for ; Tue, 10 Apr 2001 17:03:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14n4pA-000Nz4-00 for namedroppers-data@psg.com; Tue, 10 Apr 2001 13:33:16 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14n4p8-000Ny8-00 for namedroppers@ops.ietf.org; Tue, 10 Apr 2001 13:33:15 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3AKO8A11838 for namedroppers@ops.ietf.org; Tue, 10 Apr 2001 16:24:08 -0400 (EDT) Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.16 #1) id 14n3S7-000Lq0-00 for namedroppers@ops.ietf.org; Tue, 10 Apr 2001 12:05:23 -0700 Received: from engill.ogud.com (ns.dc.ogud.com [10.20.30.6]) by ogud.com (8.11.2/8.11.2) with ESMTP id f3AJ4cO18628; Tue, 10 Apr 2001 15:04:41 -0400 (EDT) (envelope-from ogud@ogud.com) Message-Id: <5.0.2.1.0.20010410144927.02787ec0@localhost> X-Sender: post@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 10 Apr 2001 15:04:35 -0400 To: "D. J. Bernstein" , namedroppers@ops.ietf.org From: Olafur Gudmundsson Subject: Re: How to parse an AXFR response packet In-Reply-To: <20010409210800.25738.qmail@cr.yp.to> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-namedroppers@ops.ietf.org Precedence: bulk At 17:08 09-04-2001, D. J. Bernstein wrote: >The BIND company is trying, through its ``AXFR clarification,'' to >prohibit the working djbdns behavior: ``Slaves MUST ignore any authority >section contents [and] any unexpected RRs in the additional section.'' Utter nonsense, Andreas is the editor of document for the working group, if he was in any way trying to create a market opportunity for someone, Randy and/or I would find another editor, period. Andreas was drafted by me to write this document because of his skills, knowledge and ability to express protocol issues clearly. The goal is to write a extension to RFC1035 helps future developers in writing AXFR code that interoperates with all implementations without having to do the low level checking you had to do when you implemented your code. >This draft is in clear violation of RFC 2119, section 6, which says that >words such as MUST and SHOULD ``must not be used to try to impose a >particular method on implementors where the method is not required for >interoperability.'' If there are slave servers that ignore data outside answer section then there is an interoperabilty problem. Olafur (DNSEXT co-chair). to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 10 21:50:08 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01045 for ; Tue, 10 Apr 2001 21:50:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14n9WT-0005YT-00 for namedroppers-data@psg.com; Tue, 10 Apr 2001 18:34:17 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14n9WT-0005Y4-00 for namedroppers@ops.ietf.org; Tue, 10 Apr 2001 18:34:17 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3B1PAc13022 for namedroppers@ops.ietf.org; Tue, 10 Apr 2001 21:25:10 -0400 (EDT) Received: from artemas.reachin.com ([64.14.214.33]) by psg.com with smtp (Exim 3.16 #1) id 14n7al-0002NA-00 for namedroppers@ops.ietf.org; Tue, 10 Apr 2001 16:30:35 -0700 Received: (qmail 20071 invoked by uid 1233); 10 Apr 2001 16:30:00 -0700 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 10 Apr 2001 16:30:00 -0700 Date: Tue, 10 Apr 2001 16:30:00 -0700 (PDT) From: Sam Trenholme To: Olafur Gudmundsson cc: Subject: Re: How to parse an AXFR response packet In-Reply-To: <5.0.2.1.0.20010410144927.02787ec0@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > The goal is to write a extension to RFC1035 helps future developers in > writing AXFR code that interoperates with all implementations without > having to do the low level checking you had to do when you implemented > your code. On a similar vein, I would love to see a document which clarifies the QDCOUNT issue. In other words, a formal document that states "QDCOUNT should be 0 or 1, otherwise you will not be able to send queries to 99%, if not all, of the DNS servers out there". I also have some ideas about how to allow binary strings to be in DNS queries without having to worry about case folding. - Sam (Who is, these days, spending too much time actually implementing DNS to have time to write up a draft right now) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 10 21:52:25 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01059 for ; Tue, 10 Apr 2001 21:52:24 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14n9VL-0005X5-00 for namedroppers-data@psg.com; Tue, 10 Apr 2001 18:33:07 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14n9VK-0005VA-00 for namedroppers@ops.ietf.org; Tue, 10 Apr 2001 18:33:06 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3B1NwQ13007 for namedroppers@ops.ietf.org; Tue, 10 Apr 2001 21:23:58 -0400 (EDT) Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14n7v1-00032Z-00 for namedroppers@ops.ietf.org; Tue, 10 Apr 2001 16:51:32 -0700 Received: (qmail 9798 invoked by uid 1001); 10 Apr 2001 22:42:43 -0000 Date: 10 Apr 2001 22:42:43 -0000 Message-ID: <20010410224243.17573.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: How to parse an AXFR response packet References: <20010409210800.25738.qmail@cr.yp.to> <200104100508.f3A57pT87624@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@nominum.com writes: > The reason for saying to ignore the authority and additional > sections is to allow the protocol to be expanded in the > future without breaking things. You are demanding that thousands of sites make changes to their working servers, yet you claim that you're trying to avoid ``breaking things''? It's fifteen years too late to start adding new forms of extensibility to the AXFR protocol. We have an installed base now, and you have no right to break compatibility with the installed base, even if you drop the pretense that you're merely ``clarifying'' the existing protocol. If you want a new protocol, use a new port. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 11 11:14:49 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25872 for ; Wed, 11 Apr 2001 11:14:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14nM0U-00028t-00 for namedroppers-data@psg.com; Wed, 11 Apr 2001 07:54:06 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14nM0T-00026r-00 for namedroppers@ops.ietf.org; Wed, 11 Apr 2001 07:54:06 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3BEivk01821 for namedroppers@ops.ietf.org; Wed, 11 Apr 2001 10:44:57 -0400 (EDT) Received: from cichlid.adsl.duke.edu ([152.16.64.203] helo=hygro.adsl.duke.edu ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14nLzL-00025n-00 for namedroppers@ops.ietf.org; Wed, 11 Apr 2001 07:52:55 -0700 Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f3BEpMc04217; Wed, 11 Apr 2001 10:51:22 -0400 Message-Id: <200104111451.f3BEpMc04217@hygro.adsl.duke.edu> To: "Eric A. Hall" cc: Robert Elz , namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) In-Reply-To: Message from "Eric A. Hall" of "Sun, 08 Apr 2001 12:48:03 PDT." <3AD0C072.61DF46D1@ehsco.com> Date: Wed, 11 Apr 2001 10:51:22 -0400 From: Thomas Narten Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Robert Elz writes: > I think we already have that policy - the philosphical question being asked > is when and why should new RR records get approved by DNSEXT, and when should > they be rejected. Personally, I think defining DNS RRs should be encourgaged where it makes sense. I.e, the DNS does the things it is designed for quite well. New RRs that fit within the existing model should be encouraged. Criteria could include: - Would use of the new RR cause operational problems? - Would it cause problems for existing implementations, or would existing resolvers/servers handle them just fine (i.e., don't forget about caching servers that could just cache the RR without undestanding its semantics)? - Is the usage of the RR consistent with the basic service the DNS provides well? - E.g,. lookup based on a heirarchical name (the DNS name). - Small number of RRs at a given name, as opposed to tens or hundreds - Relatively infrequent updates to the data (i.e., non-realtime) - Can use reasonable TTLs (i.e., other than zero) Surely there are more (does it duplicate existing RRs, is it specified clearly enough for implementors, etc.), and enumerating/documenting the issues that should be considered when evaluating a proposed RR would be a useful exercise, especially for folks that are thinking about whether they should define a new RR. "Eric A. Hall" writes: > The key point in my argument is that data in the DNS should only be used > for lookups. It should provide a critical piece of information which is > necessary for some other application process to complete, and nothing > more. It should not provide any application data whatsoever. I think this distinction is too absolute. As long as the application data can easily be put into the DNS without causing contortions, why shouldn't that be allowed? And isn't the info in an MX record "application data"? Thomas to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 11 14:39:23 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00718 for ; Wed, 11 Apr 2001 14:39:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14nPEz-0008ft-00 for namedroppers-data@psg.com; Wed, 11 Apr 2001 11:21:17 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14nPEy-0008fQ-00 for namedroppers@ops.ietf.org; Wed, 11 Apr 2001 11:21:17 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3BIC9M02921 for namedroppers@ops.ietf.org; Wed, 11 Apr 2001 14:12:09 -0400 (EDT) Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14nNxg-00068T-00 for namedroppers@ops.ietf.org; Wed, 11 Apr 2001 09:59:20 -0700 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 670; Wed, 11 Apr 2001 09:59:15 -0700 Message-ID: <3AD48D63.7A82A544@ehsco.com> Date: Wed, 11 Apr 2001 09:59:15 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: Robert Elz , namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) References: <200104111451.f3BEpMc04217@hygro.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thomas Narten wrote: > Personally, I think defining DNS RRs should be encourgaged where it > makes sense. I.e, the DNS does the things it is designed for quite > well. New RRs that fit within the existing model should be encouraged. Agreed. The tricky part is defining what that is exactly. > - Would it cause problems for existing implementations, or would > existing resolvers/servers handle them just fine (i.e., don't forget > about caching servers that could just cache the RR without > undestanding its semantics)? Does it provide unambiguous data. > - Is the usage of the RR consistent with the basic service the DNS > provides well? > > - E.g,. lookup based on a heirarchical name (the DNS name). > > - Small number of RRs at a given name, as opposed to tens or > hundreds > > - Relatively infrequent updates to the data (i.e., non-realtime) > > - Can use reasonable TTLs (i.e., other than zero) Agree > Surely there are more (does it duplicate existing RRs, is it specified > clearly enough for implementors, etc.), and enumerating/documenting > the issues that should be considered when evaluating a proposed RR > would be a useful exercise, especially for folks that are thinking > about whether they should define a new RR. Is it a lookup and not data. Does it provide information about Internet resources and not local data (lookups that only have relevance within an administrative domain should not be stored in the global DNS). > > It should provide a critical piece of information which is > > necessary for some other application process to complete, and > > nothing more. It should not provide any application data whatsoever. > > I think this distinction is too absolute. As long as the application > data can easily be put into the DNS without causing contortions, why > shouldn't that be allowed? Because too many RRs will trigger UDP overflow which impacts the performance of lookups. Way-too-many RRs will also trigger TCP overflow whichi will prevent lookups from working at all. This is my primary concern: the main function of the DNS is for lookups, it should not be hampered or blocked with excessive RRs which are better served by other processes. > And isn't the info in an MX record "application data"? Yes, but I'm not advocating its removal. A lot of the filtering effort comes from trying to keep things like MX out of DNS. Putting MX into the DNS in the first place could be considered a mistake by my defintion. However, I certainly recognize the value and stickiness of MX and also recognize that there was no other alternative at the time, and so I certainly have no desire or goal of pulling it out of DNS. But that doesn't mean new MX-like RRs should go into the DNS either. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 11 14:39:59 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00732 for ; Wed, 11 Apr 2001 14:39:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14nPI9-0008m3-00 for namedroppers-data@psg.com; Wed, 11 Apr 2001 11:24:33 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14nPI7-0008lq-00 for namedroppers@ops.ietf.org; Wed, 11 Apr 2001 11:24:32 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3BIFOc02974 for namedroppers@ops.ietf.org; Wed, 11 Apr 2001 14:15:24 -0400 (EDT) Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.16 #1) id 14nMAH-0002UK-00 for namedroppers@ops.ietf.org; Wed, 11 Apr 2001 08:04:14 -0700 Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.2/8.11.2) with ESMTP id f3BF40T85767; Thu, 12 Apr 2001 01:04:02 +1000 (EST) (envelope-from marka@nominum.com) Message-Id: <200104111504.f3BF40T85767@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@nominum.com Subject: Re: How to parse an AXFR response packet In-reply-to: Your message of "10 Apr 2001 22:42:43 GMT." <20010410224243.17573.qmail@cr.yp.to> Date: Thu, 12 Apr 2001 01:04:00 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@nominum.com writes: > > The reason for saying to ignore the authority and additional > > sections is to allow the protocol to be expanded in the > > future without breaking things. > > You are demanding that thousands of sites make changes to their working > servers, yet you claim that you're trying to avoid ``breaking things''? No. I'm not demanding that any servers be upgraded. I'm saying don't ship code in *future* that caches the authority and additional sections of a AXFR. Natural attrition will take care of the existing servers. Old code does get replaced, usually when the machine dies or the OS is upgraded to the next release. You can eventually make things the default that when you first started doing it you needed to be cautious to ensure that both ends were capable of handling otherwise thing broke badly. I seriously doubt we will ever use those sections for anything other than signing the AXFR stream. However if there is another use found for them then I want to minimise the damage caused if such a AXFR stream is sent to a server that does not understand it. > > It's fifteen years too late to start adding new forms of extensibility > to the AXFR protocol. We have an installed base now, and you have no > right to break compatibility with the installed base, even if you drop > the pretense that you're merely ``clarifying'' the existing protocol. > If you want a new protocol, use a new port. -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 12 09:27:04 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29433 for ; Thu, 12 Apr 2001 09:27:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ngkH-000F2v-00 for namedroppers-data@psg.com; Thu, 12 Apr 2001 06:02:45 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14ngkG-000F2o-00 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 06:02:44 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3CCrYY07008 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 08:53:34 -0400 (EDT) Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14nce3-0009fb-00 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 01:40:03 -0700 Received: (qmail 26563 invoked by uid 1001); 12 Apr 2001 08:35:13 -0000 Date: 12 Apr 2001 08:35:13 -0000 Message-ID: <20010412083513.5629.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: How to parse an AXFR response packet References: <20010410224243.17573.qmail@cr.yp.to> <200104111504.f3BF40T85767@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Mark.Andrews@nominum.com writes: > However if there is another use found for them then I want to minimise > the damage caused if such a AXFR stream is sent to a server that does > not understand it. You're demanding that my users and I go to extra effort so that you can someday run an incompatible protocol on the same port. This is absurd. > Natural attrition will take care of the existing servers. Natural attrition? You mean security holes that force people to upgrade? Sorry, Mark, but my DNS implementation doesn't have that feature. I've seen servers run for several _years_ without a software upgrade. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 12 09:27:06 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29444 for ; Thu, 12 Apr 2001 09:27:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14nggE-000Ex5-00 for namedroppers-data@psg.com; Thu, 12 Apr 2001 05:58:34 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14nggD-000Evv-00 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 05:58:33 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3CCnNQ06968 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 08:49:23 -0400 (EDT) Received: from [192.100.77.3] (helo=ratree.psu.ac.th) by psg.com with esmtp (Exim 3.16 #1) id 14ndog-000BBO-00 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 02:55:06 -0700 Received: from brandenburg.cs.mu.OZ.AU (sw11.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id QAA02401; Thu, 12 Apr 2001 16:55:02 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f3C9sxh02329; Thu, 12 Apr 2001 16:55:00 +0700 (ICT) From: Robert Elz To: "Eric A. Hall" cc: Thomas Narten , namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) In-reply-to: Your message of "Wed, 11 Apr 2001 09:59:15 MST." <3AD48D63.7A82A544@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Apr 2001 16:54:59 +0700 Message-ID: <2327.987069299@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Wed, 11 Apr 2001 09:59:15 -0700 From: "Eric A. Hall" Message-ID: <3AD48D63.7A82A544@ehsco.com> | Agreed. The tricky part is defining what that is exactly. It doesn't need to be defined, no-one is looking at creating an automated RR registration service. As long as we can make the distinction when required, that will be fine. | Is it a lookup and not data. I have no idea what that means. If it is in the DNS, it is going to be used in a lookup, or having it would certainly be a wast of time. If it is going to be represented in the DNS, it is certainly going to be data. Hence, I would have thought everything in the DNS is used in a lookup and is data... | Does it provide information about Internet | resources and not local data (lookups that only have relevance within an | administrative domain should not be stored in the global DNS). I'm not sure I would go quite that far. If the data is going to be useful all over the place, and it is data that can be made publicly available (isn't intended to be private) then I don't think it matters in the slightest whether the majority of the uses will be local. Certainly the vast majority of the A records are only used locally, are you suggesting that they shouldn't be in the DNS but should be someplace else instead? | Because too many RRs will trigger UDP overflow which impacts the | performance of lookups. Only if there are large numbers of RRs for the same RR type (that should certainly be discouraged) - or for used of ANY type lookups, which I don't consider all that important. | Way-too-many RRs will also trigger TCP overflow | whichi will prevent lookups from working at all. There's no way a FOO RR type can prevent my A lookups from working, regardless of how many RRs are there. Nor can 2 or 3 hundred other RR types defined at the same node. | This is my primary concern: the main function of the DNS is for lookups, The only function of the DNS was for lookups - before DynDNS, that (and the odd zone transfer) were all it could do. But you seem to have "lookups" defined somewhere with a particular kind of data being returned, whereas I can see no justification for that. | A lot of the filtering effort comes from trying to keep things like MX out | of DNS. Then that is wasted effort, as that would not be a sane result. | Putting MX into the DNS in the first place could be considered a | mistake by my defintion. It could be considered to be that way, but without any rational justification. If MX is on the "wrong side", then I don't think there's any data in the DNS that would justify staying, certainly I don't see A or PTR as being any different than MX. Certainly not HINFO or MB. I guess you'd just be left with the RRs that build the tree (NS and SOA), without which there would be no DNS at all. But at that stage, there wouldn't be a lot of use delegating domains. | However, I certainly recognize the value and | stickiness of MX and also recognize that there was no other alternative at | the time, and so I certainly have no desire or goal of pulling it out of | DNS. But that doesn't mean new MX-like RRs should go into the DNS either. RRs like MX (eg; SRV) are just fine in the DNS - that's exactly the kind of thing it ought be used for. I wouldn't even look very closely at that kind of RR (other than the definition of its data format - SRV certainly had a bunch of that in its time). The ones that are more problematic are stuff like the (proposed) apl RR, which just doesn't seen to be able to drum up sufficient interest (and hence most likely wouldn't really ever be used), and the (still? proposed) kitchen sink rr, which overloaded an RR type so that people could add random data without needing to get their own RR type. This isn't to say that those ones are automatically no good - just that those are the types of requests that demand greater scrutiny, not anything which smells like MX. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 12 21:16:06 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14594 for ; Thu, 12 Apr 2001 21:16:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14nrui-0006dx-00 for namedroppers-data@psg.com; Thu, 12 Apr 2001 17:58:16 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14nrug-0006d5-00 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 17:58:15 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3D0n4Q09287 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 20:49:04 -0400 (EDT) Received: from [64.38.134.101] (helo=gate.internaut.com) by psg.com with esmtp (Exim 3.16 #1) id 14njDP-000IgL-00 for namedroppers@psg.com; Thu, 12 Apr 2001 08:40:59 -0700 Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f3CFU2N30322; Thu, 12 Apr 2001 08:30:02 -0700 From: "Bernard Aboba" To: , Cc: , Subject: RE: comments on mnds-00 Date: Thu, 12 Apr 2001 08:42:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > As I mentioned above, I don't see any problems with sending multicast > queries for the names that don't end with ".local.arpa". I think that the original concern was that you'd end up sending unnecessary queries for hosts that are not on the local link as a result of moving through the searchlist. > I think that, if hosts may respond to a query for any name, so also those >not ending with .local.arpa, there should be a specified way to turn off the >mDNS behavior. The DHCP searchlist option accomplishes this. Hosts that are configured without .local.arpa in their searchlist neither send nor respond to mDNS queries. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 12 21:16:07 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14593 for ; Thu, 12 Apr 2001 21:16:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14nrro-0006bV-00 for namedroppers-data@psg.com; Thu, 12 Apr 2001 17:55:16 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14nrrn-0006aB-00 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 17:55:15 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3D0k4209251 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 20:46:04 -0400 (EDT) Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.16 #1) id 14nrAP-0005XV-00 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 17:10:25 -0700 Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.2/8.11.2) with ESMTP id f3D09mT93923; Fri, 13 Apr 2001 10:09:51 +1000 (EST) (envelope-from marka@nominum.com) Message-Id: <200104130009.f3D09mT93923@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: namedroppers@ops.ietf.org From: Mark.Andrews@nominum.com Subject: Re: How to parse an AXFR response packet In-reply-to: Your message of "12 Apr 2001 08:35:13 GMT." <20010412083513.5629.qmail@cr.yp.to> Date: Fri, 13 Apr 2001 10:09:48 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Mark.Andrews@nominum.com writes: > > However if there is another use found for them then I want to minimise > > the damage caused if such a AXFR stream is sent to a server that does > > not understand it. > > You're demanding that my users and I go to extra effort so that you can > someday run an incompatible protocol on the same port. This is absurd. I'm not asking your users to do a single thing. I'm asking you to change the way your server caches messages recieved on a AXFR stream. I'm asking you to do something that would have taken less time to do than the time spent arguing over doing it. I'm asking you to do something will have no impact on your existing customers. I'm asking you to revisit the decision you made to cache all sections of a message and not just the answer section when you must have known that only the answer section was involved. If I remember correctly you asked about what sections the answers went in and you were told only the answer section. > > > Natural attrition will take care of the existing servers. > > Natural attrition? You mean security holes that force people to upgrade? > Sorry, Mark, but my DNS implementation doesn't have that feature. Dan I meant what I said. If you don't understand the phrase "natural attrition" look it up. > > I've seen servers run for several _years_ without a software upgrade. So have I. I'm taking the long view on this issue as well. Mark > > ---Dan > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 12 21:16:08 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14604 for ; Thu, 12 Apr 2001 21:16:06 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14nrsl-0006cK-00 for namedroppers-data@psg.com; Thu, 12 Apr 2001 17:56:15 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14nrsk-0006bp-00 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 17:56:14 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3D0l4M09265 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 20:47:04 -0400 (EDT) Received: from fxodpr10.extra.daimlerchrysler.com ([204.189.94.74] helo=fxodpr10.is.chrysler.com ident=firewall-user) by psg.com with esmtp (Exim 3.16 #1) id 14nn2R-000OwU-00 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 12:45:56 -0700 Received: (from uucp@localhost) by fxodpr10.is.chrysler.com (8.9.0/8.9.0) id PAA18878 for ; Thu, 12 Apr 2001 15:42:24 -0400 (EDT) Received: from nodnsquery(129.9.202.19) by fwodpr10.is.chrysler.com via smap (V5.5) id xma018759; Thu, 12 Apr 01 15:42:17 -0400 Received: from daimlerchrysler.com (clkcdts1.is.chrysler.com [129.9.209.47]) by odmrspr1-pf0.oddc.chrysler.com (8.11.2/8.11.2/daimlerchrysler-relay-1.1-kcd) with ESMTP id f3CJjjl01237 for ; Thu, 12 Apr 2001 15:45:45 -0400 (EDT) Message-ID: <3AD605D8.D520060C@daimlerchrysler.com> Date: Thu, 12 Apr 2001 15:45:28 -0400 From: Kevin Darcy X-Mailer: Mozilla 4.04 [en] (X11; I; SunOS 5.8 sun4u) MIME-Version: 1.0 To: namedroppers@ops.ietf.org Subject: Re: How to parse an AXFR response packet References: <20010410224243.17573.qmail@cr.yp.to> <200104111504.f3BF40T85767@drugs.dv.isc.org> <20010412083513.5629.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit D. J. Bernstein wrote: > Mark.Andrews@nominum.com writes: > > However if there is another use found for them then I want to minimise > > the damage caused if such a AXFR stream is sent to a server that does > > not understand it. > > You're demanding that my users and I go to extra effort so that you can > someday run an incompatible protocol on the same port. This is absurd. I don't know where you get off calling this "incompatible"; the use of Authority and/or Additional sections in AXFR transactions for proprietary extensions was never blessed or encouraged by an RFC. Anyone who implemented such a thing did so at their own risk. We can't put standards into stasis just because folks sometimes exploit the vagueness and/or incompleteness of prior specifications, and then complain that it's too hard to change their code or for their user base to upgrade. If you want to minimize the possibility of having to change your code *EVER*, then stick with the absolute most conservative interpretation of the RFC's that you possibly can. Stuffing proprietary junk into AXFR Authority and/or Additional sections does *not* strike me as a conservative interpretation of RFCs 1034 and/or 1035. In fact, it strikes me as borderline reckless. - Kevin to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 12 21:17:01 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14636 for ; Thu, 12 Apr 2001 21:16:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14nrtz-0006d2-00 for namedroppers-data@psg.com; Thu, 12 Apr 2001 17:57:31 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14nrty-0006cZ-00 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 17:57:30 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3D0mKI09278 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 20:48:20 -0400 (EDT) Received: from [209.31.7.46] (helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14njQY-000Izt-00 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 08:54:34 -0700 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 466; Thu, 12 Apr 2001 08:54:28 -0700 Message-ID: <3AD5CFB3.B9B2B89F@ehsco.com> Date: Thu, 12 Apr 2001 08:54:27 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Elz CC: Thomas Narten , namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) References: <2327.987069299@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | Is it a lookup and not data. > > I have no idea what that means. If it is in the DNS, it is going to > be used in a lookup, or having it would certainly be a wast of time. > If it is going to be represented in the DNS, it is certainly going > to be data. Hence, I would have thought everything in the DNS is > used in a lookup and is data... I consider "lookup" to be a piece of required data which is necessary for a distributed (eg, Internet-wide) application process to complete. I consider "data" to be (poorly termed) information which is not required for the distributed portion of the application process to complete. MX is a lookup for a remote domain's mail servers and is necessary for SMTP delivery over the Internet to complete. MB is data which is not required for the Internet portion of the process. Local mailertable RRs would also not meet this requirement, but reusing MX for this is not necessarily bad. > Certainly the vast majority of the A records are only used locally, > are you suggesting that they shouldn't be in the DNS but should be > someplace else instead? As a class of data, A RRs are necessary for distributed network processes to complete. Something that provided MAC addresses would be local-only. RT RRs are probably local-only. > It could be considered to be that way, but without any rational > justification. If MX is on the "wrong side", then I don't think > there's any data in the DNS that would justify staying, certainly I > don't see A or PTR as being any different than MX. [I may be wrong on MX, I'm trying to define the line too.] My feeling is that MX is wrong when it is compared to SRV because SRV uses protocol-specific labels which are not likely to cause overload. If SRV were used with DNs without the service-specific labels (similar to the MX method) then we could end up with dozens of service-specific RRs associated with a DN, such that requests for qtype=* qname=oz.au. would be overloaded. > I guess you'd just be left with the RRs that build the tree (NS and > SOA), without which there would be no DNS at all. Well, that's certainly not my goal. :p -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 13 08:49:15 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06866 for ; Fri, 13 Apr 2001 08:49:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14o2io-000LoY-00 for namedroppers-data@psg.com; Fri, 13 Apr 2001 05:30:42 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14o2in-000LnC-00 for namedroppers@ops.ietf.org; Fri, 13 Apr 2001 05:30:41 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3DCLTM11144 for namedroppers@ops.ietf.org; Fri, 13 Apr 2001 08:21:29 -0400 (EDT) Received: from muncher.math.uic.edu ([131.193.178.181]) by psg.com with smtp (Exim 3.16 #1) id 14ntjU-0009bV-00 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 19:54:48 -0700 Received: (qmail 11427 invoked by uid 1001); 13 Apr 2001 02:55:02 -0000 Date: 13 Apr 2001 02:55:02 -0000 Message-ID: <20010413025502.19293.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: How to parse an AXFR response packet References: <20010410224243.17573.qmail@cr.yp.to> <200104111504.f3BF40T85767@drugs.dv.isc.org> <20010412083513.5629.qmail@cr.yp.to> <3AD605D8.D520060C@daimlerchrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Kevin Darcy writes: > stick with the absolute most conservative interpretation of the RFC's > that you possibly can. The existing standards do not say ``read only the answer section.'' They also do not say ``read the entire packet.'' Both methods work. Neither method is ``most conservative.'' I chose the simpler method. The BIND company, in violation of RFC 2119 section 6, is trying to impose the other method. > Stuffing proprietary junk into AXFR Authority and/or > Additional sections does *not* strike me as a conservative interpretation > of RFCs 1034 and/or 1035. In fact, it strikes me as borderline reckless. I'm not putting anything into the authority section. The BIND company is saying that _they_ might want to put things there. They know that this won't work with some existing standards-compliant servers. They are demanding that those servers be changed. Kevin, you seem to have been fooled by their misstatement of the issue. The issue is _not_ whether the server is allowed to put anything into the authority section. We all agree that, if records appear there, the server is violating the protocol. The issue is whether the _client_ is violating the protocol by accepting those records. Right now there is no prohibition on this. The BIND company wants to prohibit it. I object. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 13 08:50:09 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06918 for ; Fri, 13 Apr 2001 08:50:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14o2hh-000LmS-00 for namedroppers-data@psg.com; Fri, 13 Apr 2001 05:29:33 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14o2hf-000LlL-00 for namedroppers@ops.ietf.org; Fri, 13 Apr 2001 05:29:31 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3DCKJY11129 for namedroppers@ops.ietf.org; Fri, 13 Apr 2001 08:20:19 -0400 (EDT) Received: from 208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com ([208.59.114.172] helo=ogud.com) by psg.com with esmtp (Exim 3.16 #1) id 14nuUn-000AkX-00 for namedroppers@ops.ietf.org; Thu, 12 Apr 2001 20:43:42 -0700 Received: from localhost (ogud@localhost) by ogud.com (8.11.2/8.11.2) with ESMTP id f3D3gnB31655; Thu, 12 Apr 2001 23:42:49 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Thu, 12 Apr 2001 23:42:48 -0400 (EDT) From: Olafur Gudmundsson X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list cc: proceedings@ietf.org Subject: DNSEXT IETF-50 WG minutes (final) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk IETF 50 DNSEXT minutes Note-takers: Matt Larson, and Donald Eastlake Editor: Olafur Gudmundsson Agenda bashing Working Group status: OG (Olafur Gudmundsson) - Lots of documents: two in RFC editors queue, one in author editing cycle, IESG sitting on four, OG sitting on one, one waiting for IXFR interop report. - 20 I-Ds: 5 new, 4 last call, 6 on IESG/RFC plate Next steps: - Write Dynamic Update implementation report and update RFC. - Rewrite DNSSEC - DNS clarifications - Update charter New charter: - No major changes, new milestones WG consensus is that this is ready to be forwarded to the IESG. - New model for advancing RFC's a person or an organization will adopt an RFC and be responsible for interoperabilty testing. DNSSEC core editing: - RFC 2535: difficult to read, split into: - architecture and design goals - terminology - protocol - Many updates make it hard to follow - Impossible to generate test plan from the document - Collaborate with DNSOP WG on operational guidelines RFC2535bis editors - WG chair recruited Dan Massey and Scott Rose - Need small number of people to be on Editors list to review drafts - Charter: combine RFC2535 and subsequent updates - Only include updates from existing RFCs or I-Ds - Donald Eastlake to edit KEY documents - Brian Wellington to edit secure Dynamic Update document - Time line for DNSSEC editing 2001/04/15 Outline of new documents posted to namedroppers 2001/05/15 First drafts posted 2001/06/15 Revised drafts posted 2001/07/15 First WG last call on documents 2001/10/15 Documents advanced to IESG 2002/06/15 Documents and Interop report sent to IESG for advancement to draft standard. Eric Nordmark (AD) questioned if all specs are currently (or soon) proposed standard the need to recycle at proposed rather than go directly to. AD and WG-chars are to address this once the revised specs are close to completion. Working group documents: DNSSEC Roadmap: Scott Rose Latest version is out. Only comments are typos or editing things. Still being pushed through last call unless anyone has any objections. AXFR Clarify: Mark Andrews impersonating Andreas Gustafsson Chair commented that discussions on mailing list going from technical to insults. Mark Andrews conducted three straw-polls on the document. Do we want a negative answer returned if refusing an AXFR? Resounding yes, (hum yes) Preservation of zone content? What you load in the zone is what is transferred in the AXFR? (or the difference between bind-8 and bind-9). Bind-9 (preserve content has more support) Where should AXFR records go? Entire packet or answer section only? Answer section only is supported. (hum for answer section only) AD is secure: Olafur Gudmundsson No comments on mailing list on this document. One comment from off-line: AD is secure should reflect first non-empty section. (Right now says answer and authority) Border case is negative answer, but there are certain problems dealing with CNAME or DNAME chains--any chains. How about: should cover the answer section, if answer section is empty covers authority. (hum in agreement) NO record: Simon Josefsson OG: Simon is not here. Minor discussion on this on the mailing list, which is interesting, because this is a big question in front of us. NO has certain properties that some people and organizations don't like. NXT is disliked, NO is not as universally disliked. Main argument against changing is we have some experience with NXT and no chance for interoperabilty with NO any time soon. The question in front of the working group is to - Go with NO, - go with NXT, - drop authenticated denial completely? Lively discussion resulted, pointing out that even if NO sucks less than NXT the cost of deploying it is higher (no software, longer names) and there is no real experience either way. Rob Austein proposed that the working group try on the mailing list to come to a consensus on if authenticated denial is needed. Some questions if NO should be published as experimental, and there is support for that and to try to get some operational measures on how NXT and NO compare. Inverse query obsoleted: David Lawrence The consensus of the meeting was that it is a good idea to document that IQUERY is a bad idea and why. Further more that implementors should remove it from any future releases. DNSSEC Opt IN: Mark Kosters DNSSEC has scaling problems. What is the best way to sign large zones? Want to give a low cost of entry. There's a big bang now for DNSSEC: NXT records and NULL keys for unsecured subzones. This is an idea of how to do it in incremental fashion. Has low cost of entry. An opt-in idea. Somewhat controversial--I realize that. One way of solving the big bang dilemma. Read the draft to find out more. Some discussion on how this proposal and the proposal about storing signatures for child keys in parent zone interact. GSS-TSIG: Levon Esibov LE (Levon Esibov): Quick status report on progress with GSS-TSIG. Submitted second draft in March 2001. Made technical updates to clarify ambiguities. No outstanding issues that we're aware of. Currently two independent implementations: Microsoft and Lucent. Foresee question on interoperabilty. Few bugs to fix, few more to fix before claiming interoperabilty. OG: Are those implementations in release products or products in testing? LE: Lucent's is in beta testing Micorsoft is in a released product, but there are some bugs. Unknown RR types: Andreas Gustafsson MA: Never saw this as a controversial draft. Do people think we should continue to go forward as standards track? OG: This is standardizing a presentation format of unknown types, forcing implementations to support unknown types in the future and load them. It's surprising this is not specified in the original spec. OG: Sense for last call? (positive hum) Zone and View options Two drafts now, used to be one, Zone allows specific data from one side of a zone cut, VIEW is specific to BIND 9. Zone goes standards track, VIEW would be informational. OG: I don't think either one is controversial. Should move ahead to last call. NO objections. EDNS handling unknown: Mark Andrews EDNS0 didn't specify default handling of unknown options. This splits the option space so that a server has a better chance of proceeding forward if an option is really optional vs. the server has to do something special with it. Olafur: Trying to do something that EDNS0.5 was trying to address in a much more narrow manner. Harald Alvestrand (HA): I'd like to check the sense of the room on whether or not something in this space is needed? I think that it is. We are currently fielding about between 5 and 20 DNS extensions with various flavors, we need something Does the group agree? (positive hum) Mark: Want some way to sort out the option space, just which way to do it. One or other of these (this or 0.5) has to die. DHCID RR: Mark Strapp MS: DHCID RR drafted for a little while now. Specifies information for of use with one population of DNS clients that are important users of the DNS update protocol, in particular, in many DHCP environments, more than one DHCP server allowed to make updates on behalf of clients. May also be clients allowed to do their own updates. Need to coordinate useful information among some population of updaters. Would need some out of band mechanism. Only reasonable place for data to go is in the DNS. This is a hash of the identifier and the FQDN. Haven't seen any response since most recent publication. OG: Is the doc ready for last call in your opinion? MS: Yes, it's stable. OG: I'll issue a last call after the meeting. NIST DNSSEC implementation testing: Scott Rose SR: NIST is starting a performance test of DNSSEC. Hoping to get a large repository of statistics and a set of tools: workload generation, stress testing. Have email drop point and ask for anybody's help. Interested in number of queries and types of queries. Generate traffic and feed it to various implementations. Please contact Scott if you have statistics and want to share them. If you have implementations that do DNSSEC, we'll take those, too, if you want us to beat on them with the workload generation tools. We won't issue any certification, but we'll test interop. Tools will be made available. Child SIG at the parent: Miek Gieben (MK) These advantages: - Makes key roll-over scale - Reduces involvement of child zone DNS admin - Make an unscheduled key roll over possible DNSSEC resolver must be aware of this change. Have somebody working on that right now. Some discussion on the protocol and authority implications if SIG data (and possibly KEY RRs) are stored in parent. Miek is to update his draft and submit it to dnsext for discussion, possibly trying to eliminate the NULL KEY definition in parent. NGTRANS requirements/IPv6 DNS operational needs: Alain Durand AD: Follow up to what happened in DNSOP. Started in San Diego at IETF 49. NGTRANS asked by Area Director to specify some needs. Yesterday, RB asked would this partition the DNS? Now I'm presenting this update, which is just an example. Need a IPv6/IPv4 translator. Fall back translator: "last resort" solution when an IPv6 record is not available to an IPv6-only DNS server - Only accept IPv6 queries - Would force RD bit off - Forward queries in IPv4 - Fallback translator discovery? - Integration of fallback mechanism in IPv6 DNS resolver? IPv6 DNS transition and deployment: Rob Austein - Problems: two complete IPv6 DNS Address record solutions - One standard, other deprecated - Known implementations using deprecated one - Becoming issue for IPv6 deployment - Concern about complexity and scalability - In untenable place. Need to have something, rough consensus. - Haven't made a strong case for the need for advanced features. - Simple stuff "optimized for reads"--assume people look things up more often than writing. New stuff looks like it's optimized for writes. - Proposed approach - Already got AAAA deployed. Can wave magic wand and make it go away. Vendors seem to care about stub resolvers, don't want to replace the stub resolvers. - Need to have transition plan to get from AAAA to A6. Will require protocol things, like synthesizing AAAA records. - Need to make a case for A6 ("Case for A6" document) - Need to do this soon, try to get it done by London - Why A6 is worth keeping - Provides features that AAAA can't do: nice to split the address in two pieces - Other issues like rapid renumbering - If we find we need A6, it will be too late. - Rob recommends using "degenerate" case (no chaining) form of A6. - It's a paranoid thing to implement now in case we might need it. - Overview of A6 transition plan - Use A6 in zone files - Anything that needs AAAA is assumed to be stub resolvers and we synthesize it - No AAAA in root or TLD zones - Binary labels - Proposal: punt 'em - Get a FORMERR if any implementations it passes through don't understand it - Doesn't provide any fundamental new features - Have DNAME to assist - DNAME - DNAME provides ways to do things that would be difficult to do things otherwise - For example, moving the entire ip6.int to ip6.arpa - Write strong text to say only use this if nothing else will work Discussion on if there is need for the the case for AAAA as well, conclusion was that the case for A6 should compare both. Discussion if it is reasonable to expect AAAA to die or if we will end up with both forever, some comments about the capabilities or lack there off in stub resolvers, AAAA might be retained as a meta query forever. Chair to send out message about transition plan to all relevant mailing lists. (missing name) from FRNIC requested show on hands on the question how many people thought killing A6 would speed up deployment of IPv6, few hands raised. Some discussion on that existing base has not found any problems in using AAAA, rebuttal was that IPv6 is not yet deployed in the large networks using DNSSEC that motivated A6. Consensus was that there was need for a study and report on this issue, chair is to facilitate that by next IETF. IPNG DDDT/DNS Discovery Discussion: Dave Thaler - Problem is to enable a host to do name resolution in the absence of a DNS server, i.e., a zero-conf environment. - Need to know: - 1 or more DNS server addresses, domain name, search list - Scope of discussion - Only discover information you need to know within the local site - Goal of team: discuss pros and cons and provide an analysis and recommendation Bill Manning: I've done anycast service discovery and found OPCODE QUERY problem. Made proposal for a new OPCODE called DISCOVERY. We're re-casting the I-D we wrote about it. Consider looking at DISCOVER: supports many answers better than QUERY. Long discussion on the assumption that DHCP server is not needed, given that hosts need more information about their information. Final document will live in IPng unless there are DNS protocol changes needed, authors want to avoid protocol changes if possible. ECC KEY record type: Donald Eastlake - Describes new KEY and how to do an ECC SIG. Gives specific format for a SIG for ECC. Since SIGs specify a DNSSEC thing and not a general thing, Olafur will recommend that it be removed. We also recommend text to discourage implementation in DNSSEC. OG: This draft is explicitly requesting to be an official WG item. I have a problem with defining a SIG format: people will start using it and lead to interoperabilty problems. Have strongly recommended anything expect no signature format is defined. What is consensus of the room on adopting this draft ? (strong hum, no against) OG: Should we adopt without signature definition? (no consensus) Suggestion to advance the document for experimental status. Do not update TLD's,Levon Esibov draft-esibov-dnsext-dynupdtld-00.txt Esibov: Don't send any updates to root or TLDs since they are being inundated with updates from some software. Discussion: What about com.au. and other third level zones with the same problem? How about a special label "_no-update" whose presence would indicate that no updates are accepted by a zone? More discussion of alternatives on list needed. Top Level private label name Levon Esibov draft-coffeystrain-dnsext-privatednstld-00.txt Proposes .pri as a private zone. Discssuion: mixed. Narten: Must co-ordinate with IANA. Conclusion: Further discussion and bureaucratic steps needed. Label management proposal Michael L. Macgowan Jr. draft-macgowan-dnsext-label-intel-manage-00.txt Not discussed due to lack of time. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 13 20:59:30 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21244 for ; Fri, 13 Apr 2001 20:59:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14oCXI-0009BB-00 for namedroppers-data@psg.com; Fri, 13 Apr 2001 15:59:28 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14oCXH-0009A3-00 for namedroppers@ops.ietf.org; Fri, 13 Apr 2001 15:59:27 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3DMoBQ12972 for namedroppers@ops.ietf.org; Fri, 13 Apr 2001 18:50:11 -0400 (EDT) Received: from spratly.nominum.com ([204.152.187.92]) by psg.com with esmtp (Exim 3.16 #1) id 14o8MJ-0003f1-00 for namedroppers@ops.ietf.org; Fri, 13 Apr 2001 11:31:51 -0700 Received: from localhost (bwelling@localhost) by spratly.nominum.com (8.11.0/8.11.0) with ESMTP id f3DIVIX08984; Fri, 13 Apr 2001 11:31:18 -0700 X-Authentication-Warning: spratly.nominum.com: bwelling owned process doing -bs Date: Fri, 13 Apr 2001 11:31:18 -0700 (PDT) From: Brian Wellington X-Sender: To: "D. J. Bernstein" cc: Subject: Re: How to parse an AXFR response packet In-Reply-To: <20010413025502.19293.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk On 13 Apr 2001, D. J. Bernstein wrote: > Kevin Darcy writes: > > stick with the absolute most conservative interpretation of the RFC's > > that you possibly can. > > The existing standards do not say ``read only the answer section.'' They > also do not say ``read the entire packet.'' Both methods work. Neither > method is ``most conservative.'' > > I chose the simpler method. The BIND company, in violation of RFC 2119 > section 6, is trying to impose the other method. Funny, when I implemented AXFR in a non-bind product, I chose to only parse the answer section, because it was simpler. Apparently the DJB company has a different view of simple. > > Stuffing proprietary junk into AXFR Authority and/or > > Additional sections does *not* strike me as a conservative interpretation > > of RFCs 1034 and/or 1035. In fact, it strikes me as borderline reckless. > > I'm not putting anything into the authority section. And no one else is either. So changing your software to only parse the answer section would have essentially no effect except making it more compliant. > The BIND company is saying that _they_ might want to put things there. > They know that this won't work with some existing standards-compliant > servers. They are demanding that those servers be changed. No, individual people with many years of DNS experience are saying that there may be protocol extensions in the future. There have been extensions before, and there may be again. > Kevin, you seem to have been fooled by their misstatement of the issue. > The issue is _not_ whether the server is allowed to put anything into > the authority section. We all agree that, if records appear there, the > server is violating the protocol. > > The issue is whether the _client_ is violating the protocol by accepting > those records. Right now there is no prohibition on this. The BIND > company wants to prohibit it. I object. This argument is going nowhere, since you're blatantly refusing to accept that you're wrong. Servers don't put any records in the authority section anyway and this would be a 5 minute change to djbdns with no adverse effects. In the time it will take you to respond and disagree again (which I'm sure you will), you could have fixed djbdns. And there is no 'BIND company'. Brian to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 14 12:21:36 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13502 for ; Sat, 14 Apr 2001 12:21:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14oPLz-00023G-00 for namedroppers-data@psg.com; Sat, 14 Apr 2001 05:40:39 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14oPLy-00021y-00 for namedroppers@ops.ietf.org; Sat, 14 Apr 2001 05:40:39 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3ECVOc14918 for namedroppers@ops.ietf.org; Sat, 14 Apr 2001 08:31:24 -0400 (EDT) Received: from artemas.reachin.com ([64.14.214.33]) by psg.com with smtp (Exim 3.16 #1) id 14oLNA-000MbR-00 for namedroppers@ops.ietf.org; Sat, 14 Apr 2001 01:25:37 -0700 Received: (qmail 23013 invoked by uid 1233); 14 Apr 2001 01:25:03 -0700 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 Apr 2001 01:25:03 -0700 Date: Sat, 14 Apr 2001 01:25:03 -0700 (PDT) From: Sam Trenholme To: cc: , , , Subject: Re: How to parse an AXFR response packet In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk [note from moderator: this will be the last post dealing with this issue] While this debate is very quickly becoming a pointless argument, since I am in the middle of the process of implementing a DNS server, I would like to bring my two cents in to this debate. First of all, here is the patch, which, when run against axfr-get.c in version 1.05 of DjbDNS, makes axfr-get no longer consider records outside of the answer section authoritative: 354a355 > uint16_unpack_big(out + 6,&numanswers); 361c362,363 < while (pos < packet.len) { --- > while (pos < packet.len && numanswers) { > --numanswers; This patch has been tested against my "tuzona" zoneserver (included with MaraDNS) modified to put some records in the "additional" section, and is verified to work. Second of all, even if Dan integrates this patch in to DjbDNS, and releases this patched DjbDNS tomorrow, and encourages all users to use a version of axfr-dns so patched, there will still be many machines out there using the previous axfr-dns. In light of this, I do not believe we should make this draft a RFC without taking in to account the reality of thousands of DNS servers which consider authority and additional records part of a zone. There are ways to handle this situtation which do not affect interoperability. One is to require that records in the authority and additional section be records that are deliberately "out of baliwick" records. In other words, we can create a special TLD called "ignore-me" (for example), and add this suffix to the end of the domain labels. Since axfr-get silently discards any hosts with names not part of the zone being transferred, these zones will be ignored by axfr-get. For example, if someone suddenly decided that we should have NS records in the authority seciton during a zone transfer, and was transferring the zone example.com, the data for a single record would look like this (dig-style output): ;; ANSWER SECTION: host.example.com. 1H IN A 192.168.99.99 ;; AUTHORITY SECTION: host.example.com.ignore-me. 1H IN NS ns1.example.com. host.example.com.ignore-me. 1H IN NS ns2.example.com. BIND will ignore these entries because they are not in the answer section. Unpatched version of axfr-get will ignore these entries because they are not part of the example.com zone. Any new zone transfer client that wishes to use these records can truncate the "ignore-me" before processing the records in question. End of interoperability problems. Since the RFCs which currently exist do not specifically forbid adding authority and additional records to a zone, I feel it did not "break the spec", as the spec exists today, to have written clients which add these records to a zone file. On the other hand, it is not very difficult to patch the existing software to have behavior more consistant with the behavior specified in the proposed draft. - Sam to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Apr 15 22:54:31 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16072 for ; Sun, 15 Apr 2001 22:54:30 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14oxh4-000HGl-00 for namedroppers-data@psg.com; Sun, 15 Apr 2001 18:20:42 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14oxh4-000HGf-00 for namedroppers@ops.ietf.org; Sun, 15 Apr 2001 18:20:42 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14oxh4-00029A-00 for namedroppers@ops.ietf.org; Sun, 15 Apr 2001 18:20:42 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Thomas Narten Cc: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) References: <3AD0C072.61DF46D1@ehsco.com> <200104111451.f3BEpMc04217@hygro.adsl.duke.edu> Message-Id: Date: Sun, 15 Apr 2001 18:17:51 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I.e, the DNS does the things it is designed for quite well. opinions on this seem to vary. and the trend seems to be more dissatisfaction. responses are perceived to be slower, though hardware is faster and bandwidth wider. it would be helpful to have actual data. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 00:53:23 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17118 for ; Mon, 16 Apr 2001 00:53:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14p0lv-000LSz-00 for namedroppers-data@psg.com; Sun, 15 Apr 2001 21:37:55 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14p0lu-000LSt-00 for namedroppers@ops.ietf.org; Sun, 15 Apr 2001 21:37:54 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14p0lu-0003EI-00 for namedroppers@ops.ietf.org; Sun, 15 Apr 2001 21:37:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104160350.UAA13713@toad.com> To: namedroppers@ops.ietf.org, gnu@toad.com Subject: Re: DNS vs. non-DNS Data In-reply-to: Date: Sun, 15 Apr 2001 20:50:09 -0700 From: John Gilmore Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > I.e, the DNS does the things it is designed for quite well. > > opinions on this seem to vary. and the trend seems to be more > dissatisfaction. responses are perceived to be slower, though > hardware is faster and bandwidth wider. The DNS is really the only game in town for what it does. Who else has a locally published, globally accessible, hierarchical, distributed, replicated, cached, high availability, dynamic database? With hundreds of thousands of publishers and hundreds of millions of hourly users? With end-to-end cryptographic authentication coming soon? Oracle? Don't make me laugh. The fact that this 1983 bear is still dancing under 2001's load is quite admirable, even if a small sheen of sweat appears on her upper lip occasionally. The amazing thing is that the protocol and implementation scaled right up through nine orders of magnitude with minor tuning, despite bungled administrative policy that resulted in a large fraction the nodes being hung off a single node of the tree (.com). The occasionally announced political initiatives to "stabilize the DNS infrastructure" have all been hooey; the technical infrastructure was and is solid, even in the hands of largely incompetent self-serving bribeocrats. Mostly the initiatives were to get the infrastructure under somebody's political thumb, rather than being managed by sane people exercising judgement. If the DNS is slow, it can be sped up by implementation, without protocol changes. Find the pinch points, and replicate the servers for those zones on a more globally equidistant basis from the queries. If a speed problem is due to needing better retransmission algorithms than UDP offers, let's resurrect a protocol for three-packet TCP for short connections (similar to T/TCP) that automatically scales up to an arbitrary number of packets and bytes if you don't terminate the connection (as TCP does now). This would let us gradually switch to defaulting to TCP queries, even for short queries and answers. As for what data belongs in the only global distributed database, I say whatever data fits the query method. Any information that ties directly to domain names or IP addresses on the Internet is a legitimate candidate to be there. Crypto keys. Physical locations. Mail handlers. Other service handlers. Text. Names. Addresses for lower or higher level protocols (X.25, Frame, IPv6, email, IPSEC, Mobile IP, routing, whatever). For data that doesn't tie to domain names or IP addresses, even it can be accessed via the DNS, by delegating it a chunk of the label space. You could put baseball scores there, as records under .baseball./ or .baseball.org, giving them a record type or two if they needed one. (This is how lookups by IP addresses were handily slid in, using .in-addr.arpa and PTR.) There is no reason to limit this capability to just IP addresses; such sub-delegations produce almost zero load on the pre-existing DNS, even if widely used, and have no effect on publishers elsewhere in the hierarchy below the root, nor on queriers who never ask for those records. There is similarly no reason for the DNS to limit the number of records of a given type, or the number of record types that could exist at a given label. There are efficiency issues if large numbers of users are expected to make queries that resulted in large volumes of data being served to them -- but those are design decisions best made in the individual context of a DNS RR design and of the application that uses it. There should be no hard-and-fast rule that says "no RRset will ever have more than 16 entries or consume more than 64K bytes" or "No label will ever have more than 42 record types". There is little technical reason for limiting sizes or the creation of new types. I for one am a bit tired of people deciding that administrative control over the evolution of the technology should be used to squelch applications that particular people in positions of control don't happen to like. We get far too much of this from the music monopolies and from the anti-spammers already. They are trying to design-out the ability to copy information -- and the ability to send the first communication in a protocol exchange. Both of these are basic foundations of how the Internet works. We really don't need this kind of arbitrary control imposed on what kinds or types of info can go into the big global database in the sky. ANY kind or type of info should be able to be put into the DNS. Indeed anything can today be encoded into TXT records in labels delegated to the folks who wish to publish it. This capability should remain available, should never be administratively outlawed, and applications that expect to see broad use should be able to get new RRtypes, for higher efficiency or convenience of widespread administration. Programs dumb enough to make queries for "all records at label X" will someday soon want to change to request only the records they really want. That was one of those penny-wise, pound-foolish optimizations that only improves efficiency for a brief time. If it turns out that many applications would like to ask for more than one RRtype at once, and kludges like special rules for MX or IPv6 QTYPEs keep proliferating, then we should revise the protocol to clearly and cleanly define a way to query for multiple RRtypes and unambiguously interpret the answer. (Today's protocol puts too much reliance on minor differences of response, like NODATA versus NXDOMAIN versus more-than-0-records-returned. It doesn't cleanly scale to answering more than one question, and has ended up more complicated than it needs to be.) If multiple-query is a real need, fixing it isn't complicated, just a little tedious. If today's arbitrary limits on the size of DNS labels, records, sections, queries, or responses are pinching us a little, such that we couldn't retrieve a megabyte or two of ".baseball.org" SCORE records if we wanted to, then we should revise the protocol in minor ways to allow these length fields to be expanded. It would be better to do this now rather than when serious applications are feeling the pinch, since deployment always takes a few years. I do think that a complete replacement for DNS should be researched, designed, and prototyped. It should use what we have learned about building distributed databases over the last twenty years, and what we have learned about how NOT to administer globally vital resources. (Thus it should probably not be hierarchical, since that provides a pinch-point where administrative control can -- and therefore inevitably will -- be exerted.) But that's a ten year plus project, which should run in parallel with evolving the current DNS to support whatever applications people can find for it. If the research produces something better, people will switch over to it naturally; if not, the current DNS has to keep working. John Gilmore to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 02:18:04 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01046 for ; Mon, 16 Apr 2001 02:18:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14p1r9-000NBU-00 for namedroppers-data@psg.com; Sun, 15 Apr 2001 22:47:23 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14p1r8-000NBO-00 for namedroppers@ops.ietf.org; Sun, 15 Apr 2001 22:47:22 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14p1r8-0003bz-00 for namedroppers@ops.ietf.org; Sun, 15 Apr 2001 22:47:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104160546.f3G5kaT05285@drugs.dv.isc.org> To: Randy Bush Cc: Thomas Narten , namedroppers@ops.ietf.org From: Mark.Andrews@nominum.com Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) In-reply-to: Your message of "Sun, 15 Apr 2001 18:17:51 MST." Date: Mon, 16 Apr 2001 15:46:36 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > I.e, the DNS does the things it is designed for quite well. > > opinions on this seem to vary. and the trend seems to be more > dissatisfaction. responses are perceived to be slower, though > hardware is faster and bandwidth wider. it would be helpful > to have actual data. > > randy Given that DNS queries and answers are small compared to most other uses of the internet. Increasing bandwidth has little effect compared with the effect of increasing bandwidth with other protocols. The dominant factor in the rtt calculation is signal transmission speed not the time it takes to spit all the bits into the link. As everything else speeds up the DNS *seems* slower. Mark > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 02:22:29 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01070 for ; Mon, 16 Apr 2001 02:22:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14p1qU-000N9s-00 for namedroppers-data@psg.com; Sun, 15 Apr 2001 22:46:42 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14p1qT-000N9l-00 for namedroppers@ops.ietf.org; Sun, 15 Apr 2001 22:46:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14p1qT-0003ba-00 for namedroppers@ops.ietf.org; Sun, 15 Apr 2001 22:46:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 15 Apr 2001 22:35:15 -0700 (PDT) From: Bernard Aboba To: John Gilmore cc: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data In-Reply-To: <200104160350.UAA13713@toad.com> Message-ID: Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If a speed problem is due to needing better retransmission algorithms > than UDP offers, I'm not even sure that we've got the best retransmission algorithm possible with UDP. I do find it curious that the transport behavior of resolvers has never been standardized. Some may take RTT into account in their algorithms; others do not. I have observed some resolvers failing over to secondary DNS servers at time intervals that would barely even permit a response from the primary to be returned. My suspicion is that better behaving resolvers could cut down on query volume. Perhaps a "DNS resolver implementation problem" draft is appropriate? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 03:40:14 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01431 for ; Mon, 16 Apr 2001 03:40:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14p2YB-000OEk-00 for namedroppers-data@psg.com; Sun, 15 Apr 2001 23:31:51 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14p2YA-000OEb-00 for namedroppers@ops.ietf.org; Sun, 15 Apr 2001 23:31:50 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14p2YA-0003qs-00 for namedroppers@ops.ietf.org; Sun, 15 Apr 2001 23:31:50 -0700 Date: Sun, 15 Apr 2001 23:21:57 -0700 (PDT) From: Bernard Aboba To: John Gilmore cc: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data In-Reply-To: <200104160350.UAA13713@toad.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If a speed problem is due to needing better retransmission algorithms > than UDP offers, let's resurrect a protocol for three-packet TCP for > short connections (similar to T/TCP) that automatically scales up to > an arbitrary number of packets and bytes if you don't terminate the > connection (as TCP does now). This would let us gradually switch to > defaulting to TCP queries... Use of TCP would address congestion between the host and local DNS server. However, it would *not* necessarily address overall congestion. Since hosts implement "stub" resolvers, local DNS servers act as proxies. Thus you'd really have two TCP connections, one from the host to the local DNS server, and another between the local DNS server and its correspondent. Assuming the two connections operate independently without coupling, self-clocking will not necessarily occur. For example, where the bottleneck exists between the local DNS server and its correspondent, the overall conversation will not self-clock. This is because the host will happily dispatch packets to the local DNS server oblivious of the overall bottleneck, which it cannot see, since there is no e2e transport connection. In this case the overall transport behavior will be influenced by the size of the queue on the local DNS server and the details of the implementation (e.g. whether backpressure is used, and if so, when). In the case of DNS, the effect is moderated by caching. The local DNS server will thus typically have the answer and thus will not have to originate its own query. Thus the typical query will only involve a single connection. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 04:42:15 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01689 for ; Mon, 16 Apr 2001 04:42:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14p47E-0000cl-00 for namedroppers-data@psg.com; Mon, 16 Apr 2001 01:12:08 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14p47E-0000cf-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 01:12:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14p47E-0006oV-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 01:12:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data In-Reply-To: Message from Bernard Aboba dated "Sun, 15 Apr 2001 22:35:15 PDT" References: Date: Mon, 16 Apr 2001 04:10:46 -0400 From: Rob Austein Message-Id: <20010416081051Z23396-220+549@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: Sun, 15 Apr 2001 22:35:15 -0700 (PDT) From: Bernard Aboba I'm not even sure that we've got the best retransmission algorithm possible with UDP. I have long suspected that something like TCP's variance-based retransmission algorithm would help UDP-based applications like DNS. Perhaps there are other algorithms better suited to this, but the variance-based algorithm is easy to implement (core algorithm is seven lines of code), conceptually straightforward (in retrospect :), and is almost certainly a better retransmission algorithm than is likely to occur to anybody who has not been immersed head down in a transport protocol implementation for several years. As far as I know nothing like this has never been tried with DNS. I'd be interested to hear otherwise. Reference: Appendix A of Van Jacobson's and Mike Karels's 1988 SIGCOMM paper "Congestion Avoidance and Control", which was still available from ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z last time I checked. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 11:38:34 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06724 for ; Mon, 16 Apr 2001 11:38:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14p9Y1-0008EE-00 for namedroppers-data@psg.com; Mon, 16 Apr 2001 07:00:09 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14p9Xv-0008Dp-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 07:00:04 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3GDojY04205 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 09:50:45 -0400 (EDT) Received: from [140.174.2.1] (helo=toad.com) by psg.com with esmtp (Exim 3.16 #1) id 14p01j-000KRZ-00 for namedroppers@ops.ietf.org; Sun, 15 Apr 2001 20:50:11 -0700 Received: from localhost (localhost [127.0.0.1]) by toad.com (8.7.5/8.7.3) with SMTP id UAA13713; Sun, 15 Apr 2001 20:50:10 -0700 (PDT) Message-Id: <200104160350.UAA13713@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: namedroppers@ops.ietf.org, gnu@toad.com Subject: Re: DNS vs. non-DNS Data In-reply-to: Date: Sun, 15 Apr 2001 20:50:09 -0700 From: John Gilmore Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I.e, the DNS does the things it is designed for quite well. > > opinions on this seem to vary. and the trend seems to be more > dissatisfaction. responses are perceived to be slower, though > hardware is faster and bandwidth wider. The DNS is really the only game in town for what it does. Who else has a locally published, globally accessible, hierarchical, distributed, replicated, cached, high availability, dynamic database? With hundreds of thousands of publishers and hundreds of millions of hourly users? With end-to-end cryptographic authentication coming soon? Oracle? Don't make me laugh. The fact that this 1983 bear is still dancing under 2001's load is quite admirable, even if a small sheen of sweat appears on her upper lip occasionally. The amazing thing is that the protocol and implementation scaled right up through nine orders of magnitude with minor tuning, despite bungled administrative policy that resulted in a large fraction the nodes being hung off a single node of the tree (.com). The occasionally announced political initiatives to "stabilize the DNS infrastructure" have all been hooey; the technical infrastructure was and is solid, even in the hands of largely incompetent self-serving bribeocrats. Mostly the initiatives were to get the infrastructure under somebody's political thumb, rather than being managed by sane people exercising judgement. If the DNS is slow, it can be sped up by implementation, without protocol changes. Find the pinch points, and replicate the servers for those zones on a more globally equidistant basis from the queries. If a speed problem is due to needing better retransmission algorithms than UDP offers, let's resurrect a protocol for three-packet TCP for short connections (similar to T/TCP) that automatically scales up to an arbitrary number of packets and bytes if you don't terminate the connection (as TCP does now). This would let us gradually switch to defaulting to TCP queries, even for short queries and answers. As for what data belongs in the only global distributed database, I say whatever data fits the query method. Any information that ties directly to domain names or IP addresses on the Internet is a legitimate candidate to be there. Crypto keys. Physical locations. Mail handlers. Other service handlers. Text. Names. Addresses for lower or higher level protocols (X.25, Frame, IPv6, email, IPSEC, Mobile IP, routing, whatever). For data that doesn't tie to domain names or IP addresses, even it can be accessed via the DNS, by delegating it a chunk of the label space. You could put baseball scores there, as records under .baseball./ or .baseball.org, giving them a record type or two if they needed one. (This is how lookups by IP addresses were handily slid in, using .in-addr.arpa and PTR.) There is no reason to limit this capability to just IP addresses; such sub-delegations produce almost zero load on the pre-existing DNS, even if widely used, and have no effect on publishers elsewhere in the hierarchy below the root, nor on queriers who never ask for those records. There is similarly no reason for the DNS to limit the number of records of a given type, or the number of record types that could exist at a given label. There are efficiency issues if large numbers of users are expected to make queries that resulted in large volumes of data being served to them -- but those are design decisions best made in the individual context of a DNS RR design and of the application that uses it. There should be no hard-and-fast rule that says "no RRset will ever have more than 16 entries or consume more than 64K bytes" or "No label will ever have more than 42 record types". There is little technical reason for limiting sizes or the creation of new types. I for one am a bit tired of people deciding that administrative control over the evolution of the technology should be used to squelch applications that particular people in positions of control don't happen to like. We get far too much of this from the music monopolies and from the anti-spammers already. They are trying to design-out the ability to copy information -- and the ability to send the first communication in a protocol exchange. Both of these are basic foundations of how the Internet works. We really don't need this kind of arbitrary control imposed on what kinds or types of info can go into the big global database in the sky. ANY kind or type of info should be able to be put into the DNS. Indeed anything can today be encoded into TXT records in labels delegated to the folks who wish to publish it. This capability should remain available, should never be administratively outlawed, and applications that expect to see broad use should be able to get new RRtypes, for higher efficiency or convenience of widespread administration. Programs dumb enough to make queries for "all records at label X" will someday soon want to change to request only the records they really want. That was one of those penny-wise, pound-foolish optimizations that only improves efficiency for a brief time. If it turns out that many applications would like to ask for more than one RRtype at once, and kludges like special rules for MX or IPv6 QTYPEs keep proliferating, then we should revise the protocol to clearly and cleanly define a way to query for multiple RRtypes and unambiguously interpret the answer. (Today's protocol puts too much reliance on minor differences of response, like NODATA versus NXDOMAIN versus more-than-0-records-returned. It doesn't cleanly scale to answering more than one question, and has ended up more complicated than it needs to be.) If multiple-query is a real need, fixing it isn't complicated, just a little tedious. If today's arbitrary limits on the size of DNS labels, records, sections, queries, or responses are pinching us a little, such that we couldn't retrieve a megabyte or two of ".baseball.org" SCORE records if we wanted to, then we should revise the protocol in minor ways to allow these length fields to be expanded. It would be better to do this now rather than when serious applications are feeling the pinch, since deployment always takes a few years. I do think that a complete replacement for DNS should be researched, designed, and prototyped. It should use what we have learned about building distributed databases over the last twenty years, and what we have learned about how NOT to administer globally vital resources. (Thus it should probably not be hierarchical, since that provides a pinch-point where administrative control can -- and therefore inevitably will -- be exerted.) But that's a ten year plus project, which should run in parallel with evolving the current DNS to support whatever applications people can find for it. If the research produces something better, people will switch over to it naturally; if not, the current DNS has to keep working. John Gilmore to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 11:38:37 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06735 for ; Mon, 16 Apr 2001 11:38:37 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14p9Uz-0008Aj-00 for namedroppers-data@psg.com; Mon, 16 Apr 2001 06:57:01 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14p9Uy-00089k-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 06:57:00 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3GDlgw04132 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 09:47:42 -0400 (EDT) Received: from dsl092-066-067.bos1.dsl.speakeasy.net ([66.92.66.67] helo=thrintun.hactrn.net) by psg.com with smtp (Exim 3.16 #1) id 14p467-0000bl-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 01:10:59 -0700 Received: from localhost ([127.0.0.1]:60941 "EHLO hactrn.net" ident: "IDENT-NOT-QUERIED [port 60941]") by thrintun.hactrn.net with ESMTP id <23396-220>; Mon, 16 Apr 2001 04:10:46 -0400 To: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data In-Reply-To: Message from Bernard Aboba dated "Sun, 15 Apr 2001 22:35:15 PDT" References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Mon, 16 Apr 2001 04:10:46 -0400 From: Rob Austein Message-Id: <20010416081051Z23396-220+549@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Sun, 15 Apr 2001 22:35:15 -0700 (PDT) From: Bernard Aboba I'm not even sure that we've got the best retransmission algorithm possible with UDP. I have long suspected that something like TCP's variance-based retransmission algorithm would help UDP-based applications like DNS. Perhaps there are other algorithms better suited to this, but the variance-based algorithm is easy to implement (core algorithm is seven lines of code), conceptually straightforward (in retrospect :), and is almost certainly a better retransmission algorithm than is likely to occur to anybody who has not been immersed head down in a transport protocol implementation for several years. As far as I know nothing like this has never been tried with DNS. I'd be interested to hear otherwise. Reference: Appendix A of Van Jacobson's and Mike Karels's 1988 SIGCOMM paper "Congestion Avoidance and Control", which was still available from ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z last time I checked. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 11:40:20 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06794 for ; Mon, 16 Apr 2001 11:40:19 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14p9Wm-0008DB-00 for namedroppers-data@psg.com; Mon, 16 Apr 2001 06:58:52 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14p9Wl-0008Cs-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 06:58:52 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3GDnYs04170 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 09:49:34 -0400 (EDT) Received: from drugs.dv.isc.org ([130.155.191.236]) by psg.com with esmtp (Exim 3.16 #1) id 14p1qa-000N9v-00; Sun, 15 Apr 2001 22:46:49 -0700 Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.2/8.11.2) with ESMTP id f3G5kaT05285; Mon, 16 Apr 2001 15:46:38 +1000 (EST) (envelope-from marka@nominum.com) Message-Id: <200104160546.f3G5kaT05285@drugs.dv.isc.org> To: Randy Bush Cc: Thomas Narten , namedroppers@ops.ietf.org From: Mark.Andrews@nominum.com Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) In-reply-to: Your message of "Sun, 15 Apr 2001 18:17:51 MST." Date: Mon, 16 Apr 2001 15:46:36 +1000 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > I.e, the DNS does the things it is designed for quite well. > > opinions on this seem to vary. and the trend seems to be more > dissatisfaction. responses are perceived to be slower, though > hardware is faster and bandwidth wider. it would be helpful > to have actual data. > > randy Given that DNS queries and answers are small compared to most other uses of the internet. Increasing bandwidth has little effect compared with the effect of increasing bandwidth with other protocols. The dominant factor in the rtt calculation is signal transmission speed not the time it takes to spit all the bits into the link. As everything else speeds up the DNS *seems* slower. Mark > > > to unsubscribe send a message to namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 11:41:22 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06818 for ; Mon, 16 Apr 2001 11:41:20 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14p9VU-0008C6-00 for namedroppers-data@psg.com; Mon, 16 Apr 2001 06:57:32 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14p9VT-0008Ai-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 06:57:31 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3GDmDg04145 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 09:48:13 -0400 (EDT) Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.16 #1) id 14p2Uc-000OAR-00 for namedroppers@ops.ietf.org; Sun, 15 Apr 2001 23:28:11 -0700 Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA69963; Sun, 15 Apr 2001 23:21:57 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sun, 15 Apr 2001 23:21:57 -0700 (PDT) From: Bernard Aboba To: John Gilmore cc: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data In-Reply-To: <200104160350.UAA13713@toad.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If a speed problem is due to needing better retransmission algorithms > than UDP offers, let's resurrect a protocol for three-packet TCP for > short connections (similar to T/TCP) that automatically scales up to > an arbitrary number of packets and bytes if you don't terminate the > connection (as TCP does now). This would let us gradually switch to > defaulting to TCP queries... Use of TCP would address congestion between the host and local DNS server. However, it would *not* necessarily address overall congestion. Since hosts implement "stub" resolvers, local DNS servers act as proxies. Thus you'd really have two TCP connections, one from the host to the local DNS server, and another between the local DNS server and its correspondent. Assuming the two connections operate independently without coupling, self-clocking will not necessarily occur. For example, where the bottleneck exists between the local DNS server and its correspondent, the overall conversation will not self-clock. This is because the host will happily dispatch packets to the local DNS server oblivious of the overall bottleneck, which it cannot see, since there is no e2e transport connection. In this case the overall transport behavior will be influenced by the size of the queue on the local DNS server and the details of the implementation (e.g. whether backpressure is used, and if so, when). In the case of DNS, the effect is moderated by caching. The local DNS server will thus typically have the answer and thus will not have to originate its own query. Thus the typical query will only involve a single connection. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 11:41:39 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06835 for ; Mon, 16 Apr 2001 11:41:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14p9XK-0008Dn-00 for namedroppers-data@psg.com; Mon, 16 Apr 2001 06:59:26 -0700 Received: from h236.s254.netsol.com ([216.168.254.236]) by psg.com with esmtp (Exim 3.16 #1) id 14p9XJ-0008DD-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 06:59:25 -0700 Received: (from markk@localhost) by h236.s254.netsol.com (8.11.0/8.11.0) id f3GDo7A04182 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 09:50:08 -0400 (EDT) Received: from [64.38.134.99] (helo=internaut.com) by psg.com with esmtp (Exim 3.16 #1) id 14p1lR-000N1h-00 for namedroppers@ops.ietf.org; Sun, 15 Apr 2001 22:41:29 -0700 Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id WAA69911; Sun, 15 Apr 2001 22:35:15 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Sun, 15 Apr 2001 22:35:15 -0700 (PDT) From: Bernard Aboba To: John Gilmore cc: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data In-Reply-To: <200104160350.UAA13713@toad.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > If a speed problem is due to needing better retransmission algorithms > than UDP offers, I'm not even sure that we've got the best retransmission algorithm possible with UDP. I do find it curious that the transport behavior of resolvers has never been standardized. Some may take RTT into account in their algorithms; others do not. I have observed some resolvers failing over to secondary DNS servers at time intervals that would barely even permit a response from the primary to be returned. My suspicion is that better behaving resolvers could cut down on query volume. Perhaps a "DNS resolver implementation problem" draft is appropriate? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 11:42:08 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06847 for ; Mon, 16 Apr 2001 11:42:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pAdr-000AKk-00 for namedroppers-data@psg.com; Mon, 16 Apr 2001 08:10:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14pAdr-000AKe-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 08:10:15 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14pAdr-00092I-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 08:10:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104161434.JAA22180@gungnir.fnal.gov> To: Rob Austein Cc: namedroppers@ops.ietf.org From: "Matt Crawford" Subject: Re: DNS vs. non-DNS Data In-reply-to: Your message of Mon, 16 Apr 2001 04:10:46 EDT. <20010416081051Z23396-220+549@thrintun.hactrn.net> Date: Mon, 16 Apr 2001 09:34:39 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I have long suspected that something like TCP's variance-based > retransmission algorithm would help UDP-based applications like DNS. > Perhaps there are other algorithms better suited to this, ... And the more you concentrate your wide-area DNS queries through a small set of intermediaries, the more bang you can get out of better server, address & retransmission decisions ... up to the point at which you lose due to common points of failure. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 11:42:12 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06857 for ; Mon, 16 Apr 2001 11:42:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pAIP-0009k1-00 for namedroppers-data@psg.com; Mon, 16 Apr 2001 07:48:05 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14pAIP-0009jv-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 07:48:05 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14pAIP-0008tn-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 07:48:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: randy@psg.com Cc: narten@raleigh.ibm.com, namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) From: Havard Eidnes In-Reply-To: References: <3AD0C072.61DF46D1@ehsco.com> <200104111451.f3BEpMc04217@hygro.adsl.duke.edu> Message-Id: <20010416144308F.he@runit.sintef.no> Date: Mon, 16 Apr 2001 14:43:08 +0200 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > I.e, the DNS does the things it is designed for quite well. > > opinions on this seem to vary. and the trend seems to be more > dissatisfaction. responses are perceived to be slower, though > hardware is faster and bandwidth wider. it would be helpful > to have actual data. I have a suspicion that is a little more than vague that the root cause to this problem is probably misconfiguration of the DNS, in particular inconsistencies at zone cuts / delegation points and the resulting lame delegations. Since this is perhaps primarily a "people problem" at this point, throwing more hardware or bandwidth at it isn't going to make it go away. As one of my friends say in one of his plays with words: what the DNS needs the most is more CLUE records... Regards, - H=E5vard to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 12:48:09 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08154 for ; Mon, 16 Apr 2001 12:48:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pBGY-000BRx-00 for namedroppers-data@psg.com; Mon, 16 Apr 2001 08:50:14 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14pBGX-000BRr-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 08:50:13 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14pBGX-0009HE-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 08:50:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 16 Apr 2001 15:30:44 -0000 Message-ID: <20010416153044.25511.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data References: <200104160350.UAA13713@toad.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John Gilmore writes: > Programs dumb enough to make queries for "all records at label X" Unfortunately, mail transfer agents have been forced to do that for interoperability. Here's what happened: * RFC 821 prohibited ``nicknames or aliases'' in domain names in SMTP requests. RFC 1123 specifically prohibited DNS aliases: domain names with CNAME records. (Why? Because the IETF is incompetent.) * Sendmail's SMTP client checked for CNAME records by doing a * query. When it found a CNAME record, it replaced the alias with the contents of the CNAME record. * Many sites started relying on Sendmail's alias replacement. Users would type aliases and expect their mail to be delivered. * Meanwhile, when BIND found syntax errors in a zone, it wouldn't revert to the previous version of the zone, nor would it produce a consistent SERVFAIL answer. It replaced _negative answers_ with SERVFAIL. It didn't replace positive answers with SERVFAIL. (This was fixed recently.) * System administrators often made syntax errors in BIND zone files, and didn't realize that anything was wrong. There are still a huge number of domains for which CNAME requests produce SERVFAIL but * requests succeed. * New MTAs were forced to check for CNAME, because users relied on that behavior, but couldn't do it with CNAME queries, because that wouldn't interoperate with all those BIND sites. The only solution was to do * queries, just like Sendmail. The prohibition on CNAME records was abruptly yanked in 821bis, without regard for interoperability. I'm going to stop checking for CNAME records sometime in the next few years. In the meantime, however, I'm not going to accept any blame for my use of * queries in qmail. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 13:01:14 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08472 for ; Mon, 16 Apr 2001 13:01:13 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pC7e-000Cxb-00 for namedroppers-data@psg.com; Mon, 16 Apr 2001 09:45:06 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14pC7e-000CxV-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 09:45:06 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14pC7e-0009ah-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 09:45:06 -0700 Date: Mon, 16 Apr 2001 09:35:18 -0700 (PDT) From: Bernard Aboba To: Rob Austein cc: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data In-Reply-To: <20010416081051Z23396-220+549@thrintun.hactrn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > I have long suspected that something like TCP's variance-based > retransmission algorithm would help UDP-based applications like DNS. In practice, we see resolvers failing over to the secondary before an RTO timer would have expired. Emission of dual packets often continues even after the primary has not responded for quite a while. So in addition to the RTT/RTO logic, we also need to think about failover/failback behavior. > Perhaps there are other algorithms better suited to this, but the > variance-based algorithm is easy to implement (core algorithm is seven > lines of code), conceptually straightforward (in retrospect :), and is > almost certainly a better retransmission algorithm than is likely to > occur to anybody who has not been immersed head down in a transport > protocol implementation for several years. > > As far as I know nothing like this has never been tried with DNS. I'd > be interested to hear otherwise. I'm told that some implementations have incorporated RTT estimates, though probably not in the same manner. Looking into this in a systematic way would seem worthwhile (any grad students interested in a thesis topic?) It would be likely to have a particularly big impact on the root servers. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 14:24:00 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10608 for ; Mon, 16 Apr 2001 14:24:00 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pCoA-000EBt-00 for namedroppers-data@psg.com; Mon, 16 Apr 2001 10:29:02 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14pCo9-000EBn-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 10:29:01 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14pCo9-0009rt-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 10:29:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Apr 2001 13:23:40 -0400 (EDT) From: Tim Seaver Message-Id: <200104161723.NAA08087@spike.eng.bellsouth.net> To: randy@psg.com Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)) Cc: namedroppers@ops.ietf.org, narten@raleigh.ibm.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > I.e, the DNS does the things it is designed for quite well. > > > > opinions on this seem to vary. and the trend seems to be more > > dissatisfaction. responses are perceived to be slower, though > > hardware is faster and bandwidth wider. it would be helpful > > to have actual data. I'm in the middle of a DNS performance study. Right now, I can say with confidence that most DNS performance problems from my perspective in the network/DNS topology come from: 1) Short TTLs on second-level NS records combined with overload of gTLD servers, leading to caching server retries for delegation data. 2) Short TTLs on popular address records combined with overload of second-level domain servers, leading to caching server retries for web host address records. 3) Short TTLs on second-level NS records combined with second-level servers in a different domain than the name being queried combined with BIND's decision to ignore additional data in such circumstances combined with BIND's decision to drop client queries when no address records exist for the authoritative servers required to resolve a query, leading to non-response from caching servers and client retries. Network-level problems come in a distant second to server problems combined with short TTLs. When I have a report done, I'll see if I can release it to the list. Thanks, Tim to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 16:31:23 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13312 for ; Mon, 16 Apr 2001 16:31:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pEfA-000Gzg-00 for namedroppers-data@psg.com; Mon, 16 Apr 2001 12:27:52 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14pEfA-000Gza-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 12:27:52 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14pEf9-000AcP-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 12:27:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3ADB4467.6659EA2E@ehsco.com> Date: Mon, 16 Apr 2001 12:13:43 -0700 From: "Eric A. Hall" To: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data References: <200104160350.UAA13713@toad.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John Gilmore wrote: > The DNS is really the only game in town for what it does. Who else > has a locally published, globally accessible, hierarchical, > distributed, replicated, cached, high availability, dynamic database? > With hundreds of thousands of publishers and hundreds of millions of > hourly users? With end-to-end cryptographic authentication coming > soon? Oracle? Don't make me laugh. Let's look at this position up close for a moment. In order for DNS to serve as a general-purpose database, it would need several new features. For example: o DNS would need record-locking mechanisms so that a user could modify data without another user modifying the same record simultaneously. DNS as a lookup service for Internet resources does not need this capabilty. Please submit your draft on record-locking. :) By the way, you should also plan ahead for byte-range locking so that two users can modify different parts of the same "database record," since feature creep is hard to stop once it gets started. o Databases need user-specific ACLs, lookups do not. This also requires user-specific authentication which is verifiable and not subject to replay attacks. It also means implementing a key-exchange structure, and a management architecture that allows for adding/editing/deleting keys from the structure. The user auth part would actually be pretty easy to implement in the protocol if it weren't for the 512 byte limit and the datagram centric approach to lookup operations. Implementing a management architecture such that non-replay user-specific keys are verifiable in a datagram exchange within this size constraint is not easy. o What good is a database table that can't be joined with other tables? Conversely, DNS does not need joins since lookups are one dimensional. Although DNS has an effective db architecure for lookups, the architecture is effective because it is optimized for lookups. It has NO existing constructs for building joins. There aren't even any conceptual hooks for this. You'd literally have to add an entire new framework, along with a collection of verbs and protocol mechanisms to DNS in order for this to work. Don't forget the locking and authentication requirements. o Databases need tools and hooks for the tools. Surely you don't expect users to edit zone files directly? But GUI gizmos that let users lock a record and edit the contents, set permissions, and perform triggered updates, they require protocol hooks which leverage authentication, etc. In short, DNS is not capable of serving as a general-purpose database without totally overhauling the protocol and service. Unfortunately, DNS does not have the structure to allow these changes. It doesn't even have a version field! Morover, overloading the DNS service with these features would MAKE IT USELESS FOR LOOKUPS. If DNS were converted into a general purpose lookup archicture that resulted in a magnitude more queries, all kinds of problems would happen. Do you think the root could handle a magnitude more queries? We already know that responses overflow, but what happens when DNS caches start to overflow? How useful is the distributed lookup service when none of the distributed lookup points have the data? Furthermore, calling DNS a database and comparing it to Oracle is a false premise. It is not a general purpose database along the lines of any existing database product. Seriously, you would have an easier time turning IMAP into a distributed database than you would with DNS. DNS is a _distributed lookup_ service. There is no way that DNS can serve the kinds of functions that people expect from general purpose database and still be useful for lookups. Advocating its usage for such or representing that it is capable of performing as such would be irresponsible of this group and the Internet community in general. But since this comes up so very often, my position is to advocacate restraint so that we keep DNS from being loved to death by people who think it can be a general purpose database or a directory. And since we know that if all of the necessary cruft were added to DNS in order to support those functions IT WOULD BECOME USELESS FOR LOOKUPS, lets define where the line is, and let's not be arbitrary about it. As for your baseball score application, there are a lot of issues with that. Putting all of the systems in a single .baseball domain doesn't give you access to all of the systems unless you use zone transfers. At that point, why do you need DNS, since you aren't doing lookups? Couldn't you just be replicating static lists with TFTP? Couldn't you use FTP or HTTP and gain authentication? Or use CGI and XML and get update capabilities with locking and more? Again, you would be further ahead if you started with something like a shared IMAP message store; as inappropriate as that would be, it would be much more usable than DNS. Use DNS to find the server(s) for your application, you don't need to use DNS for the application data, and doing so would be a bad idea anyway. > I do think that a complete replacement for DNS should be researched, > designed, and prototyped. It should use what we have learned about > building distributed databases over the last twenty years, and what we > have learned about how NOT to administer globally vital resources. DNS works pretty damn well as a lookup service. We don't need another lookup service. What we need are better tools for managing distributed data, of which DNS data is a subset. LDAP is advancing nicely and there is now a locator protocol in place so things like user-specific authentication and application-specific transactions are certainly now possible. For large-scale database services, I agree that the IETF needs to develop a vendor-neutral database transport protocol (similar to the way that SMTP/POP/IMAP provide vendor-neutral email transports, we need a vendor-neutral database access protcol). DNS is not it. > whatever applications people can find for it. If the research > produces something better, people will switch over to it naturally; if > not, the current DNS has to keep working. The current DNS will only keep working if it is restrained to lookups, the very function that it was designed to serve. It will not keep working if the protocol, service, tables and caches are overloaded with excessive amounts of data which doesn't benefit from the lookup architecture. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 16 17:10:22 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13886 for ; Mon, 16 Apr 2001 17:10:21 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pFPo-000I8J-00 for namedroppers-data@psg.com; Mon, 16 Apr 2001 13:16:04 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14pFPo-000I8B-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 13:16:04 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14pFPo-000Avj-00 for namedroppers@ops.ietf.org; Mon, 16 Apr 2001 13:16:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: "Larson, Matt" Reply-To: dnsop@cafax.se To: "'Tim Seaver'" Cc: namedroppers@ops.ietf.org Subject: RE: DNS vs. non-DNS Data (was Re: Signature at parent (draft-ietf -dnsop-parent-sig-00.txt)) Date: Mon, 16 Apr 2001 15:56:50 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Message-Id: Content-Transfer-Encoding: 7bit Seems like this thread has strayed into operational territory, so I'm directing replies to dnsop@cafax.se (and including the whole message for background). Tim, could you please elaborate on your #1 below? I'm not sure if you're attributing the short TTLs to the {com,net,org} zone contents. But I just wanted to point out that although all delegations in the {com,net,org} zones have a 48-hour TTL, that should have little effect on how long a zone's NS RRset is actually cached. In any BIND name server since 4.9, as well as the Microsoft DNS server (at least the W2K version--don't have an NT 4 system handy to test), the NS RRset in the delegated zone overrides the RRset obtained from the parent. So NS RRsets for subzones of {com,net,org} with "short" TTLs are an issue with individual zone administrators. What do you mean by "overload of gTLD servers"? We've sized the {com,net,org} name servers very carefully and monitor the query volume in real time. We have lots of headroom and have yet to come close to our maxmimum. I'd be very interested in any data you've got--I wouldn't like to think we've missed something. Thanks, Matt -- Matt Larson VeriSign Global Registry Services / www.verisign-grs.com > -----Original Message----- > From: Tim Seaver [mailto:tas@bellsouth.net] > Sent: Monday, April 16, 2001 1:24 PM > To: randy@psg.com > Cc: namedroppers@ops.ietf.org; narten@raleigh.ibm.com > Subject: Re: DNS vs. non-DNS Data (was Re: Signature at parent > (draft-ietf-dnsop-parent-sig-00.txt)) > > > > > > I.e, the DNS does the things it is designed for quite well. > > > > > > opinions on this seem to vary. and the trend seems to be more > > > dissatisfaction. responses are perceived to be slower, though > > > hardware is faster and bandwidth wider. it would be helpful > > > to have actual data. > > I'm in the middle of a DNS performance study. Right now, I can > say with confidence that most DNS performance problems from my > perspective in the network/DNS topology come from: > > 1) Short TTLs on second-level NS records combined with overload of > gTLD servers, leading to caching server retries for delegation data. > > 2) Short TTLs on popular address records combined with overload of > second-level domain servers, leading to caching server retries for > web host address records. > > 3) Short TTLs on second-level NS records combined with second-level > servers in a different domain than the name being queried combined > with BIND's decision to ignore additional data in such circumstances > combined with BIND's decision to drop client queries when no address > records exist for the authoritative servers required to > resolve a query, > leading to non-response from caching servers and client retries. > > Network-level problems come in a distant second to server problems > combined with short TTLs. When I have a report done, I'll see if I > can release it to the list. > > Thanks, > > Tim > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 17 10:16:06 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08281 for ; Tue, 17 Apr 2001 10:16:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pV3b-0000Iu-00 for namedroppers-data@psg.com; Tue, 17 Apr 2001 05:58:11 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14pV3b-0000Io-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 05:58:11 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14pV3L-0000Kv-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 05:57:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104170716.AAA19391@toad.com> To: "Eric A. Hall" cc: namedroppers@ops.ietf.org, gnu@toad.com Subject: Re: DNS vs. non-DNS Data In-reply-to: <3ADB4467.6659EA2E@ehsco.com> Date: Tue, 17 Apr 2001 00:16:31 -0700 From: John Gilmore Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > ... a locally published, globally accessible, hierarchical, > > distributed, replicated, cached, high availability, dynamic database ... Just as I said, Oracle doesn't offer this. Nor does the DNS offer what Oracle has. DNS is the only game in town for what it does. There's no point in beating up the strawman of "DNS as generic database". The point is that it is the ONLY database of any sort that has the above characteristics. There's only one in the known universe. Everybody who ever needed something like this (e.g. the Web) ended up using DNS as a sub-component, because it already existed and worked, and tens of thousands of people already maintain the information in it. Randy's point seemed to be that we should limit access to this singular wonder (I assume on the grounds that we would thereby be protecting it). I argue instead that rather than reserve DNS for only holding information for some sort of privileged applications, that we let it be used as it has been used for decades. For publishing and obtaining information useful to whatever applications need its facilities. If we did withhold access to it, new significant applications would have to provide similar facilities -- and then there would be TWO global distributed replicated blah blah blah databases. In the long run that might be a good thing, having a backup or two. It's more likely that the next world-shaking system like Email or the Web will merely fail, because it lacked a global database and couldn't use ours. I suggest that if we want to protect the DNS, it would be better to design a backup system -- as IPv6 is for IPv4. The One That Fixes The Structural Problems We Know Will Bite Us Someday. Let's get it ready as a research project, and deploy it as we need it or find it fun, rather than forcing some poor application to invent it because we won't give them a DNS record type. And meanwhile, to protect the DNS, we should fix the minor limits in the DNS protocol, whether they be performance, implementation, fixed-size fields, or whatever. So it can keep evolving in case the research doesn't pan out. When I was a DNS registrar (of no TLDs, due to NSI) I was surprised that no registrars built tools for automatically telling their customers when the customer's DNS was misconfigured, and suggesting what to do about it. If there's a performance problem due to misconfigured servers or zones, a few relatively simple tools could perhaps diagnose the problems, letting humans focus their attention on the hot spots. John to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 17 12:10:06 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10995 for ; Tue, 17 Apr 2001 12:10:05 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pWpw-00037y-00 for namedroppers-data@psg.com; Tue, 17 Apr 2001 07:52:12 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14pWpv-00037s-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 07:52:11 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14pWpv-0002kw-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 07:52:11 -0700 To: Peter Koch Cc: namedroppers@ops.ietf.org Subject: Re: DNSEXT WGLC: NO record References: <200104061614.SAA23487@grimsvotn.TechFak.Uni-Bielefeld.DE> From: Simon Josefsson In-Reply-To: <200104061614.SAA23487@grimsvotn.TechFak.Uni-Bielefeld.DE> (Peter Koch's message of "Fri, 06 Apr 2001 18:14:34 +0200") Date: 17 Apr 2001 16:46:38 +0200 Message-ID: Lines: 22 User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.102 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Peter Koch writes: > > What I thought about was that some of the problems with NXT might not > > be visible at the registry level -- like the zone walking problem. > > Registries won't consider it to be an issue, they don't store SSH host > > keys, personal PGP keys etc in DNS. Registries aren't the "end-users" > > of DNS data. Once the registries (the infrastructure) use DNSSEC, > > Do you want to say that preventing zone-walking is not important for TLD > registries? From what I've heard it's the other way round. I think it's important for some, and not important for others -- and for the same reason that some operators allow anonymous zone transfers and others don't. I know at least .SE and .NL, which both have been visible in DNSSEC testing, allow zone transfers, so there wouldn't be a need to "walk" these zones for information. With the "end-users" of DNS above I meant companys and organizations that will be running DNS(SEC), and I think the zone walking issue will be regarded (by themself) as more problematic. TLDs that disallow zone transfers might also agree, depending on their reasons for not allowing zone transfers. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 17 18:31:10 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17379 for ; Tue, 17 Apr 2001 18:31:08 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pcWT-000ByY-00 for namedroppers-data@psg.com; Tue, 17 Apr 2001 13:56:29 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14pcWR-000ByR-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 13:56:28 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14pcWQ-0002XO-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 13:56:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104171916.PAA13915@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) to Proposed Standard Date: Tue, 17 Apr 2001 15:16:20 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has approved the Internet-Draft 'RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)' as a Proposed Standard. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary Since the adoption of a Proposed Standard for RSA signatures in the DNS [RFC 2537], advances in hashing have been made. A new DNS signature algorithm is defined to make these advances available in SIG resource records (RRs). The use of the previously specified weaker mechanism is deprecated. The algorithm number of the RSA KEY RR is changed to correspond to this new SIG algorithm. No other changes are made to DNS security. The document obsoletes RFC 2537. Implementation of the RSA algorithm in DNS with SHA1 is MANDATORY for DNSSEC. The generation of RSA/MD5 SIG RRs as described in [RFC 2537] is NOT RECOMMENDED. Working Group Summary There was concensus in the WG to advance the document. Protocol Quality This specification was reviewed for the IESG by Erik Nordmark. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 17 18:31:13 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17389 for ; Tue, 17 Apr 2001 18:31:10 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pcXx-000C0b-00 for namedroppers-data@psg.com; Tue, 17 Apr 2001 13:58:01 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14pcXw-000C0V-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 13:58:00 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14pcXw-0002XS-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 13:58:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104171913.PAA13863@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: namedroppers@ops.ietf.org From: The IESG Subject: Protocol Action: RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) to Proposed Standard Date: Tue, 17 Apr 2001 15:13:18 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has approved the Internet-Draft 'RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)' as a Proposed Standard. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary Since the adoption of a Proposed Standard for RSA signatures in the DNS [RFC 2537], advances in hashing have been made. A new DNS signature algorithm is defined to make these advances available in SIG resource records (RRs). The use of the previously specified weaker mechanism is deprecated. The algorithm number of the RSA KEY RR is changed to correspond to this new SIG algorithm. No other changes are made to DNS security. The document obsoletes RFC 2537. Implementation of the RSA algorithm in DNS with SHA1 is MANDATORY for DNSSEC. The generation of RSA/MD5 SIG RRs as described in [RFC 2537] is NOT RECOMMENDED. Working Group Summary There was concensus in the WG to advance the document. Protocol Quality This specification was reviewed for the IESG by Erik Nordmark. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 17 18:44:09 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17507 for ; Tue, 17 Apr 2001 18:44:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pZmw-0007kJ-00 for namedroppers-data@psg.com; Tue, 17 Apr 2001 11:01:18 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14pZmv-0007kC-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 11:01:17 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14pZmr-0002Wj-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 11:01:13 -0700 Received: from arachnid.ehsco.com ([209.31.7.46] helo=Arachnid.NTRG.com) by psg.com with esmtp (Exim 3.16 #1) id 14pZcL-0007S0-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 10:50:21 -0700 Received: from ehsco.com (ferret.ntrg.com [192.168.10.10]) by Arachnid.NTRG.com (Netscape Messaging Server 3.62) with ESMTP id 363 for ; Tue, 17 Apr 2001 10:50:19 -0700 Message-ID: <3ADC8258.A80203AB@ehsco.com> Date: Tue, 17 Apr 2001 10:50:17 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data References: <200104170716.AAA19391@toad.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John Gilmore wrote: > I argue instead that rather than reserve DNS for only holding > information for some sort of privileged applications, Nobody is advocating that we should restrict it to specific apps. What I am advocating is that we restrict it to pure lookups of Internet specific resources rather than succumbing to the constant push to extend it into general-purpose database and directory services. For example, some of the things you listed in your prior message are not connection-critical lookups, do not require the use of DNS (life would just be easier if you could use DNS), and would actually be better served by something like LDAP: >>> Crypto keys. Physical locations. Mail handlers. Other service >>> handlers. Text. Names. Addresses for lower or higher level >>> protocols. All of those would be better served through local authenticated queries (aka LDAP). None of them are optimally served with DNS. > that we let it be used as it has been used for decades. For publishing > and obtaining information useful to whatever applications need its > facilities. The Internet of the last 10 years is a lot smaller than the Internet of the next 10 years. There are better alternatives for data that won't require polluting DNS' lookup functionality or rewriting the protocols, and which will just work better. > If we did withhold access to it, new significant applications would > have to provide similar facilities Or they could use any of the existing data-publishing and gathering technologies already out there. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 18 00:53:14 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23244 for ; Wed, 18 Apr 2001 00:53:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pikS-000HsV-00 for namedroppers-data@psg.com; Tue, 17 Apr 2001 20:35:20 -0700 Received: from endicott-ninety-seven.mit.edu ([18.99.1.97] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14pikR-000HsO-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 20:35:19 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14pikM-0002gK-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 23:35:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3ADCDB32.597883BD@ehsco.com> Date: Tue, 17 Apr 2001 17:09:22 -0700 From: "Eric A. Hall" To: John Gilmore CC: namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data References: <200104172325.QAA13342@toad.com> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So, define "lookups of Internet specific resources". If you propose > to limit the availability of DNS, you have the burden to define > exactly who will and who won't be allowed to use it. I have: | Date: Thu, 12 Apr 2001 08:54:27 -0700 | From: "Eric A. Hall" | To: Robert Elz | CC: Thomas Narten , | namedroppers@ops.ietf.org | I consider "lookup" to be a piece of required data which is | necessary for a distributed (eg, Internet-wide) application | process to complete. There are other quals which I am incorporating into a personal draft on the general subject of ~"Considerations for new DNS RRs". > An earlier post by you suggested that you thought "MX" was a mistake, > that email server info should never have gone into the DNS. That > statement seemed to me to be a bit of a gauntlet thrown down. If > email, which is the long-term killer application of the Internet and > its predecessors, doesn't qualify as an "Internet specific resource", > then what would? To be precise, I said that RRs for service- or application-specific data should not go into DNS (with MX being cited as an example), and that keeping app-specific RRs *like* MX out of DNS has been an ongoing effort (which eventually resulted in SRV, a single RR for general service-layer connection config). > I didn't mean to start an LDAP flame war. I wasn't even talking about > LDAP. I'm sorry that LDAP is threatened by the DNS. I'm sorry that > you're sensitive about it. I wish LDAP could be just as popular as > you want it to be. Forget I ever mentioned it, even though I didn't. This isn't about LDAP vs DNS, it is about your insistance that DNS is always the appropriate technology for all data of any kind on any network anywhere. For the application-specific authenticated queries required by your own examples, LDAP is a more-suitable technology than DNS. I don't know how you got LDAP-vs-DNS from that, nor do I really care. What I *do* care about is the globally-distributed lookup service which everybody depends on, and that it doesn't get broken by excessive extensions which do not serve the purpose of the protocol and which do not even benefit from the nature of the protocol. To wit, you have yet to provide an example which absolutely requires DNS and which could not be better served by some other technology. You have only provided examples which overload the hierarchy and protocol, which require significant amounts of protocol redevelopment to optimize for, and which don't even BENEFIT from being in DNS in the first place. In all of your examples, faster deployment and better access to the localized data would be achieved by using something other than DNS. Your demand that DNS be prostituted to accomodate this cruft is simply untenable. > Just don't tell us that new applications CAN'T use DNS, and MUST use > something else. Without a very good justification, which so far I > haven't seen. This group reject extensions fairly often. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 18 00:59:15 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23284 for ; Wed, 18 Apr 2001 00:59:14 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14pii4-000HqL-00 for namedroppers-data@psg.com; Tue, 17 Apr 2001 20:32:52 -0700 Received: from endicott-ninety-seven.mit.edu ([18.99.1.97] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14pii4-000HqF-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 20:32:52 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14pii2-0002g7-00 for namedroppers@ops.ietf.org; Tue, 17 Apr 2001 23:32:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104172325.QAA13342@toad.com> To: "Eric A. Hall" cc: namedroppers@ops.ietf.org, gnu@toad.com Subject: Re: DNS vs. non-DNS Data In-reply-to: <3ADC8258.A80203AB@ehsco.com> Date: Tue, 17 Apr 2001 16:25:36 -0700 From: John Gilmore Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Nobody is advocating that we should restrict it to specific apps. What I > am advocating is that we restrict it to pure lookups of Internet specific > resources rather than succumbing to the constant push to extend it into > general-purpose database and directory services. So, define "lookups of Internet specific resources". If you propose to limit the availability of DNS, you have the burden to define exactly who will and who won't be allowed to use it. An earlier post by you suggested that you thought "MX" was a mistake, that email server info should never have gone into the DNS. That statement seemed to me to be a bit of a gauntlet thrown down. If email, which is the long-term killer application of the Internet and its predecessors, doesn't qualify as an "Internet specific resource", then what would? > All of those would be better served through local authenticated queries > (aka LDAP). None of them are optimally served with DNS. I didn't mean to start an LDAP flame war. I wasn't even talking about LDAP. I'm sorry that LDAP is threatened by the DNS. I'm sorry that you're sensitive about it. I wish LDAP could be just as popular as you want it to be. Forget I ever mentioned it, even though I didn't. Let's let a thousand flowers bloom. YOU can serve your information your way, I will serve mine with DNS. We can live and let live. Just don't tell us that new applications CAN'T use DNS, and MUST use something else. Without a very good justification, which so far I haven't seen. John to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 18 14:44:39 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15603 for ; Wed, 18 Apr 2001 14:44:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14psOY-000DWH-00 for namedroppers-data@psg.com; Wed, 18 Apr 2001 06:53:22 -0700 Received: from endicott-ninety-seven.mit.edu ([18.99.1.97] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14psOX-000DRq-00 for namedroppers@ops.ietf.org; Wed, 18 Apr 2001 06:53:21 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14psOT-0009Kv-00 for namedroppers@ops.ietf.org; Wed, 18 Apr 2001 09:53:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: John Gilmore Cc: "Eric A. Hall" , namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data References: <3ADC8258.A80203AB@ehsco.com> <200104172325.QAA13342@toad.com> Message-Id: Date: Wed, 18 Apr 2001 08:45:19 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > So, define "lookups of Internet specific resources". If you propose > to limit the availability of DNS, you have the burden to define > exactly who will and who won't be allowed to use it. or, conversely, if you plan to add gnurr to it, you need to justify that. design conservatives may prefer the latter. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 18 14:45:02 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15628 for ; Wed, 18 Apr 2001 14:45:01 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14prif-0000Py-00 for namedroppers-data@psg.com; Wed, 18 Apr 2001 06:10:05 -0700 Received: from endicott-ninety-seven.mit.edu ([18.99.1.97] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14prif-0000Ps-00 for namedroppers@ops.ietf.org; Wed, 18 Apr 2001 06:10:05 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14prid-0002xH-00 for namedroppers@ops.ietf.org; Wed, 18 Apr 2001 09:10:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104180656.XAA05569@toad.com> To: "Eric A. Hall" cc: John Gilmore , namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data In-reply-to: <3ADCDB32.597883BD@ehsco.com> Date: Tue, 17 Apr 2001 23:56:01 -0700 From: John Gilmore Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This isn't about LDAP vs DNS, it is about your insistance that DNS is > always the appropriate technology for all data of any kind on any network > anywhere. This isn't about that strawman, either, since I didn't insist on that. Maybe you and I should give it a rest, and see what a few other people think. John to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 18 14:45:05 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15640 for ; Wed, 18 Apr 2001 14:45:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14prZN-0000Fw-00 for namedroppers-data@psg.com; Wed, 18 Apr 2001 06:00:29 -0700 Received: from endicott-ninety-seven.mit.edu ([18.99.1.97] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14prZM-0000Fp-00 for namedroppers@ops.ietf.org; Wed, 18 Apr 2001 06:00:29 -0700 Received: from randy by roam.psg.com with local (Exim 3.20 #1) id 14prZI-0002wh-00 for namedroppers@ops.ietf.org; Wed, 18 Apr 2001 09:00:24 -0400 From: Robert Elz To: "Eric A. Hall" cc: John Gilmore , namedroppers@ops.ietf.org Subject: Re: DNS vs. non-DNS Data In-reply-to: Your message of "Tue, 17 Apr 2001 17:09:22 MST." <3ADCDB32.597883BD@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Apr 2001 11:27:53 +0700 Message-ID: <2194.987568073@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Tue, 17 Apr 2001 17:09:22 -0700 From: "Eric A. Hall" Message-ID: <3ADCDB32.597883BD@ehsco.com> | | I consider "lookup" to be a piece of required data which is | | necessary for a distributed (eg, Internet-wide) application | | process to complete. That restricts absolutely nothing that anyone is going to care about. Anything that uses the internet is distributed by definition (as opposed to things that simply run on computers attached to the internet - eg: my computer runs a compiler, but that is local, not distributed, and fortunately, has no need for anything at all in the DNS). But all e-mail, web, irc, ... all count as distributed. So, your definition just says that anything that is needed by any such application can go in the DNS. That's fine, I don't have a problem with that, though I would probably restrict it a bit more, so it better fits the current DNS protocols (unless/until they are ever extended, and then that is deployed widely enough to make a difference). | There are other quals which I am incorporating into a personal draft on | the general subject of ~"Considerations for new DNS RRs". Then those we are going to have to see before the rest of us will have any idea whether we agree or not. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Tue Apr 24 18:46:52 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17070 for ; Tue, 24 Apr 2001 18:46:51 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14sBA0-0008V6-00 for namedroppers-data@psg.com; Tue, 24 Apr 2001 15:19:52 -0700 Received: from mg-206253200-51.ricochet.net ([206.253.200.51] helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14sB9z-0008Uz-00 for namedroppers@ops.ietf.org; Tue, 24 Apr 2001 15:19:52 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14sAhV-00009z-00 for namedroppers@ops.ietf.org; Tue, 24 Apr 2001 14:50:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104241909.PAA12870@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: namedroppers@ops.ietf.org From: The IESG Subject: Document Action: A DNS RR Type for Lists of Address Prefixes (APL RR) to Experimental Date: Tue, 24 Apr 2001 15:09:27 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The IESG has approved the Internet-Draft 'A DNS RR Type for Lists of Address Prefixes (APL RR)' as an Experimental Protocol. This document is the product of the DNS Extensions Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 25 12:23:39 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21650 for ; Wed, 25 Apr 2001 12:23:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14sRg8-0004fo-00 for namedroppers-data@psg.com; Wed, 25 Apr 2001 08:58:08 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14sRg7-0004fi-00 for namedroppers@ops.ietf.org; Wed, 25 Apr 2001 08:58:07 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14sRg7-0002VE-00 for namedroppers@ops.ietf.org; Wed, 25 Apr 2001 08:58:07 -0700 Date: Wed, 25 Apr 2001 11:54:11 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: comments on mnds-00 To: sander.van-valkenburg@nokia.com Cc: namedroppers@psg.com, levone@Exchange.Microsoft.com, erik.guttman@sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Sander, Levon, --- erik> I suggest that, just as other zeroconf protocols, a host may erik> either run this zeroconf protocol service or not. This need erik> not be something that can be turned off by DHCP, nor should erik> it be - any more than v4LL autoconfiguration. levon> I don't agree. There must be a way to disable mDNS through levon> DHCP, to prevent mDNS traffic in well managed (i.e. non-zero- levon> conf) corporate environments, where the last thing users need levon> is more network traffic. As I argued in my other response, I argue that link-local scoped mDNS traffic is not an issue. Even on an enormous bridged network with many hosts, there would not be enough mdns traffic to have an impact on even a 1MB link. --- mdns-00> It is not expected that a device "host.example.com." will mdns-00> be manually configured to have additional name mdns-00> "host.example.com.local.arpa." when it is configured to use mdns-00> multicast DNS. Instead, a responder with a name mdns-00> "host.example.com." configured with ".local.arpa." suffix in mdns-00> its domain search configuration is authoritative for the name mdns-00> "host.example.com.local.arpa.". I.e. when responder with the mdns-00> name "host.example.com." receives an A type query for the mdns-00> name "host.example.com.local.arpa." it authoritatively mdns-00> responds to the query. erik> Why attach the suffix '.local.arpa' stuff? Why not just erik> multicast a request for 'host.example.com'? levon> As I mentioned above, I don't see any problems with sending levon> multicast queries for the names that don't end with levon> ".local.arpa". sander> I think that, if hosts may respond to a query for any name, sander> so also those not ending with .local.arpa, there should be sander> a specified way to turn off the mDNS behavior. As Levon sander> mentioned, in managed networks it would be undesirable to sander> have nodes sending mDNS queries for any name e.g. as last sander> resort for resolving a host name. If this is desirable, we have to define a new DHCP option to do it, instead of overloading the name search list semantics. --- sander> I am not against responding to queries for any name, but it sander> may complicate things in case of a zeroconf-to-non-zeroconf sander> transition takes place. In the case of name resolution, the way this transition takes place is the resolver is reconfigured to send unicast requests to a DNS server. The only way that a resolver will resort to using mDNS is if there is no DNS server available. (How does this reconfiguration take place? I am taking this up in another thread.) If mDNS is disabled, this is equivalent to saying that in the case where there is no DNS server available hosts (without a static configured host file mechanism) will be guaranteed to fail to resolve names. Please discuss why this is a good thing that some administrators would want. Regards, Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 25 12:23:41 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21661 for ; Wed, 25 Apr 2001 12:23:40 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14sRgF-0004g6-00 for namedroppers-data@psg.com; Wed, 25 Apr 2001 08:58:15 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14sRgE-0004g0-00 for namedroppers@ops.ietf.org; Wed, 25 Apr 2001 08:58:14 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14sRgE-0002VR-00 for namedroppers@ops.ietf.org; Wed, 25 Apr 2001 08:58:14 -0700 Date: Wed, 25 Apr 2001 11:56:48 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: comments on mnds-00 To: Levon Esibov Cc: Erik Guttman , namedroppers@psg.com, erik.guttman@Sun.COM, Dave Thaler , Bernard Aboba , cheshire@apple.com In-Reply-To: "Your message with ID" <5B90AD65A9E8934987DB0C8C0762657405146FDC@DF-BOWWOW.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Levon, > > >The responder includes in the additional and authority section of > > >the response the same records, as a DNS server would insert in the > > >response to the unicast DNS query. > > > > Please reword: > It is not the purpose of this draft to specify which records should be > included in the additional and authority sections of the response to a > query. The set of records that should be included in the additional and > authority sections is specified elsewhere. OK. > > A responder must not send anything except a positive non-null > > response. That is, a null response or a negative response MUST > > NOT be sent. The argument for this is given above. > > Agree. As I mentioned above, the draft is probably not very about this. > Suggestions on how to improve the text are welcome. Please modify the following paragraph as follows: - Sender MUST anticipate receiving no replies to some multicasted queries, - in the event that no responders are available within the multicast - scope, or in the event that no positive non-null responses exist to the - transmitted query. -> + Responders MUST NOT send a null response or a negative response. + + Senders MUST anticipate receiving no replies to some multicasted + queries, in the event that no responders are availabile within the + multicast scope. > > >If no positive response is received, a resolver treats it as > > a response > > >that no records of the specified type and class for the > > specified name > > >exist (NXRRSET), which SHOULD be cached for a period that SHOULD NOT > > >exceed 5 seconds. > > > > Why define this behavior? This is complicated and will make little > > difference when a single mdns request is already takes a few seconds > > to complete. > > This behavior will prevent poorly written application from resending > the same query after it receives NXRRSET. I agree with your comment > that if sender resends the same query 5 times, with exponentially > increasing interval between them, then the mdsn query resolution may > take a few seconds, what makes negative caching not that useful. May > be we should recommend less number retries (e.g. 3 instead of 5)? In > this case we'll suppress larger number of useless multicast queries. Why can't we keep this simple? If no reply comes back by the time the mdns requester gives up (however long that is), the requester can treat this as a negative response. I do not see that caching helps, unless the caching is for a longer duration (on the order of minutes). This is bad in a boot-up scenario, where all machines come up around the same time and need to resolve each others names to access critical services. Adding negative result caching will then require minutes to get up and running instead of a few seconds, or cause clients to fail completely. Please modify the following paragraph as follows: - If no positive response is received, a resolver treats it as a response - that no records of the specified type and class for the specified name - exist (NXRRSET), which SHOULD be cached for a period that SHOULD NOT - exceed 5 seconds. -> + If no response is received, a resolver treats it as a response that + no records of the specified type and class for the specified name + exist. > > >Any device whose domain search configuration contains ".local.arpa." > > >domain is configured to behave as "responder". > > > > Why should this behavior be configured using the search path? > > Why should the resolver search path IN ANY CASE determine the > > multicast dns server behavior? > > I don't have any argument in favor of using the search path to > enable/disable device to use mDNS. Original version of the draft > suggested use of a new parameter, but the initiative group that met in > Adelaide a year ago recommended to use the search path. If we want a mechanism to disable multicast DNS, why not create an DHCP option to do just that. I believe overloading search paths with implied transmission semantics will lead to confusion. Further, why should search path and behavior be tied together? Why couldn't a DNS server which exists on the same local link as the requestor respond to requests for local names? > > I suggest that, just as other zeroconf protocols, a host may either > > run this zeroconf protocol service or not. This need not be something > > that can be turned off by DHCP, nor should it be - any more than v4LL > > autoconfiguration. > > I don't agree. There must be a way to disable mDNS through DHCP, to > prevent mDNS traffic in well managed (i.e. non-zero-conf) corporate > environments, where the last thing users need is more network traffic. mDNS as specified runs only in a *link-local* mode. Are you suggesting that mDNS could be a burden to link-local network traffic? If so, please substantiate. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 25 12:24:35 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21680 for ; Wed, 25 Apr 2001 12:24:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14sRg1-0004fg-00 for namedroppers-data@psg.com; Wed, 25 Apr 2001 08:58:01 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14sRg1-0004fa-00 for namedroppers@ops.ietf.org; Wed, 25 Apr 2001 08:58:01 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14sRg0-0002V0-00 for namedroppers@ops.ietf.org; Wed, 25 Apr 2001 08:58:00 -0700 Date: Wed, 25 Apr 2001 11:53:51 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: dns server discovery using mdns To: namedroppers@psg.com Cc: erik.guttman@sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk mdns-00> Discovery of the services in general as well as discovery mdns-00> of the DNS servers in particular using multicast DNS is mdns-00> left outside of the scope of this document. Why shouldn't the mdns resolver first send a request of type NS or SOA for a particular domain? This was suggested by Manning & Woodcock and seems right to me. This allows a DNS resolver to bootstrap in the absence of DHCP. This is even explicitely allowed in RFC 1123, section 6.1.3.2, page 76: A server MAY support a UDP query that is delivered using an IP broadcast or multicast address. However, the Recursion Desired bit MUST NOT be set in a query that is multicast, and MUST be ignored by name servers receiving queries via a broadcast or multicast address. A host that sends broadcast or multicast DNS queries SHOULD send them only as occasional probes, caching the IP address(es) it obtains from the response(s) so it can normally send unicast queries. DISCUSSION: Broadcast or (especially) IP multicast can provide a way to locate nearby name servers without knowing their IP addresses in advance. However, general broadcasting of recursive queries can result in excessive and unnecessary load on both network and servers. Since we are presently only discussing the use of link-local multicast, the concern over excessive load on network and servers is unnecessary. If multicast is used to discover DNS servers *which are present,* this will lighten the load on servers subsequently, as resolvers will then begin to unicast their requests. ' The load on the network will be analogous (whether unicast or multicast is used) since both unicast and multicast requests have to traverse the same link. Multicast requests could be slightly more expensive since requests which fail to receive a response will be retransmitted (a limited number of times). Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 25 14:58:44 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27028 for ; Wed, 25 Apr 2001 14:58:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14sToA-00079m-00 for namedroppers-data@psg.com; Wed, 25 Apr 2001 11:14:34 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14sToA-00079g-00 for namedroppers@ops.ietf.org; Wed, 25 Apr 2001 11:14:34 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14sToA-00069G-00 for namedroppers@ops.ietf.org; Wed, 25 Apr 2001 11:14:34 -0700 Date: Wed, 25 Apr 2001 11:02:19 -0700 (PDT) From: Bernard Aboba To: Erik Guttman cc: namedroppers@psg.com Subject: Re: dns server discovery using mdns In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > Why shouldn't the mdns resolver first send a request of type NS or > SOA for a particular domain? This was suggested by Manning & Woodcock > and seems right to me. This allows a DNS resolver to bootstrap in > the absence of DHCP. Well, given that mDNS is linklocal only, at best you'd only be able to find a DNS server on a local link. I would think that a useful DNS discovery mechanism would need to be able to find DNS servers anywhere in the administrative domain. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 25 16:12:45 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29703 for ; Wed, 25 Apr 2001 16:12:44 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14sVJ3-0008we-00 for namedroppers-data@psg.com; Wed, 25 Apr 2001 12:50:33 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14sVJ2-0008wY-00 for namedroppers@ops.ietf.org; Wed, 25 Apr 2001 12:50:32 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14sVJ2-0008ow-00 for namedroppers@ops.ietf.org; Wed, 25 Apr 2001 12:50:32 -0700 Date: Wed, 25 Apr 2001 21:50:24 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: dns server discovery using mdns To: Bernard Aboba Cc: Erik Guttman , namedroppers@psg.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Why shouldn't the mdns resolver first send a request of type NS or > > SOA for a particular domain? This was suggested by Manning & Woodcock > > and seems right to me. This allows a DNS resolver to bootstrap in > > the absence of DHCP. > > Well, given that mDNS is linklocal only, at best you'd only be able to > find a DNS server on a local link. I would think that a useful DNS > discovery mechanism would need to be able to find DNS servers anywhere in > the administrative domain. Any way a host can discover a DNS server is better than none. A static configuration file is one way, DHCP is another. Why not allow hosts to discover DNS servers on their local link, too? mDNS as it is defined today is link-local only. This doesn't mean that in the future we won't define mDNS to use admin-local scope. This could occur, say, when admin-local scope has been deployed to contain multicast reasonably in enterprise networks and we have some (cheery) experience with mdns deployment. What I am reacting to is the text in the mdns-00 draft which explicitely excludes DNS server discovery - which seems to me (and to RFC 1123) to be multicast DNS's primary function. At any rate, as I argued elsewhere, it wouldn't hurt to attempt to find a DNS server on the local link before attempting to do mdns based resolution. (This additional discovery step would not lead to excessive bandwidth consumption). Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Wed Apr 25 17:30:45 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01779 for ; Wed, 25 Apr 2001 17:30:45 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14sWXz-000AcL-00 for namedroppers-data@psg.com; Wed, 25 Apr 2001 14:10:03 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14sWXy-000AcD-00 for namedroppers@ops.ietf.org; Wed, 25 Apr 2001 14:10:02 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14sWXy-000Avo-00 for namedroppers@ops.ietf.org; Wed, 25 Apr 2001 14:10:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Erik Guttman Cc: namedroppers@psg.com Subject: Re: dns server discovery using mdns References: Message-Id: Date: Wed, 25 Apr 2001 14:05:14 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Any way a host can discover a DNS server is better than none. possibly, though i can postulate many that might not be. but nine ways is not better than one. and don't we already have dhcp? randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 26 08:28:19 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00662 for ; Thu, 26 Apr 2001 08:28:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14skU8-000Prw-00 for namedroppers-data@psg.com; Thu, 26 Apr 2001 05:03:00 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14skU7-000Prp-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 05:02:59 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14skU7-0009SS-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 05:02:59 -0700 Date: Thu, 26 Apr 2001 09:32:48 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: dns server discovery using mdns To: Randy Bush Cc: Erik Guttman , namedroppers@psg.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Any way a host can discover a DNS server is better than none. > > possibly, though i can postulate many that might not be. > > but nine ways is not better than one. and don't we already have dhcp? Randy, In the case where are no DNS servers and we can benefit from mdns resolution. But what if this is transient? We should really be able to use a DNS server if one becomes available. Do we really want to assume/require that a (correctly configured) DHCP server will be available whenever DNS is? Resist the urge to count '0,1,infinity.' We have DHCP and resolv.conf. But we also have DNS resolution, too (mDNS being only a slight modification to the DNS client). Why not allow *2* dynamic mechanisms for finding the DNS server? Unlike DHCP, this mDNS mechanism is decentralized and requires no administration. Available DNS servers simply respond. SLP faces a similar problem: One can configure services via DHCP or by requesting DNS SRV RRs - but these are not dynamic services, that is, they may be inconsistent with the actual state of the network. SLP allows multicast based service discovery. This does not scale up very well - so we have 'directory agents' (DAs). (a) DAs are discovered via SLP (b) services are registered (soft state) with DAs (c) service discovery requests are unicasted to DAs This allows SLP to scale up. Why can't DNS operate in the same manner? (a) DNS servers are discovered mDNS (b) names are registered with DNS servers via dynamic update (c) name resolution requests are unicasted to DNS servers I do not believe we have all the pieces together to do this yet. I submit it is the right solution in the long run. I am concerned we are precluding this from happening by excluding DNS server discovery from mDNS. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 26 08:48:00 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01598 for ; Thu, 26 Apr 2001 08:47:59 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14sksl-0000OS-00 for namedroppers-data@psg.com; Thu, 26 Apr 2001 05:28:27 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14sksl-0000OM-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 05:28:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14sksl-000A58-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 05:28:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Erik Guttman Cc: namedroppers@psg.com Subject: Re: dns server discovery using mdns References: Message-Id: Date: Thu, 26 Apr 2001 05:02:54 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Do we really want to assume/require that a (correctly > configured) DHCP server will be available whenever DNS is? i suspect that's not the exactly right question. can we expect a dhcp server will be available wherever a client wakes up and wants to find a dns server? as i suspect that my wristwatch has a dhcp server these days, i think so. > Resist the urge to count '0,1,infinity.' We have DHCP and > resolv.conf. But we also have DNS resolution, too (mDNS > being only a slight modification to the DNS client). Why > not allow *2* dynamic mechanisms for finding the DNS server? because we will soon be asked to support both everywhere. because we already have one that works. all those types of arguments. > Unlike DHCP, this mDNS mechanism is decentralized and requires > no administration. Available DNS servers simply respond. it's cute. it's tempting. but ... if the lan is multicast enabled, and the overwhelming success of global multicast has not driven this well. i don't want to explain to a site admin, who is clue-light enough to have an crippled switch among the 42 on her lan, why roamers in the boardroom are unable to find a dns server. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 26 09:19:28 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02622 for ; Thu, 26 Apr 2001 09:19:27 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14slQQ-00015j-00 for namedroppers-data@psg.com; Thu, 26 Apr 2001 06:03:14 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14slQP-00015c-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 06:03:13 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14slQP-000Azm-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 06:03:13 -0700 Date: Thu, 26 Apr 2001 15:00:49 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: dns server discovery using mdns To: Randy Bush Cc: Erik Guttman , namedroppers@psg.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > > Do we really want to assume/require that a (correctly > > configured) DHCP server will be available whenever DNS is? > > i suspect that's not the exactly right question. can we expect a dhcp > server will be available wherever a client wakes up and wants to find > a dns server? as i suspect that my wristwatch has a dhcp server these > days, i think so. Are we really willing to accept this 'fate sharing'? > > Unlike DHCP, this mDNS mechanism is decentralized and requires > > no administration. Available DNS servers simply respond. > > it's cute. it's tempting. but ... > > if the lan is multicast enabled, and the overwhelming success of > global multicast has not driven this well. i don't want to explain > to a site admin, who is clue-light enough to have an crippled switch > among the 42 on her lan, why roamers in the boardroom are unable to > find a dns server. Naive question: Would this crippled switch fail to transmit a datagram with a multicast destination address but succeed in transmitting one with a broadcast destination address? If broadcast doesn't work, then DHCP won't either & those in the boardroom are out of luck. Erik to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 26 09:45:49 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03567 for ; Thu, 26 Apr 2001 09:45:49 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14slr2-0001fT-00 for namedroppers-data@psg.com; Thu, 26 Apr 2001 06:30:44 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14slr1-0001fN-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 06:30:43 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14slr1-000Bj0-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 06:30:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Erik Guttman Cc: namedroppers@psg.com Subject: Re: dns server discovery using mdns References: Message-Id: Date: Thu, 26 Apr 2001 06:09:00 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>> Do we really want to assume/require that a (correctly >>> configured) DHCP server will be available whenever DNS is? >> i suspect that's not the exactly right question. can we expect a dhcp >> server will be available wherever a client wakes up and wants to find >> a dns server? as i suspect that my wristwatch has a dhcp server these >> days, i think so. > Are we really willing to accept this 'fate sharing'? are we willing to accept that both routers and circuits are working at the same time? > Naive question: Would this crippled switch fail to transmit a > datagram with a multicast destination address but succeed in > transmitting one with a broadcast destination address? a prudent site admin checks for igmp capability. and prudent site admins seem as common as helpful it departments. randy to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 26 11:25:39 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08133 for ; Thu, 26 Apr 2001 11:25:38 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14snNq-0003pF-00 for namedroppers-data@psg.com; Thu, 26 Apr 2001 08:08:42 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14snNp-0003p8-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 08:08:41 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14snNp-000EP2-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 08:08:41 -0700 Date: Thu, 26 Apr 2001 07:47:57 -0700 (PDT) From: Bernard Aboba To: Erik Guttman cc: Randy Bush , namedroppers@psg.com Subject: Re: dns server discovery using mdns In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-namedroppers@ops.ietf.org Precedence: bulk > In the case where are no DNS servers and we can benefit from > mdns resolution. But what if this is transient? We should > really be able to use a DNS server if one becomes available. > Do we really want to assume/require that a (correctly > configured) DHCP server will be available whenever DNS is? It's not necessarily a bad assumption because almost all home gateway routers now include both a DHCP server and a DNS proxy. This is one of the basic assumptions of the mDNS draft. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 26 11:54:29 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09349 for ; Thu, 26 Apr 2001 11:54:28 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14snix-0004Ms-00 for namedroppers-data@psg.com; Thu, 26 Apr 2001 08:30:31 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14snix-0004Mm-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 08:30:31 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14snix-000F0G-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 08:30:31 -0700 Message-ID: <3AE83DD1.F9449E5@ehsco.com> Date: Thu, 26 Apr 2001 08:25:05 -0700 From: "Eric A. Hall" Organization: EHS Company X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Guttman CC: Randy Bush , namedroppers@psg.com Subject: Re: dns server discovery using mdns References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Unlike DHCP, this mDNS mechanism is decentralized and requires > no administration. Available DNS servers simply respond. I should read drafts before commenting, but... Clients have specific needs, such as finding a server that performs recursion, and discovering the search base domain name which should be applied to unqualified lookups. These require specific operational mechanisms within the protocol, such as providing a weighted set of responses from the eligible servers, and then having the client choose from those accordingly. These aren't difficult, but they need to be defined. I certainly agree that mDNS for clients is very useful for a variety of situations and it should absolutely be done (routers/switches that need DNS for various functions but which cannot use DHCP, is one obvious example). I also think there are a bunch of issues that have to be taken into consideration, and that it is probably a standalone effort. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 26 15:22:43 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16842 for ; Thu, 26 Apr 2001 15:22:42 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14sqq8-0008LE-00 for namedroppers-data@psg.com; Thu, 26 Apr 2001 11:50:08 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14sqq8-0008L8-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 11:50:08 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14sqq8-000KQj-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 11:50:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104261739.KAA09110@redpaul.mfnx.net> To: namedroppers@psg.com Subject: Re: dns server discovery using mdns In-Reply-To: Message from Erik Guttman of "Thu, 26 Apr 2001 09:32:48 +0200." Date: Thu, 26 Apr 2001 10:39:57 -0700 From: Paul A Vixie X-DCC-MAPS-Metrics: ernie.mail-abuse.org 667; IP=2973 env_From=3209 From=4890 Subject=61 Message-ID=1 Received=1 Body=1 Fuz1=1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Woody's example of why mDNS was needed was if two PDA's want to beam stuff to each other but use IP-over-IRDA rather than something proprietary. There is a need for stateless peer-to-peer autoconfiguration with no DHCP servers, no DNS servers, no default gateway. mDNS is part of that. Saying "why don't we just use DHCP" entirely misses the thrust of the argument. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Thu Apr 26 16:45:08 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20642 for ; Thu, 26 Apr 2001 16:45:07 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14ssCd-000A47-00 for namedroppers-data@psg.com; Thu, 26 Apr 2001 13:17:27 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14ssCd-000A41-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 13:17:27 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14ssCc-000MkF-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 13:17:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Paul A Vixie Cc: namedroppers@psg.com Subject: Re: dns server discovery using mdns References: <200104261739.KAA09110@redpaul.mfnx.net> Message-Id: Date: Thu, 26 Apr 2001 13:15:47 -0700 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Woody's example of why mDNS was needed was if two PDA's want to beam stuff > to each other but use IP-over-IRDA rather than something proprietary. > There is a need for stateless peer-to-peer autoconfiguration with no DHCP > servers, no DNS servers, no default gateway. mDNS is part of that. > Saying "why don't we just use DHCP" entirely misses the thrust of the > argument. what is being questioned is the belief that there are significant [0] scenarios where actual dns resolution is needed and yet it is not reasonable to expect dhcp service. i.e. why would two isolated pdas wanting to beam stuff to eachother, regardless of transport mechanism, need to resolve lcs.mit.edu? as they beam stuff now, what about a change at the transport level causes dns requirements? and, before someone tries to construct the situation why it is needed, maybe for the sake of simplicty in life, they should try and construct the situation where it is not. randy --- [0] - where 'significant' means, among other things, worth the cruft of yet another solution to the same problems. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Fri Apr 27 00:49:18 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02271 for ; Fri, 27 Apr 2001 00:49:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14szjH-000MlR-00 for namedroppers-data@psg.com; Thu, 26 Apr 2001 21:19:39 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14szjH-000MlL-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 21:19:39 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14szjH-0009UN-00 for namedroppers@ops.ietf.org; Thu, 26 Apr 2001 21:19:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@psg.com Subject: AAAA/A6 thing From: itojun@iijlab.net Date: Fri, 27 Apr 2001 13:12:24 +0900 Message-ID: <7130.988344744@itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit it seems that there's no activity regarding to AAAA/A6 thing. since it was mentioned that "if there's no strong case for A6, AAAA wins" during IETF50 meeting, i guess "no activity" means "AAAA wins" :-) seriously, if it seems to be a good starting point, I can compile my question I've sent to the list, and the arguments I've seen, into a draft. note that the draft does not seem to make "a case for doing A6" - rather, the draft will mainly list problems in A6, and will compile existing arguments/observations. if i were to work on it, i plan to make it ready before ipngwg interim meeting. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 28 02:53:04 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11128 for ; Sat, 28 Apr 2001 02:53:04 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14tNUo-000Azx-00 for namedroppers-data@psg.com; Fri, 27 Apr 2001 22:42:18 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14tNUm-000Azb-00 for namedroppers@ops.ietf.org; Fri, 27 Apr 2001 22:42:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14tNNf-0003yg-00 for namedroppers@ops.ietf.org; Fri, 27 Apr 2001 22:34:55 -0700 From: Robert Elz To: itojun@iijlab.net cc: namedroppers@psg.com Subject: Re: AAAA/A6 thing In-reply-to: Your message of "Fri, 27 Apr 2001 13:12:24 +0900." <7130.988344744@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Apr 2001 22:54:05 +0700 Message-ID: <2087.988386845@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Fri, 27 Apr 2001 13:12:24 +0900 From: itojun@iijlab.net Message-ID: <7130.988344744@itojun.org> | it seems that there's no activity regarding to AAAA/A6 thing. I plan on doing some actual A6 testing, sometime in the near(ish) future. Until someone does, there's no data upon which to base a decision, other than guesswork. A draft listing the imagined possible problems with A6 can't hurt, but by itself nor will it achieve a lot. kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 28 02:53:05 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11127 for ; Sat, 28 Apr 2001 02:53:03 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14tNUp-000B01-00 for namedroppers-data@psg.com; Fri, 27 Apr 2001 22:42:19 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14tNUm-000Azh-00 for namedroppers@ops.ietf.org; Fri, 27 Apr 2001 22:42:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14tNNr-0003yy-00 for namedroppers@ops.ietf.org; Fri, 27 Apr 2001 22:35:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: namedroppers@psg.com In-reply-to: kre's message of Fri, 27 Apr 2001 22:54:05 +0700. <2087.988386845@brandenburg.cs.mu.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: AAAA/A6 thing From: itojun@iijlab.net Date: Sat, 28 Apr 2001 01:03:52 +0900 Message-ID: <14687.988387432@itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > | it seems that there's no activity regarding to AAAA/A6 thing. >I plan on doing some actual A6 testing, sometime in the near(ish) >future. just a datapoint - kame.net has been having A6 records for a while. and we have been testing resolvers and nameservers with these records for a while. i'm not sure what is the best quantitative way to understand the problems though (# of queries, delays, complexity in resolver code?). >Until someone does, there's no data upon which to base a decision, >other than guesswork. yup. most of the past discussions were guessings and future tellings, basically ("in the future we would need to renumber every day..."). we must admit that we cannot really test everything, though. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 28 02:53:11 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11148 for ; Sat, 28 Apr 2001 02:53:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14tNUn-000Azt-00 for namedroppers-data@psg.com; Fri, 27 Apr 2001 22:42:17 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14tNUm-000AzV-00 for namedroppers@ops.ietf.org; Fri, 27 Apr 2001 22:42:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14tNNa-0003yV-00 for namedroppers@ops.ietf.org; Fri, 27 Apr 2001 22:34:50 -0700 From: Robert Elz To: itojun@iijlab.net cc: namedroppers@psg.com Subject: Re: AAAA/A6 thing In-reply-to: Your message of "Sat, 28 Apr 2001 01:03:52 +0900." <14687.988387432@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Apr 2001 01:05:01 +0700 Message-ID: <2604.988394701@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Date: Sat, 28 Apr 2001 01:03:52 +0900 From: itojun@iijlab.net Message-ID: <14687.988387432@itojun.org> | just a datapoint - kame.net has been having A6 records for a while. Yes, there are a few A6 RR's out in the wild - but aside from demonstrating that the world hasn't ended because of that, those don't prove much, either way. | and we have been testing resolvers and nameservers with these | records for a while. But that is more interesting, if you have some results from that to put in the draft, then it will be much more interesting. | i'm not sure what is the best quantitative way | to understand the problems though (# of queries, delays, complexity in | resolver code?). I suspect that there is no best way. What we need (I think) is for several people to have tried using the things (really using them, including attempting some of the wilder configurations possible), and then for their experiences to be made known to the group(s) as a whole (A6 is really an ipngwg work item, not dnsext though - but it is certainly good for both groups to be involved). With that data, the group(s) might be able to get a better feel for whether the costs (of which there will certainly be some) of using them outweigh the undisputed extra flexibility that they provide. And whether that flexibility is useful or not. | yup. most of the past discussions were guessings and future tellings, | basically ("in the future we would need to renumber every day..."). | we must admit that we cannot really test everything, though. No, we cannot test everything, other than letting it out in the wild, and then observing the effects. But we can see if we can gather some evidence on whether this is too dangerous to release or not, rather than just relying upon first impressions. (Eg: in Aus we have some wicked looking goannas and snakes, and stuff, which are really pretty harmless to anyone. On the other hand, catch one of those cuddly looking koalas at a bad time, and you're in for a nasty shock.) kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 28 02:53:24 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11159 for ; Sat, 28 Apr 2001 02:53:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14tNUn-000Azs-00 for namedroppers-data@psg.com; Fri, 27 Apr 2001 22:42:17 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14tNUm-000AzQ-00 for namedroppers@ops.ietf.org; Fri, 27 Apr 2001 22:42:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14tNNS-0003yE-00 for namedroppers@ops.ietf.org; Fri, 27 Apr 2001 22:34:42 -0700 Message-Id: <200104271043.GAA20915@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-roadmap-03.txt Date: Fri, 27 Apr 2001 06:43:54 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNS Security Document Roadmap Author(s) : S. Rose Filename : draft-ietf-dnsext-dnssec-roadmap-03.txt Pages : 12 Date : 26-Apr-01 DNS Security (DNSSEC)technology is composed of extensions to the Domain Name System (DNS) protocol that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Several documents exist to describe these extensions and the implementation-specific details regarding specific digital signing schemes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-roadmap-03.txt 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-dnsext-dnssec-roadmap-03.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-dnsext-dnssec-roadmap-03.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: <20010426132224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-roadmap-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-roadmap-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010426132224.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 28 02:54:19 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11191 for ; Sat, 28 Apr 2001 02:54:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14tNUo-000Azv-00 for namedroppers-data@psg.com; Fri, 27 Apr 2001 22:42:18 -0700 Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.16 #1) id 14tNUm-000AzO-00 for namedroppers@ops.ietf.org; Fri, 27 Apr 2001 22:42:16 -0700 Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14tNNO-0003y8-00 for namedroppers@ops.ietf.org; Fri, 27 Apr 2001 22:34:38 -0700 Message-Id: <200104271044.GAA20932@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-dnssec-okbit-02.txt Date: Fri, 27 Apr 2001 06:43:59 -0400 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Indicating Resolver Support of DNSSEC Author(s) : D. Conrad Filename : draft-ietf-dnsext-dnssec-okbit-02.txt Pages : 5 Date : 26-Apr-01 In order to deploy DNSSEC operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and the necessary protocol changes to implement that notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-okbit-02.txt 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-dnsext-dnssec-okbit-02.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-dnsext-dnssec-okbit-02.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: <20010426132255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-dnssec-okbit-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-dnssec-okbit-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010426132255.I-D@ietf.org> --OtherAccess-- --NextPart-- to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sat Apr 28 17:05:58 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17046 for ; Sat, 28 Apr 2001 17:05:57 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14tbTw-0009ht-00 for namedroppers-data@psg.com; Sat, 28 Apr 2001 13:38:20 -0700 Received: from [63.112.78.94] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14tbTt-0009hd-00 for namedroppers@ops.ietf.org; Sat, 28 Apr 2001 13:38:18 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14tbTo-0000Fn-00 for namedroppers@ops.ietf.org; Sat, 28 Apr 2001 13:38:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <2604.988394701@brandenburg.cs.mu.OZ.AU> From: Paul Vixie Date: 28 Apr 2001 10:57:35 -0700 In-Reply-To: Robert Elz's message of "27 Apr 2001 23:42:07 -0700" Message-ID: Lines: 41 X-Mailer: Gnus v5.7/Emacs 20.4 X-DCC-MAPS-Metrics: ernie.mail-abuse.org 667; IP=778 env_From=845 From=102 Subject=20 Message-ID=1 Received=1 Body=1 Fuz1=1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Yes, there are a few A6 RR's out in the wild - but aside from demonstrating > that the world hasn't ended because of that, those don't prove much, > either way. Nor will proof of that kind be available without a lot more operational deployment. It sounds like you're not planning to wait for proof of that kind, but rather, get in a room with some like minded others and simply decide whether A6 is worth deploying or whether it really does suffer from all the woes which have been attributed to it and if so whether they add up to something fatal or not. Which means IPv6's "quick renumbering" requirement is back on the table. And since quick renumbering was used to sell the fast path IPv6 is on, I assume that we can now listen to Tony Li's "too little, too soon" complaint and just pull back from IPv6-as-specified and try to come up with something that's going to solve more of the problems we DO and WILL have, and fewer of the problems we MIGHT or COULD have? No? You mean that stuff isn't back on the table, and we're going ahead with IPv6 regardless of whether or not it has quick renumbering capabilities? If so, I will accuse the various directorates of "bait and switch" tactics used to ram their limited vision through various debates with no actual intent to follow through on any of their "campaign promises." Which would make this whole thing a lot like the RSA/DSA problem DNSSEC has. Are we still considering rearranging the IPv6 packet format to put destination address first? After all if the whole thing's still so experimental that we don't know what features it has or how we will deliver them, let's see the WHOLE laundry list. (I don't think IPv6 could stand that kind of scrutiny, but then, neither could IPv4 if it were proposed today.) Hint to whoever is in charge: the time to debate A6's merits at this level was: before it got put on the standards track, before a lot of code got written, and before a lot of operational deployment was put into various long and expensive pipelines. -- Paul Vixie President, PAIX.Net Inc. (MFNX.O) to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Apr 29 13:38:19 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10602 for ; Sun, 29 Apr 2001 13:38:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14tunS-000Jis-00 for namedroppers-data@psg.com; Sun, 29 Apr 2001 10:15:46 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14tunR-000JiQ-00 for namedroppers@ops.ietf.org; Sun, 29 Apr 2001 10:15:45 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14tuie-0000J4-00 for namedroppers@ops.ietf.org; Sun, 29 Apr 2001 19:10:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Robert Elz To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-reply-to: Your message of "28 Apr 2001 10:57:35 MST." Date: Sun, 29 Apr 2001 17:58:19 +0700 Message-ID: <2128.988541899@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Date: 28 Apr 2001 10:57:35 -0700 From: Paul Vixie Message-ID: | Nor will proof of that kind be available without a lot more operational | deployment. Yes, that was my point. | It sounds like you're not planning to wait for proof of that kind, I don't know how I sounded like that, as that's the exact opposite of what I am proposing. What I'm proposing is to do some real testing of A6, and gather the evidence. I would hope that many others would as well. | Hint to whoever is in charge: the time to debate A6's merits at this level | was: before it got put on the standards track, No, that's not right. The whole point of standards at PS, and then implementations, and then implementation reports before DS, is to see whether the standard proposed can actually be implemented properly, and then between DS and full std there's supposed to be widespread deployment, so see if the thing actually works, and is accepted, in the field. At either of those stages the entire thing (any proposal) can be found wanting and killed. Now I'm in general a believer of A6, I suspect that as defined, it will work in practice. But I don't yet know that, which is why I'm planning on doing some real testing (though I doubt I will have much in the way of meaningful results before the ipngwg interim meeting, which I won't be at anyway - I should have before the next IETF though, which I hope I will manage to get to). kre to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Apr 29 13:38:22 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10621 for ; Sun, 29 Apr 2001 13:38:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14tunD-000Jh2-00 for namedroppers-data@psg.com; Sun, 29 Apr 2001 10:15:31 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14tun7-000Jf8-00 for namedroppers@ops.ietf.org; Sun, 29 Apr 2001 10:15:26 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14tuNH-0000GJ-00 for namedroppers@ops.ietf.org; Sun, 29 Apr 2001 18:48:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104282100.RAA13625@egyptian-gods.MIT.EDU> To: Paul Vixie cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: Your message of "28 Apr 2001 10:57:35 PDT." Date: Sat, 28 Apr 2001 17:00:40 -0400 From: Greg Hudson Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I understand Paul's frustration that this issue is being debated at such a late date and after other decisions have been made on top of it. But since I'm not in charge, and I have a question, I'll ask it. > Which means IPv6's "quick renumbering" requirement is back on the > table. Does DNS "quick renumbering" have to be done in a way visible to DNS clients? Which is to say: if what we need is a way to change a whole bunch of host -> address mappings in a single operation, is there a compelling reason to make that mechanism visible to the client, instead of just handling it in server implementations? One reason for doing it the A6 way is that it allows a prefix to be renumbered when the hostnames using that prefix live in different zones, without creating new communication channels between servers. Another reason to do it the A6 way probably has to do with TTLs. Are either of these reasons compelling? Are there other reasons? (I also have a comment which goes beyond the question I'm asking:) If I'm not mistaken, IPV6 has already given up on the kind of "quick renumbering" which wouldn't cause a catastrophic loss of everyone's open TCP connections; my particular organization would probably be taken out back and shot if we subjected users to that every day or every few weeks. How much pain is it worth to enable a DNS renumbering mechanism which sucks too much to use? to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Apr 29 13:38:23 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10622 for ; Sun, 29 Apr 2001 13:38:22 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14tunB-000Jg3-00 for namedroppers-data@psg.com; Sun, 29 Apr 2001 10:15:29 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14tun7-000Jf9-00 for namedroppers@ops.ietf.org; Sun, 29 Apr 2001 10:15:26 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14tuc2-0000Hp-00 for namedroppers@ops.ietf.org; Sun, 29 Apr 2001 19:03:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 29 Apr 2001 05:37:52 -0000 Message-ID: <20010429053752.15731.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing References: <2604.988394701@brandenburg.cs.mu.OZ.AU> <14687.988387432@itojun.org> <2604.988394701@brandenburg.cs.mu.OZ.AU> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm cc'ing this to IPNG. It's up to IPNG to deprecate A6. Furthermore, standardization activities should not be carried out on namedroppers, for reasons discussed in http://cr.yp.to/djbdns/namedroppers.html. Robert Elz writes: > undisputed extra flexibility We all agree that A6 is an extension to the DNS protocol. This does not mean that it adds flexibility to DNS. Server-side indirection provides the same functions with no protocol changes. Paul Vixie writes: > Hint to whoever is in charge: the time to debate A6's merits at this level > was: before it got put on the standards track, That would have been a good time, but now is a good time too. There is no guarantee that a protocol put on the standards track will move along that track, or that it will stay on the track. In fact, under IETF rules, protocols that want to advance are subject to more scrutiny, not less. The proponents of A6-everywhere think that they have the right to deprecate AAAA. So why don't the proponents of AAAA-everywhere have the right to deprecate A6? > before a lot of code got written, and before a lot of operational > deployment was put into various long and expensive pipelines. So, because you and Microsoft have wasted time on a bad extension, every other DNS implementor is required to waste time too? Including all future DNS implementors? ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Apr 29 13:38:43 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10642 for ; Sun, 29 Apr 2001 13:38:43 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14tunE-000JhP-00 for namedroppers-data@psg.com; Sun, 29 Apr 2001 10:15:32 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14tunD-000Jg8-00 for namedroppers@ops.ietf.org; Sun, 29 Apr 2001 10:15:32 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14tuaK-0000HT-00 for namedroppers@ops.ietf.org; Sun, 29 Apr 2001 19:02:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul Vixie Cc: namedroppers@ops.ietf.org In-reply-to: vixie's message of 28 Apr 2001 10:57:35 MST. Subject: Re: AAAA/A6 thing From: itojun@iijlab.net Date: Sun, 29 Apr 2001 13:15:01 +0900 Message-ID: <2406.988517701@itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Hint to whoever is in charge: the time to debate A6's merits at this level >was: before it got put on the standards track, before a lot of code got >written, and before a lot of operational deployment was put into various >long and expensive pipelines. for the last portion ("lot of operational deployment...") is yet to be done for A6, and i believe it very important to re-evaluate merits and demerits of AAAA/A6 before we really try to deply A6. i would like to thank for every efforts put for A6 codebase (BIND9), however, i see a lot of issues in deploying A6, and i personally have problem seeing merits of A6. we ran some experiments for renumbering, and the result made me believe that there's no such thing as "rapid renumbering". network renubmer is a very very difficult thing. there are a lot of other protocols which (1) tries to upgrade other existing protocol and (2) has trouble in deployment because of some issues (like the previous protocol was too popular, previous protocol was enough, previous protocol was more suitable for the real world goals). i won't give examples here, but i guess you can name a lot of examples. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Sun Apr 29 13:38:56 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10603 for ; Sun, 29 Apr 2001 13:38:18 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14tunB-000JgD-00 for namedroppers-data@psg.com; Sun, 29 Apr 2001 10:15:29 -0700 Received: from [147.28.4.2] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14tun7-000JfA-00 for namedroppers@ops.ietf.org; Sun, 29 Apr 2001 10:15:27 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14tube-0000Hi-00 for namedroppers@ops.ietf.org; Sun, 29 Apr 2001 19:03:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104290514.WAA55084@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: Message from itojun@iijlab.net of "Sun, 29 Apr 2001 13:15:01 +0900." <2406.988517701@itojun.org> Date: Sat, 28 Apr 2001 22:14:16 -0700 From: Paul A Vixie Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > >... before a lot of operational deployment was put into various > >long and expensive pipelines. > > for the last portion ("lot of operational deployment...") is yet to > be done for A6, i agree. it's not "done". it is however, by this time, "in various long and expensive pipelines." the commitment to A6 has been made in a number of places. this commitment would have been withheld in at least several places i know of, had A6's optionality been publically known a year ago. that makes the declaration of its optionality "feel like" a bait & switch. operational deployment isn't done in a day. there's a multi-year planning cycle for something like IPv6. and it's becoming apparent to me that some folks inside IETF whose success with IPv6 depends on the good will, trust and confidence of these planners, are just not aware of that dependence at all. again, i refer you all to the DSA-RSA-DSA-RSA "standards" in DNSSEC. > and i believe it very important to re-evaluate > merits and demerits of AAAA/A6 before we really try to deply A6. > i would like to thank for every efforts put for A6 codebase (BIND9), > however, i see a lot of issues in deploying A6, and i personally have > problem seeing merits of A6. sra, sob and i debated the merits of the A6-like approach in toronto, some years ago. ultimately we decided not to propose it because of its drawbacks. matt crawford eventually came forward with a similar proposal, and its drawbacks were pointed out and debated extensively. the community decided to go forward with it. anyone who didn't like the way the debate ended is welcome to add something new to it and try to get a different result. i have not, yet, heard anything new against A6 in this round of the debate. > we ran some experiments for renumbering, and the result made me > believe that there's no such thing as "rapid renumbering". network > renubmer is a very very difficult thing. sure it's difficult. nobody who eventually hummed in the affirmative about A6 thought it was a magic bullet. bill manning wrote some very good text some years ago about the difficulties of rapid renumbering, all still valid. but the thing that propped up the rapid adoption of IPv6 -- in spite of the fact that it solves absolutely none of the known problems in the routing system -- was rapid renumbering. A6 was then set forth as the means by which this would be achieved, and moreover, the means by which the routing system's pain would be eased since multihoming would be a first order effect and it would cease to matter who owned the address space you used day-to-day. if we're going to abandon A6 then i for one am ready to listen to tony li's "too little, too soon" comment, through IPv6 itself into the waste bin, and go back to the whiteboard and solve more of the problems we actually have. there is NO justification for the rapid and early adoption of IPv6 in its present form unless A6 or something very much like A6 is made a part of it. that your experiments showed that rapid renumbering isn't ready for prime time does not surprise me even a little bit. this stuff is all very raw. but if the technical community plans to tell the business community and the world at large that we want them to upgrade every router and every IP stack in the universe and _still_have_ address ownership concerns whereby providers can hold their customers hostage due to renumbering penalties, then we ought to declare failure, pack up and go home, and hope the next generation can do better. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 30 00:19:48 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16945 for ; Mon, 30 Apr 2001 00:19:48 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14u4of-000EHr-00 for namedroppers-data@psg.com; Sun, 29 Apr 2001 20:57:41 -0700 Received: from [206.163.43.51] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14u4od-000EHG-00 for namedroppers@ops.ietf.org; Sun, 29 Apr 2001 20:57:40 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14u3nO-0000eD-00 for namedroppers@ops.ietf.org; Mon, 30 Apr 2001 04:52:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: Message from itojun@iijlab.net dated "Fri, 27 Apr 2001 13:12:24 +0900" <7130.988344744@itojun.org> References: <7130.988344744@itojun.org> Date: Sun, 29 Apr 2001 14:23:22 -0400 From: Rob Austein Message-Id: <20010429182332Z23448-220+833@thrintun.hactrn.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Itojun, Feel free to write the draft you mentioned. I'd ask, though, that if you do so, you please also consider how many of the perceived problems with A6 become non-issues if we restrict use of A6 to the zero-prefix case until and unless there is a demonstrable need to use non-zero prefixes. As you know, my concern with the "let's just retreat to AAAA" proposal all along has been worry about deployment time if we discover down the road that we do need the extra features of A6. Sorry if you were expecting to hear more about the "case for A6" draft by now. I never expected to have anything done on it this early (known day-job schedule issues in April and early May), but I failed to communicate that to you when we discussed this in Minneapolis. --Rob to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 30 00:19:55 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16956 for ; Mon, 30 Apr 2001 00:19:55 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14u4oQ-000EGd-00 for namedroppers-data@psg.com; Sun, 29 Apr 2001 20:57:26 -0700 Received: from [206.163.43.51] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14u4o9-000EGQ-00 for namedroppers@ops.ietf.org; Sun, 29 Apr 2001 20:57:21 -0700 Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 14u4iW-0000ji-00 for namedroppers@ops.ietf.org; Mon, 30 Apr 2001 05:51:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Paul A Vixie Cc: ipng@sunroof.eng.sun.com Cc: namedroppers@ops.ietf.org In-reply-to: vixie's message of Sat, 28 Apr 2001 22:14:16 MST. <200104290514.WAA55084@redpaul.mfnx.net> Subject: Re: AAAA/A6 thing From: itojun@iijlab.net Date: Mon, 30 Apr 2001 11:05:14 +0900 Message-ID: <10857.988596314@itojun.org> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >but the thing that propped up the rapid adoption of IPv6 -- in spite of the >fact that it solves absolutely none of the known problems in the routing >system -- was rapid renumbering. A6 was then set forth as the means by >which this would be achieved, and moreover, the means by which the routing >system's pain would be eased since multihoming would be a first order effect >and it would cease to matter who owned the address space you used day-to-day. > >if we're going to abandon A6 then i for one am ready to listen to tony li's >"too little, too soon" comment, through IPv6 itself into the waste bin, and >go back to the whiteboard and solve more of the problems we actually have. >there is NO justification for the rapid and early adoption of IPv6 in its >present form unless A6 or something very much like A6 is made a part of it. sorry, i cannot follow your logic here. as far as i understand rapid renumbering was not the sole reason to pursue IPv6. for me, bigger address space is the most important concern. i have checked all IPng requirement documents (rfc17xx and 16xx) and i found no text that says "renumbering is the biggest concern". is there really a large consensus on this? on the contrary, there are wording for routing table size. as far as i understand IPv6 addressing plan as well as 6bone routing guideline solves this portion of the problem. itojun to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 30 03:31:18 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02299 for ; Mon, 30 Apr 2001 03:31:17 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14u7tI-000L2p-00 for namedroppers-data@psg.com; Mon, 30 Apr 2001 00:14:40 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14u7tH-000L2P-00 for namedroppers@ops.ietf.org; Mon, 30 Apr 2001 00:14:39 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14u7tG-0000r6-00 for namedroppers@ops.ietf.org; Mon, 30 Apr 2001 09:14:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 30 Apr 2001 06:07:10 -0000 Message-ID: <20010430060710.18274.qmail@cr.yp.to> From: "D. J. Bernstein" To: namedroppers@ops.ietf.org Cc: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing References: <2406.988517701@itojun.org> <200104290514.WAA55084@redpaul.mfnx.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul A Vixie writes: > i have not, yet, heard anything new against A6 in this round of the debate. http://cr.yp.to/djbdns/killa6.html In January, Elz claimed that these issues were already covered in the ``IPNG, and perhaps DNSIND'' archives. I commented that I didn't see server-side indirection discussed anywhere in the IPNG archives; I asked when the discussion happened, and what benefits were attributed to client-side indirection. Elz dodged both questions. Now we have Vixie trying to pull a similar stunt. Legitimate standards organizations never have any trouble showing people the justifications for their decisions. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 30 06:10:35 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03754 for ; Mon, 30 Apr 2001 06:10:35 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uAHV-000Pon-00 for namedroppers-data@psg.com; Mon, 30 Apr 2001 02:47:49 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uAHV-000Poh-00 for namedroppers@ops.ietf.org; Mon, 30 Apr 2001 02:47:49 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uAHT-00012a-00 for namedroppers@ops.ietf.org; Mon, 30 Apr 2001 11:47:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Masataka Ohta Message-Id: <200104300916.SAA06619@necom830.hpcl.titech.ac.jp> Subject: Re: AAAA/A6 thing In-Reply-To: <20010430060710.18274.qmail@cr.yp.to> from "D. J. Bernstein" at "Apr 30, 2001 06:07:10 am" To: "D. J. Bernstein" Date: Mon, 30 Apr 2001 18:16:21 +0859 () CC: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dan; It's your problem. > Paul A Vixie writes: > > i have not, yet, heard anything new against A6 in this round of the debate. > > http://cr.yp.to/djbdns/killa6.html How about: aol.com. NS ns0.aol.net. aol.com. NS ns1.aol.net. aol.net. NS ns0.aol.com. aol.net. NS ns1.aol.com. ? > Legitimate standards organizations never have any trouble showing people > the justifications for their decisions. As we already discussed with AXFR, you must put glue information in a separate cache local to a zone (or, better, a referral). RFC 1034 does not prohibit to do so. I thought you had already fixed your broken implementation. Masataka Ohta to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 30 06:55:34 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04210 for ; Mon, 30 Apr 2001 06:55:33 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uB9u-0001bq-00 for namedroppers-data@psg.com; Mon, 30 Apr 2001 03:44:02 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uB9t-0001bi-00 for namedroppers@ops.ietf.org; Mon, 30 Apr 2001 03:44:01 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uB9s-00015s-00 for namedroppers@ops.ietf.org; Mon, 30 Apr 2001 12:44:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Ian Jackson Message-ID: <15085.16615.417771.360536@davenant.relativity.greenend.org.uk> Date: Mon, 30 Apr 2001 11:39:35 +0100 (BST) To: Paul A Vixie Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing Newsgroups: chiark.mail.ietf.namedroppers In-Reply-To: <200104290514.WAA55084@redpaul.mfnx.net> References: <2406.988517701@itojun.org> <200104290514.WAA55084@redpaul.mfnx.net> Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ could we please restrict the namedroppers discussion to the dns aspects, and not the v6 wars? let's assume v6, whether we like it or not. if you do, use the ipngwg list. if not, use v6haters. thanks. -- rb ] Paul A Vixie writes ("Re: AAAA/A6 thing "): > sra, sob and i debated the merits of the A6-like approach in toronto, some > years ago. ultimately we decided not to propose it because of its drawbacks. > matt crawford eventually came forward with a similar proposal, and its > drawbacks were pointed out and debated extensively. > > the community decided to go forward with it. Can you please give us references into the relevant list archives ? > anyone who didn't like the way the debate ended is welcome to add something > new to it and try to get a different result. i have not, yet, heard anything > new against A6 in this round of the debate. Asking A6 opponents to `add something new to the debate' is not reasonable unless you can point us to where we can read what was said already. The namedroppers archives have practically nothing about RFC2874 that I could find. Surely the designs of A6, DNAME and bitstrings should have been done here ? > there is NO justification for the rapid and early adoption of IPv6 in its > present form unless A6 or something very much like A6 is made a part of it. I strongly disagree. IPv6 is needed because we are running out of IPv4 address space. NAT has prolonged its life, but comes with a whole pile of other problems - and it's nowadays mandatory to use NAT because it's so hard to get globally routeable address space for all hosts at a site. But, if we want to argue these issues, the ipng lists is probably the right place. Ian. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 30 13:00:33 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18914 for ; Mon, 30 Apr 2001 13:00:31 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uGgq-000DSc-00 for namedroppers-data@psg.com; Mon, 30 Apr 2001 09:38:24 -0700 Received: from [193.0.8.118] (helo=dhcp118.ripemtg.ripe.net ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uGgp-000DSW-00 for namedroppers@ops.ietf.org; Mon, 30 Apr 2001 09:38:23 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uGgo-0004yF-00 for namedroppers@ops.ietf.org; Mon, 30 Apr 2001 18:38:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 30 Apr 2001 09:25:12 -0700 From: David Terrell To: Masataka Ohta Cc: "D. J. Bernstein" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing Message-ID: <20010430092511.A591@pianosa.catch22.org> Reply-To: David Terrell References: <20010430060710.18274.qmail@cr.yp.to> <200104300916.SAA06619@necom830.hpcl.titech.ac.jp> In-Reply-To: <200104300916.SAA06619@necom830.hpcl.titech.ac.jp>; from mohta@necom830.hpcl.titech.ac.jp on Mon, Apr 30, 2001 at 06:16:21PM +0859 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, Apr 30, 2001 at 06:16:21PM +0859, Masataka Ohta wrote: > Dan; > > It's your problem. > > > Paul A Vixie writes: > > > i have not, yet, heard anything new against A6 in this round of the debate. > > > > http://cr.yp.to/djbdns/killa6.html > > How about: > > aol.com. NS ns0.aol.net. > aol.com. NS ns1.aol.net. > > aol.net. NS ns0.aol.com. > aol.net. NS ns1.aol.com. > > ? In this case, ns[01].aol.{net,com} will be in the {net,com} zones as glue. I think the question that I have yet to see answered that Dan is not articulating well is "how the hell is DNS glue supposed to work sanely with A6?" I can't find an answer to that myself. Everybody's talking about no full IP addresses written anywhere, and DNS delegation is one place where that just doesn't work. You need the full 128 bit address in there, and glue registry is the one place that these addresses can't change frequently, because of the bulk of TLD zones and complicated, time consuming procedures registrars use to update those records... -- David Terrell | "I went into Barnes and Noble to look for a Prime Minister, Nebcorp | book on A.D.D., but I got bored and left." dbt@meat.net | - Benjy Feen http://wwn.nebcorp.com/ | to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 30 13:13:10 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19358 for ; Mon, 30 Apr 2001 13:13:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uGwl-000E6o-00 for namedroppers-data@psg.com; Mon, 30 Apr 2001 09:54:51 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uGwk-000E6h-00 for namedroppers@ops.ietf.org; Mon, 30 Apr 2001 09:54:51 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uGwj-00050B-00 for namedroppers@ops.ietf.org; Mon, 30 Apr 2001 18:54:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104301645.JAA79685@redpaul.mfnx.net> To: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: Message from Ian Jackson of "Mon, 30 Apr 2001 11:39:35 BST." <15085.16615.417771.360536@davenant.relativity.greenend.org.uk> Date: Mon, 30 Apr 2001 09:45:10 -0700 From: Paul A Vixie X-DCC-MAPS-Metrics: ernie.mail-abuse.org 667; IP=896 env_From=993 From=1352 Subject=97 Message-ID=1 Received=1 Body=1 Fuz1=1 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Asking A6 opponents to `add something new to the debate' is not > reasonable unless you can point us to where we can read what was said > already. alas, the ietf meeting minutes don't do this debate full justice. > The namedroppers archives have practically nothing about RFC2874 that > I could find. Surely the designs of A6, DNAME and bitstrings should > have been done here ? A6/DNAME was an architecture proposed by matt crawford who is a member of both DNSEXT (though it wasn't call that when this work was done) and IPNGWG. it's not clear which working group's mailing list the discussion was held on. however, the parts that were discussed in DNSEXT (called DNSIND at that time) were just the DNS-relevant stuff -- would A6 and DNAME _work_as_specified_ -- whether they were necessary for IPv6 or would address IPv6's needs was outside the scope of DNS. to really deeply understand where A6/DNAME came from, read the archives and meeting minutes of CIDRD, as well as BIGZ, as well as COM-PRIV, as well as various "@sunroof" lists where IPNG was discussed, as long ago as 1990. > > there is NO justification for the rapid and early adoption of IPv6 in its > > present form unless A6 or something very much like A6 is made a part of it. > > I strongly disagree. IPv6 is needed because we are running out of > IPv4 address space. pfaa. prove that. that we do not have enough IPv4 address space for new prospective uses of Internet-like technology, i agree. but that these new prospective uses are barrelling down the pike at us so quickly that we can afford to ignore the problems of address ownership and portability just to standardize on technology that expands the address space pool, i DISagree. > NAT has prolonged its life, but comes with a whole pile of other problems > - and it's nowadays mandatory to use NAT because it's so hard to get > globally routeable address space for all hosts at a site. But, if we > want to argue these issues, the ipng lists is probably the right place. and that argument has raged for most of a decade without clear resolution. i only wish "global routeable address space" were SIMPLY a problem of how many bits we had available in the datagram source and destination addresses. don't anybody mistake me for an IPv6 naysayer. but for IPv6 to be worth deploying, somebody is going to have to come up with a system whereby routers in the defaultless core of the internet can have fewer than 1*10^6 routes -- we're at 1*10^5 now and an order of magnitude is within reach of the CAMs we see on various drawing boards. 2^64 > 1*10^5, however. this means address space will continue to be owned. this in turn means that transit customers must have an easy way to add or drop "address space owners". this in turn takes us all the way back (sherman, set the wayback machine for 1991) to the endless raging debate about endpoint identifiers. ick. on second thought, DON'T set the wayback machine for 1991. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. From owner-namedroppers@ops.ietf.org Mon Apr 30 13:19:11 2001 Received: from psg.com (exim@[147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19636 for ; Mon, 30 Apr 2001 13:19:09 -0400 (EDT) Received: from lserv by psg.com with local (Exim 3.16 #1) id 14uGxA-000E7D-00 for namedroppers-data@psg.com; Mon, 30 Apr 2001 09:55:16 -0700 Received: from dhcp118.ripemtg.ripe.net ([193.0.8.118] ident=root) by psg.com with esmtp (Exim 3.16 #1) id 14uGx9-000E77-00 for namedroppers@ops.ietf.org; Mon, 30 Apr 2001 09:55:16 -0700 Received: from randy by dhcp118.ripemtg.ripe.net with local (Exim 3.22 #1) id 14uGx8-00050G-00 for namedroppers@ops.ietf.org; Mon, 30 Apr 2001 18:55:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200104301649.LAA13142@gungnir.fnal.gov> To: David Terrell Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: AAAA/A6 thing In-reply-to: Your message of Mon, 30 Apr 2001 09:25:12 PDT. <20010430092511.A591@pianosa.catch22.org> Date: Mon, 30 Apr 2001 11:49:51 -0500 Sender: owner-namedroppers@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I think the question that I have yet to see answered that Dan is > not articulating well is "how the hell is DNS glue supposed to work > sanely with A6?" I can't find an answer to that myself. Everybody's > talking about no full IP addresses written anywhere, Whoa! Who is this "everybody"? > and DNS delegation is one place where that just doesn't work. You > need the full 128 bit address in there, and glue registry is the > one place that these addresses can't change frequently, because of > the bulk of TLD zones and complicated, time consuming procedures > registrars use to update those records... I think you aren't intending to make a case in favor of well- segemented A6 chains, but your ellipsis could be completed in exactly that way. Then if you the end site choose to renumber, you're responsible for coordinating the TLD's glue. If renumbering is thrust upon you because your ISP is renumbering, they are responsible for it. And if the glue record of concern is the very same one they use for their own DNS infrastructure, the right sort of motivations are in place. But never mind that, because the world isn't ready to play that way and it isn't what RFC 2874, section 5.1.2 suggests: 5.1.2. Glue When, as is common, some or all DNS servers for X.EXAMPLE are within the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry enough "glue" information to enable DNS clients to reach those nameservers. This is true in IPv6 just as in IPv4. However, the A6 record affords the DNS administrator some choices. The glue could be any of o a minimal set of A6 records duplicated from the X.EXAMPLE zone, o a (possibly smaller) set of records which collapse the structure of that minimal set, o or a set of A6 records with prefix length zero, giving the entire global addresses of the servers. The trade-off is ease of maintenance against robustness. The best and worst of both may be had together by implementing either the first or second option together with the third. To illustrate the ... If the EXAMPLE zone includes redundant glue, for instance the union of the A6 records of the first and third options, then under normal circumstances duplicate IPv6 addresses will be derived by DNS clients. But if provider DNS fails, addresses will still be obtained from the zero-prefix-length records, while if the EXAMPLE zone lags behind a renumbering of X.EXAMPLE, half of the addresses obtained by DNS clients will still be up-to-date. The zero-prefix-length glue records can of course be automatically generated and/or checked in practice. to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.