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

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

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11709

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[khanipov at gmail dot com]

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

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

[pasky at suse dot cz]

------- Additional Comments From pasky at suse dot cz  2010-06-16 21:10 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


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.