> I found this 'best practices' draft, we might want to evaluate
> how c-ares handles these different situations (at least the ones
> which are applicable to client-only):
> http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-05
Ok, let's take the 4 general best practices and see what c-ares
does ... please fill in any blanks or make corrections where I
am wrong:
DNS data is to be accepted by a resolver if and only if:
1. The question section of the reply packet is equivalent to that of
a question packet currently waiting for a response
-- Yes, c-ares 1.5.2, ares_process.c, line 544
2. The ID field of the reply packet matches that of the question
packet
-- Yes, c-ares 1.5.2, ares_process.c, line 544
3. The response comes from the same network address the question was
sent to
-- **NO**. c-ares 1.5.2, ares_process.c, line 467.
Should be using recvfrom(), which returns a struct sockaddr
which should be used to determine the network address the
response came from.
4. The response comes in on the same network address, including port
number, as the question was sent from
-- MAYBE. The port number should be guaranteed by the way
socket() and recv() work. I'm not sure how determine
what address the request was sent from (especially if you
have multiple addresses bound to a NIC). It's possible the
OS is guaranteeing this for us ...
Now lets take the recommended countermeasures:
Resolver implementations MUST have the ability to:
o Use an unpredictable source port for outgoing queries from the
range (53, or > 1024) of available ports that is as large as
possible and practicable;
-- MAYBE. The port numbers are only as random as the OS
allows. This could be OS-specific. I don't think you
can randomize source ports unless you use raw sockets
(which require root access, so may not be feasible).
o Use multiple different source ports simultaneously in case of
multiple outstanding queries;
-- YES. Different connections mean different source ports.
o Use an unpredictable query ID for outgoing queries, utilizing the
full range available (0-65535);
-- YES. Appears to be, don't fully understand it but it
appears that an initial rc4 key is created, then on
each request, the a counter changes and some keys are
swapped so each request returns a different ID. I'm
not sure where this methodology came from, but this
patch by Shmulik Regev made the patch that was eventually
integrated...
http://daniel.haxx.se/projects/c-ares/mail/c-ares-archive-2007-05/0013.shtml
-Brad
Received on 2008-07-14