Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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!

share|improve this question

3 Answers 3

up vote 0 down vote accepted

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.

share|improve this answer
    
Yes. If I use FQDN (ending with trailing dot) then the returned result is the desired one. (NXDOMAIN) But the problem is that the browser don't use FQDN to resolve host domain name... I mean when I type in _non-exist-domain_.com in browser address bar then it will visit 192.168.0.1. Of course I can type _non-exist-domain_.com. (trailing dot) then it will return correct result (could not find host). But people don't type the trailing dot normally I think... –  fubupc Aug 2 '11 at 11:26
    
Thank you all! Although this problem is not resolved I have a better understanding in DNS and resolve.conf now. Thanks! –  fubupc Aug 3 '11 at 6:00

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.

share|improve this answer
    
Yes. If I use FQDN (ending with trailing dot) then the returned result is the desired one. (NXDOMAIN) But the problem is that the browser don't use FQDN to resolve host domain name... I mean when I type in _non-exist-domain_.com in browser address bar then it will visit 192.168.0.1. Of course I can type _non-exist-domain_.com. (trailing dot) then it will return correct result (could not find host). But people don't type the trailing dot normally I think... –  fubupc Aug 2 '11 at 11:27

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.

share|improve this answer
    
Thank you for answering! Yes, that's where the problem lie. If I remove the domain entry in /etc/resolv.conf then it will be working normally. But I want the convenient of ping somehost will ping somehost.bogus. Are there some method to only append domain part to hostname which not contain a dot so ping sdjflksjdflksjdf.com will not ping sdjflksjdflksjdf.com.bogus? –  fubupc Aug 2 '11 at 10:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.