Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
tag 343140 + fixed-upstream
close 343140 2.9-1
found 343140 2.9-6
thanks
On Mon, Dec 12, 2005 at 09:13:13PM -0800, Edward Buck wrote:
Package: libc6
Version: 2.3.2.ds1-22
Severity: important
I originally posted a bug report for postfix detailing the problem but I
can reproduce the bug outside of postfix. Here's the postfix bug
report in case you're interested:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314891
In a nutshell, when using 'search' lines in /etc/resolv.conf, the
resolver always appends listed search domains to a hostname lookup even
when the host being searched is fully-qualified (contains one or more dots).
This results in a LOT of needless DNS traffic. On a busy mail server,
it makes using the 'search' lines extremely expensive (because DNS traffic
increases exponentially).
Here's an strace of 'telnet mx1.hotmail.com 25'. Oddly, it seems to do
the right thing initially but the fully-qualified lookup must always
fail, resulting in subsequent lookups using the search list.
$ cat /etc/resolv.conf
nameserver 69.51.81.36
nameserver 69.51.78.68
search ul.aspextra.net aspextra.net
$ strace telnet mx1.hotmail.com 25
...
open(/etc/resolv.conf, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=274, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40018000
read(3, # Dynamic resolv.conf(5) file fo..., 4096) = 274
read(3, , 4096) = 0
close(3)= 0
munmap(0x40018000, 4096)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.81.36)}, 28) = 0
send(3, \n\177\1\0\0\1\0\0\0\0\0\0\3mx1\7hotmail\3com\0\0\34\0..., 33, 0) =
33
gettimeofday({1134449292, 353764}, NULL) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(3, FIONREAD, [98])= 0
recvfrom(3, \n\177\201\200\0\1\0\0\0\1\0\0\3mx1\7hotmail\3com\0\0\34...,
1024, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.81.36)}, [16]) = 98
close(3)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.81.36)}, 28) = 0
send(3, \n\200\1\0\0\1\0\0\0\0\0\0\3mx1\7hotmail\3com\2ul\10..., 49, 0) = 49
gettimeofday({1134449292, 357407}, NULL) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(3, FIONREAD, [49])= 0
recvfrom(3, \n\200\201\205\0\1\0\0\0\0\0\0\3mx1\7hotmail\3com\2ul\10...,
1024, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.81.36)}, [16]) = 49
close(3)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.78.68)}, 28) = 0
send(3, \n\200\1\0\0\1\0\0\0\0\0\0\3mx1\7hotmail\3com\2ul\10..., 49, 0) = 49
gettimeofday({1134449292, 361191}, NULL) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 3000) = 1
ioctl(3, FIONREAD, [100]) = 0
recvfrom(3, \n\200\201\203\0\1\0\0\0\1\0\0\3mx1\7hotmail\3com\2ul\10...,
1024, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.78.68)}, [16]) = 100
close(3)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.81.36)}, 28) = 0
send(3, \n\201\1\0\0\1\0\0\0\0\0\0\3mx1\7hotmail\3com\10asp..., 46, 0) = 46
gettimeofday({1134449292, 364427}, NULL) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(3, FIONREAD, [97])= 0
recvfrom(3, \n\201\201\203\0\1\0\0\0\1\0\0\3mx1\7hotmail\3com\10as...,
1024, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.81.36)}, [16]) = 97
close(3)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.81.36)}, 28) = 0
send(3, \n\202\1\0\0\1\0\0\0\0\0\0\3mx1\7hotmail\3com\0\0\1\0..., 33, 0) =
33
gettimeofday({1134449292, 367710}, NULL) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(3, FIONREAD, [195]) = 0
recvfrom(3, \n\202\201\200\0\1\0\4\0\5\0\0\3mx1\7hotmail\3com\0\0\1...,
1024, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.81.36)}, [16]) = 195
close(3)= 0
socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/.nscd_socket}, 110) = -1
ENOENT (No such file or directory)
close(3)= 0
gettimeofday({1134449292, 371589}, NULL) = 0
getpid()= 15269
open(/etc/resolv.conf, O_RDONLY) = 3
...
This bug is fixed by unified IPv6 and IPv4 lookup since glibc 2.9-1.
Unfortunately we had to disable this feature in glibc 2.9-6 due to
broken
Re: Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
This one time, at band camp, Edward Buck said: In this case, the algorithm does not match the specification. Therefore, it's a bug. Quoting the man page: Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found. IPv6 queries are not excluded from this description. The fact is that with this bug, resolver queries with MORE than ndots are ALWAYS attempted using each component of the search path. Yes, the queries are IPv6 but that does not matter. If you read further down the man page: ndots:n sets a threshold for the number of dots which must appear in a name given to res_query() (see resolver(3)) before an initial absolute query will be made. There's no ambiguity in the term 'absolute query'. A lookup for the IPv6 address example.com.domain.in.search.path is NOT an initial absolute query no matter how you look at it. Unless of course you missed the part of the report where the query under discussion has greater than ndots in it. The original query under discussion was mx1.hotmail.com, and ndots was unset, so defaulted to 1. There are 2 dots in mx1.hotmail.com, so the search order was correctly used. That it defaulted to ipv6 first is the only thing really left for discussion, it seems to me. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
Stephen Gran wrote: This one time, at band camp, Edward Buck said: If you read further down the man page: ndots:n sets a threshold for the number of dots which must appear in a name given to res_query() (see resolver(3)) before an initial absolute query will be made. There's no ambiguity in the term 'absolute query'. A lookup for the IPv6 address example.com.domain.in.search.path is NOT an initial absolute query no matter how you look at it. Unless of course you missed the part of the report where the query under discussion has greater than ndots in it. The original query under discussion was mx1.hotmail.com, and ndots was unset, so defaulted to 1. There are 2 dots in mx1.hotmail.com, so the search order was correctly used. That it defaulted to ipv6 first is the only thing really left for discussion, it seems to me. The issue is that it defaulted to the IPv6 _family_ first. It's not a bug that IPv6 is tried first since RFC's recommend that. And even with the original query of mx1.hotmail.com, I'm saying that the search order is _not_ correct. Let's say the search line has: search domain1.com domain2.com The correct query order for mx1.hotmail.com (containing 2 dots) should be: 1. mx1.hotmail.com. - 2. mx1.hotmail.com. - A 3. mx1.hotmail.com.domain1.com. - 4. mx1.hotmail.com.domain1.com. - A 5. mx1.hotmail.com.domain2.com. - 6. mx1.hotmail.com.domain2.com. - A If step 1 or 2 returns a host address, step 3 and later are skipped. The Debian (or glibc) query order is: 1. mx1.hotmail.com. - 2. mx1.hotmail.com.domain1.com. - 3. mx1.hotmail.com.domain2.com. - 4. mx1.hotmail.com. - A 5. mx1.hotmail.com.domain1.com. - A 6. mx1.hotmail.com.domain2.com. - A With Debian's query order, mx1.hotmail.com exists as an A record yet the system doesn't check until it has already done 3 queries, 2 of which do not qualify as an 'initial absolute query'. The bug is not just limited to those who use the search line. If your resolv.conf contains 'domain ...', e.g. domain example.com nameserver x.x.x.x nameserver y.y.y.y Then a query of mx1.hotmail.com will ALWAYS yield: 1. mx1.hotmail.com. - 2. mx1.hotmail.com.example.com. - (extraneous) 3. mx1.hotmail.com. - A In other words, Debian's networking already starts at a disadvantage (doing extra queries) as long as you use _either_ 'search' or 'domain' in /etc/resolv.conf. Regards, Ed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
On Fri, Dec 23, 2005 at 01:21:54PM -0800, Edward Buck wrote: The correct query order for mx1.hotmail.com (containing 2 dots) should be: 1. mx1.hotmail.com. - 2. mx1.hotmail.com. - A 3. mx1.hotmail.com.domain1.com. - 4. mx1.hotmail.com.domain1.com. - A 5. mx1.hotmail.com.domain2.com. - 6. mx1.hotmail.com.domain2.com. - A If step 1 or 2 returns a host address, step 3 and later are skipped. The Debian (or glibc) query order is: 1. mx1.hotmail.com. - 2. mx1.hotmail.com.domain1.com. - 3. mx1.hotmail.com.domain2.com. - 4. mx1.hotmail.com. - A 5. mx1.hotmail.com.domain1.com. - A 6. mx1.hotmail.com.domain2.com. - A With Debian's query order, mx1.hotmail.com exists as an A record yet the system doesn't check until it has already done 3 queries, 2 of which do not qualify as an 'initial absolute query'. Ok, let's clarify some things here. resolv.conf(5) describes the behaviour of a _single_ resolver query. If you look at resolv/nss_dns/dns-host.c in the glibc source, you'll see that gethostbyname(3) is implemented as _two_ distinct resolver invocations. Since it is nowhere specified how many resolver invocations gethostbyname(3) should cause, the glibc behaviour is correct and will result in the second list of DNS queries you specified. If you want to avoid the extra query, you should use getaddrinfo(3) or the GNU-specific gethostbyname2(3) and specify explicitely the address family you are interested in. The bug is not just limited to those who use the search line. If your resolv.conf contains 'domain ...', e.g. domain example.com nameserver x.x.x.x nameserver y.y.y.y Then a query of mx1.hotmail.com will ALWAYS yield: 1. mx1.hotmail.com. - 2. mx1.hotmail.com.example.com. - (extraneous) 3. mx1.hotmail.com. - A This is the same as before, as by default the search list is initialized to contain the local domain if there are no explicit search lines. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
Gabor Gombas wrote: Ok, let's clarify some things here. resolv.conf(5) describes the behaviour of a _single_ resolver query. If you look at resolv/nss_dns/dns-host.c in the glibc source, you'll see that gethostbyname(3) is implemented as _two_ distinct resolver invocations. Since it is nowhere specified how many resolver invocations gethostbyname(3) should cause, the glibc behaviour is correct and will result in the second list of DNS queries you specified. That would explain the behavior yes. Constraints in gethostbyname notwithstanding, it still feels like an OS bug. Perhaps not a glibc bug though. If you want to avoid the extra query, you should use getaddrinfo(3) or the GNU-specific gethostbyname2(3) and specify explicitely the address family you are interested in. I think postfix was moving away from gethostbyname in favor of getaddrinfo. So maybe some of the postfix-related problems will go away in the future. At the moment though, the sarge combo of postfix + glibc's IPv6 support + search/domain lines results in very unexpected, undesirable behavior, especially when compared to woody which by default did not do these extra lookups. Thanks for your help. Regards, Ed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
On Wed, Dec 21, 2005 at 06:08:04PM +0100, Marco d'Itri wrote: I find this reasoning very peculiar. If an algorithm is inefficient and this causes problems then it is obviously buggy. An algorithm is buggy if it does not match the specification. I see no description about the lookup order wrt. multiple protocols, so the behaviour is conformant to the documentation. Also note that resolv.conf(5) explicitely says that using search lines may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is available for one of the domains. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu -
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
On Dec 23, Gabor Gombas [EMAIL PROTECTED] wrote: I find this reasoning very peculiar. If an algorithm is inefficient and this causes problems then it is obviously buggy. An algorithm is buggy if it does not match the specification. I see no Yet another very peculiar definition from you. description about the lookup order wrt. multiple protocols, so the behaviour is conformant to the documentation. While this may be true, it does not make it less than a bug. Also note that resolv.conf(5) explicitely says that using search lines may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is available for one of the domains. Which is true, but does not mean that the current behaviour is correct and should not be changed. -- ciao, Marco signature.asc Description: Digital signature
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
On Wed, Dec 21, 2005 at 10:42:03AM -0800, Edward Buck wrote: On the first point, I (and thus my company) use search lines in combination with LAN-only DNS subdomains for internal address management. It allows us to use internal IP addresses for hosts without fiddling with /etc/hosts. All our host subdomains are managed in DNS. A LOT of scripts, i.e. for backup, rsync, load balancing, use short hostnames that get their address information from internal DNS zones, a process that depends on the search functionality in /etc/resolv.conf. My personal opinion is that this is wrong, and now you are trying to paper over an initial design flaw. Should you had a policy to always use full host names everywhere, you'd not have this problem now. In my experience relying on lookup service configuration is never good. To give you an idea of impact, I was recently greeted with an e-mail from a DNS service provider that I use saying that I was getting close to my query quota. It surprised me that I got this e-mail because I was never close to hitting the quota before. It turns out that 90% of the queries were coming from 1 server where I unwittingly added the domain to the search path! Well, resolv.conf(5) says about search lines that they will generate a lot of network traffic if the servers for the listed domains are not local. You should not add a search line for a domain not server by a local name server. In most cases this can be solved by installing a local caching-only name server. On the subject of work-arounds, I'm not having much luck finding one without recompiling glibc, which is not a good option IMO. If anyone has any ideas on this, please let me know. Did you try apt-get install bind9 and putting nameserver 127.0.0.1 in /etc/resolv.conf? You can also try lwresd libnss-lwres if you need something smaller, or djbdns if you like its author :-) This may reduce your DNS traffic even more than changing the lookup order in glibc would. Of course you have to pay with some memory and a little CPU usage. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
On Fri, Dec 23, 2005 at 01:31:16AM +0100, Marco d'Itri wrote: Yet another very peculiar definition from you. Well, that's the first thing thaught in programming theory here. If the algorithm matches the specification, then it is correct. If the specification does not cover something, then the algorithm is free to choose whatever behaviour it prefers. Of course, a correct algorithm is not neccessarily the best. Bubblesort is correct since the traditional sorting specification does not put constraints on the number of comparisons, but there is a reason people prefer to use qsort when there are more than a handful of elements :-) Which is true, but does not mean that the current behaviour is correct and should not be changed. Then convince upstream to change the current behaviour. Or write a patch, and convince the Debian glibc team that Debian should diverge from upstream behaviour. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu -
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
Gabor Gombas wrote: On Wed, Dec 21, 2005 at 06:08:04PM +0100, Marco d'Itri wrote: I find this reasoning very peculiar. If an algorithm is inefficient and this causes problems then it is obviously buggy. An algorithm is buggy if it does not match the specification. I see no description about the lookup order wrt. multiple protocols, so the behaviour is conformant to the documentation. In this case, the algorithm does not match the specification. Therefore, it's a bug. Quoting the man page: Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found. IPv6 queries are not excluded from this description. The fact is that with this bug, resolver queries with MORE than ndots are ALWAYS attempted using each component of the search path. Yes, the queries are IPv6 but that does not matter. If you read further down the man page: ndots:n sets a threshold for the number of dots which must appear in a name given to res_query() (see resolver(3)) before an initial absolute query will be made. There's no ambiguity in the term 'absolute query'. A lookup for the IPv6 address example.com.domain.in.search.path is NOT an initial absolute query no matter how you look at it. Also note that resolv.conf(5) explicitely says that using search lines may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is available for one of the domains. The author of that man page did not have this bug in mind when he wrote that. If he did, the search functionality would have been removed. Yes, using the search line causes more network traffic than not using it. But this bug causes WAY more network traffic than a proper functioning search line. As I said in a previous e-mail, FreeBSD's resolver does it the correct way. Debian should follow suit, regardless of whether glibc developers consider this a bug (I'd be surprised if they thought it wasn't). Also, keep in mind that even if you DON'T use the search line at all and simply have 'domain example.com' in resolv.conf, which most users have by convention, then you're STILL having extraneous queries. I checked this too. Every resolver query your system ever makes will also look for an record of example.com.example.com even when example.com exists! How is that not a bug? Regards, Ed Gabor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
On Dec 21, Gabor Gombas [EMAIL PROTECTED] wrote: It's not a bug. It may be inefficient, but that's not a bug in itself. I find this reasoning very peculiar. If an algorithm is inefficient and this causes problems then it is obviously buggy. And it's doubly buggy if its inefficiencies cause are harmful for third parties. -- ciao, Marco signature.asc Description: Digital signature
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
Marco d'Itri wrote: On Dec 21, Gabor Gombas [EMAIL PROTECTED] wrote: It's not a bug. It may be inefficient, but that's not a bug in itself. I find this reasoning very peculiar. If an algorithm is inefficient and this causes problems then it is obviously buggy. And it's doubly buggy if its inefficiencies cause are harmful for third parties. I won't get into the debate of whether this constitutes a debian bug but I can tell you that this bug causes significant problems for those who: * use search lines for host management * have busy machines On the first point, I (and thus my company) use search lines in combination with LAN-only DNS subdomains for internal address management. It allows us to use internal IP addresses for hosts without fiddling with /etc/hosts. All our host subdomains are managed in DNS. A LOT of scripts, i.e. for backup, rsync, load balancing, use short hostnames that get their address information from internal DNS zones, a process that depends on the search functionality in /etc/resolv.conf. This bug effectively forces us to discard this internal process on certain machines, which means the process is no longer a good one. A bug (or design flaw or whatever) that causes re-evaluation of internal processes is pretty significant in my mind. On the 2nd point, the increase in DNS load is not something that normal users may appreciate or notice. But those who manage DNS servers know that a 2x or 3x increase in DNS load has consequences. For those who are unlucky enough to have 5 domains in their search path (not an uncommon scenario I would think), you're looking at 6 extraneous DNS lookups for every legitimate lookup! To give you an idea of impact, I was recently greeted with an e-mail from a DNS service provider that I use saying that I was getting close to my query quota. It surprised me that I got this e-mail because I was never close to hitting the quota before. It turns out that 90% of the queries were coming from 1 server where I unwittingly added the domain to the search path! It took me a while to figure this out but eventually I did and it was the impetus for resubmitting this bug report (my first bug report was for postfix back in June). After removing the domain from the search line on this machine, the query lookups suddenly have dropped to insignificant levels again. On the subject of work-arounds, I'm not having much luck finding one without recompiling glibc, which is not a good option IMO. If anyone has any ideas on this, please let me know. Thanks. Regards, Ed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
Marco d'Itri wrote: On Dec 21, Gabor Gombas [EMAIL PROTECTED] wrote: It's not a bug. It may be inefficient, but that's not a bug in itself. I find this reasoning very peculiar. If an algorithm is inefficient and this causes problems then it is obviously buggy. And it's doubly buggy if its inefficiencies cause are harmful for third parties. Just wanted to add some more information to this bug report. Etch has the exact same behavior as sarge. I tested on a system running the latest version of glibc from testing. To add some perspective on this issue, I did the same test on a FreeBSD 6.0 system which has IPv6 support. Interestingly, it does the sane thing and only does one extra lookup, e.g. the IPv6 query for the initial hostname, regardless of how many search domains are listed. Search lines in /etc/resolv.conf aren't referenced unless the hostname contains less than one dot, which corresponds to the documentation. So although it's tempting to write this off as an inherent flaw in IPv6 support, FreeBSD apparently got it right. Please don't take my FreeBSD comparison as anything more than bug insight. I prefer Debian to all other distros/BSDs and this bug does not change that. But the performance implications of this bug are real, especially when compared to competing solutions. As I mentioned before, disabling ipv6 kernel support in /etc/modprobe.d/aliases does not help. Thanks. Regards, Ed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
On Tue, Dec 20, 2005 at 12:41:05AM +, Stephen Gran wrote: I guess the answer to this problem for you is to just disable ipv6 (unless you need it) - blacklisting the kernel module(s) ought to do it, although there may be some other parts I am unaware of. I doubt disabling IPv6 in the kernel would make any difference since querying for records does not require an IPv6 socket. You will only find out if IPv6 is disabled if you do have an record and you try to use the address. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu -
Processed: Re: Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
Processing commands for [EMAIL PROTECTED]: reopen 343140 Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf Bug reopened, originator not changed. retitle 343140 resolver uses the search list before other address families Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf Changed Bug title. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
reopen 343140 retitle 343140 resolver uses the search list before other address families thanks On Dec 20, GOTO Masanori [EMAIL PROTECTED] wrote: Okay, I close it. If you think there's bugs in libc, please tell me about it. I think this is definitely a glibc bug, and disabling IPv6 support (if possible at all) just means sweeping it under the carpet for a while. The submitter reported that his system makes three times the usual DNS queries, and as OS vendors we have a duty to not ship software which badly interacts with other systems. -- ciao, Marco signature.asc Description: Digital signature
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
At Thu, 15 Dec 2005 17:13:25 -0800, Edward Buck wrote: I guess the problem then is in the ipv6 support and how it implements domains in the search path. Instead of doing ipv6, then ipv4 for mx1.hotmail.com, it runs through all possible ipv6 queries, including exhausting all domains in the search path, before ipv4 queries are attempted. That seems (is) really inefficient. As a result of ipv6 supports, DNS queries have tripled on systems with two domains in their search path. Okay, perhaps this isn't a bug. It's just ipv6 hell. Okay, I close it. If you think there's bugs in libc, please tell me about it. -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
At Thu, 15 Dec 2005 17:13:25 -0800, Edward Buck wrote: I guess the problem then is in the ipv6 support and how it implements domains in the search path. Instead of doing ipv6, then ipv4 for mx1.hotmail.com, it runs through all possible ipv6 queries, including exhausting all domains in the search path, before ipv4 queries are attempted. That seems (is) really inefficient. As a result of ipv6 supports, DNS queries have tripled on systems with two domains in their search path. Okay, perhaps this isn't a bug. It's just ipv6 hell. I guess the answer to this problem for you is to just disable ipv6 (unless you need it) - blacklisting the kernel module(s) ought to do it, although there may be some other parts I am unaware of. HTH, and take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
Stephen Gran wrote: At Thu, 15 Dec 2005 17:13:25 -0800, Edward Buck wrote: I guess the problem then is in the ipv6 support and how it implements domains in the search path. Instead of doing ipv6, then ipv4 for mx1.hotmail.com, it runs through all possible ipv6 queries, including exhausting all domains in the search path, before ipv4 queries are attempted. That seems (is) really inefficient. As a result of ipv6 supports, DNS queries have tripled on systems with two domains in their search path. Okay, perhaps this isn't a bug. It's just ipv6 hell. I guess the answer to this problem for you is to just disable ipv6 (unless you need it) - blacklisting the kernel module(s) ought to do it, although there may be some other parts I am unaware of. I did try commenting out: #alias net-pf-10 ipv6 in /etc/modprobe.d/aliases. Unfortunately, that doesn't keep the resolver from doing ipv6 queries. The behavior is the same regardless of whether the ipv6 kernel module is loaded (rebooted after the change and lsmod shows no ipv6 module). Is there another way to disable ipv6 queries by the resolver? I'm probably missing something simple but couldn't find anything in the docs. Thanks. Regards, Ed HTH, and take care, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
On Wed, Dec 14, 2005 at 11:41:38AM -0800, Edward Buck wrote: If it's a frequently used feature, it wasn't available until sarge. Woody did not behave this way (I checked). Huh? $ cat /etc/debian_version 3.0 $ cat /etc/resolv.conf search hpcc.sztaki.hu lpds.sztaki.hu sztaki.hu nameserver 127.0.0.1 $ ping rs2.lvs PING rs2.lvs.sztaki.hu (193.6.200.132): 56 data bytes ... It is definitely available in Woody. I'm using it regularly. Also, this new feature completely breaks software that doesn't expect this feature, since postfix, telnet and others are doing WAY more DNS queries than they should. Depending on how many search domains are listed and how many caching nameservers are listed, in my case (2 search domains and 2 nameservers) I count at least 4 unnecessary queries. That's very bad. Well, why do you have any search domains then? It is for human convenience only, and a mail server usually does not have regular user accounts so no need for such convenience features. Sure, I can do that with telnet interactively. How do I tell postfix to do that without a patch? I guess I could try setting the ndots option to postfix's environment but that seems like a bad hack. The current behavior makes using the search lines impossible for busy servers, especially mail servers that do DNS queries for every piece of mail. Just imagine the excess DNS load on a server processing a million e-mail messages a day. That's what I'm seeing. For such setups I suggest running some local DNS-catching solution (nscd or a local caching-only name server). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
Hi Gabor, Gabor Gombas wrote: On Wed, Dec 14, 2005 at 11:41:38AM -0800, Edward Buck wrote: If it's a frequently used feature, it wasn't available until sarge. Woody did not behave this way (I checked). Huh? $ cat /etc/debian_version 3.0 $ cat /etc/resolv.conf search hpcc.sztaki.hu lpds.sztaki.hu sztaki.hu nameserver 127.0.0.1 $ ping rs2.lvs PING rs2.lvs.sztaki.hu (193.6.200.132): 56 data bytes ... It is definitely available in Woody. I'm using it regularly. Your test does not say much regarding this bug because it's not a question of whether the search domains are checked eventually. It's a question of the order in which queries are done. When you ping 'rs2.lvs', the order of queries (according to the documentation) is that rs2.lvs is checked as rs2.lvs. (note the ending dot) FIRST because it does not contain fewer than ndots dots (default is 1). If it cannot be found in DNS, then the search domains are checked. Your test merely confirms that at some point, the search domains are checked. The bug I'm reporting here is that rs2.lvs is NOT checked as rs2.lvs(.) first but rather as rs2.lvs.search.domains first. The order is important and is the cause of the extraneous lookups. In any case, I can't speak to 'ping' functionality as I never tested that. I tested only telnet and postfix. And the bug only matters in the context of postfix. If you do a 'strace telnet mx1.hotmail.com 25' on a woody machine, you'll see that it works according to the documentation. Sarge does not. I can forward you more strace output if it will help. Maybe all my woody machines are weird. I don't know. But as I said, this functionality is new with sarge. Also, this new feature completely breaks software that doesn't expect this feature, since postfix, telnet and others are doing WAY more DNS queries than they should. Depending on how many search domains are listed and how many caching nameservers are listed, in my case (2 search domains and 2 nameservers) I count at least 4 unnecessary queries. That's very bad. Well, why do you have any search domains then? It is for human convenience only, and a mail server usually does not have regular user accounts so no need for such convenience features. You're right. It is for user convenience sake and I've temporarily removed the search lines on these machines. But the convenience will still be missed by those who administer these machines. Even a busy mail server with few shell accounts need regular logins from sysadmins for maintenance work. The problem here is that regardless of whether the feature is needed or not, it used to work as documented. Now it does not. And those who have come to depend on that documentation and previous behavior have to deal with process changes (and code changes!) that they did not expect, not to mention significant changes to system load on affected machines. If this functionality is intentional (as you seem to imply), then please update the documentation to reflect that. The 'search' section of the man page for resolv.conf is very explicit on this subject. If I'm reading it incorrectly, please let me know how I am. Regards, Ed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
This one time, at band camp, Edward Buck said: If you do a 'strace telnet mx1.hotmail.com 25' on a woody machine, you'll see that it works according to the documentation. Sarge does not. I can forward you more strace output if it will help. Maybe all my woody machines are weird. I don't know. But as I said, this functionality is new with sarge. I took the easy way out, and turned on query logging in my local caching nameserver (since that also helps to see exactly what the load is on the nameserver, the point of this bug, really). This is what I see: Dec 16 00:07:27 hadrian named[17102]: client 127.0.0.1#41145: query: mx1.hotmail.com IN Dec 16 00:07:27 hadrian named[17102]: client 127.0.0.1#41145: query: mx1.hotmail.com.lobefin.net IN Dec 16 00:07:27 hadrian named[17102]: client 127.0.0.1#41145: query: mx1.hotmail.com IN A [ followed by normal PTR lookups for the records returned ] Which is exactly what it should be. This is a sarge system. Maybe you didn't notice that the extra lookups were IPv6? IIRC woody didn't have a working IPv6 stack out of the box, so this would explain the behavior you're seeing. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
Hi Stephen, Stephen Gran wrote: This one time, at band camp, Edward Buck said: If you do a 'strace telnet mx1.hotmail.com 25' on a woody machine, you'll see that it works according to the documentation. Sarge does not. I can forward you more strace output if it will help. Maybe all my woody machines are weird. I don't know. But as I said, this functionality is new with sarge. I took the easy way out, and turned on query logging in my local caching nameserver (since that also helps to see exactly what the load is on the nameserver, the point of this bug, really). This is what I see: Yes, you are correct in that this bug is all about DNS load (especially extraneous load). Dec 16 00:07:27 hadrian named[17102]: client 127.0.0.1#41145: query: mx1.hotmail.com IN Dec 16 00:07:27 hadrian named[17102]: client 127.0.0.1#41145: query: mx1.hotmail.com.lobefin.net IN Dec 16 00:07:27 hadrian named[17102]: client 127.0.0.1#41145: query: mx1.hotmail.com IN A [ followed by normal PTR lookups for the records returned ] Which is exactly what it should be. This is a sarge system. I just did the same test and got similar results. With two domains in the search path: Dec 15 16:37:53 potato named[914]: client 192.168.0.40#43823: query: mx1.hotmail.com IN Dec 15 16:37:53 potato named[914]: client 192.168.0.40#43823: query: mx1.hotmail.com.hn.aspextra.net IN Dec 15 16:37:53 potato named[914]: client 192.168.0.40#43823: query: mx1.hotmail.com.bashware.net IN Dec 15 16:37:53 potato named[914]: client 192.168.0.40#43825: query: mx1.hotmail.com IN A I guess the problem then is in the ipv6 support and how it implements domains in the search path. Instead of doing ipv6, then ipv4 for mx1.hotmail.com, it runs through all possible ipv6 queries, including exhausting all domains in the search path, before ipv4 queries are attempted. That seems (is) really inefficient. As a result of ipv6 supports, DNS queries have tripled on systems with two domains in their search path. Okay, perhaps this isn't a bug. It's just ipv6 hell. Thanks for your help. Regards, Ed Maybe you didn't notice that the extra lookups were IPv6? IIRC woody didn't have a working IPv6 stack out of the box, so this would explain the behavior you're seeing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
On Mon, Dec 12, 2005 at 09:13:13PM -0800, Edward Buck wrote: In a nutshell, when using 'search' lines in /etc/resolv.conf, the resolver always appends listed search domains to a hostname lookup even when the host being searched is fully-qualified (contains one or more dots). No, a host name containing a dot is _not_ a FQDN. A host name _ending_ with a dot is a FQDN. Using host.subdomain while search is set to some.domain to access host.subdomain.some.domain is a common and frequently used feature. This results in a LOT of needless DNS traffic. On a busy mail server, it makes using the 'search' lines extremely expensive (because DNS traffic increases exponentially). Here's an strace of 'telnet mx1.hotmail.com 25'. Oddly, it seems to do the right thing initially but the fully-qualified lookup must always fail, resulting in subsequent lookups using the search list. Then use a _real_ FQDN and try 'telnet mx1.hotmail.com. 25' (note the terminating dot). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
Hi Gabor, Gabor Gombas wrote: On Mon, Dec 12, 2005 at 09:13:13PM -0800, Edward Buck wrote: In a nutshell, when using 'search' lines in /etc/resolv.conf, the resolver always appends listed search domains to a hostname lookup even when the host being searched is fully-qualified (contains one or more dots). No, a host name containing a dot is _not_ a FQDN. A host name _ending_ with a dot is a FQDN. It's fully qualified in the sense that it contains one or more dots, which according to the documentation determines whether the search list is referenced. $ man resolv.conf ... search Search list for host-name lookup. The search list is normally determined from the local domain name; by default, it contains only the local domain name. This may be changed by listing the desired domain search path follow- ing the search keyword with spaces or tabs separating the names. Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found. For environments with multiple subdomains please read options ndots:n below to avoid man-in- the-middle attacks and unnecessary traffic for the root-dns- servers. Note that this process may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is avail- able for one of the domains. ... Using host.subdomain while search is set to some.domain to access host.subdomain.some.domain is a common and frequently used feature. If it's a frequently used feature, it wasn't available until sarge. Woody did not behave this way (I checked). Also, this new feature completely breaks software that doesn't expect this feature, since postfix, telnet and others are doing WAY more DNS queries than they should. Depending on how many search domains are listed and how many caching nameservers are listed, in my case (2 search domains and 2 nameservers) I count at least 4 unnecessary queries. That's very bad. As far as the feature you reference, one should be able to change the 'ndots' option in resolv.conf to get the behavior you want. At the moment, this new behavior is breaking postfix and other software. This results in a LOT of needless DNS traffic. On a busy mail server, it makes using the 'search' lines extremely expensive (because DNS traffic increases exponentially). Here's an strace of 'telnet mx1.hotmail.com 25'. Oddly, it seems to do the right thing initially but the fully-qualified lookup must always fail, resulting in subsequent lookups using the search list. Then use a _real_ FQDN and try 'telnet mx1.hotmail.com. 25' (note the terminating dot). Sure, I can do that with telnet interactively. How do I tell postfix to do that without a patch? I guess I could try setting the ndots option to postfix's environment but that seems like a bad hack. The current behavior makes using the search lines impossible for busy servers, especially mail servers that do DNS queries for every piece of mail. Just imagine the excess DNS load on a server processing a million e-mail messages a day. That's what I'm seeing. Thanks for your help. Regards, Ed Gabor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343140: libc6: resolver always checks search list in /etc/resolv.conf
Package: libc6
Version: 2.3.2.ds1-22
Severity: important
I originally posted a bug report for postfix detailing the problem but I
can reproduce the bug outside of postfix. Here's the postfix bug
report in case you're interested:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314891
In a nutshell, when using 'search' lines in /etc/resolv.conf, the
resolver always appends listed search domains to a hostname lookup even
when the host being searched is fully-qualified (contains one or more dots).
This results in a LOT of needless DNS traffic. On a busy mail server,
it makes using the 'search' lines extremely expensive (because DNS traffic
increases exponentially).
Here's an strace of 'telnet mx1.hotmail.com 25'. Oddly, it seems to do
the right thing initially but the fully-qualified lookup must always
fail, resulting in subsequent lookups using the search list.
$ cat /etc/resolv.conf
nameserver 69.51.81.36
nameserver 69.51.78.68
search ul.aspextra.net aspextra.net
$ strace telnet mx1.hotmail.com 25
...
open(/etc/resolv.conf, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=274, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40018000
read(3, # Dynamic resolv.conf(5) file fo..., 4096) = 274
read(3, , 4096) = 0
close(3)= 0
munmap(0x40018000, 4096)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.81.36)}, 28) = 0
send(3, \n\177\1\0\0\1\0\0\0\0\0\0\3mx1\7hotmail\3com\0\0\34\0..., 33, 0) = 33
gettimeofday({1134449292, 353764}, NULL) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(3, FIONREAD, [98])= 0
recvfrom(3, \n\177\201\200\0\1\0\0\0\1\0\0\3mx1\7hotmail\3com\0\0\34...,
1024, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.81.36)}, [16]) = 98
close(3)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.81.36)}, 28) = 0
send(3, \n\200\1\0\0\1\0\0\0\0\0\0\3mx1\7hotmail\3com\2ul\10..., 49, 0) = 49
gettimeofday({1134449292, 357407}, NULL) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(3, FIONREAD, [49])= 0
recvfrom(3, \n\200\201\205\0\1\0\0\0\0\0\0\3mx1\7hotmail\3com\2ul\10...,
1024, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.81.36)}, [16]) = 49
close(3)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.78.68)}, 28) = 0
send(3, \n\200\1\0\0\1\0\0\0\0\0\0\3mx1\7hotmail\3com\2ul\10..., 49, 0) = 49
gettimeofday({1134449292, 361191}, NULL) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 3000) = 1
ioctl(3, FIONREAD, [100]) = 0
recvfrom(3, \n\200\201\203\0\1\0\0\0\1\0\0\3mx1\7hotmail\3com\2ul\10...,
1024, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.78.68)}, [16]) = 100
close(3)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.81.36)}, 28) = 0
send(3, \n\201\1\0\0\1\0\0\0\0\0\0\3mx1\7hotmail\3com\10asp..., 46, 0) = 46
gettimeofday({1134449292, 364427}, NULL) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(3, FIONREAD, [97])= 0
recvfrom(3, \n\201\201\203\0\1\0\0\0\1\0\0\3mx1\7hotmail\3com\10as..., 1024,
0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr(69.51.81.36)},
[16]) = 97
close(3)= 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(69.51.81.36)}, 28) = 0
send(3, \n\202\1\0\0\1\0\0\0\0\0\0\3mx1\7hotmail\3com\0\0\1\0..., 33, 0) = 33
gettimeofday({1134449292, 367710}, NULL) = 0
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1
ioctl(3, FIONREAD, [195]) = 0
recvfrom(3, \n\202\201\200\0\1\0\4\0\5\0\0\3mx1\7hotmail\3com\0\0\1..., 1024,
0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr(69.51.81.36)},
[16]) = 195
close(3)= 0
socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, path=/var/run/.nscd_socket}, 110) = -1 ENOENT
(No such file or directory)
close(3)= 0
gettimeofday({1134449292, 371589}, NULL) = 0
getpid()= 15269
open(/etc/resolv.conf, O_RDONLY) = 3
...
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages libc6 depends on:
ii libdb1-compat 2.1.3-7The Berkeley database routines [gl
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
