Page 1 of 2 12 LastLast
Results 1 to 10 of 15
  1. #1
    Newbie
    Join Date
    Sep 2020
    Posts
    4

    Default No support for DNS over TLS?

    I just heard of Untangle. Thinking of putting it on my pfSense box. I was trying to see if Untangle supports DNS over TLS. I only found one post from 2018 that says it doesn’t.

    Not getting any relevant results when googling.

    Am I missing something or does Untangle not support DNS over TLS?

  2. #2
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    25,268

    Default

    Untangle does not support DNS over TLS, and it likely will never support DNS over TLS until such time as DNSMasq supports DNS over TLS.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  3. #3
    Untangle Ninja
    Join Date
    May 2008
    Posts
    1,335

    Default

    Pi-hole is probably the easiest way to get "DNS over TLS". Google will tell you how.

  4. #4
    Newbie
    Join Date
    Sep 2020
    Posts
    4

    Default

    Quote Originally Posted by sky-knight View Post
    Untangle does not support DNS over TLS, and it likely will never support DNS over TLS until such time as DNSMasq supports DNS over TLS.
    Got it. Thank you!

    Quote Originally Posted by donhwyo View Post
    Pi-hole is probably the easiest way to get "DNS over TLS". Google will tell you how.
    I will look into it when I try Untangle. TBH, I like my DNS over TLS and will probably stick with pfSense until Untangle adds the capability. I'd rather not go down the route of over complicating with pi-hole.

  5. #5
    Untangle Ninja
    Join Date
    May 2008
    Posts
    1,335

    Default

    Quote Originally Posted by imthenachoman View Post
    I'd rather not go down the route of over complicating with pi-hole.
    PF and Untangle isn't complicated? LOL

  6. #6
    Newbie
    Join Date
    Sep 2020
    Posts
    4

    Default

    Quote Originally Posted by donhwyo View Post
    PF and Untangle isn't complicated? LOL

    It is another artificial dependency. I don't use/want pi-hole but I want DNS over TLS. I still might give Untangle a try cause some folks I know are raving about it. Will see.

  7. #7
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,606

    Lightbulb Dnssec

    A slightly off-topic idea:

    Although not equivalent, DNSSEC is possible with dnsmasq in NGFW.

    In #config/network/advanced/dns_and_dhcp - Custom dnsmasq options:

    Code:
    # Validate DNS replies and cache DNSSEC data. When forwarding DNS queries, dnsmasq requests the DNSSEC records needed to validate the replies. 
    # The replies are validated and the result returned as the Authenticated Data bit in the DNS packet. In addition the DNSSEC records are stored in the cache, 
    # making validation by clients more efficient. Note that validation by clients is the most secure DNSSEC mode, but for clients unable to do validation, 
    # use of the AD bit set by dnsmasq is useful, provided that the network between the dnsmasq server and the client is trusted. 
    # Dnsmasq must be compiled with HAVE_DNSSEC enabled, and DNSSEC trust anchors provided, see --trust-anchor. 
    #
    # Because the DNSSEC validation process uses the cache, 
    # it is not permitted to reduce the cache size below the default when DNSSEC is enabled. 
    #
    # The nameservers upstream of dnsmasq must be DNSSEC-capable, ie capable of returning DNSSEC records with data. If they are not, 
    # then dnsmasq will not be able to determine the trusted status of answers and this means that DNS service will be entirely broken.
    #
    # * NOTE: Your upstream DNS server must support DNSSEC.
    conf-file=/usr/share/dnsmasq-base/trust-anchors.conf
    dnssec
    
    # Set the size of dnsmasq's cache. The default is 150 names. Setting the cache size to zero disables caching. Note: huge cache size impacts performance.
    # * big enough to be useful
    cache-size=1000
    Note: In dnsmasq, a "huge cache size" is essentially unobtanium on modern hardware. A previous 10,000 name clipping value was removed a couple of years ago.
    Personal experience with dnsmasq as a caching DNS server for a few
    hundred fairly active clients shows no notable performance impact even
    when allowing the maximum cache size to be > 100,000 (query reply time
    from cache is on the order of < 5 msec). It may always be that I miss
    something but even when dnsmasq's cache would be 10 (or more) times
    slower, it would still be much faster than when we'd periodically ask
    upstream servers.

    Best,
    Dominik
    - from http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q2/012189.html

    However, there is no need to approach that (now a logged warning) 10,000 limit, either.
    So with the previous cache size, less than 4% of queries cause eviction
    of a name from the cache before the time-to-live expires and it
    disappears anyway. Only a small fraction of those will be re-queried so
    the number of extra cache-misses is in the noise. I'd say that the cache
    size you had before was pretty much optimal, but in response you tried
    to increase it to more than the total number of cache insertions ever,
    during that run of dnsmasq.

    ...

    The local copy of dnsmasq here, which is handling a network of a dozen
    machines, has a tiny cache, and very similar stats. It just doesn't need
    to be any bigger. (and that instance is doing DNSSEC, so the cache
    holding all sorts of DNSSEC records too.)

    cache size 600, 50/28526 cache insertions re-used unexpired cache entries.

    Simon Kelley simon at thekelleys.org.uk
    From: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2018q2/012198.html

    Disclaimer:
    Use of these options is not supported by Untangle. Use at your own risk.
    This configuration was developed for my purposes, on my system, based on my experience and opinions.
    It is provided for informational and educational purposes only. It is not advice on what you should do.
    Certain options, if copied directly, are likely to stop DNS/DHCP from working on your local network.
    It is provided to spur research into the use of these options for your own purposes. Understand them before you implement any of it.


    Most of the comment text was copied from the man pages at: http://www.thekelleys.org.uk/dnsmasq...smasq-man.html

    There is more valuable documentation at: http://www.thekelleys.org.uk/dnsmasq...q.conf.example
    Last edited by Jim.Alles; 09-29-2020 at 12:55 PM.

  8. #8
    Untangle Ninja Jim.Alles's Avatar
    Join Date
    Jul 2008
    Location
    Central PA
    Posts
    2,606

    Default

    Quote Originally Posted by sky-knight View Post
    Untangle does not support DNS over TLS, and it likely will never support DNS over TLS until such time as DNSMasq supports DNS over TLS.
    Indeed.
    And current indications are still that dnsmasq is not likely to implement DoT.

    from: Simon Kelley {simon at thekelleys.org.uk} September 8, 2015
    I have a few, fairly orthogonal, reponses to this.

    First to, "What would it take to implement in dnsmasq?"

    It actually not that easy to do. DNS-over-TLS happens, by necessity,
    over TCP. Your interesting client support scenario would require that
    dnsmasq receive queries over UDP and forward then over TCP-with-TLS.
    Dnsmasq is optimised to forward DNS-over-UDP queries very efficiently.
    It does a passable job forwarding DNS-over-TCP. The architecture pretty
    much precludes receiving over UDP and then forwarding over TCP, which is
    a problem, as that's exactly what's needed for the TLS case. Lonnie's
    example using DNSCrypt is probably the most sensible way to implement
    this, as least to start with.

    Second, "is the proposed mechanism worth implementing".

    Frankly, it sucks. The problem is that it specifies the same simple
    framing for DNS queries and answers over TCP that's used in RFC1035. The
    requestor sends the query, preceded by its length, then listens for the
    answer, again preceded by its length. The effect is that you need one
    TCP connection for DNS query in-flight. But now you need a TLS
    negotiation for each one too. Imagine you open a typical busy web page,
    it has 50 different DNS resolutions to do, and they all get fired off at
    once. The DNS resolver now needs 50 TLS connections to your ISPs DNS
    server, or it has to start serialising the DNS resolution. Once you have
    you 50 answers, your DNS resolver is mandated to keep the connections
    around, so that it doesn't need to open them again when you go to the
    next page. So your ISP's DNS server, instead of doing stateless UDP, has
    to hold 50 TLS connections for every customer. Really? The hardware
    suppliers will be pleased. Much, much better to define a method to
    multiplex multiple questions and answers over _one_ TLS stream.

    Third "should it go in dnsmasq".

    Probably, eventually. We're pretty stretched implementing and
    maintaining a whole slew of well-established protocols. There's not much
    slack for experimental stuff in the stable releases.

    Sorry, that's not what you want to hear.

    I really should post my critique to the WG mailing list.


    Cheers,

    Simon.
    http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q3/009837.html

    It appears that a proxy is the best suggestion.
    Last edited by Jim.Alles; 09-29-2020 at 10:06 AM.

  9. #9
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    25,268

    Default

    And Simon's comments spell out clearly why I despise DoH and DoT, they're both broken in that regard.

    The Internet as we know it is horridly dependent on the stateless nature of UDP supporting DNS. Now I have no issues with resolvers being updated to use HTTPs or TLS to authenticate the DNS server they are communicating with. But to do so for each and every resolution introduces a BUCKET of load.

    You know the lag you get when you use any VPN protocol? We're talking about injecting that onto the simple DNS resolution process. Do you want more latency? Because this is how you get more latency... Though latency is the wrong word, this is more like extended page load times... but it's the same idea. It takes more work to connect to any reasonably complicated resource.

    To make matters worse, we have a market full of people that think DoT, DoH, and 3rd party VPNs actually do something to improve privacy, when we have no evidence of that actually being the case. The only thing they do is change the scope of who gets to peek at the data. In effect, only granting the end user the power to choose specifically who gets to sell their data. Which the consumer already has the power over, by choosing their ISP. In jurisdictions where ISP choice is limited, that's something the user needs to take up with local governments. Here in the US specifically, the city and county councils are to blame for the oligarchies we deal with. These elections can be swung with 10 votes... so a modicum of involvement is all it takes to resolve the anti-competitive nature of the ISP.

    Yet, we don't do it... and look to useless "improvements" in technology instead.

    So yeah... I'm with Simon, too much work, too little benefit, and I honestly could care less DNSMasq doesn't support it. Should Untangle? Perhaps, but doing so means another module. And unless someone creates one and submits it to the code tree for "free", that's going to be a paid feature if it happens at all. Which will start yet another forum fire... but now I'm just advertising my cynicism.
    Last edited by sky-knight; 09-29-2020 at 09:44 AM.
    Jim.Alles and CMcNaughton like this.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  10. #10
    Newbie
    Join Date
    Sep 2020
    Posts
    4

    Default

    Quote Originally Posted by sky-knight View Post
    And Simon's comments spell out clearly why I despise DoH and DoT, they're both broken in that regard.

    To make matters worse, we have a market full of people that think DoT, DoH, and 3rd party VPNs actually do something to improve privacy, when we have no evidence of that actually being the case. The only thing they do is change the scope of who gets to peek at the data. In effect, only granting the end user the power to choose specifically who gets to sell their data. Which the consumer already has the power over, by choosing their ISP.
    You have convinced me. I've been using DoT for a bit but yes, you're right, it doesn't move the privacy dial enough. MTM attacks are a concern but all they'd be able to see is where you're trying to go.

    I guess I'm back to giving Untangle a shot w/o DoT.
    Jim.Alles likes this.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2