Difference between dnslookup and dig/drill

when I use these tool to check the ip of a blocked website (my country gives private addresses for blocked pages like 10.10. range)
nslookup shows this

nslookup ads.mopub.com
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   ads.mopub.com
Address: 10.10.34.35

but dig and drill filter that answers and give empty answers.

both on my laptop and directly on openwrt device.

I use drill because I read somewhere it is the best tool for dns checking but with this I see that it filters the answers.

even more weird when I directly run on openwrt I see two results.(dns at 8.8.8.8 is not actually google but my country intercepts and change the result to the private ip)

openwrt# drill ads.mopub.com                
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 17501
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; ads.mopub.com.       IN      A

;; ANSWER SECTION:

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 22 msec
;; SERVER: 127.0.0.1
;; WHEN: Sat Jul 10 10:32:04 2021
;; MSG SIZE  rcvd: 31



openwrt# drill @8.8.8.8 ads.mopub.com       
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 13355
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; ads.mopub.com.       IN      A

;; ANSWER SECTION:
ads.mopub.com.  1       IN      A       10.10.34.35

what I am missing.
is dnsmasq on my openwrt give a flag with the ip address that makes dig and drill ignore that address but nslookup doesnt ignore it?

You are seeing the result of a deliberate bug in dnsmasq, causing it to reject any reply with a "private" (RFC1918) address coming from a DNS server on the WAN. See the documentation of rebind_protection here: https://openwrt.org/docs/guide-user/base-system/dhcp

You'd want to disable that. And so should everyone else, IMHO.

I am claiming the dnsmasq implementation is buggy because it doesn't take the real LAN addresses into account. That's essential for any real rebind protection scheme.

Instead dnsmasq just makes this bogus, simplified and dangerous assumtion than any RFC1918 address is a LAN address, and any non-RFC1918 address is not. So you have a false claim of protection combined with false rejections. The worst of both worlds.

3 Likes

I think you didnt get my point (or I wasn't clear).
I have removed dnsmasq on my laptop.
I just have it on my router/wifi AP.

nslookup on laptop gets it answer from router (which has dnsmasq) and give the 10range private ip. and curl also uses the private ip (which for https timeouts and for http shows a static page that says page is blocked.

but drill and dig that get the result from the same router/dnsmasq, they show an empty answer.
so I dont think it is dnsmasq it filtering it.

btw if I want to replace the dns part of dnsmasq should I use bind or unbound ?
i am a novice and the last time I used unbound its ram usage ballooned and hanged my router.

btw anecdotally I kind of agree with your point about not all private addresses being bogus,
there is a news website in my country that uses a private ip for iranian users and another public one for world. so when I would use a dndscypt I would get a public ip that the website would NOT answer to for a Iranian ip. so for that website I have set 8.8.8.8 as dns server, which is hijacked by national net.
Iranian government hijacks dns servers on port 53 and gives its own answer. stupid,I know. but this causes the 8.8.8.8 to give me the correct internal ip for the news website and I could connect to it,
and dnsmasq giving error about the ip pointed me to the issue.