This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/11709] glibc domain resolution does not obtain IP addresses from truncated UDP DNS responses.


------- 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]