[PATCH] resolv.conf parser: concatenate multiple search domain lines

[PATCH] resolv.conf parser: concatenate multiple search domain lines

[William Pitcock]

Programs such as Docker and Kubernetes write multiple domain search lines, such as

search serious-business.big-data.prod.foo.com
search big-data.prod.foo.com
search prod.foo.com

instead of

search serious-business.big-data.prod.foo.com big-data.prod.foo.com prod.foo.com

Accordingly, we concatenate the namelist together so that the search path is
not truncated.

(Sorry, not sorry, for ruining the "omg Alpine sucks at DNS" talk at Kubecon)
---
 src/network/lookup_name.c | 2 +-
 src/network/resolvconf.c  | 7 ++++++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/src/network/lookup_name.c b/src/network/lookup_name.c
index 209c20f0..c83c11c5 100644
--- a/src/network/lookup_name.c
+++ b/src/network/lookup_name.c
@@ -172,7 +172,7 @@ static int name_from_dns(struct address buf[static MAXADDRS], char canon[static
 
 static int name_from_dns_search(struct address buf[static MAXADDRS], char canon[static 256], const char *name, int family)
 {
-	char search[256];
+	char search[2048];
 	struct resolvconf conf;
 	size_t l, dots;
 	char *p, *z;
diff --git a/src/network/resolvconf.c b/src/network/resolvconf.c
index 4c3e4c4b..72ed4082 100644
--- a/src/network/resolvconf.c
+++ b/src/network/resolvconf.c
@@ -9,6 +9,7 @@ int __get_resolv_conf(struct resolvconf *conf, char *search, size_t search_sz)
 {
 	char line[256];
 	unsigned char _buf[256];
+	char *search_base = search;
 	FILE *f, _f;
 	int nns = 0;
 
@@ -74,9 +75,13 @@ int __get_resolv_conf(struct resolvconf *conf, char *search, size_t search_sz)
 			continue;
 		for (p=line+7; isspace(*p); p++);
 		size_t l = strlen(p);
+		ptrdiff_t m = search - search_base;
 		/* This can never happen anyway with chosen buffer sizes. */
-		if (l >= search_sz) continue;
+		if (l + m >= search_sz) continue;
 		memcpy(search, p, l+1);
+		/* We concatenate the search list as domain1 domain2\0 */
+		search += l;
+		*search++ = ' ';
 	}
 
 	__fclose_ca(f);
-- 
2.16.2

Re: [PATCH] resolv.conf parser: concatenate multiple search domain lines

[Quentin Rameau]

Hi William,

> Programs such as Docker and Kubernetes write multiple domain search
> lines, such as
> 
> search serious-business.big-data.prod.foo.com
> search big-data.prod.foo.com
> search prod.foo.com
> 
> instead of
> 
> search serious-business.big-data.prod.foo.com big-data.prod.foo.com
> prod.foo.com
> 
> Accordingly, we concatenate the namelist together so that the search
> path is not truncated.

I think this patch should be sent to Docker and Kubernetes instead of
pushing a mitigation for their bug in the libc.

According to documentation, “The domain and search keywords are
mutually exclusive.  If more than one instance of these keywords is
present, the last instance wins.”

This patch would break existing applications relying on documented
behaviour.

- Quentin

Re: [PATCH] resolv.conf parser: concatenate multiple search domain lines

[Rich Felker]

On Fri, Mar 30, 2018 at 02:27:42PM +0200, Quentin Rameau wrote:
> Hi William,
> 
> > Programs such as Docker and Kubernetes write multiple domain search
> > lines, such as
> > 
> > search serious-business.big-data.prod.foo.com
> > search big-data.prod.foo.com
> > search prod.foo.com
> > 
> > instead of
> > 
> > search serious-business.big-data.prod.foo.com big-data.prod.foo.com
> > prod.foo.com
> > 
> > Accordingly, we concatenate the namelist together so that the search
> > path is not truncated.
> 
> I think this patch should be sent to Docker and Kubernetes instead of
> pushing a mitigation for their bug in the libc.
> 
> According to documentation, “The domain and search keywords are
> mutually exclusive.  If more than one instance of these keywords is
> present, the last instance wins.”
> 
> This patch would break existing applications relying on documented
> behaviour.

I wrote the current behavior based on that documentation. Apparently
the current glibc behavior does not match the documentation, but I'd
really rather not go against the documentation unless there's
agreement from glibc/others that the documentation is wrong and their
current behavior is desired. Either way I think Docker/Kubernetes
should fix this, since it's ambiguous what the "right" thing to do is
and there very well could end up being inconsistent behaviors between
libcs/versions into the future.

Rich

Re: [PATCH] resolv.conf parser: concatenate multiple search domain lines

[William Pitcock]

Hello,

On Fri, Mar 30, 2018 at 8:21 AM, Rich Felker <dalias@libc.org> wrote:
> On Fri, Mar 30, 2018 at 02:27:42PM +0200, Quentin Rameau wrote:
>> Hi William,
>>
>> > Programs such as Docker and Kubernetes write multiple domain search
>> > lines, such as
>> >
>> > search serious-business.big-data.prod.foo.com
>> > search big-data.prod.foo.com
>> > search prod.foo.com
>> >
>> > instead of
>> >
>> > search serious-business.big-data.prod.foo.com big-data.prod.foo.com
>> > prod.foo.com
>> >
>> > Accordingly, we concatenate the namelist together so that the search
>> > path is not truncated.
>>
>> I think this patch should be sent to Docker and Kubernetes instead of
>> pushing a mitigation for their bug in the libc.
>>
>> According to documentation, “The domain and search keywords are
>> mutually exclusive.  If more than one instance of these keywords is
>> present, the last instance wins.”
>>
>> This patch would break existing applications relying on documented
>> behaviour.
>
> I wrote the current behavior based on that documentation. Apparently
> the current glibc behavior does not match the documentation, but I'd
> really rather not go against the documentation unless there's
> agreement from glibc/others that the documentation is wrong and their
> current behavior is desired. Either way I think Docker/Kubernetes
> should fix this, since it's ambiguous what the "right" thing to do is
> and there very well could end up being inconsistent behaviors between
> libcs/versions into the future.

It turns out this problem has been fixed a while ago.  The actual
problem is something else, which I was able to reproduce.
I sent a patch for it, too.

William