Sergio (~sergiodj) did some digging on `search .` and found out that it should be supported after all. I'm copy/pasting here his email to <email address hidden> for future reference:
=== Message-ID: <email address hidden> ===
I think the reporter from #1906970 is right: it seems that "search ." is
indeed supported.
Interestingly, I could not find any documentation to truly back this up;
even though the manpage for resolv.conf(5) is well written (kudos to
Michael Kerrisk and the man-pages project, btw!), it is not
authoritative when it comes to defining what "search ." means. So I had
to resort to the real source of knowledge here: glibc and its resolver.
Long story short, the resolver code lives under the "resolv/" directory
on glibc. If you look at the res_search function (which performs DNS
queries taking "search" into account), you will find this excerpt here:
When RES_DNSRCH is set, it means that the resolver will search for
hostnames in the current domain and in parent domains. Particularly,
this excerpt is interesting:
/* __res_context_querydoman concatenates name
with dname with a "." in between. If we
pass it in dname the "." we got from the
configured default search path, we'll end
up with "name..", which won't resolve.
OTOH, passing it "" will result in "name.",
which has the intended effect for both
possible representations of the root
domain. */
if (dname[0] == '.')
dname++;
if (dname[0] == '\0')
root_on_list++;
So you see that the code takes into account the case when "search ." is
used, and interprets it as representing the root domain indeed.
Sergio (~sergiodj) did some digging on `search .` and found out that it should be supported after all. I'm copy/pasting here his email to <email address hidden> for future reference:
=== Message-ID: <email address hidden> ===
I think the reporter from #1906970 is right: it seems that "search ." is
indeed supported.
Interestingly, I could not find any documentation to truly back this up;
even though the manpage for resolv.conf(5) is well written (kudos to
Michael Kerrisk and the man-pages project, btw!), it is not
authoritative when it comes to defining what "search ." means. So I had
to resort to the real source of knowledge here: glibc and its resolver.
Long story short, the resolver code lives under the "resolv/" directory
on glibc. If you look at the res_search function (which performs DNS
queries taking "search" into account), you will find this excerpt here:
https:/ /sourceware. org/git/ ?p=glibc. git;a=blob; f=resolv/ res_query. c;h=ebbe5a6a4ed 86abe3fccd4a134 bfcf6f613c9bbb; hb=HEAD# l385
When RES_DNSRCH is set, it means that the resolver will search for
hostnames in the current domain and in parent domains. Particularly,
this excerpt is interesting:
/* __res_context_ querydoman concatenates name
with dname with a "." in between. If we
pass it in dname the "." we got from the
configured default search path, we'll end
up with "name..", which won't resolve.
OTOH, passing it "" will result in "name.",
which has the intended effect for both
possible representations of the root
domain. */
if (dname[0] == '.')
dname++;
if (dname[0] == '\0')
root_on_list++;
So you see that the code takes into account the case when "search ." is
used, and interprets it as representing the root domain indeed.