Comment 13 for bug 1906970

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=ebbe5a6a4ed86abe3fccd4a134bfcf6f613c9bbb;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.