From: <dominic.chambers@glencore.com>
To: <musl@lists.openwall.com>
Subject: Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work
Date: Wed, 15 Mar 2017 10:28:15 +0000 [thread overview]
Message-ID: <075030ca6fc64b13be5651fe32c5e770@CHBARSRV1EXCHP1.ANYACCESS.NET> (raw)
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.
next reply other threads:[~2017-03-15 10:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-15 10:28 dominic.chambers [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=075030ca6fc64b13be5651fe32c5e770@CHBARSRV1EXCHP1.ANYACCESS.NET \
--to=dominic.chambers@glencore.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).