From owner-freebsd-security Sun Jun 13 19: 0:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from tok.qiv.com (tok.qiv.com [205.238.142.68]) by hub.freebsd.org (Postfix) with ESMTP id C83B214E92 for ; Sun, 13 Jun 1999 19:00:26 -0700 (PDT) (envelope-from jdn@acp.qiv.com) Received: (from uucp@localhost) by tok.qiv.com (MailHost/Current) with UUCP id VAA62470; Sun, 13 Jun 1999 21:00:24 -0500 (CDT) Received: from localhost (jdn@localhost) by acp.qiv.com (8.9.3/8.9.2) with ESMTP id UAA01313; Sun, 13 Jun 1999 20:40:35 -0500 (CDT) (envelope-from jdn@acp.qiv.com) Date: Sun, 13 Jun 1999 20:40:35 -0500 (CDT) From: Jay Nelson To: Gary Palmer Cc: security@FreeBSD.ORG Subject: Re: Fwd: [linux-security] Re: Port 7 scan In-Reply-To: <34083.929310846@noop.colo.erols.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 13 Jun 1999, Gary Palmer wrote: >Basically, if you didn't understand the previous reply (or need more >info) Resonate make a couple of DNS based load balancing solutions, I understood the reply and understand why latency is central to their solution. The answer, though, raised the question of why a port that can identify a host platform -- for that matter, why not port 25, which, at worst, yields the same lack of response? Logging? >one for replacing DNS round robin in a single datacenter environment, >one for distributing load across multiple datacenters, with traffic >being sent to the `closest' one. Their distributed DNS system works >by having a system at each of the datacenters `ping' (somehow) the DNS >server doing the lookup. The one with the lowest latency (generally, >although load at the datacenter, and local preferences, can also weigh >in) will be chosen, and an A record for ad.doubleclick.net will be >returned pointing at that datacenter. Generally, that A record will be >pointing at their local load balacing solution, which is an entire >other story. I agree that there may be another story, here. The answer is sufficient to re-evaluate our security policy. Particularly in light of the fact that others have been able to implement similar solutions, without the invasion. Thank you all for your answers. -- Jay To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message