[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <075030ca6fc64b13be5651fe32c5e770@CHBARSRV1EXCHP1.ANYACCESS.NET>
Date: Wed, 15 Mar 2017 10:28:15 +0000
From: <dominic.chambers@...ncore.com>
To: <musl@...ts.openwall.com>
Subject: Queries with less than `ndots` dots never lead to resolution using
the global namespace if the `search` domains don't work
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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
