[PROXYPER] Re: [RC5-PROXYPER] Basic setup for LAN with a...
hank at black-hole.com
Thu Sep 10 00:26:50 EDT 1998
Well, the problems are not likely, but if you don't know how you could
ahve them, stop. What I suggested was setting up a DNS internal to the
private network. This would give other advantages on a private network.
However it is nessicary to make sure the real world never talks to your
Normally this isn't a problem. However, if you try to run your internal
name server on a machine that is also connected to the real world, and
someone in the real world uses your name server, you poison them. This is
mostly possibal if you point all machines to an internal name server that
internic already points to. If your DNS is on the private lan only, you
are fine. If your machines can comunicate with part of the real internet
(ie you allow anyone to access company servers, but use the private
address space to make sure they can't get to the internet) you might hve
them pointed to a internet connected name server.
I do not know that the above would be the case with the specific case in
question, but I always try to remember the person two months from now
searching the archives with a very similear situation.
In the latter case someone might (stupidly) setup a name server at an ISP
for instance to give the wrong address, and others wouldn't connect to
anything. The case for this would be a perminant internet conenction for
a few machines, private subnetting for the rest, the ISP runs the
nameserver, and knows to route to the prvate subnet. I don't know if it
ever happens, but it could. Don't let it.
On Wed, 9 Sep 1998, Joe Zbiciak wrote:
> 'Henry Miller' said previously:
> | WARNING! The following messages suggests a technical move that is not in
> | the best interest of everyone.
> Pardon me while I scratch my head... HUH?
> The message thread attached described
> -- Setting up a personal proxy on a private segment of network
> -- Setting it up with a hard-coded IP for the main keyserver
> -- Setting your clients to see the personal proxy manually, since
> they default to sending them to us.v27.distributed net.
> Yes, DNS cache poisoning and spoofing might subvert a handful of clients
> out there into talking to someone's perproxy instead of a main keyserver,
> but I really don't think that's much of a problem. Besides, perproxies
> announce themselves as perproxies (see the "[pp]" in the log files).
> By hardcoding IPs, DNS is bypassed entirely, which is a different issue
> -- the load balancing between the main key servers that's usually
> accomplished by round-robin DNS no longer works.
> | If you do not understand the implications
> | of it, don't try it. In particular anyone using this system must be sure
> | that they will not send incorrect data to the internet.
> What *are* the implications you're referring to? What specific action
> are you objecting to?
> The most controversial bit in the whole mess is hardcoding IP's in the
> perproxy because it doesn't seem to be able to do DNS reliably.
> +------ Joseph Zbiciak -----+
> | - - j-zbiciak1 at ti.com - - | "Can I ask you a really stupid question?"
> |-Texas Instruments, Dallas-|
> | - #include <disclaim.h> - | "Yes, and history will bear me out on that."
> To unsubscribe, send 'unsubscribe proxyper' to majordomo at lists.distributed.net
hank at black-hole.com
To unsubscribe, send 'unsubscribe proxyper' to majordomo at lists.distributed.net
More information about the proxyper