* Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work
@ 2017-03-15 10:28 dominic.chambers
2017-03-15 12:25 ` Rich Felker
0 siblings, 1 reply; 8+ messages in thread
From: dominic.chambers @ 2017-03-15 10:28 UTC (permalink / raw)
To: musl
As you can see from the comments starting here:
https://github.com/gliderlabs/docker-alpine/issues/8#issuecomment-223901519
quite a number of people are finding that the `search` and `domain` support added to musl libc doesn't work in their case. In that same issue I wrote my findings up, here:
https://github.com/gliderlabs/docker-alpine/issues/8#issuecomment-286561614
which I'll duplicate here so that's it's archived on the mailing list:
[MESSAGE]
Even based on its own documentation this would appear to be a bug in musl libc:
[QUOTE]
musl's resolver previously did not support the "domain" and "search" keywords in resolv.conf. This feature was added in version 1.1.13, but its behavior differs slightly from glibc's: queries with fewer dots than the `ndots` configuration variable are processed with search first then tried literally (just like glibc), but those with at least as many dots as `ndots` are only tried in the global namespace (never falling back to search, which glibc would do if the name is not found in the global DNS namespace). This difference comes from a consistency requirement not to return different results subject to transient failures or to global DNS namespace changes outside of one's control (addition of new TLDs).
[/QUOTE]
While I can confirm the second part (queries greater than `ndots` never fall-back to using search), the first part (queries smaller than `ndots` fall-back to using an absolute query) isn't what I observe.
Using dig on an Ubuntu container and attempting to resolve the nonsensical query `google.com.default.svc.cluster.local` (simulates the type of initial query for a short domain that would be occurring) returns a `QUESTION SECTION` and an `AUTHORITY SECTION`, but no `ANSWER SECTION`. This should cause musl libc to attempt to resolve the absolute query (`google.com`) instead, yet it doesn't seem to based on the final result of the query.
Here's the (tiny) commit where support for search and domain was added to musl libc, and here's the `name_from_dns` function that that diff relies on. I think this `dns_parse_callback` function maybe the thing that determines whether we consider we've received a result or not, yet the code indicates this would only occur if we receive either an `A`, `AAAA` or `CNAME` record, yet in our case there's no `ANSWER SECTION` whatsoever.
[/MESSAGE]
I'd really like to help debug this one if at all possible, and would appreciate any pointers as to how best to go about doing that?
Thanks, Dominic.
LEGAL DISCLAIMER. The contents of this electronic communication
and any attached documents are strictly confidential and they may not
be used or disclosed by someone who is not a named recipient.
If you have received this electronic communication in error please notify
the sender by replying to this electronic communication inserting the
word "misdirected" as the subject and delete this communication from
your system.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work
2017-03-15 10:28 Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work dominic.chambers
@ 2017-03-15 12:25 ` Rich Felker
2017-03-15 12:58 ` dominic.chambers
0 siblings, 1 reply; 8+ messages in thread
From: Rich Felker @ 2017-03-15 12:25 UTC (permalink / raw)
To: musl
On Wed, Mar 15, 2017 at 10:28:15AM +0000, dominic.chambers@glencore.com wrote:
> As you can see from the comments starting here:
>
> https://github.com/gliderlabs/docker-alpine/issues/8#issuecomment-223901519
>
> quite a number of people are finding that the `search` and `domain` support added to musl libc doesn't work in their case. In that same issue I wrote my findings up, here:
>
> https://github.com/gliderlabs/docker-alpine/issues/8#issuecomment-286561614
>
> which I'll duplicate here so that's it's archived on the mailing list:
>
> [...]
>
> While I can confirm the second part (queries greater
> than `ndots` never fall-back to using search), the first part
> (queries smaller than `ndots` fall-back to using an absolute query)
> isn't what I observe.
>
> Using dig on an Ubuntu container and attempting to resolve the
> nonsensical query `google.com.default.svc.cluster.local` (simulates
> the type of initial query for a short domain that would be
> occurring) returns a `QUESTION SECTION` and an `AUTHORITY SECTION`,
> but no `ANSWER SECTION`. This should cause musl libc to attempt to
> resolve the absolute query (`google.com`) instead, yet it doesn't
> seem to based on the final result of the query.
This is where your problem lies. A response with an empty answer
section is an affirmative answer that the requested name exists but
has no records of the requested type (A or AAAA). In this case the
answer must be accepted; otherwise results are inconsistent depending
on how the query is performed. See the previous discussion of the same
topic here: http://www.openwall.com/lists/musl/2017/01/19/4
and commit 0fef7ffac114befc94ab5fa794a1754442dcd531.
To fix the problem, whatever local nameserver is returning affirmative
no-A-record results for nonexistent domains needs to be fixed to
return NxDomain.
Rich
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work
2017-03-15 12:25 ` Rich Felker
@ 2017-03-15 12:58 ` dominic.chambers
2017-03-15 15:11 ` Rich Felker
0 siblings, 1 reply; 8+ messages in thread
From: dominic.chambers @ 2017-03-15 12:58 UTC (permalink / raw)
To: musl
HI Rich,
Thanks for the prompt response here. Apologies for any confusion I may have created, but I think the server is responding with an overall `NXDOMAIN` response. This is what I get from running `dig google.com.default.svc.cluster.local`:
```
; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com.default.svc.cluster.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20863
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com.default.svc.cluster.local. IN A
;; AUTHORITY SECTION:
cluster.local. 60 IN SOA ns.dns.cluster.local. hostmaster
.cluster.local. 1489579200 28800 7200 604800 60
;; Query time: 0 msec
;; SERVER: 10.43.0.10#53(10.43.0.10)
;; WHEN: Wed Mar 15 12:49:14 UTC 2017
;; MSG SIZE rcvd: 147
```
Although there's less information with nslookup, the response from running `nslookup google.com.default.svc.cluster.local` seems even more definitive:
```
Server: 10.43.0.10
Address: 10.43.0.10#53
** server can't find google.com.default.svc.cluster.local: NXDOMAIN
```
Maybe I was just reading too much into the output from dig regarding exactly what was being returned from the server. Any further thoughts?
Thanks again, Dominic.
-----Original Message-----
From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
Sent: 15 March 2017 13:25
To: musl@lists.openwall.com
Subject: Re: [musl] Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work
On Wed, Mar 15, 2017 at 10:28:15AM +0000, dominic.chambers@glencore.com wrote:
> As you can see from the comments starting here:
>
>
> https://github.com/gliderlabs/docker-alpine/issues/8#issuecomment-2239
> 01519
>
> quite a number of people are finding that the `search` and `domain` support added to musl libc doesn't work in their case. In that same issue I wrote my findings up, here:
>
>
> https://github.com/gliderlabs/docker-alpine/issues/8#issuecomment-2865
> 61614
>
> which I'll duplicate here so that's it's archived on the mailing list:
>
> [...]
>
> While I can confirm the second part (queries greater than `ndots`
> never fall-back to using search), the first part (queries smaller than
> `ndots` fall-back to using an absolute query) isn't what I observe.
>
> Using dig on an Ubuntu container and attempting to resolve the
> nonsensical query `google.com.default.svc.cluster.local` (simulates
> the type of initial query for a short domain that would be
> occurring) returns a `QUESTION SECTION` and an `AUTHORITY SECTION`,
> but no `ANSWER SECTION`. This should cause musl libc to attempt to
> resolve the absolute query (`google.com`) instead, yet it doesn't seem
> to based on the final result of the query.
This is where your problem lies. A response with an empty answer section is an affirmative answer that the requested name exists but has no records of the requested type (A or AAAA). In this case the answer must be accepted; otherwise results are inconsistent depending on how the query is performed. See the previous discussion of the same topic here: http://www.openwall.com/lists/musl/2017/01/19/4
and commit 0fef7ffac114befc94ab5fa794a1754442dcd531.
To fix the problem, whatever local nameserver is returning affirmative no-A-record results for nonexistent domains needs to be fixed to return NxDomain.
Rich
LEGAL DISCLAIMER. The contents of this electronic communication
and any attached documents are strictly confidential and they may not
be used or disclosed by someone who is not a named recipient.
If you have received this electronic communication in error please notify
the sender by replying to this electronic communication inserting the
word "misdirected" as the subject and delete this communication from
your system.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work
2017-03-15 12:58 ` dominic.chambers
@ 2017-03-15 15:11 ` Rich Felker
2017-03-15 16:58 ` dominic.chambers
2017-03-15 17:10 ` dominic.chambers
0 siblings, 2 replies; 8+ messages in thread
From: Rich Felker @ 2017-03-15 15:11 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]
On Wed, Mar 15, 2017 at 12:58:02PM +0000, dominic.chambers@glencore.com wrote:
> HI Rich,
>
> Thanks for the prompt response here. Apologies for any confusion I
> may have created, but I think the server is responding with an
> overall `NXDOMAIN` response. This is what I get from running `dig
> google.com.default.svc.cluster.local`:
>
> ```
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com.default.svc.cluster.local
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20863
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;google.com.default.svc.cluster.local. IN A
>
> ;; AUTHORITY SECTION:
> cluster.local. 60 IN SOA ns.dns.cluster.local. hostmaster
> .cluster.local. 1489579200 28800 7200 604800 60
>
> ;; Query time: 0 msec
> ;; SERVER: 10.43.0.10#53(10.43.0.10)
> ;; WHEN: Wed Mar 15 12:49:14 UTC 2017
> ;; MSG SIZE rcvd: 147
> ```
>
> Although there's less information with nslookup, the response from
> running `nslookup google.com.default.svc.cluster.local` seems even
> more definitive:
>
> ```
> Server: 10.43.0.10
> Address: 10.43.0.10#53
>
> ** server can't find google.com.default.svc.cluster.local: NXDOMAIN
> ```
>
> Maybe I was just reading too much into the output from dig regarding
> exactly what was being returned from the server. Any further
> thoughts?
Can you send an strace log of an affected lookup with musl's resolver
(rather than dig/nslookup which use bind's resolver) for me to look
at? Attached is source for a trivial sample utility to perform a
lookup.
Rich
[-- Attachment #2: gai3a.c --]
[-- Type: text/plain, Size: 785 bytes --]
#include <stdio.h>
#include <netdb.h>
#include <netinet/in.h>
int main(int argc, char **argv)
{
int r;
char buf[256], buf2[32];
struct addrinfo *ai, hints = { .ai_protocol = IPPROTO_TCP, .ai_flags = 0, .ai_family = AF_UNSPEC };
char *name = argc>1 ? argv[1][0] ? argv[1] : 0 : 0;
char *serv = argc>2 ? argv[2] : 0;
r = getaddrinfo(name, serv, &hints, &ai);
if (r<0)
printf("%s: %s\n", name, gai_strerror(r));
else for (; ai; ai = ai->ai_next)
if (!getnameinfo(ai->ai_addr,
ai->ai_addrlen, buf, sizeof buf,
buf2, sizeof buf2, NI_NUMERICHOST|NI_NUMERICSERV))
printf("%s: %s %s %s %s %s\n", name?name:"NULL",
ai->ai_canonname, buf, buf2,
ai->ai_protocol == IPPROTO_TCP ? "tcp" : "udp",
ai->ai_socktype == SOCK_STREAM ? "stream" : "dgram");
return 0;
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work
2017-03-15 15:11 ` Rich Felker
@ 2017-03-15 16:58 ` dominic.chambers
2017-03-15 17:10 ` dominic.chambers
1 sibling, 0 replies; 8+ messages in thread
From: dominic.chambers @ 2017-03-15 16:58 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]
HI Rich,
I've attached the results from running the following two commands:
1. ` strace ./gai3a google.com 2> strace_of_google-com`
2. ` strace ./gai3a google.com.default.svc 2> strace_of_google-com-default-svc`
Is this what you were looking for or can I provide something more useful?
Thanks again, Dominic.
-----Original Message-----
From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
Sent: 15 March 2017 16:11
To: musl@lists.openwall.com
Subject: Re: [musl] Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work
On Wed, Mar 15, 2017 at 12:58:02PM +0000, dominic.chambers@glencore.com wrote:
> HI Rich,
>
> Thanks for the prompt response here. Apologies for any confusion I may
> have created, but I think the server is responding with an overall
> `NXDOMAIN` response. This is what I get from running `dig
> google.com.default.svc.cluster.local`:
>
> ```
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com.default.svc.cluster.local
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20863 ;; flags:
> qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;google.com.default.svc.cluster.local. IN A
>
> ;; AUTHORITY SECTION:
> cluster.local. 60 IN SOA ns.dns.cluster.local. hostmaster
> .cluster.local. 1489579200 28800 7200 604800 60
>
> ;; Query time: 0 msec
> ;; SERVER: 10.43.0.10#53(10.43.0.10)
> ;; WHEN: Wed Mar 15 12:49:14 UTC 2017
> ;; MSG SIZE rcvd: 147
> ```
>
> Although there's less information with nslookup, the response from
> running `nslookup google.com.default.svc.cluster.local` seems even
> more definitive:
>
> ```
> Server: 10.43.0.10
> Address: 10.43.0.10#53
>
> ** server can't find google.com.default.svc.cluster.local: NXDOMAIN
> ```
>
> Maybe I was just reading too much into the output from dig regarding
> exactly what was being returned from the server. Any further thoughts?
Can you send an strace log of an affected lookup with musl's resolver (rather than dig/nslookup which use bind's resolver) for me to look at? Attached is source for a trivial sample utility to perform a lookup.
Rich
LEGAL DISCLAIMER. The contents of this electronic communication
and any attached documents are strictly confidential and they may not
be used or disclosed by someone who is not a named recipient.
If you have received this electronic communication in error please notify
the sender by replying to this electronic communication inserting the
word "misdirected" as the subject and delete this communication from
your system.
[-- Attachment #2: strace_of_google-com --]
[-- Type: application/octet-stream, Size: 5095 bytes --]
execve("./gai3a", ["./gai3a", "google.com"], [/* 15 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7f98bb5b2b48) = 0
set_tid_address(0x7f98bb5b2b80) = 44
mprotect(0x7f98bb5af000, 4096, PROT_READ) = 0
mprotect(0x5591835ef000, 4096, PROT_READ) = 0
open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
readv(3, [{iov_base="", iov_len=0}, {iov_base="# Kubernetes-managed hosts file."..., iov_len=1024}], 2) = 202
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=1024}], 2) = 0
close(3) = 0
open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
readv(3, [{iov_base="", iov_len=0}, {iov_base="search default.svc.cluster.local"..., iov_len=248}], 2) = 218
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=248}], 2) = 0
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "\271\377\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 54, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 54
sendto(3, "\341\262\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 54, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 54
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\271\377\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 147
recvfrom(3, "\341\262\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 147
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "\376\300\1\0\0\1\0\0\0\0\0\0\6google\3com\3svc\7clus"..., 46, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 46
sendto(3, "\2.\1\0\0\1\0\0\0\0\0\0\6google\3com\3svc\7clus"..., 46, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 46
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\376\300\201\203\0\1\0\0\0\1\0\0\6google\3com\3svc\7clus"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 139
recvfrom(3, "\2.\201\203\0\1\0\0\0\1\0\0\6google\3com\3svc\7clus"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 139
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "\7\340\1\0\0\1\0\0\0\0\0\0\6google\3com\7cluster\5"..., 42, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 42
sendto(3, "\n\346\1\0\0\1\0\0\0\0\0\0\6google\3com\7cluster\5"..., 42, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 42
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\7\340\201\203\0\1\0\0\0\1\0\0\6google\3com\7cluster\5"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 135
recvfrom(3, "\n\346\201\203\0\1\0\0\0\1\0\0\6google\3com\7cluster\5"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 135
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "H\244\1\0\0\1\0\0\0\0\0\0\6google\3com\7kubelet\n"..., 64, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 64
sendto(3, "K\266\1\0\0\1\0\0\0\0\0\0\6google\3com\7kubelet\n"..., 64, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 64
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "H\244\205\200\0\1\0\0\0\1\0\0\6google\3com\7kubelet\n"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 100
recvfrom(3, 0x7fff9c3f83c0, 512, 0, 0x7fff9c3f7e70, [16]) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}], 1, 2498) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "K\266\205\200\0\1\0\0\0\1\0\0\6google\3com\7kubelet\n"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 100
close(3) = 0
ioctl(1, TIOCGWINSZ, {ws_row=0, ws_col=0, ws_xpixel=0, ws_ypixel=0}) = 0
writev(1, [{iov_base="google.com: Name does not resolv"..., iov_len=33}, {iov_base="\n", iov_len=1}], 2) = 34
exit_group(0) = ?
+++ exited with 0 +++
[-- Attachment #3: strace_of_google-com-default-svc --]
[-- Type: application/octet-stream, Size: 5081 bytes --]
execve("./gai3a", ["./gai3a", "google.com.default.svc"], [/* 15 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7f0198178b48) = 0
set_tid_address(0x7f0198178b80) = 48
mprotect(0x7f0198175000, 4096, PROT_READ) = 0
mprotect(0x55a2dfb68000, 4096, PROT_READ) = 0
open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
readv(3, [{iov_base="", iov_len=0}, {iov_base="# Kubernetes-managed hosts file."..., iov_len=1024}], 2) = 202
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=1024}], 2) = 0
close(3) = 0
open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
readv(3, [{iov_base="", iov_len=0}, {iov_base="search default.svc.cluster.local"..., iov_len=248}], 2) = 218
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=248}], 2) = 0
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "\4\24\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 66, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 66
sendto(3, "\tI\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 66, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 66
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\4\24\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 159
recvfrom(3, "\tI\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 159
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "0f\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 58, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 58
sendto(3, "3\310\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 58, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 58
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "0f\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 151
recvfrom(3, "3\310\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 151
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "m\25\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 54, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 54
sendto(3, "pc\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 54, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 54
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "m\25\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 147
recvfrom(3, "pc\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 147
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "\311\20\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 76, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 76
sendto(3, "\314\262\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 76, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 76
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\311\20\205\200\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 112
recvfrom(3, 0x7ffd858042e0, 512, 0, 0x7ffd85803d90, [16]) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}], 1, 2498) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\314\262\205\200\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 112
close(3) = 0
ioctl(1, TIOCGWINSZ, {ws_row=0, ws_col=0, ws_xpixel=0, ws_ypixel=0}) = 0
writev(1, [{iov_base="google.com.default.svc: Name doe"..., iov_len=45}, {iov_base="\n", iov_len=1}], 2) = 46
exit_group(0) = ?
+++ exited with 0 +++
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work
2017-03-15 15:11 ` Rich Felker
2017-03-15 16:58 ` dominic.chambers
@ 2017-03-15 17:10 ` dominic.chambers
2017-03-15 17:22 ` Rich Felker
1 sibling, 1 reply; 8+ messages in thread
From: dominic.chambers @ 2017-03-15 17:10 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 2754 bytes --]
HI Rich,
I've attached the results from running the following two commands:
1. ` strace ./gai3a google.com 2> strace_of_google-com.txt`
2. ` strace ./gai3a google.com.default.svc 2> strace_of_google-com-default-svc.txt`
Is this what you were looking for or can I provide something more useful?
Thanks again, Dominic.
-----Original Message-----
From: Rich Felker [mailto:dalias@aerifal.cx] On Behalf Of Rich Felker
Sent: 15 March 2017 16:11
To: musl@lists.openwall.com
Subject: Re: [musl] Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work
On Wed, Mar 15, 2017 at 12:58:02PM +0000, dominic.chambers@glencore.com wrote:
> HI Rich,
>
> Thanks for the prompt response here. Apologies for any confusion I may
> have created, but I think the server is responding with an overall
> `NXDOMAIN` response. This is what I get from running `dig
> google.com.default.svc.cluster.local`:
>
> ```
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com.default.svc.cluster.local
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20863 ;; flags:
> qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;google.com.default.svc.cluster.local. IN A
>
> ;; AUTHORITY SECTION:
> cluster.local. 60 IN SOA ns.dns.cluster.local. hostmaster
> .cluster.local. 1489579200 28800 7200 604800 60
>
> ;; Query time: 0 msec
> ;; SERVER: 10.43.0.10#53(10.43.0.10)
> ;; WHEN: Wed Mar 15 12:49:14 UTC 2017
> ;; MSG SIZE rcvd: 147
> ```
>
> Although there's less information with nslookup, the response from
> running `nslookup google.com.default.svc.cluster.local` seems even
> more definitive:
>
> ```
> Server: 10.43.0.10
> Address: 10.43.0.10#53
>
> ** server can't find google.com.default.svc.cluster.local: NXDOMAIN
> ```
>
> Maybe I was just reading too much into the output from dig regarding
> exactly what was being returned from the server. Any further thoughts?
Can you send an strace log of an affected lookup with musl's resolver (rather than dig/nslookup which use bind's resolver) for me to look at? Attached is source for a trivial sample utility to perform a lookup.
Rich
LEGAL DISCLAIMER. The contents of this electronic communication
and any attached documents are strictly confidential and they may not
be used or disclosed by someone who is not a named recipient.
If you have received this electronic communication in error please notify
the sender by replying to this electronic communication inserting the
word "misdirected" as the subject and delete this communication from
your system.
[-- Attachment #2: strace_of_google-com.txt --]
[-- Type: text/plain, Size: 5095 bytes --]
execve("./gai3a", ["./gai3a", "google.com"], [/* 15 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7f98bb5b2b48) = 0
set_tid_address(0x7f98bb5b2b80) = 44
mprotect(0x7f98bb5af000, 4096, PROT_READ) = 0
mprotect(0x5591835ef000, 4096, PROT_READ) = 0
open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
readv(3, [{iov_base="", iov_len=0}, {iov_base="# Kubernetes-managed hosts file."..., iov_len=1024}], 2) = 202
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=1024}], 2) = 0
close(3) = 0
open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
readv(3, [{iov_base="", iov_len=0}, {iov_base="search default.svc.cluster.local"..., iov_len=248}], 2) = 218
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=248}], 2) = 0
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "\271\377\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 54, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 54
sendto(3, "\341\262\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 54, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 54
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\271\377\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 147
recvfrom(3, "\341\262\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 147
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "\376\300\1\0\0\1\0\0\0\0\0\0\6google\3com\3svc\7clus"..., 46, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 46
sendto(3, "\2.\1\0\0\1\0\0\0\0\0\0\6google\3com\3svc\7clus"..., 46, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 46
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\376\300\201\203\0\1\0\0\0\1\0\0\6google\3com\3svc\7clus"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 139
recvfrom(3, "\2.\201\203\0\1\0\0\0\1\0\0\6google\3com\3svc\7clus"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 139
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "\7\340\1\0\0\1\0\0\0\0\0\0\6google\3com\7cluster\5"..., 42, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 42
sendto(3, "\n\346\1\0\0\1\0\0\0\0\0\0\6google\3com\7cluster\5"..., 42, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 42
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\7\340\201\203\0\1\0\0\0\1\0\0\6google\3com\7cluster\5"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 135
recvfrom(3, "\n\346\201\203\0\1\0\0\0\1\0\0\6google\3com\7cluster\5"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 135
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "H\244\1\0\0\1\0\0\0\0\0\0\6google\3com\7kubelet\n"..., 64, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 64
sendto(3, "K\266\1\0\0\1\0\0\0\0\0\0\6google\3com\7kubelet\n"..., 64, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 64
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "H\244\205\200\0\1\0\0\0\1\0\0\6google\3com\7kubelet\n"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 100
recvfrom(3, 0x7fff9c3f83c0, 512, 0, 0x7fff9c3f7e70, [16]) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}], 1, 2498) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "K\266\205\200\0\1\0\0\0\1\0\0\6google\3com\7kubelet\n"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 100
close(3) = 0
ioctl(1, TIOCGWINSZ, {ws_row=0, ws_col=0, ws_xpixel=0, ws_ypixel=0}) = 0
writev(1, [{iov_base="google.com: Name does not resolv"..., iov_len=33}, {iov_base="\n", iov_len=1}], 2) = 34
exit_group(0) = ?
+++ exited with 0 +++
[-- Attachment #3: strace_of_google-com-default-svc.txt --]
[-- Type: text/plain, Size: 5081 bytes --]
execve("./gai3a", ["./gai3a", "google.com.default.svc"], [/* 15 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7f0198178b48) = 0
set_tid_address(0x7f0198178b80) = 48
mprotect(0x7f0198175000, 4096, PROT_READ) = 0
mprotect(0x55a2dfb68000, 4096, PROT_READ) = 0
open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
readv(3, [{iov_base="", iov_len=0}, {iov_base="# Kubernetes-managed hosts file."..., iov_len=1024}], 2) = 202
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=1024}], 2) = 0
close(3) = 0
open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
readv(3, [{iov_base="", iov_len=0}, {iov_base="search default.svc.cluster.local"..., iov_len=248}], 2) = 218
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=248}], 2) = 0
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "\4\24\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 66, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 66
sendto(3, "\tI\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 66, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 66
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\4\24\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 159
recvfrom(3, "\tI\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 159
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "0f\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 58, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 58
sendto(3, "3\310\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 58, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 58
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "0f\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 151
recvfrom(3, "3\310\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 151
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "m\25\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 54, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 54
sendto(3, "pc\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 54, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 54
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "m\25\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 147
recvfrom(3, "pc\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 147
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "\311\20\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 76, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 76
sendto(3, "\314\262\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 76, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 76
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\311\20\205\200\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 112
recvfrom(3, 0x7ffd858042e0, 512, 0, 0x7ffd85803d90, [16]) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}], 1, 2498) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\314\262\205\200\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 112
close(3) = 0
ioctl(1, TIOCGWINSZ, {ws_row=0, ws_col=0, ws_xpixel=0, ws_ypixel=0}) = 0
writev(1, [{iov_base="google.com.default.svc: Name doe"..., iov_len=45}, {iov_base="\n", iov_len=1}], 2) = 46
exit_group(0) = ?
+++ exited with 0 +++
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work
2017-03-15 17:10 ` dominic.chambers
@ 2017-03-15 17:22 ` Rich Felker
2017-03-15 19:26 ` dominic.chambers
0 siblings, 1 reply; 8+ messages in thread
From: Rich Felker @ 2017-03-15 17:22 UTC (permalink / raw)
To: musl
On Wed, Mar 15, 2017 at 05:10:08PM +0000, dominic.chambers@glencore.com wrote:
> HI Rich,
>
> I've attached the results from running the following two commands:
>
> 1. ` strace ./gai3a google.com 2> strace_of_google-com.txt`
> 2. ` strace ./gai3a google.com.default.svc 2> strace_of_google-com-default-svc.txt`
>
> Is this what you were looking for or can I provide something more useful?
Yes, this works. Here's the problem:
> execve("./gai3a", ["./gai3a", "google.com"], [/* 15 vars */]) = 0
> [...]
> socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
> bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
> sendto(3, "\271\377\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 54, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 54
> sendto(3, "\341\262\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 54, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 54
> poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "\271\377\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 147
> recvfrom(3, "\341\262\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 147
^^^^^^^
This correctly returns NxDomain (the \203 byte). But:
> [...]
> socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
> bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
> sendto(3, "H\244\1\0\0\1\0\0\0\0\0\0\6google\3com\7kubelet\n"..., 64, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 64
> sendto(3, "K\266\1\0\0\1\0\0\0\0\0\0\6google\3com\7kubelet\n"..., 64, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 64
> poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "H\244\205\200\0\1\0\0\0\1\0\0\6google\3com\7kubelet\n"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 100
> recvfrom(3, 0x7fff9c3f83c0, 512, 0, 0x7fff9c3f7e70, [16]) = -1 EAGAIN (Resource temporarily unavailable)
> poll([{fd=3, events=POLLIN}], 1, 2498) = 1 ([{fd=3, revents=POLLIN}])
> recvfrom(3, "K\266\205\200\0\1\0\0\0\1\0\0\6google\3com\7kubelet\n"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 100
^^^^^^^^
Here we see your nameserver returning a RCODE=0 (Success, the \200
byte) reply for google.com.kubelet[...] rather than NxDomain. Sorry I
don't have the full name; you need to pass a larger -s to strace to
get it not to truncate strings. You need to figure out why the
nameserver is claiming this exists; it might be some sort of wildcard
record or just a buggy nameserver (probably some component of
kubernetes).
Rich
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work
2017-03-15 17:22 ` Rich Felker
@ 2017-03-15 19:26 ` dominic.chambers
0 siblings, 0 replies; 8+ messages in thread
From: dominic.chambers @ 2017-03-15 19:26 UTC (permalink / raw)
To: musl
[-- Attachment #1: Type: text/plain, Size: 4279 bytes --]
> Yes, this works. Here's the problem:
>
> > execve("./gai3a", ["./gai3a", "google.com"], [/* 15 vars */]) = 0
> > [...] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK,
> > IPPROTO_IP) = 3 bind(3, {sa_family=AF_INET, sin_port=htons(0),
> > sin_addr=inet_addr("0.0.0.0")}, 16) = 0 sendto(3,
> > "\271\377\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 54,
> > MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53),
> > sin_addr=inet_addr("10.43.0.10")}, 16) = 54 sendto(3,
> > "\341\262\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3"..., 54,
> > MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53),
> > sin_addr=inet_addr("10.43.0.10")}, 16) = 54 poll([{fd=3,
> > events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}]) recvfrom(3,
> > "\271\377\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0,
> > {sa_family=AF_INET, sin_port=htons(53),
> > sin_addr=inet_addr("10.43.0.10")}, [16]) = 147 recvfrom(3,
> > "\341\262\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3"..., 512, 0,
> > {sa_family=AF_INET, sin_port=htons(53),
> > sin_addr=inet_addr("10.43.0.10")}, [16]) = 147
> ^^^^^^^
>
> This correctly returns NxDomain (the \203 byte). But:
>
> > [...]
> > socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
> > bind(3, {sa_family=AF_INET, sin_port=htons(0),
> > sin_addr=inet_addr("0.0.0.0")}, 16) = 0 sendto(3,
> > "H\244\1\0\0\1\0\0\0\0\0\0\6google\3com\7kubelet\n"..., 64,
> > MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53),
> > sin_addr=inet_addr("10.43.0.10")}, 16) = 64 sendto(3,
> > "K\266\1\0\0\1\0\0\0\0\0\0\6google\3com\7kubelet\n"..., 64,
> > MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53),
> > sin_addr=inet_addr("10.43.0.10")}, 16) = 64 poll([{fd=3,
> > events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}]) recvfrom(3,
> > "H\244\205\200\0\1\0\0\0\1\0\0\6google\3com\7kubelet\n"..., 512, 0,
> > {sa_family=AF_INET, sin_port=htons(53),
> > sin_addr=inet_addr("10.43.0.10")}, [16]) = 100 recvfrom(3,
> > 0x7fff9c3f83c0, 512, 0, 0x7fff9c3f7e70, [16]) = -1 EAGAIN (Resource
> > temporarily unavailable) poll([{fd=3, events=POLLIN}], 1, 2498) = 1
> > ([{fd=3, revents=POLLIN}]) recvfrom(3,
> > "K\266\205\200\0\1\0\0\0\1\0\0\6google\3com\7kubelet\n"..., 512, 0,
> > {sa_family=AF_INET, sin_port=htons(53),
> > sin_addr=inet_addr("10.43.0.10")}, [16]) = 100
> ^^^^^^^^
>
> Here we see your nameserver returning a RCODE=0 (Success, the \200
> byte) reply for google.com.kubelet[...] rather than NxDomain. Sorry I don't have the full name; you need to pass a larger -s to strace to get it not to truncate strings. You need to figure out why the nameserver is claiming this exists; it might be some sort of wildcard record or just a buggy nameserver (probably some component of kubernetes).
>
> Rich
By preventing the trace from being truncated (see attached) it appears that this only occurs when querying names for which Rancher's DNS is authoritative, and is not happening for names for which Kubernetes' DNS is authoritative.
FYI, this is how `search` was defined in `resolv.conf`:
```
search default.svc.cluster.local svc.cluster.local cluster.local kubelet.kubernetes.rancher.internal kubernetes.rancher.internal rancher.internal
```
Where `default.svc.cluster.local`, `svc.cluster.local` and `cluster.local` are for service discovery in Kubernetes and `kubelet.kubernetes.rancher.internal`, `kubernetes.rancher.internal` and `rancher.internal` are (I believe) something to do with rancher-dns.
This would explain why only some people have continued having problems since Alpine 3.4 was released with the `search` and `domain` support contained within musl libc.
Raising a bug with Rancher now. Thanks so much for your help here!
LEGAL DISCLAIMER. The contents of this electronic communication
and any attached documents are strictly confidential and they may not
be used or disclosed by someone who is not a named recipient.
If you have received this electronic communication in error please notify
the sender by replying to this electronic communication inserting the
word "misdirected" as the subject and delete this communication from
your system.
[-- Attachment #2: strace_of_google-com_non-truncated.txt --]
[-- Type: text/plain, Size: 7033 bytes --]
execve("./gai3a", ["./gai3a", "google.com"], [/* 15 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7fbaf4db7b48) = 0
set_tid_address(0x7fbaf4db7b80) = 49
mprotect(0x7fbaf4db4000, 4096, PROT_READ) = 0
mprotect(0x560558d0f000, 4096, PROT_READ) = 0
open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
readv(3, [{iov_base="", iov_len=0}, {iov_base="# Kubernetes-managed hosts file.\n127.0.0.1\tlocalhost\n::1\tlocalhost ip6-localhost ip6-loopback\nfe00::0\tip6-localnet\nfe00::0\tip6-m"..., iov_len=1024}], 2) = 202
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=1024}], 2) = 0
close(3) = 0
open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
readv(3, [{iov_base="", iov_len=0}, {iov_base="search default.svc.cluster.local svc.cluster.local cluster.local kubelet.kubernetes.rancher.internal kubernetes.rancher.internal"..., iov_len=248}], 2) = 218
readv(3, [{iov_base="", iov_len=0}, {iov_base="", iov_len=248}], 2) = 0
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "\307\240\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3svc\7cluster\5local\0\0\1\0\1", 54, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 54
sendto(3, "\342\253\1\0\0\1\0\0\0\0\0\0\6google\3com\7default\3svc\7cluster\5local\0\0\34\0\1", 54, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 54
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\307\240\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3svc\7cluster\5local\0\0\1\0\1\7cluster\5local\0\0\6\0\1\0\0\0<\0D\2ns\3dns\7cluster\5local\0\nhostmaster\7cluster\5local\0X"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 147
recvfrom(3, 0x7ffcca669dd0, 512, 0, 0x7ffcca669880, [16]) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}], 1, 2499) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\342\253\201\203\0\1\0\0\0\1\0\0\6google\3com\7default\3svc\7cluster\5local\0\0\34\0\1\7cluster\5local\0\0\6\0\1\0\0\0<\0D\2ns\3dns\7cluster\5local\0\nhostmaster\7cluster\5local\0X"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 147
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "\34U\1\0\0\1\0\0\0\0\0\0\6google\3com\3svc\7cluster\5local\0\0\1\0\1", 46, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 46
sendto(3, "\37\211\1\0\0\1\0\0\0\0\0\0\6google\3com\3svc\7cluster\5local\0\0\34\0\1", 46, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 46
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\34U\201\203\0\1\0\0\0\1\0\0\6google\3com\3svc\7cluster\5local\0\0\1\0\1\7cluster\5local\0\0\6\0\1\0\0\0<\0D\2ns\3dns\7cluster\5local\0\nhostmaster\7cluster\5local\0X\311\201 \0\0p\200\0"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 139
recvfrom(3, 0x7ffcca669dd0, 512, 0, 0x7ffcca669880, [16]) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}], 1, 2499) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\37\211\201\203\0\1\0\0\0\1\0\0\6google\3com\3svc\7cluster\5local\0\0\34\0\1\7cluster\5local\0\0\6\0\1\0\0\0<\0D\2ns\3dns\7cluster\5local\0\nhostmaster\7cluster\5local\0X\311\201 \0\0p\200\0"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 139
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "\21f\1\0\0\1\0\0\0\0\0\0\6google\3com\7cluster\5local\0\0\1\0\1", 42, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 42
sendto(3, "\24\204\1\0\0\1\0\0\0\0\0\0\6google\3com\7cluster\5local\0\0\34\0\1", 42, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 42
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\21f\201\203\0\1\0\0\0\1\0\0\6google\3com\7cluster\5local\0\0\1\0\1\7cluster\5local\0\0\6\0\1\0\0\0<\0D\2ns\3dns\7cluster\5local\0\nhostmaster\7cluster\5local\0X\311\201 \0\0p\200\0\0\34 \0"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 135
recvfrom(3, 0x7ffcca669dd0, 512, 0, 0x7ffcca669880, [16]) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}], 1, 2499) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\24\204\201\203\0\1\0\0\0\1\0\0\6google\3com\7cluster\5local\0\0\34\0\1\7cluster\5local\0\0\6\0\1\0\0\0<\0D\2ns\3dns\7cluster\5local\0\nhostmaster\7cluster\5local\0X\311\201 \0\0p\200\0\0\34 \0"..., 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 135
close(3) = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
sendto(3, "\211\260\1\0\0\1\0\0\0\0\0\0\6google\3com\7kubelet\nkubernetes\7rancher\10internal\0\0\1\0\1", 64, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 64
sendto(3, "\214\374\1\0\0\1\0\0\0\0\0\0\6google\3com\7kubelet\nkubernetes\7rancher\10internal\0\0\34\0\1", 64, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, 16) = 64
poll([{fd=3, events=POLLIN}], 1, 2500) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\211\260\205\200\0\1\0\0\0\1\0\0\6google\3com\7kubelet\nkubernetes\7rancher\10internal\0\0\1\0\1\300*\0\6\0\1\0\0\2X\0\30\300*\300*\0-\21B\0\0\0<\0\0\0\n\0\1Q\200\0\0\0\1", 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 100
recvfrom(3, 0x7ffcca669dd0, 512, 0, 0x7ffcca669880, [16]) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}], 1, 2499) = 1 ([{fd=3, revents=POLLIN}])
recvfrom(3, "\214\374\205\200\0\1\0\0\0\1\0\0\6google\3com\7kubelet\nkubernetes\7rancher\10internal\0\0\34\0\1\300*\0\6\0\1\0\0\2X\0\30\300*\300*\0-\21C\0\0\0<\0\0\0\n\0\1Q\200\0\0\0\1", 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.43.0.10")}, [16]) = 100
close(3) = 0
ioctl(1, TIOCGWINSZ, {ws_row=0, ws_col=0, ws_xpixel=0, ws_ypixel=0}) = 0
writev(1, [{iov_base="google.com: Name does not resolve", iov_len=33}, {iov_base="\n", iov_len=1}], 2) = 34
exit_group(0) = ?
+++ exited with 0 +++
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2017-03-15 19:26 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-15 10:28 Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work dominic.chambers
2017-03-15 12:25 ` Rich Felker
2017-03-15 12:58 ` dominic.chambers
2017-03-15 15:11 ` Rich Felker
2017-03-15 16:58 ` dominic.chambers
2017-03-15 17:10 ` dominic.chambers
2017-03-15 17:22 ` Rich Felker
2017-03-15 19:26 ` dominic.chambers
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).