4

I'm trying to resolve a DNS issue and am running short of ideas. Google doesn't seem to be helping, either.

When I use my local caching name server to resolve external host names, it always returns 192.168.1.251. There are some examples below.

Where is this invalid address coming from, and more importantly, how can I correct the issue?

My setup: Local Domain name Solwiz.net 192.168.0.*

Broadband router - internal address is 192.168.0.1 - DHCP: Disabled

Caching Nameserver: Bind 9 192.168.0.32 Debian Squeeze

Digging:

dig - host on local network works

$ dig @ns2 mail2.solwiz.net

; <<>> DiG 9.7.3 <<>> @ns2 mail2.solwiz.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17568
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;mail2.solwiz.net.              IN      A

;; ANSWER SECTION:
mail2.solwiz.net.       259200  IN      A       192.168.0.34

;; AUTHORITY SECTION:
solwiz.net.             259200  IN      NS      ns2.solwiz.net.

;; ADDITIONAL SECTION:
ns2.solwiz.net.         259200  IN      A       192.168.0.32

;; Query time: 0 msec
;; SERVER: 192.168.0.32#53(192.168.0.32)
;; WHEN: Fri Aug  1 21:09:36 2014
;; MSG SIZE  rcvd: 84

dig - host on external network returns incorrect IP

$ dig @ns2 www.google.ch

; <<>> DiG 9.7.3 <<>> @ns2 www.google.ch
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16611
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.ch.                 IN      A

;; ANSWER SECTION:
www.google.ch.          0       IN      A       192.168.1.251

;; AUTHORITY SECTION:
google.ch.              333349  IN      NS      ns4.google.com.
google.ch.              333349  IN      NS      ns3.google.com.
google.ch.              333349  IN      NS      ns2.google.com.
google.ch.              333349  IN      NS      ns1.google.com.

;; Query time: 1 msec
;; SERVER: 192.168.0.32#53(192.168.0.32)
;; WHEN: Fri Aug  1 21:11:44 2014
;; MSG SIZE  rcvd: 129

dig - host on external network returns incorrect IP

$ dig @ns2 www.microsoft.com

; <<>> DiG 9.7.3 <<>> @ns2 www.microsoft.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5476
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;www.microsoft.com.             IN      A

;; ANSWER SECTION:
www.microsoft.com.      0       IN      A       192.168.1.251

;; AUTHORITY SECTION:
com.                    160501  IN      NS      j.gtld-servers.net.
com.                    160501  IN      NS      k.gtld-servers.net.
com.                    160501  IN      NS      h.gtld-servers.net.
com.                    160501  IN      NS      e.gtld-servers.net.
com.                    160501  IN      NS      f.gtld-servers.net.
com.                    160501  IN      NS      d.gtld-servers.net.
com.                    160501  IN      NS      m.gtld-servers.net.
com.                    160501  IN      NS      l.gtld-servers.net.
com.                    160501  IN      NS      a.gtld-servers.net.
com.                    160501  IN      NS      i.gtld-servers.net.
com.                    160501  IN      NS      c.gtld-servers.net.
com.                    160501  IN      NS      b.gtld-servers.net.
com.                    160501  IN      NS      g.gtld-servers.net.

;; Query time: 2 msec
;; SERVER: 192.168.0.32#53(192.168.0.32)
;; WHEN: Fri Aug  1 21:12:20 2014
;; MSG SIZE  rcvd: 275

I dumped the cache with rdnc dumpdb --all, there is a 192.168.1.* addresses mentioned.

Cleared the _default view, the entry for 192.168.1.* was gone.

Repeated the Dig for Microsoft.com, the entry is back:

;
; Start view _default
;
;
; Cache dump of view '_default' (cache _default)
;
$DATE 20140801194948

(several lines removed)

; Unassociated entries

(several lines removed)

;       192.168.1.251 [srtt 722240] [flags 00002000] [ttl 1780]

(lines to end of file removed)

From /etc/bind/named.conf.options

    forwarders {
            8.8.8.8;
            62.2.24.162; 62.2.17.60;
    };

8.8.8.8 is, of course, Google's DNS, The two 62.2.* are my provider's DNS servers.

Querying the forwarders directly (from my Nameserver)

dig @8.8.8.8 www.google.ch

; <<>> DiG 9.7.3 <<>> @8.8.8.8 www.google.ch
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17711
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0


;; QUESTION SECTION:
;www.google.ch.                 IN      A

;; ANSWER SECTION:
www.google.ch.          0       IN      A       192.168.1.251

;; Query time: 0 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Aug  2 15:36:51 2014
;; MSG SIZE  rcvd: 47

The other forwarders give the same response.

A little background: I have my main network wlan-bridged to the wlan router, some clients access the wlan router directly. I've been experiencing connectivity and performance problems for some time. The internal network died completely yesterday, not even the direct wlan clients were getting service, although there was excellent service on the broadband router's ethernet ports. My network technician disabled the WLAN functionality of the broadband adapter, and connected an access point to one of the ethernet ports of the adapter. The access port's default ip is 192.168.1.2, but he changed that to 192.168.0.2. As far as I know, he disabled any DHCP functionality in the access point. Since the change I've been having the ip resolution issue.

  • 1
    Ok, if you get the same strange response when querying the forwarders directly then the problem would appear to be outside of your bind installation. Possibly something that intercepts 53/udp? – Håkan Lindqvist Aug 2 '14 at 14:00
  • Exactly what are the "routers" and "access points" that your network path travels through before it leaves your office? – Michael Hampton Aug 2 '14 at 14:45
  • Welcome to Server Fault. Please do not tag questions as "SOLVED" or place answers in the question. Use the Answer below for answers. – Michael Hampton Aug 2 '14 at 20:58
  • This looks pretty much exactly like what you'd get if you were connected to a captive portal. Something is obviously intercepting your DNS queries and providing spoofed answers, with a TTL of 0. I wonder whether there is a webserver on 192.168.1.251? It would figure. Also, I assume you get the same reply for DNS names that don't even exist on the real Internet? It's unclear from your description what the network looks like. Is it possible you're not connected to the wlan you think you're connected to? – András Korn Sep 1 '14 at 14:37
0

I suspect that your router has a "Catch all"/"Intercept Web Traffic" option enabled by default. I had the same problem in my CPE because I had not set a DNS on the CPE. I solved it when I disabled the "Intercept Web Traffic" option.

0

Why would you need DNS forwarders on your local DNS resolver? Why not using resolver on it's own?

  • In my opinion your named.conf config should include recursion yes;
  • On your client machine you should have only your DNS resolver IP.

Please provide traceroute results to your DNS resolver and to 192.168.1.251

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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