This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/11709] glibc domain resolution does not obtain IP addresses from truncated UDP DNS responses.
- From: "khanipov at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 17 Jun 2010 04:18:18 -0000
- Subject: [Bug libc/11709] glibc domain resolution does not obtain IP addresses from truncated UDP DNS responses.
- References: <20100616132818.11709.khanipov@gmail.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From khanipov at gmail dot com 2010-06-17 04:18 -------
(In reply to comment #1)
Thank you for a quick reply and thorough explanation! I am sorry to make you
read the big story, next time I will try to make a more brief report.
Now I understand that using only a truncated UDP to perform getaddrinfo() will
do no good and that the system must try to set up a TCP connection to get all
the information needed (for instance, to sort IP addresses according to their
priorities, as I understood from your reply). However, I am curious if it makes
sense to change the behavior so that the initial UDP reply won't be discarded
completely:
1. Try UDP query.
2. If the UDP response has a TC flag (truncation), try TCP query.
3. If TCP fails, return the information obtained from the initial UDP
response.
Of course I understand, that this is far not a high-priority modification, if
sensible at all. But if it is sensible, I could try to dig into the
glibc/resolv/ code and propose some changes. So I am interested in your opinion
about the idea.
Thanks.
> Thanks for your report - though its form is more of a blog post and more
> to-the-point summary would be easier to process.
>
> As you note, the router behavior is completely non-standard. However, we
cannot
> just decide we do not need anything else from the DNS record, since it may be
> crucial to get all the records e.g. to properly sort and choose the
appropriate
> IP address based on the preferred family and scope; getaddrinfo() supports
> complex ordering mechanisms for this (see gai.conf(5)). Ignoring the rest of a
> truncated reply would cause invalid behavior.
>
> Thus, even if we introduced a special option to process even truncated UDP
> replies, that behavior would be actually harmful and it is better then to use
a
> different (e.g. local-running) caching nameserver. Since this is the first bug
> report about this router I have ever seen, I don't think your problem is that
> wide-spread; but even if it was, it would be much better for the distributions
> to test and handle such broken DNS servers specially (e.g. as part of the DHCP
> negotiation), falling back to a local caching nameserver instead of forcing
> glibc to process broken DNS replies at all costs.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=11709
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.