From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11136 Path: news.gmane.org!.POSTED!not-for-mail From: Newsgroups: gmane.linux.lib.musl.general 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 Message-ID: <075030ca6fc64b13be5651fe32c5e770@CHBARSRV1EXCHP1.ANYACCESS.NET> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1489578893 14925 195.159.176.226 (15 Mar 2017 11:54:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 15 Mar 2017 11:54:53 +0000 (UTC) To: Original-X-From: musl-return-11151-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 15 12:54:47 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1co7Vs-0002nw-Ed for gllmg-musl@m.gmane.org; Wed, 15 Mar 2017 12:54:44 +0100 Original-Received: (qmail 3466 invoked by uid 550); 15 Mar 2017 11:54:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 13941 invoked from network); 15 Mar 2017 10:28:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=glencore.com; i=@glencore.com; q=dns/txt; s=glendkim1; t=1489573638; x=1521109638; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=zGOFolkQ0L+3wS/HAvKpwqYpQOzd5XMlEZw2Om6AUx4=; b=iBJw6PpoWJ/4LDuu60wBc6BswTokgx6xTqxhKoYsXVmrHObtDHmcXTF2 /mP/EXHzM52ZH6RZW/OZY8ZWx/GZx+mRRRXAHKhH+6tXKVyqhP8Ljc+UN OhI0xtUAY2HjBA2vggREH0kXvDF2bArfAMmzKiRcpy1ZdanSRKDopCEP5 E=; IronPort-PHdr: =?us-ascii?q?9a23=3ATjO+vBRiGUnht9etMiKar+NheNpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa6yYhWN2/xhgRfzUJnB7Loc0qyN4vymATRIyK3CmUhKSIZLWR4BhJ?= =?us-ascii?q?detC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+?= =?us-ascii?q?KPjrFY7OlcS30P2594HObwlSijewZbx/IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf?= =?us-ascii?q?5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbD?= =?us-ascii?q?VwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4qF2QxHqlS?= =?us-ascii?q?gHLSY0/mHJhMJtkKJVrhGvpx1jzIDbb46YL+Z+frrBcd8GWWZNQttdWipcCY28?= =?us-ascii?q?dYsPCO8BMP5foobgoFsOqBq+BQ+tBOzz0DNHmn/20rc/0+s6Dw7GxhcgEskBsH?= =?us-ascii?q?TQstr1MrsdUeevzKbW1znMc/RW2TLk5YXObxsvr/aMXbdqfsrQz0kiDwzFjlSM?= =?us-ascii?q?qYzlIjOazf4BvHSc7+plU++klm0pqxlprzSy2ssgkJfFipwVx1ze6Sl12ps5Kc?= =?us-ascii?q?GlREJjfNKoDIFcuz+EO4Z5WM8uXn9ktDogxrEbt5O3ZCYKx4okyhLDbvGKdoyF?= =?us-ascii?q?7Q/iWeqNJDp1i3Bodb X-IPAS-Result: =?us-ascii?q?A2FaAACVFslY/2UA4QpdHAEBBAEBCgEBFwEBBAEBCgEBhAe?= =?us-ascii?q?BCgeNZqcSgS8FF0MaEokeGAEBAQEBAQEBAQEBAoEQCYIqIAsERicCLwEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBEgINN4EbHQEVLj0mAQQbigavcYpfDCaQXYIADIM?= =?us-ascii?q?NBY9bQYwngVKFJIs8gliOVpNHH4EEOVhWhFcdGYFKdYglgQ0BAQE?= Thread-Topic: Queries with less than `ndots` dots never lead to resolution using the global namespace if the `search` domains don't work Thread-Index: AdKddrW/yKO9p9TESfyqxa0kHVpsaw== Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.224.120.13] Xref: news.gmane.org gmane.linux.lib.musl.general:11136 Archived-At: As you can see from the comments starting here: https://github.com/gliderlabs/docker-alpine/issues/8#issuecomment-2239015= 19 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-2865616= 14 which I'll duplicate here so that's it's archived on the mailing list: [MESSAGE] Even based on its own=A0documentation=A0this would appear to be a bug in mu= sl libc: [QUOTE] musl's resolver previously did not support the "domain" and "search" keywor= ds in resolv.conf. This feature was added in version 1.1.13, but its behavi= or differs slightly from glibc's:=A0queries with fewer dots than the `ndots= ` configuration variable are processed with search first then tried literal= ly=A0(just like glibc), but=A0those with at least as many dots as `ndots` a= re only tried in the global namespace=A0(never falling back to search, whic= h glibc would do if the name is not found in the global DNS namespace). Thi= s difference comes from a consistency requirement not to return different r= esults subject to transient failures or to global DNS namespace changes out= side of one's control (addition of new TLDs). [/QUOTE] While I can confirm the second part (queries greater than=A0`ndots`=A0never= fall-back to using search), the first part (queries smaller than=A0`ndots`= =A0fall-back to using an absolute query) isn't what I observe. Using=A0dig=A0on an Ubuntu container and attempting to resolve the nonsensi= cal query=A0`google.com.default.svc.cluster.local`=A0(simulates the type of= initial query for a short domain that would be occurring) returns a=A0`QUE= STION SECTION`=A0and an=A0`AUTHORITY SECTION`, but=A0no=A0`ANSWER SECTION`.= This should cause musl libc to attempt to resolve the absolute query (`goo= gle.com`) instead, yet it doesn't seem to based on the final result of the = query. Here's the (tiny)=A0commit=A0where support for=A0search=A0and=A0domain=A0wa= s added to musl libc, and here's the=A0`name_from_dns`=A0function that that= diff relies on. I think this=A0`dns_parse_callback`=A0function maybe the t= hing that determines whether we consider we've received a result or not, ye= t the code indicates this would only occur if we receive either an=A0`A`,= =A0`AAAA`=A0or=A0`CNAME`=A0record, yet in our case there's no=A0`ANSWER SEC= TION` whatsoever. [/MESSAGE] I'd really like to help debug this one if at all possible, and would apprec= iate 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.