[Top] [All Lists]

Re: New ZeroConf Spec

Subject: Re: New ZeroConf Spec
From: "Micah J. Cowan"
Date: Mon, 10 Jul 2006 14:24:22 -0700
On Mon, Jul 10, 2006 at 09:58:58AM +0100, Scott James Remnant wrote:
> On Sun, 2006-07-09 at 13:39 -0500, Carl Karsten wrote:
> > Scott James Remnant wrote:
> > > On Mon, 2006-07-03 at 20:48 -0700, Dan Kegel wrote:
> > > 
> > >> There should be no exception: there should be no open ports by default.
> > >>
> > > This isn't actually entirely true; we currently have two open ports by
> > > default:
> > > 
> > > If you're on a network with DHCP, the DHCP client listens on UDP port 68
> > > to receive responses from the DHCP server.
> > > 
> > > And every time you make a DNS query, a UDP port is opened to receive the
> > > response from the DNS server.
> > 
> > I think you are missing the meaning or intent of "no open ports" - when a 
> > client 
> > makes a request of a server, it waits for the response on a port.  That 
> > includes 
> > a web browser, dns, e-mail client, apt-get, IRC and anything else that 
> > talks to 
> > another box.
> > 
> These all talk TCP, which has reasonably strong prevention against
> attack from an alternate source which comes for free in the kernel.
> DNS uses UDP which does NOT have this prevention, while the daemon is
> waiting for a reply, it can receive packets from ANYWHERE.

This depends a lot on how the programmer does his UDP listening.

The correct way to send a UDP packet for which you wish to receive a
response, would probably be to use connect(2) and then write(2) or
send(2), rather than just using sendto(2). This sets the default
destination of datagram packets, and tells the kernel to accept incoming
only from the host you specified as the destination. I would strongly
suspect that this is how such things as name resolution are typically
handled (someone pointed out elsethread that none of this applies for
mDNS, etc.).

Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...

ubuntu-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>