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

Shibby: Issues with dnscrypt-proxy

Discussion in 'Tomato Firmware' started by blackwind, Apr 14, 2013.

  1. blackwind

    blackwind Serious Server Member

    I've disabled dnscrypt-proxy because it needlessly adds five lines to my logs every hour:
    Apr 13 20:09:16 router daemon.info dnscrypt-proxy[779]: Refetching server certificates
    Apr 13 20:09:17 router daemon.info dnscrypt-proxy[779]: Server certificate #1358460951 received
    Apr 13 20:09:17 router daemon.info dnscrypt-proxy[779]: This certificate looks valid
    Apr 13 20:09:17 router daemon.info dnscrypt-proxy[779]: Server key fingerprint is F0DA:9278:CC0F:CDF9:BAED:8A18:B9FD:E61C:6596:6D4A:432F:FCA3:390B:5A3A:6FA7:642F
    Apr 13 20:09:17 router daemon.info dnscrypt-proxy[779]: Proxying from to
    This makes tracking down meaningful log entries that much harder, not to mention rendering the "View Last 25/50/100 Lines" links completely worthless. To resolve this, I propose removing these five particular log entries from the dnscrypt-proxy source. As far as I can tell (but please do correct me if I'm wrong), syslog filtering isn't possible with BusyBox's implementation.

    I've also noticed that the default QoS settings flag DNScrypt traffic as Crawl. To resolve this, I propose adding port 443 to the DNS rule.
  2. lancethepants

    lancethepants Network Guru Member

    I've also have noted the misclassification of the DNSCrypt traffic in QOS. I have not used Shibby's integrated DNSCrypt, but rather use my own binary loaded in /jffs.

    Unfortunately it doesn't appear that shibby allows for custom command line arguments with his integration. I've opted to run DNSCrypt on the standard DNS port, rather than on port 443, where DNSCrypt defaults to.
    Despite running on the Standard DNS port, it will still be misclassified. I've noted in this thread the following.


    I believe Shibby is also using Toastman's QoS rules.

    I personally would advise against adding port 443 to the DNS Service rule. This will classify much more that DNS and give it all highest priority.

    If Shibby provided the ability to add command line arguments, this would allow one to use port 53 instead of 443. You would also be able to specify where to write the logs files, and keep them out of the syslog if desired. Perhaps he may consider integrating this option.

    You could also follow the tutorial previously noted and could also achieve what you've described.
  3. occamsrazor

    occamsrazor Network Guru Member

    Instead of adding 443, couldn't one just add the destination server address of the OpenDNS servers as a high priority rule?
  4. lancethepants

    lancethepants Network Guru Member

    Good thought. That would work perfectly, and would take care of the DNS priority issue.
  5. blackwind

    blackwind Serious Server Member

    Didn't notice this in the short time I worked with it on Saturday. occamsrazor's solution, then, is, indeed, the superior one.

    Until Shibby resolves the logging issue, I'm executing the following script when JFFS is mounted:

    cp /usr/sbin/dnscrypt-proxy /jffs
    echo -e "#!/bin/sh\\n/jffs/dnscrypt-proxy --logfile=/dev/null \"\$@\"" > /jffs/dnscrypt-helper
    chmod +x /jffs/dnscrypt-helper
    mount --bind /jffs/dnscrypt-helper /usr/sbin/dnscrypt-proxy
    /usr/bin/killall -HUP dnscrypt-proxy
    Kind of an ugly hack, but it does the trick.
  6. shibby20

    shibby20 Network Guru Member

    by default dnscrypt-proxy is running with options "-d -P 40".
    I can do something like (In basic -> network GUI):
    [checkbox] Enable DNSCrypt-proxy: enabled/disabled
    [text field] Startup Parameters: [-d -P 40] suffix: <link to manuall>

    and anybody will be able to change startup options. What do you think?
  7. jerrm

    jerrm Network Guru Member

    I think that is more than reasonable. I didn't like the idea of modding the source for a few log lines, but I always err on the side of more logging than less.
  8. blackwind

    blackwind Serious Server Member

    That would definitely be helpful one way or the other (and should really be the standard for any daemon without extensive configuration options in the web interface), but ideally, I'd still like those five lines removed. If something goes wrong, having my logs output to /dev/null doesn't exactly help, right? I *do* want dnscrypt-proxy entries in my syslog where appropriate -- I just don't want the worthless hourly noise.
  9. koitsu

    koitsu Network Guru Member

    I will fight against your recommendation tooth and nail, because the logging lines are **INCREDIBLY** important when it comes to security. I cannot stress this enough. If the servers' certificate suddenly becomes invalid, or the server is hacked, or (the worst of the bunch) there is a MITM (man-in-the-middle) attack going on, without those logging lines you'd have no idea what's happening. The same goes for the situation where the server certificate can't be fetched (even if it could be the first time).

    shibby: DO NOT remove those logging lines. I repeat: *DO NOT*.

    The OP should contact the dnscrypt-proxy folks directly and ask via a support ticket for a command-line flag (or keyword in the configuration file (if there is one)) to inhibit those lines / decrease the logging verbosity. The actual lines in the code SHOULD NOT be removed.

    This also has the added benefit of decreasing the number of "one-off" patches between third-party applications in TomatoUSB vs. a non-TomatoUSB system. The firmware maintainers try very hard to keep the number of "one-off" customisations (vs. stock source) down to a minimum, because there are already hundreds (not exaggerating -- in OpenWRT's case I believe they have multiple hundreds). Solve the issue at the core.

    This logging model is how syslog works on UNIX, and has worked for almost 30 years. There is no "simple filtering" mechanism for stock syslogd based on strings/etc.. There is syslog-ng (available via Entware) if you want this kind of fine-grained string-based filtering capability.
    dc361 and jerrm like this.
  10. blackwind

    blackwind Serious Server Member

    Certainly, these are valid concerns, but:
    1. Many of us don't have the space for syslog-ng. I, for one, wouldn't dare run a system service off the network, and I lack the space to install it on JFFS.
    2. dnscrypt-proxy logs many, many other events, including invalid certificates. If there's a problem, you'll know it, and you'll spot it much quicker without the hourly noise than you will comparing certificate fingerprints by hand.
    I'll petition the author for a log-level setting. If he implements one, that's definitely the ideal solution, but if we have to choose between excluding these five lines or logging to /dev/null, I stand firmly behind my suggestion.
  11. koitsu

    koitsu Network Guru Member

    Understood. If the dnscrypt-proxy folks give you lip over wanting this feature (e.g. "I don't see the purpose, you're crying over 5 lines..."), let me know and I'll show up/chime in there + give them my two cents, or (if I have the desire/time) go look at the code and give them a diff/patch.
  12. jerrm

    jerrm Network Guru Member

    I couldn't agree more strongly. 120 lines a day is nothing. I do full url logging at several sites, logs are 10-100MB+ daily, and getting to the data needed has never been a problem.

    Even if there were no legitimate reason for the entries, I would never consider maintaining a patch for it if I were Shibby, but ultimately it will be his call.
  13. blackwind

    blackwind Serious Server Member

    Issue #48 posted at GitHub. Fingers crossed.
  14. shibby20

    shibby20 Network Guru Member

    I will not. I will add parameters field and anybody will be able to launch dnscrypt with own startup parameters and redirect logs to /dev/null or to another file ie: /opt/logs/dnscrypt.log. They will able to custom any option like port, host or ipv6 support. This IMO will be the best solution to have most tomato users :)
  15. blackwind

    blackwind Serious Server Member

    Good news: "--loglevel" was just added minutes ago. If you're watching, thanks, Frank!

    Please include this update in your next build in addition to the parameters field, Shibby, and we can have the best of both worlds. :)
    koitsu likes this.
  16. shibby20

    shibby20 Network Guru Member

    ok i will.
    blackwind likes this.
  17. lancethepants

    lancethepants Network Guru Member

    Wow, quick results. Ask and ye shall receive.
  18. blackwind

    blackwind Serious Server Member

    Well, the setting is in the latest build, but it apparently wasn't implemented correctly and does absolutely nothing. Too bad. At least the parameters field can now be used instead of my kludgy hack, I guess.

    EDIT: It appears that both --loglevel and --logfile are ignored when dnscrypt-proxy is launched via Tomato, but if you manually kill and relaunch the process using the exact same parameters, both function as expected.
  19. shibby20

    shibby20 Network Guru Member

    very strange :/
  20. ryzhov_al

    ryzhov_al Networkin' Nut Member

    shibby20, IMHO, it's better to disable selection of best onetimeauth implementation in libsodium. Otherwise, dnscrypt-proxy will start ~20 seconds even on RT-N66U:
    admin@RT-N66U:/tmp/mnt/SDCARD/tmp# time dnscrypt-proxy --help > /dev/null
    21.63user 0.37system 0:22.00elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (0major+0minor)pagefaults 0swaps
    All those 20 seconds CPU will be loaded up to 100%.
    koitsu and shibby20 like this.
  21. FameWolf

    FameWolf Serious Server Member

    Ok so you got loglevel added....does anyone have an example command line to remove the certificate errors?
  22. lancethepants

    lancethepants Network Guru Member

    # dnscrypt-proxy --help
    -m    --loglevel=...
    loglevel takes an int > 0.
  23. blackwind

    blackwind Serious Server Member

    Finally took some time to investigate this further. It seems the issue occurs only when multiple parameters are specified. For example, "-m 5" works, but "-m 5 -r" produces:
    Apr 22 18:59:28 ROUTER user.err syslog: Invalid max log level: [ 5 -r]
    Again, this occurs only when dnscrypt-proxy is launched via Tomato.
  24. gijs73

    gijs73 LI Guru Member

    Hello shibby,

    when will you release the update, so I can use DNScrypt?


Share This Page