Date: Thu, 28 Jun 2001 00:20:48 -0700 From: Richard Johnson <raj@cisco.com> To: questions@freebsd.org Subject: Question re. DNS resolver library Message-ID: <15162.56016.379624.538393@kitab.cisco.com>
next in thread | raw e-mail | index | archive | help
I've recently seen a rather strange situation wrt the FreeBSD resolver
code. I think it's probably a more general Bind resolver library code
issue, and I'd like to verify (1) that it's a problem, (2) that it's
in the Bind code, (3) the extent of the problem, and (4) who needs to
know about it.
Here's the issue:
I have a FreeBSD laptop which I was using at my father-in-law's house
where he has a Apple Airport box connected to a phone line. He also
has DHCP and NAT setup on the Airport box, so my laptop got a NAT'ed
address via DHCP along with the address of the DNS server. The DNS
server address was specified as the address of the Airport box. My
system sent out a DNS query, the Airport box relayed it to the
configured DNS server (at the ISP). The DNS reply, however, came back
directly from the ISP's DNS server to my laptop. This meant that the
DNS reply came back from a different address than the one to which my
system had sent the request.
It turns out that the FreeBSD resolver library (and I would think
other BSD Unix resolvers as well) doesn't like the response
originating from a different address than the one to which the query
was sent. I'm guessing this is for a little extra simple security,
although we all know that the originating address could easily be
spoofed if someone were really trying to be malicious, so there isn't
much added security here.
I was able to work around the problem by using tcpdump to see where
the replies were coming from and then telling my resolver to use that
address directly.
I talked with a friend at Apple about the issue and I think he has
some very valid points:
> The base station gives its own address in the DHCP packet, because until
> it has dialed the modem and done the PPP negotiation, it doesn't know
> what the real DNS address is going to be.
>
> I suppose it could change the source address in the reply coming back,
> but the NAT engine currently doesn't support this, and since it works
> fine with Mac OS and Windows right now, changing it is not likely to be a
> high priority for Apple.
>
> Also note that if you want to do DNS lookups using multicast by setting
> your DNS server address to be 224.0.0.251, the FreeBSD resolver also
> fails with that too, because you can never get a DNS reply *from* a
> multicast address.
Looking at the Bind resolver library code in res_send.c I see:
/* Are we still talking to whom we want to talk to? */
if (statp->_sock >= 0 &&
(statp->_flags & RES_F_VC) != 0) {
struct sockaddr_in peer;
int size = sizeof(peer);
if (getpeername(statp->_sock,
(struct sockaddr *)&peer,
&size) < 0) {
res_nclose(statp);
statp->_flags &= ~RES_F_VC;
} else if (!cmpsock(&peer, nsap)) {
res_nclose(statp);
statp->_flags &= ~RES_F_VC;
}
}
I admit to only having spend a few minutes in order to find this, so I
doubt this is the entire extent of the problem. I just wanted to
contact someone else about it before wasting much of my time.
I'm thinking the check for source IP address on replies needs to
simply be eliminated, especially if the Bind resolver library is
expected to work with Multicast DNS.
/raj
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15162.56016.379624.538393>