Subject: Why one port?

From: Ed Sawicki <[email-masked]>
Date: 20 Feb 2003 11:03:15 -0800

I'm wondering why there is only one UDP port assigned to the DNS
protocol? It prevents us from using both an iterative name
server and a recursive name server/cache on the same computer
when only one IP address is available. 

-- 
Ed Sawicki <[email-masked]>
ALC

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: bert hubert <[email-masked]>
Date: Thu, 20 Feb 2003 22:14:00 +0100

> when only one IP address is available. 

Well, that is partly due to the wording of 1034 and 1035 which pretty much
mention 'local cache' and 'local database' in one breath.

And indeed, this is a big mistake. Right now, you can't even differentiate
based on the RD bit. Compare it to running Squid and Apache both on port 80.

Regards,

bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Ed Sawicki <[email-masked]>
Date: 20 Feb 2003 13:56:19 -0800

> based on the RD bit. Compare it to running Squid and Apache both on port 80.

Shouldn't we try to fix it?

---

From: bert hubert <[email-masked]>
Date: Thu, 20 Feb 2003 23:10:20 +0100

> Shouldn't we try to fix it?

Way, way too late - changing a lot about DNS right now is next to
impossible, I'm afraid.

Regards,

bert

---

From: Bruce Campbell <[email-masked]>
Date: Fri, 21 Feb 2003 00:19:12 +0100 (CET)

> when only one IP address is available.

It does not prevent you from doing so.  Most decent DNS servers allow you
to be authoritative to one set of IP addresses, and recursive to another
set of IP addresses.

( Whether information from the recursive side leaks into the authoritative
  side is another issue )

--==--
Bruce.

---

From: Daniel Senie <[email-masked]>
Date: Thu, 20 Feb 2003 18:15:57 -0500

>Way, way too late - changing a lot about DNS right now is next to

Though that was my immediate reaction as well, I'll note the slow 
progression with SMTP servers to implement SUBMISSION protocol. That 
separation was done for much the same reason. Any change would take close 
to forever to complete, and existing servers would have to deal with users 
making requests on port 53 pretty much forever, but I it is a process that 
could be started.

The question is whether it's worth the effort in this case. Given the price 
of hardware, and the availability of virtual machine OS environments, is it 
really worth going down this road?

---

From: Brad Knowles <[email-masked]>
Date: Fri, 21 Feb 2003 01:27:46 +0100

>  based on the RD bit. Compare it to running Squid and Apache both on port 80.

	You distinguish based on source address of the query.  I see no 
other option.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Brad Knowles <[email-masked]>
Date: Fri, 21 Feb 2003 01:29:13 +0100

>  Shouldn't we try to fix it?

	How do you propose that we do that?

---

From: Brad Knowles <[email-masked]>
Date: Fri, 21 Feb 2003 01:25:33 +0100

At 11:03 AM -0800 2003/02/20, Ed Sawicki wrote:

>  protocol?

	That's the way the standard was originally written.

>            It prevents us from using both an iterative name

	Yup.  That's a big problem for programs that can't handle both 
functions in one codebase.

---

From: Ed Sawicki <[email-masked]>
Date: 21 Feb 2003 00:44:03 -0800

> functions in one codebase.

I want my systems to be as secure from attack as possible. To me,
this means never allowing both functions to be provided by the
same codebase.

---

From: Ed Sawicki <[email-masked]>
Date: 21 Feb 2003 00:50:21 -0800

> 	How do you propose that we do that?

I don't know. Allocate another port and rewrite
resolvers, libraries, and recursive name servers/caches?

---

From: Jim Reid <[email-masked]>
Date: Fri, 21 Feb 2003 01:41:10 -0800

>>>>> "Ed" == Ed Sawicki <[email-masked]> writes:

    >> How do you propose that we do that?

    Ed> I don't know. Allocate another port and rewrite resolvers,
    Ed> libraries, and recursive name servers/caches?

This is a troll, right? If such a scheme was going to be deployed, we
might as well fix everything else in the DNS that needs fixing. Since
there would be the mother of all flag days, we might as well ensure
that every device on the net got upgraded to the as-yet-undesigned
DNSv2.

Oh and IANA would likely take a dim view of assigning >1 port number
for the same protocol.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Jim Reid <[email-masked]>
Date: Fri, 21 Feb 2003 01:46:59 -0800

>>>>> "Ed" == Ed Sawicki <[email-masked]> writes:

    Ed> I want my systems to be as secure from attack as possible. To
    Ed> me, this means never allowing both functions to be provided by
    Ed> the same codebase.

Fine. But by the same reasoning, you wouldn't want to provide both
functions on the same box. So have discrete hardware and software for
the authoritative and resolving servers and we're done. Beats changing
the whole internet, no?
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Brad Knowles <[email-masked]>
Date: Fri, 21 Feb 2003 13:47:22 +0100

>  resolvers, libraries, and recursive name servers/caches?

	Riiiiiiiight.  You're going to fix all machines on the entire 
Internet?  I don't think so.

	We might theoretically add another port for non-recursive 
server-to-server communications, at at some point in the far distant 
future, we might be able to switch port 53 to be recursive only.

	But all current nameserver software would have to be fixed, and 
we'd have to monitor how many queries are coming in to what machines 
on what ports and only make the cutover once we got past some 
milestone threshold -- e.g., less than 10% of all queries are coming 
in to port 53.

	Frankly, without a predefined Flag Day, I don't think you could 
make this work.  And I don't think you'd want to try to define a Flag 
Day until this sort of thing was relatively widely adopted already.

---

From: Brad Knowles <[email-masked]>
Date: Fri, 21 Feb 2003 13:43:13 +0100

>  this means never allowing both functions to be provided by the

	Your only other option is to use forwarding, like PowerDNS.

---

From: Ed Sawicki <[email-masked]>
Date: 21 Feb 2003 08:52:56 -0800

On Fri, 2003-02-21 at 01:46, Jim Reid wrote:
> functions on the same box.

I can run both processes in the same computer safely because each
is running as a different non-root user and each is chrooted to
a different place in the file system. If I'm really paranoid, I
can run each in its own Linux virtual machine (UML) - all the while
using only one IP address.

> Beats changing the whole internet, no?

I suspect my response to this comment would be unpopular here.

---

From: bert hubert <[email-masked]>
Date: Fri, 21 Feb 2003 18:08:33 +0100

> I suspect my response to this comment would be unpopular here.

For what it's worth - if DNS continues to (d)evolve at the current rate, I
expect it soon to be usurped by other directory protocols that perhaps only
use DNS to find their .NET or whatever NameResolverService.

Grabbing the namespace is way too juicy a target for many to let it die and
degrade without trying to take over. 

Why is it dying? The current issues with DNSSEC, AXFR interoperability, the
arbitrary creation of some top level domains and not others and the UTF-8
plugin & takeover by VRSN. 

So I'd be all in favour of looking with an open mind towards 'DNS2'.

Regards,

bert

---

From: Jim Reid <[email-masked]>
Date: Fri, 21 Feb 2003 09:15:50 -0800

>>  Fine. But by the same reasoning, you wouldn't want to provide
    >> both functions on the same box.

    Ed> I can run both processes in the same computer safely because
    Ed> each is running as a different non-root user and each is
    Ed> chrooted to a different place in the file system. If I'm
    Ed> really paranoid, I can run each in its own Linux virtual
    Ed> machine (UML) - all the while using only one IP address.

So what? The stuff is still on just one box. You've still got all your
eggs in one basket. Albeit a basket with fancy padded compartments. All
this software ring-fencing isn't going to help if the CPU catches fire
or someone trips over the power cable and disconnects it, etc, etc.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Ed Sawicki <[email-masked]>
Date: 21 Feb 2003 11:09:15 -0800

> or someone trips over the power cable and disconnects it, etc, etc.

It sounds like you agree that "ring-fencing" is an effective means
of securing the processes. I've never had a CPU catch fire and my
power cables are not exposed to foot traffic so I rate that risk
as low for my network.

---

From: [email-masked]
Date: Fri, 21 Feb 2003 10:22:39 -0800

> or someone trips over the power cable and disconnects it, etc, etc.

Sure, there is a large set of problems that the "padded compartments"
won't address.  Doesn't invalidate the idea, since there is also a real 
value to having small highly separable components that are individually 
easier to validate and secure.

There are numerous failure modes, and numerous tradeoffs.  In some
environments IP addresses are scarce, and one develops the habit of
being very conservative in their use. 

Kent

---

From: Ed Sawicki <[email-masked]>
Date: 21 Feb 2003 11:24:28 -0800

On Fri, 2003-02-21 at 10:33, Kandra Nygårds wrote:
> From: "Ed Sawicki" <[email-masked]>
> 
> Presumably so that clients would not have to guess what port to use.

I'm not sure if you intended this as humor. If you didn't, why was
FTP assigned two ports without clients getting confused?

> It does make some sense in allowing a user-configurable port, but it makes
> (IMHO) a lot more sense in sticking to a single DNS-port.

I never suggested that we need a user-configurable port. We need
a fixed UDP port for our recursive name servers/caches.

> 
> I have to wonder, why are you only able to use a single IP-address? Is it a
> provider limitation? Get a real provider. OS limitation? Application
> limitation? In either case, I'd recommend running the resolver on a separate
> machine. If security is your concern, it makes even more sense,

Many people are using /28 and /29 nets and some have only a single
IP address assigned to them by, in some cases, the only ISP in town.
Yet, they want to take control of their DNS _and_ not be prone to
attacks such as cache poisoning. Why should they be forced to use
up two precious or non-existent IP addresses when the limitation
is really artificial?

>and you don't have to rewrite the Internet to do it.

This seems to be a popular theme here. I see it as an exaggeration.

> - Kandra

---

From: Kandra Nygårds <[email-masked]>
Date: Fri, 21 Feb 2003 19:33:01 +0100

I have to wonder, why are you only able to use a single IP-address? Is it a
provider limitation? Get a real provider. OS limitation? Application
limitation? In either case, I'd recommend running the resolver on a separate
machine. If security is your concern, it makes even more sense, and you
don't have to rewrite the Internet to do it.

- Kandra

---

From: Ed Sawicki <[email-masked]>
Date: 21 Feb 2003 11:02:53 -0800

> So I'd be all in favour of looking with an open mind towards 'DNS2'.

Oh, it looks like my opinions would not be completely unpopular here.
Still, is this the right place for criticism of ICANN, BIND, AXFR,
DNSSEC, Verisign/NSI, conflicting RFCs, etc.? I'd planned on sticking
to specific technical aspects of DNS but questions like "Beats changing
the whole internet, no?" leaves little room for avoiding controversial
issues.

---

From: Peter Koch <[email-masked]>
Date: Fri, 21 Feb 2003 21:14:35 +0100

> up two precious or non-existent IP addresses when the limitation

if they have only one externally routable IP address available, to whom
would they like to offer recursive resolving services?

-Peter

---

From: Kandra Nygårds <[email-masked]>
Date: Fri, 21 Feb 2003 20:45:10 +0100

> FTP assigned two ports without clients getting confused?

One control channel, one data channel, so to speak. You might have noticed
how the two assigned ports are called "ftp" and "ftp-data" respectively.

> a fixed UDP port for our recursive name servers/caches.

Ah, in that case no. It makes no sense at all to use separate ports, just
like it makes no sense at all to use a different port for SMTP between mail
relays as between a client and server. It's the same protocol.

> up two precious or non-existent IP addresses when the limitation

NAT or portforward to 1918-space, if you've no other option. However, I
still maintain that you should either pick a provider with clue, or find a
better solution. If you don't have a clueful ISP, use a colo-facility for
your authorative servers (which, in itself, is a pretty good idea).

Question, how would running two instances of DNS software on the same
machine, using different ports protect against cache poisoning?

> This seems to be a popular theme here. I see it as an exaggeration.

The DNS protocol has worked quite well so far. I see no need to rewrite it
in order to enable users perform less than clueful tasks.

- Kandra

---

From: Jim Reid <[email-masked]>
Date: Fri, 21 Feb 2003 17:16:57 -0800

>>>>> "Ed" == Ed Sawicki <[email-masked]> writes:

    Ed> It sounds like you agree that "ring-fencing" is an effective
    Ed> means of securing the processes. I've never had a CPU catch
    Ed> fire and my power cables are not exposed to foot traffic so I
    Ed> rate that risk as low for my network.

This does not amount to a justification for requiring the DNS to use
two different port numbers and forcing every bit of DNS software on
this planet to be changed.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Jim Reid <[email-masked]>
Date: Fri, 21 Feb 2003 17:27:20 -0800

>>>>> "Ed" == Ed Sawicki <[email-masked]> writes:

    Ed> I'm not sure if you intended this as humor. If you didn't, why
    Ed> was FTP assigned two ports without clients getting confused?

Because one port is used for data transfer and the other for control.
This paradigm is not appropriate to the DNS.

    Ed> I never suggested that we need a user-configurable port. We
    Ed> need a fixed UDP port for our recursive name servers/caches.

Isn't that what port 53 is for?

    >> and you don't have to rewrite the Internet to do it.

    Ed> This seems to be a popular theme here. I see it as an exaggeration.

In that case, please explain how you propose to make everything
continue to work with two ports for DNS, one for authoritative service
and one for resolving, and how this could be deployed. For bonus marks,
provide an implementation scheme that does not involve changing
existing software or configurations.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Jim Reid <[email-masked]>
Date: Fri, 21 Feb 2003 17:42:03 -0800

>>>>> "Ed" == Ed Sawicki <[email-masked]> writes:

    Ed> Oh, it looks like my opinions would not be completely
    Ed> unpopular here.  Still, is this the right place for criticism
    Ed> of ICANN, BIND, AXFR, DNSSEC, Verisign/NSI, conflicting RFCs,
    Ed> etc.? I'd planned on sticking to specific technical aspects of
    Ed> DNS but questions like "Beats changing the whole internet,
    Ed> no?" leaves little room for avoiding controversial issues.

There are plenty of places where you can vent your spleen about your
pet peeves. Most of them are not relevant to this list. You can work
out which ones may be appropriate from the charter of this WG and its
mailing list:

	The DNS Operations Working Group will develop guidelines for
	the operation DNS name servers and the administration of DNS
	zone files. These guidelines will provide technical
	information relating to the implementation of the DNS protocol
	by the operators and administrators of DNS domains. 

You invited controversy by making a suggestion which would mean
changing every DNS server and client on the internet. And annoying
IANA. You didn't give a valid reason for that change. Other than it
would be convenient for the almost unique constraints that are imposed
on the way you operate your name server.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Sat, 22 Feb 2003 17:53:36 +0100

Truly, why not to define a DNS.2 system on another set of ports, performing 
DNS+ services?
With resolvers.2 to query them. There would be nothing to change. Just 
value added. There should only be a program to co-produce the DNS1&2 files. 
Who wants implement them.

The interest is that these two DNS parallel systems would be asynchronously 
managed. So they could immediately permit to check the validity of a 
response in one by the other. Since 2 would not be in real operations, it 
could be considered as a test. But in starting with common services with 
low additional CPU and complexity, DNS.2 could bring some immediate plus. 
And produce good field test data.

However, I suppose the test could go very fast if DNS.2 "tested" the direct 
support of Unicode names. Also if the user resolvers had their own root 
file? I am ready to maintain a DNS wish list on dot-root, to see what could 
be the suggestions? If they do not make sense we will see it quick, 
otherwise it would give some ideas to chew.
jfc

On 17:52 21/02/03, Ed Sawicki said:

>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.454 / Virus Database: 253 - Release Date: 10/02/03

---

From: David Conrad <[email-masked]>
Date: Sat, 22 Feb 2003 11:36:41 -0800

On Saturday, February 22, 2003, at 08:53  AM, J-F C. (Jefsey) Morfin 
wrote:
> Truly, why not to define a DNS.2 system on another set of ports, 
> performing DNS+ services?

Where is the ID that describes DNS+ services so I can read it?

Rgds,
-drc

---

From: Brad Knowles <[email-masked]>
Date: Sat, 22 Feb 2003 23:22:33 +0100

>  up two precious or non-existent IP addresses when the limitation

	In that case, they can run a recursive resolver on 127.0.0.1 and 
the authoritative server on their officially assigned IP address. 
Just because they've got only one officially assigned IP address 
doesn't mean that they can't run both a caching recursive resolver 
and an authoritative server on the same box.

	I still recommend separating the services and running them on 
separate machines (where possible), but you can run two copies of the 
nameserver on the same machine, each listening to different IP 
addresses.

---

From: Brad Knowles <[email-masked]>
Date: Sat, 22 Feb 2003 23:36:07 +0100

At 5:53 PM +0100 2003/02/22, J-F C. (Jefsey)  Morfin wrote:

>  The interest is that these two DNS parallel systems would be
>  asynchronously managed. So they could immediately permit to check
>  the validity of a response in one by the other.

	Not really.  They will be separately managed, and therefore you 
can be reasonably guaranteed that you will frequently get different 
answers from the two different services.  So, when they disagree (and 
they frequently will), which is wrong?

---

From: Brad Knowles <[email-masked]>
Date: Sat, 22 Feb 2003 23:29:52 +0100

>  machine, using different ports protect against cache poisoning?

	The authoritative-only server doesn't do any caching, and 
therefore there is no poisoning or pollution of the cache.

	The caching-only server isn't authoritative for anything, and 
while the cache could potentially become polluted, it can't pass that 
pollution on to clients in an authoritative manner (which is the real 
danger).

>  in order to enable users perform less than clueful tasks.

	There are some problems in the DNS, but I am still convinced that 
we can fix these problems without throwing out the whole thing.

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Sun, 23 Feb 2003 10:00:26 +0100

On 20:36 22/02/03, David Conrad said:
>On Saturday, February 22, 2003, at 08:53  AM, J-F C. (Jefsey) Morfin wrote:

It will be where we will have drafted it from the received inputs. Many 
have suggestions but I do not think that any of us can make a complete list 
yet. So the suggested scheme would be:

1. to call and welcome suggestions
2. collectively discuss and asses them
3. interested parties to propose two drafts for information:
     - services to be supported (named DNS+ services from existing various 
experiences)
     - investigations on how to support them through a DNS.2
4. everyone can read them and assess if there is an interest or not to pursue.

rgds. jfc

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Sun, 23 Feb 2003 10:12:13 +0100

On 23:36 22/02/03, Brad Knowles said:

>Not really.  They will be separately managed, and therefore you can be 
>reasonably guaranteed that you will frequently get different answers from 
>the two different services.  So, when they disagree (and they frequently 
>will), which is wrong?

Absolutely true. But remember that I suggest DNS.2 to be first just an 
"under development system". So it would first act only as an alarm. There 
will be first discrepancies because of bugs. They will help debugging 
faster since DNS.1 would act as reference. Then the discrepancies will be 
reduced and may be DNS.1 flaws also reduced. Ahain this would permit to 
progressively have DNS.2 switching from an alarm, to a back-up, to a 
replacement.

We all agree that sometimes the DNS will have to support Unicode and new 
services. I think the earlier we start working and testing, the smoother 
will be the transition (may take 10 years). The difference in such an 
approach with IPv6 would be that there would be no need for "tunels". It 
would start with very limited services plus test, and progressively more 
and more services, without killing DNS.1.

Ideal would be that DNS.2 stays compatible with DNS.1 permitting an 
enhancement and not a transition. To know if it is possible we need to 
consider the suggestions. At this stage I am just suggesting a "suggestions 
collection", and a collective analysis of what we may get.

jfc

---

From: David Conrad <[email-masked]>
Date: Sun, 23 Feb 2003 10:07:58 -0800

Jfc,

On Sunday, February 23, 2003, at 01:00  AM, J-F C. (Jefsey) Morfin 
wrote:
> It will be where we will have drafted it from the received inputs.

This is pretty much exactly the opposite of the way things 
traditionally work in the IETF.  The idea behind IDs is they are 
submitted to prompt input and discussion.

Rgds,
-drc

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Mon, 24 Feb 2003 01:20:31 +0100

At 19:07 23/02/03, David Conrad wrote:
>Jfc,
>On Sunday, February 23, 2003, at 01:00  AM, J-F C. (Jefsey) Morfin wrote:
>This is pretty much exactly the opposite of the way things traditionally 
>work in the IETF.  The idea behind IDs is they are submitted to prompt 
>input and discussion.

I understand that. Seems very much as teaching the market before making a 
market study. Lack of pre-brainstorming. May explain all the 
post-braintearing? May be the reason why the DNS.2 still expected?

Frankly, don't you think there are far more competent people than me on 
this list to write a draft on such a matter? However this topic belongs to 
the dot-root project and such a draft is foreseen on an information basis. 
But not before months, after the iterative specification mechanism I 
descirbed; and probably a few pre-testings. Also by a team including a 
better English writer that me :-). But I certainly want to share in it.

Or may be would you want to discuss it privately and try to build a draft 
with a few other interested? My approach is user centered, list all what we 
want first.
jfc

---

From: Randy Bush <[email-masked]>
Date: Mon, 24 Feb 2003 10:04:55 +0900

> this list to write a draft on such a matter?

talk is cheap

---

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Feb 2003 18:21:43 -0000

Jim Reid writes:
> changing every DNS server and client on the internet.

Actually, deployment is much easier as follows:

   existing client
   -> client forwarding tool on 127.0.0.1 port 53
   -> cache forwarding tool on cache IP address on another port
   -> existing cache on port 53

Both sides install new software, but there aren't any changes to the
existing software. The same approach also makes it fairly easy to deploy
client-cache security protocols.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Brad Knowles <[email-masked]>
Date: Mon, 24 Feb 2003 10:56:35 +0100

At 1:20 AM +0100 2003/02/24, J-F C. (Jefsey)  Morfin wrote:

>  I understand that. Seems very much as teaching the market before
>  making a market study. Lack of pre-brainstorming. May explain all
>  the post-braintearing? May be the reason why the DNS.2 still
>  expected?

	See 
<http://www.ietf.org/internet-drafts/draft-ymbk-6to4-arpa-delegation-00.txt> 
and <http://www.ietf.org/internet-drafts/draft-moore-6to4-dns-03.txt>.

	The way Internet Drafts work is to throw out some ideas, get 
comments back, then work those into future editions of the draft.  If 
you ever get to the point where things have gelled sufficiently to 
turn this into an RFC (informational or otherwise), the document 
continues to live, at least in some form.  If not, it dies after a 
while and is retracted.

	So, if you have an idea, write it up as an ID, and start using 
the process.  Otherwise, it seems to me that you're wasting your time 
and ours.

>  Frankly, don't you think there are far more competent people than
>  me on this list to write a draft on such a matter?

	Maybe, but you seem to care so passionately about this issue 
(whatever it is), that you would seem to be the person best suited to 
take on this task.

	Remember, open source only works because it is a result of 
someone having an itch that they feel they have to scratch, not 
because they're the objectively best people to solve the problem in 
question.

	You've got an itch, and I'd suggest that you just go ahead and 
scratch it, instead of moaning to us that you can't find anyone else 
to scratch it for you.

>                                                      However this
>  topic belongs to the dot-root project and such a draft is foreseen
>  on an information basis. But not before months, after the iterative
>  specification mechanism I descirbed; and probably a few
>  pre-testings. Also by a team including a better English writer that
>  me :-). But I certainly want to share in it.

	If you want to assign this topic somewhere else and wait for them 
to do something about it, that's fine.  But then I'd suggest that you 
actually do that, and not continue to spend your time by wasting ours.

>  Or may be would you want to discuss it privately and try to build
>  a draft with a few other interested? My approach is user centered,
>  list all what we want first.

	You could do that, too.

	All I ask is that you go ahead and do whatever it is you're going 
to do, and once you've got an ID together, we can then come back to 
review it and comment on it.

---

From: Jim Reid <[email-masked]>
Date: Mon, 24 Feb 2003 02:15:56 -0800

>>>>> "djb" == D J Bernstein <[email-masked]> writes:

    >> changing every DNS server and client on the internet.

    djb> Actually, deployment is much easier as follows:

    djb> existing client
    djb> -> client forwarding tool on 127.0.0.1 port 53
    djb> -> cache forwarding tool on cache IP address on another port 
    djb> -> existing cache on port 53

    djb> Both sides install new software, but there aren't any changes
    djb> to the existing software. 

I spoke of changes to *clients* and *servers*, not DNS software.

Your allegedly "easy" deployment scenario means changing every
client. It has to get new software, presumably which will need some
configuration file has to be looked after, and the existing resolver
setup has to be tweaked. And introducing this proxy agent you propose
creates more complexity and yet more ways of breaking things. This
doesn't seem all that easy, does it?

And what about folk like me who run a name server on their laptop and
want to continue to query that server over the loopback interface?
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: [email-masked]
Date: Mon, 24 Feb 2003 03:26:37 -0800

> want to continue to query that server over the loopback interface?

Not to fan the flames or anything:  use 127.0.0.2.  :-)
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Måns Nilsson <[email-masked]>
Date: Tue, 25 Feb 2003 00:51:52 +0100

--On Sunday, February 23, 2003 10:12:13 +0100 "J-F C. (Jefsey)  Morfin"
<[email-masked]> wrote:

> will be first discrepancies because of bugs. 

No, there will be discrepancies because some greedy loon "invents" a new
TLD. If the community manages to stomp those out, there will be
discrepancies because at some point the admin/tech contacts for a 2nd level
domain name will be different and domains will end up in the wrong hands.
If we do our homework, the technical differences will be minor. This of
course only as long as this is a bugfix/new features release of DNS, albeit
with a different port. 

So, where is the draft? 

-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.