DNS wildcard and /etc/resolv.conf problem

Question

I searched through google.com but can't find an answer... So I asked here.

This is the problem:

I build a DNS test environment on my PC which hostname is gamepc.

The DNS server (bind9) has a wildcard record:

* IN A 192.168.0.1

And the /etc/resolv.conf file has a entry:

domain bogus.
nameserver 127.0.0.1

So when I ping somehost it will return like:

PING somehost.bogus (192.168.0.1) 56(84) bytes of data.
64 bytes from gamepc.bogus (192.168.0.1): icmp_req=1 ttl=64 time=0.042 ms
...

And when I ping google.com it will return like:

PING google.com (74.125.71.99) 56(84) bytes of data.
64 bytes from hx-in-f99.1e100.net (74.125.71.99): icmp_req=1 ttl=51 time=68.0 ms
...

So far everything is good. But if I ping some non-exist domain e.g. sldfjsldjflksdjf.com it will still return like:

PING sldfjsldjflksdjf.com.bogus (192.168.0.1) 56(84) bytes of data.
64 bytes from gamepc.bogus (192.168.0.1): icmp_req=1 ttl=64 time=0.043 ms
...

And the expected result should be:

ping: unknown host sldfjslkdfjlksdjfklsdjf.com

I can thought how this happened. At first the resolver try sldfjslkdfjlksdjfklsdjf.com but get a NXDOMAIN response. Then it append the domain part and try sldfjslkdfjlksdjfklsdjf.com.bogus again. This time the host name match the wildcard record in DNS server and return 192.168.0.1 ...

Does anyone have the same issue? And how did you resolve it?

Thank you very much for reading!

Answer 1

Does anyone have the same issue?

Everyone has the issue. It's a standard part of most DNS client libraries. It's variously called a domain search path or DNS search path or DNS devolution.

And how did you resolve it?

By using fully-qualified domain names where I desire them. You are not using FQDNs.

the browser don't use FQDN to resolve host domain name

This is your first mention of a WWW browser. You didn't mention it in the question. WWW browsers are oddities, not least because they have two, sometimes more, domain search paths operating one on top of another. People do use fully qualified domain names in URLs for precisely this reason. If you're going to set up your DNS client library such that its search path mechanism successfully maps names to addresses like this, you're going to have to do so as well. This is the consequence of your choosing to have a search path and a wildcard that matches everything in an entire subtree. One has to think about using wildcards.

Answer 2

From man resolv.conf:

domain Local domain name.
   Most  queries  for names within this domain can use short names relative 
   to the local domain. If no domain entry is present, the domain is 
   determined from the local hostname returned by gethostname(2); the domain 
   part is taken to be everything after the first '.'.  Finally, if the 
   hostname does not contain a domain part, the root domain is assumed.

search Search list for host-name lookup.
   The search list is normally determined from the local domain name; 
   by default, it  contains  only the  local  domain name. (...)

So, if you query for sldfjslkdfjlksdjfklsdjf then bind finds no matching record, so your resolver tries sldfjslkdfjlksdjfklsdjf.bogus, which in turn returns an address.

If you ping sldfjslkdfjlksdjfklsdjf. (note the trailing dot) you should be OK (i.e. the lookup will fail). The trailing dot means that you supplied a FQDN of the host, so no domain suffixes should be tried.

Answer 3

I don't think u can actually resolve the issue due to the fact that u have the wildcard in your DNS configuration.

When not using the wildcard u will get the error message, but with the wildcard and your resolv.conf options everything unknown will resolve to your domain.