Brian Aker wrote:
Hi!
On Jan 30, 2008, at 12:03 PM, Tomash Brechko wrote:
The DNS fear is stretched too far. You are basically saying that one
should never ever bind to site-local address because there's a
possibility that it is visible form the outside, and is not protected
Because bad setups never occur with DNS? A sysadmin never binds a public
address to an internal and external device, not realizing that is some
program comes along it will be exposed to the outside world?
Memcached has no password protection, so doesn't it make sense to have
an ounce more protection? (and it is not like memcached is designed to
be a mutli-listener... and getaddrinfo() returns even junk like AF_UNIX
on older glibc).
I can patch it to bail on multi available, but that will cause older
glibc() to toss any binding (and the FreeBSD 4.x guys will be submitting
a patch later to just ignore all all entries past the first when they
hit this problem).
So:
getaddrinfo() returns a list.
If you're setting the AI_ADDRCONFIG flag it'll at least only return
addresses which are available on the interface (ipv6 only, etc).
But if a hostname returns multiple addresses (getaddrinfo(NULL, ...))
and the host might be a dedicated server with a private net, it'll bind
to both the public address and private address?
I'm not entirely clear on the conditions where getaddrinfo would suggest
you bind to both a public and a private address, unless you're binding
to INADDR_ANY, which I _believe_ is the present default for memcached,
and will certainly bind to any public IP if it exists.
Could someone perhaps clear it up a bit? Is this identical or different
to the present IPv4 default behavior, and if this is going to be
different, we might need a new option to accomodate. IE; if someone
wants to bind to a private-network in IPv4 land, they presently use -l,
but if you're binding by hostname in IPv6, it makes sense (to me) to
continue to allow someone to select a private address.
Unless I'm completely off here :P
-Dormando
