[Bug 5342] New: (patch) res_query silently rejects responses against T_ANY DNS questions
bugzilla at busybox.net
bugzilla at busybox.net
Sun Jul 8 03:21:25 UTC 2012
https://bugs.busybox.net/show_bug.cgi?id=5342
Summary: (patch) res_query silently rejects responses against
T_ANY DNS questions
Product: uClibc
Version: 0.9.33.2
Platform: All
OS/Version: Linux
Status: NEW
Severity: minor
Priority: P5
Component: Networking
AssignedTo: unassigned at uclibc.org
ReportedBy: chrisy at flirble.org
CC: uclibc-cvs at uclibc.org
Estimated Hours: 0.0
Created attachment 4394
--> https://bugs.busybox.net/attachment.cgi?id=4394
resolv-any.patch
res_query() performs a DNS query using the internal __dns_lookup function. That
much works perfectly. However, it rejects the response if the type of the first
answer returned from the DNS server does not exactly match the original
question type.
Also, when rejecting the response it still returns the length of the packet
received (instead of -1) without filling out the contents of the user-supplied
packet buffer. Without a rejection indication, parsing of the results naturally
fails - in my case, with ns_initparse() being fed an uninitialized buffer of
rubbish.
This is problematic since, when one performs a T_ANY query, you're explicitly
saying "I want anything that matches this domain name, regardless of type".
Additionally, when one does a T_A or T_AAAA query you can end up with a T_CNAME
answer, and it will generally be the first answer.
The attached patch resolves both the unduly strict answer type matching and the
failure to indicate rejection.
If the question type was T_ANY then it allows any answer type. If the question
type was T_A or T_AAAA then it allows a T_CNAME answer.
If it rejects an answer for not satisfying this condition, it returns -1, as
you would expect.
This patch has been tested on OpenWrt (trunk) against uClibc 0.9.33.2.
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the uClibc-cvs
mailing list