1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Shibby 102/104 DNS leaks

Discussion in 'Tomato Firmware' started by ipse, Dec 21, 2012.

  1. ipse

    ipse LI Guru Member

    Hey guys...thought I would pick the collective brain for my weird DNS leak problem with Shibby 104 (and 102).
    I have OpenVPN set up wit PIA, DNS set to exclusive, in router config I have supplied MY DNS server, dnsmasq is set to "strict-order" and the option to use the ISP provided DNS is UNCHECKED.
    However, with VPN UP, I get dns leaks as shown by dnsleaktest.com (ISP DNS ptroxies show up).

    I checked resolv.dnsmasq and sure enough the ISP servers are there, fine, they should NOT be used but still are.
    The only way I get a clean dnsleaktest is to vi the file, mod the servers and save. it works fine until I acquire a new IP (I'm on PPPoE) when the resolv.dnsmasq changes even if I chmod it to 444 !!!!!!
    How can this file be overwritten when it's set to read-only?

    HELP...I'm close to losing my mind as I cannot find a working solution. A VPN is pointless if my DNS is leaking.
  2. koitsu

    koitsu Network Guru Member

    1. You want to use the no-resolv and server (a.k.a. local) options to accomplish what you need -- this should inhibit changing of the DNS servers and setting them only to what you specify in the server argument. Please see the documentation (read the server section first): http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

    I do not know if the GUI properly sets these options -- your setup is not "the norm" per se, so be reasonable.

    2. dnsmasq runs as root (it changes its credentials to user nobody after opening files), which means 444 is not going to do what you think it will -- the daemon can still open a file as create+read+write and "override" or "stomp over" the permissions. Remember: root is special and effectively trumps everything.
  3. ipse

    ipse LI Guru Member

    Super-fast reply koitsu, thanks!
    I sort of figured that out on my own, and fixed the problem by setting the server=x.x.x.x manually in dnsmasq options.
    I still believe that by unchecking "Use received DNS...." I should not have to set the servers manually, as I already filled the DNS fields in the Network Basic settings.
    You're right about the resolv.dnsmasq file, I made some "windoze-user" assumptions - Linux is not my forte :)
    I did make the change as root though - and the file permissions did not change even after it was altered by the daemon. I need to read some more to understand this mechanism.

    PS. If I set the option "no-resolv" wouldn't that mean I'm not using the local DNS server (dnsmasq) and I would have to configure DNS per every client?
  4. ipse

    ipse LI Guru Member

    Do I need to open a bug with Shibby or how does this work? Not sure what value my post would have in his forums (in Polish).
  5. koitsu

    koitsu Network Guru Member

    I think what you're saying is: you feel that by unchecking Use received DNS in the GUI and adding manual IPs of servers to the DNS server list in the GUI, you feel those results should also be put into dnsmasq.conf as server lines. Am I correct?

    The trick here isn't that just the server lines get added -- it's also the the use of no-resolv that causes dnsmasq to ignore reading the contents of /etc/resolv.conf. Again: you have to read the dnsmasq documentation slowly and thoroughly to understand what this affects. If you just add the server lines, that just affects what DNS servers get queried and for what zones. Let me explain (sigh).

    If you added the following lines to dnsmasq.conf:

    All this would do is cause any DNS requests sent through dnsmasq itself to hit first, then if that fails, query any nameserver entries in /etc/resolv.dnsmasq and so on. (Actually, the order of which of the two get queried first is unknown to me -- the docs don't say, so I assume server lines get honoured first -- maybe that's not the case).

    The lines in /etc/resolv.dnsmasq come directly from one of two places: 1) DHCP negotiation with your ISP, or 2) manually entering them under Basic -> Static DNS (for the LAN section) in the GUI.

    On the other hand, if you had this:

    Then any DNS requests sent through dnsmasq itself would go to and only there. /etc/resolv.dnsmasq would not be read at all.

    Starting to understand the picture and why what you propose might work for you but not for others (depends on their needs/configuration)?

    It doesn't matter. Just because the file has user read-only bit set doesn't mean root can't modify the contents of the file. Let me make it clear to you: root can do anything it wants to any file on the filesystem, regardless of permissions. If you want to override this, there are standard ways in Linux to do this -- specifically the chattr command. You would want chattr +i /etc/dnsmasq.resolv. However, I can assure you that by doing this, you will break dnsmasq the next time it restarts or tries to update that file -- you would need to make sure your dnsmasq.conf had the no-resolv line to keep it from even bothering with that file.

    I don't think so -- the DHCP-negotiated DNS servers (between your LAN clients and dnsmasq (which is also the DHCP server)) should still result in the DNS server (router itself) being returned in the DHCP packet. You can check this yourself, obviously, using ipconfig /release followed by ipconfig /renew (and possibly ipconfig /config afterward)[/code]
  6. ipse

    ipse LI Guru Member

    I think I wasn't clear in my problem description, sorry for the confusion (and thanks for the patience to explain the details).

    What's I'm flagging as a bug is the fact that when I have static DNS entries and uncheck " Use received DNS..." I expect that I should NOT see the ISP DNS resolving the querries, as long as my added DNS servers (through GUI in Basic Network) are alive.

    There are a few examples in this forum showing how to use OpenDNS for those inclined to do so: all show that provisioning through the Basic Network settings and unchecking the ISP DNS addition should work.

    Does it make sense? Forget about the VPN at this point, that was only what prompted me to start testing DNS leaks.
    BTW: in /etc/resolv.dnsmasq I ONLY have the ISP DNS servers, despite what I configured manually. I believe this is where the bug is.
  7. koitsu

    koitsu Network Guru Member

    Firmware I use on my Asus RT-N16:


    My config:

    Basic -> Network -> (WAN Section) -> Type -> DHCP
    Basic -> Network -> (LAN Section) -> Static DNS ->
    Advanced -> DHCP/DNS -> Use internal DNS -> unchecked
    Advanced -> DHCP/DNS -> Use received DNS with user-entered DNS -> unchecked

    Resulting files:

    root@gw:/tmp/home/root# cat /etc/dnsmasq.conf
    root@gw:/tmp/home/root# cat /etc/resolv.dnsmasq
    root@gw:/tmp/home/root# cat /etc/resolv.conf
    (Note that the dhcp-option line talking about ntp servers is something I set myself/manually and has no relevance)

    dhcp-option=br0,6, indicates DHCP option type 6 (DNS servers) sets as the DNS server to use, for any DHCP clients on my LAN. Thus, on all my LAN systems, when DHCP is negotiated, the client's DNS server is set to Nothing uses dnsmasq for DNS lookups (i.e. nothing uses as a DNS server).

    You can also see that /etc/dnsmasq.conf has the IP address I specify statically.

    Finally, /etc/resolv.conf shows that for the router itself (i.e. if the router itself needs to do DNS queries), it uses is my FreeBSD box running BIND (named).

    So basically, to keep it simple: I use dnsmasq on my router only for DHCP, not for DNS. :)

    Is this effectively what you want, or do you still want DNS queries from LAN machines being siphoned through dnsmasq?
  8. ipse

    ipse LI Guru Member

    I see your setup is a bit different from what I need (I was looking for some simplistic GUI config...) but it does give you better control over the 2 functions (DNS and DHCP). I'll have to look into something similar as I have a small Linux server I could use in a similar way you did.


Share This Page