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

Script to lock DNS

Discussion in 'Tomato Firmware' started by GOPer, Aug 7, 2012.

  1. GOPer

    GOPer Network Guru Member

    Does anyone know of a script that can be used in Tomato to keep users from bypassing DNS settings? I tried the script below from DD-WRT, but it does not work in Tomato.

    DD-WRT Firmware script:

    iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to $(nvram get lan_ipaddr)
    iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to $(nvram get lan_ipaddr)


    You can prevent users from using their own DNS servers (and hence get around content filtering) by intercepting DNS queries and forcing them to use the DNS servers you specify.
     
  2. kthaddock

    kthaddock Network Guru Member

    just flipp in: Intercept DNS port (UDP 53)
     
  3. GOPer

    GOPer Network Guru Member

    Thanks Kthaddock, I did just that.
     
  4. Cyberian75

    Cyberian75 Network Guru Member

    So what's the working script?
     
  5. Dark_Shadow

    Dark_Shadow Addicted to LI Member

    Probably the nvram variables don't cross from DD-WRT to tomato
     
  6. GOPer

    GOPer Network Guru Member

    No the DD-WRT script will not work in Tomato, but Kthaddock's suggestion did work, just as if I used the DD-WRT script. I change the DNS settings on my PC to try and bypass OpenDNS and Tomato still forward the DNS request to OpenDNS just as I wanted.
     
  7. shadowken

    shadowken Networkin' Nut Member

    I'm using this script in Tomato for years and never failed me , you most propably didn't restart the firewall service after saving the script to refresh the iptables .
    In DD-WRT once you save the script it will restart the firewall automatically .
     
  8. GOPer

    GOPer Network Guru Member

    I didn't think of that! So will you say most scripts in DD-WRT will work in Tomato? Have to tried other scripts?
     
  9. shadowken

    shadowken Networkin' Nut Member

    Yes , indeed :)
    BTW , you don't have to intercept TCP becasue the DNS uses UDP only .
    iptables -t nat -I PREROUTING -i br0 -p udp --dport 53 -j DNAT --to $(nvram get lan_ipaddr) and restart the firewall .
     
  10. GOPer

    GOPer Network Guru Member

    Great! Thanks for the info!
     
  11. shadowken

    shadowken Networkin' Nut Member

    you're welcome :)
     
  12. ntest7

    ntest7 Network Guru Member

    No, DNS can use either UDP or TCP. TCP support is REQUIRED and automatically used if the returned dataset is larger than a UDP packet can handle.

    Most systems can be configured to always use tcp dns queries (handy if you're behind an unreliable link -- often used with satellite or packet radio). This would defeat redirection of udp packets only.

    But in Tomato just check the "intercept DNS" box so you don't have to worry about the details.
     
    koitsu likes this.
  13. shadowken

    shadowken Networkin' Nut Member

    I know that , you're right about it when you have domain and servers do tasks such as Zone Transfers between DNS servers , But for home use UDP is enough to handle home clients queries so easily , I never had problems with it .
     
  14. koitsu

    koitsu Network Guru Member

    Sadly you are incorrect here. UDP is the default protocol, but TCP is used either for zone transfers (which you stated), or when query response data exceeds 512 bytes. This is documented in RFC5966. Quoting RFC:

    In the absence of EDNS0 (Extension Mechanisms for DNS 0) (see below),​
    the normal behaviour of any DNS server needing to send a UDP response​
    that would exceed the 512-byte limit is for the server to truncate​
    the response so that it fits within that limit and then set the TC​
    flag in the response header. When the client receives such a
    response, it takes the TC flag as an indication that it should retry
    over TCP instead.
    ...​
    4. Transport Protocol Selection​
    All general-purpose DNS implementations MUST support both UDP and TCP
    transport.
    You can Google "dns protocol tcp" and read people's explanations as well. So what ntest7 says is correct -- limit both traffic types.
     
  15. shadowken

    shadowken Networkin' Nut Member

    I think you misunderstand me here Koitsu , I didn't say that TCP is a primary protocol for DNS or what (ntest7) stated previously is incorrect !
    anyway i don't want to bump too much in this thread and add to your information , EDNS0 when it's supported it will accept up to 3,072 bytes of DNS response message data in a single UDP packet .
     
  16. koitsu

    koitsu Network Guru Member

    That's also incorrect. EDNS will support up to whatever size the resolver is set to permit; it's configurable on most resolvers, including on Juniper and Cisco equipment. The value is not 3072; it's arbitrary. The default size in BIND/named is 4096 bytes. Other resolvers default to 8192 bytes. If there is a size mismatch it's not a problem because IP fragmentation will take care of splitting up the payload. But yes, that's outside the point of the thread.

    My point is that DNS can/does absolutely use TCP. You stated, and I quote:

    You later imply that you "knew DNS used TCP" but in some roundabout way try to save face by saying "but using the above [UDP only] rules I've had no problems". And this can be explained too:

    With DNS, initial resolver queries use UDP. The protocol will "upgrade" to TCP (meaning the server will set the TC bit in the DNS reply header and inform the querying client that it should re-submit its query using TCP) -- again, see RFC 5966, which I quoted above -- in the case that EDNS is in use (which is pretty much the norm these days).

    Is it possible to initial a query using TCP only, from the get go? Yes, absolutely. Here is proof:

    Code:
    $ dig +tcp rs.dns-oarc.net txt
     
    ; <<>> DiG 9.6.-ESV-R7-P1 <<>> +tcp rs.dns-oarc.net txt
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38697
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 1, ADDITIONAL: 1
     
    ;; QUESTION SECTION:
    ;rs.dns-oarc.net.              IN      TXT
     
    ;; ANSWER SECTION:
    rs.dns-oarc.net.        60      IN      CNAME  rst.x3827.rs.dns-oarc.net.
    rst.x3827.rs.dns-oarc.net. 59  IN      CNAME  rst.x3837.x3827.rs.dns-oarc.net.
    rst.x3837.x3827.rs.dns-oarc.net. 58 IN  CNAME  rst.x3843.x3837.x3827.rs.dns-oarc.net.
    rst.x3843.x3837.x3827.rs.dns-oarc.net. 57 IN TXT "72.20.98.66 DNS reply size limit is at least 3843"
    rst.x3843.x3837.x3827.rs.dns-oarc.net. 57 IN TXT "Tested at 2012-08-10 07:37:29 UTC"
    rst.x3843.x3837.x3827.rs.dns-oarc.net. 57 IN TXT "72.20.98.66 sent EDNS buffer size 4096"
     
    ;; AUTHORITY SECTION:
    x3843.x3837.x3827.rs.dns-oarc.net. 57 IN NS    ns00.x3843.x3837.x3827.rs.dns-oarc.net.
     
    ;; ADDITIONAL SECTION:
    ns00.x3843.x3837.x3827.rs.dns-oarc.net. 58 IN A 149.20.58.136
     
    ;; Query time: 920 msec
    ;; SERVER: 72.20.98.66#53(72.20.98.66)
    ;; WHEN: Fri Aug 10 00:37:29 2012
    ;; MSG SIZE  rcvd: 299
    
    Before initiating the above dig query, on the same machine I was running a packet capture (tcpdump -p -i em0 -l -n -s 16384 "udp and port 53") and nothing was returned, meaning the above dig used TCP only:

    Code:
    # tcpdump -p -i em0 -l -n -s 16384 "udp and port 53"
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on em0, link-type EN10MB (Ethernet), capture size 16384 bytes
    ^C
    0 packets captured
    32 packets received by filter
    0 packets dropped by kernel
    
    Thus you need to block both UDP port 53 and TCP port 53, which is exactly what ntest7 was explaining.

    If you read the TXT record responses you'll see what size was effectively used. The folks over at OARC provide a wonderful service that can help you with EDNS.

    I hope my long/verbose technical explanation will suffice, because there is nothing I can say past this point that will help.

    You stated boldly that DNS only uses UDP (that is wrong). People make mistakes all the time, it's human and it's totally cool -- see some of my other posts here where people have corrected me, I'm not perfect either! -- but there's no sense in continuing to try and save face for some strange reason. There's too much misinformation on the Internet as is.
     
  17. shadowken

    shadowken Networkin' Nut Member

    looks like you insist to misunderstand so i don't want to reply to anything about this issue because it will lead to another misunderstanding .
     

Share This Page