Sunday, July 25, 2021

Running A Root Server Locally On Your DNS Resolver

Introduction

A DNS recursive resolver is typically primed with a list of Root Servers which it uses to resolve queries. When the recursive resolver receives a query, it queries to one of the root servers to get back a list of top level domain (TLD) name servers. It then queries those TLD name servers to get back another list of name servers hosting the domain name. This process is done recursively until the an answer for the query is resolved.

The DNS recursive resolver maintains a cache to avoid frequent queries and thus improving its performance. However, when the cache expires or is flushed, the recursive resolution process is performed again.

During the recursive resolution process, there is a possibility that the response from root server is delayed due to network issues or other events like the root server being under a Denial of Service (DoS) attack. There could also be passive monitoring of DNS requests going to root servers by an on path actor compromising privacy.

To prevent these issues and to improve resiliency there is a good option to run a Root Server locally on your DNS resolver.

There are several advantages of running a Root Server locally:

  • The Root zone contains all the TLD name servers and their IP addresses. This allows the DNS resolver to skip the initial query to the Root Server and directly query to the TLD name servers saving time.
  • Since the Root zone is running locally, queries for non existent top level domain (TLD) names are resolved locally.
  • This also improves resiliency since the Root zone is local and thus there is no immediate dependency on the Root Servers for recursive resolution.

There are a few disadvantages too:

  • If there are any updates to the Root zone, it will take slightly longer for those changes to sync to your local Root zone. Though there wont be much of a noticeable issue.
  • If your local Root zone is not updating due to any reason and it was not detected, then the local Root zone will expire after 7 days (as per Root SOA Expiry). This may cause some DNS resolvers to fail to resolve any queries when cache expires. Technitium DNS Server however will fall back to root hints in such a case.

Considering both the advantages and disadvantages, its good to have a Root zone locally for a recursive resolver.

Sourcing The Root Zone

The root zone is available from ICANN DNS servers via zone transfer (AXFR-over-TCP):

  • xfr.cjr.dns.icann.org (192.0.47.132, 2620:0:2830:202::132)
  • xfr.lax.dns.icann.org (192.0.32.132, 2620:0:2d0:202::132)

The following Root Servers also support zone transfer (AXFR-over-TCP):

  • b.root-servers.net (199.9.14.201, 2001:500:200::b)
  • c.root-servers.net (192.33.4.12, 2001:500:2::c)
  • d.root-servers.net (199.7.91.13, 2001:500:2d::d)
  • f.root-servers.net (192.5.5.241, 2001:500:2f::f)
  • g.root-servers.net (192.112.36.4, 2001:500:12::d0d)
  • k.root-servers.net (193.0.14.129, 2001:7fd::1)

It is recommended to have DNSSEC enabled on your DNS resolver. Use recursive ACL to make sure that your DNS resolver accepts queries only from known clients to protect from DNS amplification attacks.

Configuration

To configure your DNS server, you just have to create a secondary zone for "." domain name which is a fully qualified domain name (FQDN) for the Root zone.

On Technitium DNS Server, configure the secondary zone as shown in the screenshot below:

Configuring Local Secondary Root Zone

Once you have the secondary zone created, wait for a few seconds for the DNS server to perform the zone transfer. The Root zone meanwhile will show as expired. If its taking a lot of time, do check the DNS server logs to see if there are any errors being logged.

After the secondary zone is synced, you will see all the root zone records. There are thousands of records and it may take a couple of seconds for the DNS panel to list all of them. Here is what you should see on the DNS panel:

Local Secondary Root Zone

Note: Having a locally configured Root zone will be always prefered over forwarders by the DNS server and thus any forwarders that are configured in Settings will be ignored.

References

If you have any queries do write in the comments section below or send an email to support@technitium.com.

Sunday, March 14, 2021

Creating And Running DNS Apps On Technitium DNS Server

Technitium DNS Server version 6.0 has just been released with a new shiny feature called DNS Apps that allows you to build and run custom applications on your DNS server. Just like how a web application runs on a web server, think of a DNS application running on a DNS Server. This makes the DNS server more powerful allowing you to run custom apps based on your own business logic.

Technitium DNS Server v6
Technitium DNS Server v6

DNS Apps

The DNS applications are written in .NET as a class library project. The compiled DLL file with its references are then zipped and installed on the DNS server as an App. There are ready to use apps available in the DNS App Store to install from the DNS Server web console. The source code too is available on GitHub which can be forked and modified as required.

Technitium DNS Server With The Default DNS App Installed
Technitium DNS Server With The Default DNS App Installed

APP Record

To use these apps you need to add the proprietary APP record to your primary zone. The APP record specifies the name of the installed app, the class path that handles the requests, and custom record data if any. When the DNS server received a request that hits the APP record, the request is then handed over to the installed DNS app as specified by the APP record. From here, the DNS App is responsible to generate a valid response to the DNS request. This entire process will look quite simple once you try to configure the APP record.

Technitium DNS Server APP Record Configuration
The APP Record Configuration

You can have an APP record per sub domain name and one APP record for the zone apex. If a sub domain or a record exists, the DNS server will use it to respond to the DNS request. If a sub domain or a record does not exists and you have an APP record configured at the zone apex then the APP record's request handler is called by the DNS server and the response returned by the DNS App is sent back to the requesting client.

A Sample DNS Zone With APP Records
A Sample DNS Zone With APP Records

I am running a sample DNS zone that has an APP record which is configured for a DNS App called "What Is My DNS". The DNS App essentially just returns the IP address of the client querying it and so can be used to find out the IP address of your DNS server. 

To try it, you can query for mydns.home.zare.im using nslookup on the command line and you will get a response back containing the IP address of your DNS server. If you query for the domain name directly to the name server ns1.technitium.net, you will get a response back with your own public IP address. You can see the source code of this DNS App here.

Creating DNS Apps

Since the DNS Apps are .NET based, to create your own DNS App you will require to have Visual Studio 2019 installed with .NET 5 SDK. The app itself is a .NET 5 class library project and requires two references to be added to the project namely, DnsApplicationCommon.dll and TechnitiumLibrary.Net.dll. Both of these DLLs are included in the DNS server setup and you can find them in the directory where the DNS server is installed.

Once you have the class library project ready with the two DLL references added, you can now create a class which implements IDnsApplicationRequestHandler interface. In here, there are two important functions to implement.

The first is InitializeAsync() which is called when the DNS App first starts or when the app config is updated from the web console to allow reloading the latest config. The app config is a simple text based config file for any initial config that the app may require e.g. if the app uses a database, you can have the database connection string stored as the config.

The second and the most important function is ProcessRequestAsync() which gets called by the DNS server when the request hits an APP record. This method provides the original request, the IP address of the client, and other relevant details that may be required to process the request. The response returned by this function is returned to the client.

The implementation uses Task based Async programming to allow you to scale the DNS application easily.

The IDnsApplicationRequestHandler interface also requires implementing two properties. The Description property allows you to provide a description for the app which gets displayed on the web console. And the ApplicationRecordDataTemplate property allows you to provide a template with the format of record data in the APP record that is expected. This template is displayed to the user to help with adding the APP record with the expected record data.

You can always refer to the code from the Default DNS App on GitHub to get your app working.

Deploying DNS Apps

Once you have the DNS App code ready, all you need to do is compile the code in Release mode and create a new zip file containing all the compiled files. In the DNS server web console, go to the Apps tab and click Install. Give a name for the app you are installing, browse the zip file that you had created, and proceed to install the app. Now as the app is installed, you will see it listed with the details like class path and the description on the web console. You can now go to the Zones tab and edit your primary zone to add an APP record for the DNS App.

Technitium DNS Server Install DNS App
Installing DNS App

You can now try to test your code by querying This Server using the DNS Client tab. The DNS Client will show you the output that your DNS App returns.

Conclusion

With DNS Apps feature, you can develop apps that provide simple split horizon responses or complex response based on things like geo-location and the health of the web server configured in the record. The apps can be coded to use databases with any business logic to process responses. This unique feature makes your DNS server even more powerful.

If you have any queries or comments, do write them below. You can also email your queries to support@technitium.com or discuss them on /r/technitium on Reddit.

Saturday, October 10, 2020

How To Host Your Own DNS-over-HTTPS And DNS-over-TLS Services

With Technitium DNS Server, you can not just consume DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) services using forwarders but you can also host these services yourself. There can be several reasons to host your own DoH or DoT service. You may wish to have better privacy by not sharing your data with public DNS providers. Or your network or ISP blocks popular DoT and DoH services and also interferes with unencrypted DNS traffic.

In this post, we will setup DoT and DoH services on a cloud server and configure a locally running Technitium DNS Server to use the DoH service as a forwarder bypassing any network restrictions that may be in place. 

Home Network

In the above home network diagram, the locally running Technitium DNS Server is installed on a desktop PC or a Raspberry Pi that is connected to your WiFi router. The Cloud Linux server will host the DoH service which will be configured as a forwarder in the locally running DNS server on your network.

Once the configuration is complete, all DNS traffic will be encrypted between your locally running DNS server and the DoH server running on the cloud server. This effectively means that all your local DNS traffic will exit from the cloud server and thus wont be visible to your network provider or your ISP.

Requirements

You need a domain name which you can get from any domain name registrar like Name.com (referral link). If you already own a domain name then you can use a sub domain on it for hosting these services. A domain name is required since both these services run over TLS protocol which uses SSL/TLS certificate to work. A domain name will usually cost around $13/yr which depends on the extension. You can check for the pricing here.

You need a Linux server which you can get from any cloud hosting provider like Digital Ocean (referral link). You can get a server for as low as $5/mo with 1GB RAM. I would recommend to create a server with Ubuntu Server as the OS since this blog post will be using the same.

Installation

We will be using Ubuntu server in this blog post but you can choose any distro of your choice and follow similar instructions.

You can install Technitium DNS Server using the single line installation command as shown:

curl -sSL https://download.technitium.com/dns/install.sh | sudo bash

If the above command fails since you do not have curl installed, install it as shown below and try the above command again:

sudo apt update
sudo apt install curl

You can also manually install the DNS server by following the install instructions.

We will be using Let's Encrypt TLS certificate and will be using certbot which does automatic certificate renewal for Let's Encrypt. Run the commands below to install certbot:

sudo apt update
sudo apt install certbot

Configuration

To proceed with the DNS configuration, login to the DNS server web console using the server's IP address and port 5380. For example, if your server's IP address is '1.2.3.4' open http://1.2.3.4:5380/ in your web browser. Chrome, Firefox and Edge web browsers are supported well.

The first configuration to be done is to enable Optional DNS Server Protocols i.e. DNS-over-HTTPS and DNS-over-TLS in the DNS server Settings as shown below. Save the settings by clicking Save Settings button at the bottom.

Optional DNS Server Protocols
Optional DNS Server Protocols

Note: If you wish to only run DoH service, enable only the DNS-over-HTTPS protocol in the settings.

Since, the DNS server requires the certificate in PKCS #12 (.pfx) format, we need to convert the issued certificate using the openssl command. To do that, we will create a small script file at /etc/letsencrypt/renewal-hooks/post/pkcs12convert.sh using nano editor.

sudo mkdir -p /etc/letsencrypt/renewal-hooks/post/
sudo nano /etc/letsencrypt/renewal-hooks/post/pkcs12convert.sh

Copy the commands as show below in the nano editor. Here, replace 'example.com' with your domain name and 'mypassword' with a password of your choice or keep it blank to generate the pfx file with no password.

#!/bin/sh
openssl pkcs12 -export -out /etc/letsencrypt/live/example.com/example.com.pfx -inkey /etc/letsencrypt/live/example.com/privkey.pem -in /etc/letsencrypt/live/example.com/cert.pem -certfile /etc/letsencrypt/live/example.com/chain.pem -passout pass:mypassword
echo "pkcs#12 generated!"

Save the script by exiting the editor using CTRL+X keys. We need to make this script excutable by using the following command:

sudo chmod +x /etc/letsencrypt/renewal-hooks/post/pkcs12convert.sh

This pkcs12convert.sh script will be automatically executed by certbot after renewing the certificate.

We also need to create a root directory for the DoH web server so that it can be used with certbot as a web root:

sudo mkdir /etc/dns/dohwww

Now, we can run certbot command with the webroot plugin to issue the TLS certificate as shown below:

sudo certbot certonly --agree-tos --email admin@example.com --webroot -w /etc/dns/dohwww -d dns.example.com

Note: Here, replace 'example.com' with your domain name. In this example, we have used 'dns.example.com' in which the sub domain 'dns' gives a good idea that you may be running a DoH service. You may wish to avoid this by not using sub domain names like dns, doh or dot and instead use something which is very common like "mail", or "blog", etc. This will make it difficult for someone on your network to identify if you are using a DoH service by looking at the domain name.

Once the certbot command succeeds, you will see the path of the certificate that was generated in the output which should be in the /etc/letsencrypt/live/<your-domain>/ directory.

Below is the output that you should see if the certbot command succeeds.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for dns.example.com
Using the webroot path /etc/dns/dohwww for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/dns.example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/dns.example.com/privkey.pem
   Your cert will expire on 2021-01-08. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Since the certificate has been issued for the first time, we need to manually executed our pkcs12convert.sh script once to generate the pfx certificate.

sudo /etc/letsencrypt/renewal-hooks/post/pkcs12convert.sh

We can now configure the DNS server with the pfx certificate file path in the settings as shown below:

Optional DNS Server Protocols With TLS Certificate
Optional DNS Server Protocols With TLS Certificate

Type in the same password that you had used while generating the pkcs12 certificate for the TLS Certificate Password option.

Save the settings by clicking the Save Settings button at the bottom so that the DNS server can start the DoT and DoH services using the newly configured TLS certificate. You may want to check the DNS Server logs from the web console to find out if there were any errors while starting these services.

Testing The Service

For DoT service, you need to use the domain name that was used to generate the certificate with port 853. Thus your DoT configuration for clients will be tls-certificate-domain:853.

For DoH service, you need to use the domain name that was used to generate the certificate in a URL format. Thus you DoH configuration for clients will be https://tls-certificate-domain/dns-query.

You can test both the DoH and DoT services using the DNS Client tool. Put in the DoT tls-certificate-domain:853 or the DoH url https://tls-certificate-domain/dns-query as the Server in the DNS Client, type in a domain name, select an appropriate protocol either TLS or HTTPS and click Resolve to test both the services.

Note: By default, the "Allow Recursion Only For Private Networks" recursive resolver option (as shown below) in the DNS server settings is enabled and thus the DNS server will refuse to respond with an answer (RCODE=Refused) when you test it with the DNS Client. You will need to disable this option to be able to use these services from the public Internet.

Recursive Resolver Options
Recursive Resolver Options

Once the tests are successful, you can configure your locally running Technitium DNS Server to use these services as a forwarder. Once you have configured the service as a forwarder your local DNS traffic will bypassing all your network or ISP restrictions.

Technitium DNS Server Forwarder Configuration
Technitium DNS Server Forwarder Configuration

You can also configure your Firefox web browser directly with the custom DoH URL. This will work only for Firefox and all other applications on your computer will keep using the default DNS server configured in your network settings.

To configure Firefox with custom DoH, go to Options > General and scroll down to find Network Settings. Click on the Settings button and find the DoH option at the bottom as shown below:

Firefox Custom DoH Option
Firefox Custom DoH Option

Auto Renewing TLS Certificate

Since, the certificate obtained from Let's Encrypt expires in 90 days, certbot automatically configures a cron job that renews the certificates before they expire. Since we have already configured the pkcs12convert.sh script file earlier, it will get automatically executed by certbot when the certificate is renewed. The Technitium DNS Server will automatically reload the renewed certificate when it detects any changes for the pfx file by looking at its date modified attribute.

To test the certbot renewal process, we can try the dry run command. If there are no errors reported then it means the renewal was successful.

sudo certbot renew --dry-run

Running DoH With Another Web Server

You may have a requirement to run both the DNS server with DoH service and another web server for hosting websites. In such cases since both the DoH service and the web server would require to use ports 80 and 443, it would create a conflict.

A solution in such a scenario is to use the web server as a reverse proxy to the DoH service. You will need to configure the web server with TLS certificate and virtual hosting to reverse proxy to http://127.0.0.1:8053/dns-query and enable only the DNS-over-HTTP optional DNS server protocol as shown below.

Optional DNS Server Protocols With TLS Certificate
Optional DNS Server Protocols With TLS Certificate

With this setup, your web server will terminate TLS and do reverse proxy allowing the DoH service through it. If your web server supports TLS termination for TCP streams then you can point it to 127.0.0.1:53 and also provide DoT service through it.

If you are using nginx as your web server, you can use the snippet below to configure a reverse proxy for the DoH service. For more details, you can refer to the blog post on using nginx as a DoT or DoH gateway.

server {
    listen 80;
    server_name dns.example.com;

    return 301 https://$http_host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name dns.example.com;

    ssl_certificate /etc/letsencrypt/live/dns.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/dns.example.com/privkey.pem;
    ssl_trusted_certificate /etc/letsencrypt/live/dns.example.com/chain.pem;

    access_log /var/log/nginx/dns.example.com-access.log;
    error_log /var/log/nginx/dns.example.com-error.log;

    location / {
        proxy_pass http://127.0.0.1:8053/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Host $http_host;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Nginx-Proxy true;

        proxy_redirect off;
    }
}

Conclusion

Using Technitium DNS Server combined with certbot, you can setup DoH and DoT services with automatic TLS certificate renewal and bypass any network restriction on DNS traffic. If you already have a web server like nginx running, you can use it for TLS termination and provide both DoH and DoT services on the same server.

If you have any queries do let me know in the comments below or send an email to support@technitium.com.

Sunday, July 19, 2020

How To Disable Firefox DNS-over-HTTPS On Your Network

Firefox includes a quite useful option since more than a year now that enables the web browser to use DNS-over-HTTPS (DoH) protocol to encrypt all the DNS requests on the network. This feature promises enhanced privacy to users such that anyone on your network path, like your ISP, wont be able to monitor or log your DNS traffic. The DoH protocol also protects your DNS requests from Man In The Middle (MITM) attacks which are possible with the default unencrypted UDP based DNS requests.

While, DoH is a really interesting feature to have from privacy perspective, it is Firefox's implementation that is a bit controversial. Firefox has deal with two public DNS providers, Cloudflare and NextDNS, in its Trusted Recursive Resolver (TRR) program which lists these providers directly into the web browser's DoH options. The controversy is Firefox enabling DoH for users automatically with an opt-out policy.

Not just Firefox but, Google Chrome and Microsoft Windows 10 is also implementing DoH support. Google Chrome's approach is a bit different from Firefox. Chrome will upgrade to use DoH protocol if you are already using a public DNS provider that supports DoH protocol. Microsoft is experimenting with a similar DoH upgrade approach with Windows 10 insider builds.

Firefox's opt-out policy bypasses the local network policies by not using the DNS servers provided by the network administrators. This creates headache for network administrators who wish to keep track or filter DNS traffic for security or other reasons. This is an issue even with people who use DNS based filtering software on their home network.

To help network administrators, Firefox has introduced a Canary domain to disable DoH on their networks. Using this canary domain (use-application-dns.net), a network administrator can signal Firefox on their networks to disable the automatic switch to DoH. However, its important to note that if a user configures DoH manually, then the canary domain signal is ignored by the web browser.
Note: The canary domain only applies to users who have DoH enabled as the default option. It does not apply for users who have made the choice to turn on DoH by themselves.
To disable DoH on your network, you need to either block the canary domain entirely such that the DNS server responds with a NXDOMAIN response code or that the server returns an empty response with no A or AAAA records.

You can do this configuration on your Technitium DNS Server setup by simply adding an empty zone for the canary domain. The zone once added must look like as shown in the screenshot below:

Firefox Canary Domain Zone Configuration
Firefox Canary Domain Zone Configuration
With this configuration, you can ensure that Firefox on your network wont automatically switch to using DoH protocol bypassing your local network DNS servers.

Let me know if you have any queries in the comments below or send an email to support@technitium.com.

Technitium DNS Server And Mesh Archived In Arctic Code Vault

I just discovered this exciting news that Technitium DNS Server and Technitium Mesh has been archived by the GitHub Archive Program in the Arctic Code Vault!

Arctic Code Vault
GitHub Arctic Code Vault

GitHub Archive Program's mission is to preserve open source software for future generations by storing public open source code repositories in an archive built to last a thousand of years.

GitHub took a snapshot of all active public open source repositories on 2nd Feb, 2020 to archive in the code vault. The total data of 21 TB was stored using digital photo sensitive archive film designed to last for a thousand years.

Arctic Code Vault Contributor Badge!

To recognize and celebrate the contributions of all the software developers, GitHub now shows a badge on the GitHub profile page. Hovering on the badge shows some of the repositories that were included in the archive.

I hope they do the archive again in coming years since the current archive contains old version with quite a few bugs!

Sunday, July 12, 2020

How To Enforce Google Safe Search And YouTube Restricted Mode On Your Network

With the release of Technitium DNS Server v5, a new feature called ANAME resource record has been introduced. ANAME resource record implementation is similar to the IETF draft with respect to its core functionality that allows adding a CNAME like functionality to the zone root. Essentially, ANAME is similar to CNAME except that the authoritative DNS server resolves the A or AAAA records by itself and returns them.

The new release also adds Conditional Forwarder feature that can be combined with the ANAME feature to enforce Google's Safe Search or YouTube's Restricted Mode.

To configure Google's Safe Search, you need to add a new "google.com" Conditional Forwarder zone with "Use This DNS Server" option enabled. The "Use This DNS Server" option tells the DNS Server to forward all the queries to itself so that you do not need to configure any other DNS server as a forwarder. This option is useful in scenarios like the current one where you just need to override a few records for a particular zone but still wish that the other records in the zone to be resolvable as usual.

Add New Conditional Forwarder Zone

Once you have added the zone, you need to add a CNAME record that points "www.google.com" to "google.com" and another ANAME record that points "google.com" to "forcesafesearch.google.com". Check the screenshot below to know how the records should look like.

Enforcing Google Safe Search

You can now test this by clicking on the DNS Client tab and querying for "www.google.com". Now open "www.google.com" in your web browser and try doing a search and notice the Safe Search option on the top right corner.

Similarly, to configure YouTube's restricted mode, you need to add a new "youtube.com" Conditional Forwarder zone with "Use This DNS Server" option enabled. Once the new zone is added, you need to add a CNAME record that points "www.youtube.com" to "youtube.com" and another ANAME record that points "youtube.com" to "restrict.youtube.com". This will enforce "Strict Restricted Mode".  To enforce "Moderate Restricted Mode" you need to point your ANAME record to "restrictmoderate.youtube.com" instead. Once you have configured the records, they should look as shown the screenshot below.

Enforcing YouTube Strict Restricted Mode

You can now test this too with the DNS Client tab by querying "www.youtube.com". You can open "www.youtube.com" in your web browser and check if the restricted mode is working by searching with any keyword.

The Conditional Forwarder zone is quite useful that not only you can forward queries to one or more DNS providers by adding one or more FWD records, you can override records that you wish and have the zone resolve as usual for other records.

If you have any queries, do let me know in the comments section below. For any feedback or support do send an email to support@technitium.com.

Sunday, July 5, 2020

Technitium DNS Server v5 Released!

I am really happy to announce the release of Technitium DNS Server v5. This version is a major upgrade with many new core features, a lot of memory and CPU optimizations, and multiple bug fixes done. Download the latest update now!

Technitium DNS Server v5

Technitium DNS Server is a free, open source software that can be used by anyone be it a novice or an expert user. The server aims to have a user friendly approach, providing an easy to use web based GUI, and with defaults that allow the server to run out-of-the-box.

The DNS server can be used to self host domain names, used as a local resolver on a desktop or laptop computer, or used as a DNS server for the entire local network. It supports many useful and powerful features like blocking domain names using block lists, overriding records for any domain, use forwarders or conditional forwarders with DNS-over-TLS or DNS-over-HTTPS, and host your own DNS-over-TLS or DNS-over-HTTPS service.

The DNS Server is cross platform and can run on Windows, Linux and macOS. It has small footprint and thus can run even on a Raspberry Pi.

Once you have used Technitium DNS Server, you will realize how powerful it is and how silly it is to rely on your ISP's DNS servers.

Conditional Forwarder Zone

Features that you may find interesting in this release:
  • QNAME minimization support in recursive resolver for privacy.
  • ANAME propriety record support to allow using CNAME like feature at zone root.
  • Primary and Secondary zone support with NOTIFY implementation and zone transfer support. 
  • Stub zone support that allows the DNS server to keep track of the name servers of the zone.
  • Conditional Forwarder zone support which allows to configure multiple forwarders for a specific domain name with all protocol support including DNS-over-HTTP or DNS-over-TLS protocols.
  • Ability to override records of a live domain name using conditional forwarder or stub zone. This allows you to easily implements things like forced Google safe search or YouTube's restricted mode.
  • Concurrent querying with more than one forwarder allows to get fastest response from multiple forwarders.
  • Option to change the DNS Server local ports for TCP and UDP protocols. 
Read the change log to know more in details about the latest release.

Conditional Forwarder Zone with Overridden Records For Google Force Safe Search

The DNS Server code has been optimized for CPU, memory and concurrency. The server now notably has a very small memory footprint which allows loading a couple of million blocked domain names easily via the blocks list URLs on a Raspberry Pi with just 1 GB RAM. The time it takes to load the blocked lists too has improved significantly.

The DNS server now internally uses a new ByteTree data structure which is a complete lock less implementation allowing concurrent threads to do read and write operations. This allows the DNS server to handle large amount of concurrent requests easily while also allowing it to update the cache data parallelly.

With the limited hardware that is available with me for testing, the DNS server was load tested on a machine with Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz on a 1 Gbps wired Ethernet network. The server could resolve more than 2 million requests per minute with an average 30% CPU utilization consistently for 3 hours. The client machine that was used to bombard requests however would peak out at 100% CPU preventing from adding any more load on the server for the load test. This update is supposed to fix issues in the previous version that caused the CPU to peak, failing to handle load more that couple of thousand requests per second.

Any comment or feedback is really appreciated and helps a lot in adding new features and fixing bugs. Do send your feedback or support requests to support@technitium.com. For any feature request or reporting bug, do create an issue on GitHub.

The DNS Server code is available under GNU General Public Licence (GPL) v3 on GitHub.

You can now make your contributions to Technitium by becoming a Patron and help in developing new software, updates and adding more features possible. Become a Patron now!

Sunday, December 8, 2019

Technitium Mesh Released!

Technitium Mesh, a successor to the Bit Chat project, has been released and is available to download directly from the Mesh website.

Technitium Mesh

Introduction

Mesh is a secure, anonymous, peer-to-peer (p2p), open source instant messenger that provides end-to-end encryption with Perfect Forward Secrecy (PFS). Mesh can be used on the Internet or on offline private LAN networks for private messaging, group messaging and file transfers. Mesh is based on Bit Chat and retains it core concepts but has some major changes.

Unlike Bit Chat, Mesh does away with centralized user profile registration based on email address. Instead, users now can create multiple local profiles that can be used simultaneously and require to use a generated User Id. This major change was decided based on many people unwilling to disclose their email address or accused Technitium of harvesting email addresses. To be clear, Technitium never used the collected email addresses provided during the profile registration process to even inform existing users that the Bit Chat project is closing its operations.

The generated Mesh User Id is required to be exchanged to initiate private chat and can be changed anytime to avoid previously used User Id from being abused by anyone to stalk or harass you. Even when joining a group chat, a new User Id is generated each time so that the User Id disclosed in group chat cannot be used to initiate a private chat invitation. This makes sure that you are in total control over who is allowed to initiate private chat invitations and when.

The User Id is generated using an algorithm that uses RSA public key linked to the user profile and a random number. This algorithm allows each peer to authenticate the other peer during the peer-to-peer connection process to ensure their identity.

Mesh also removes the use of BitTorrent trackers that were being used by Bit Chat. Using torrent trackers created connectivity issues since many ISPs around the globe use deep packet inspection to block BitTorrent traffic. This also affected Bit Chat since ISPs could not differentiate between both the applications and blocked any traffic that was found using torrent trackers. Instead, Mesh now completely relies on Distributed Hash Tables (DHT).

Mesh now allows creating anonymous profiles that use Tor Network. Mesh includes Tor binaries to allow the app to use Tor Network anytime its necessary. Anonymous profiles and peer-to-peer (p2p) profiles are the two type of profiles that are now available. Both the profiles are interoperable such that a p2p profile user can communicate with anonymous profile user using the built in Tor support. This interoperability means that you can have a group where both p2p users and anonymous users can join together. Anonymous profiles use Tor hidden service to accept inbound connection requests but use a new hidden service onion domain name each time the user logs in to the profile to avoid being tracked using the onion domain name.

Read more technical details on the Frequently Asked Questions (FAQ) page.

Features

  • Completely decentralized, peer-to-peer architecture that works even on offline private LAN networks. No centralized profile registration is needed.
  • End-to-end encryption with Perfect Forward Secrecy (PFS).
  • Allows you to create anonymous profiles that use Tor Network.
  • Multiple profile support allows you to create many profiles and use all of them simultaneously.
  • Allows creating private chat and group chat with file transfer support.
  • User profiles are stored locally using strong encryption protected by passphrase. 
  • Works peer-to-peer with IPv4 as well as IPv6 networks.
  • Automatic port forwarding using your router's UPnP feature.

Open Source

Mesh is open source and source code is available under GNU General Public License v3 on GitHub. The software code is made open source to increase confidence in the security that we intend to provide.

Alpha Version

Technitium Mesh current release is in alpha version. This means the software is not fully complete and will undergo major changes in its protocol or user interface design. There may be noticeable bugs which will be addressed with an automatic update. You are welcome to report any issues by sending an email to support@technitium.com. For any issues, feedback, or feature request you may create an issue on GitHub.

Further, you may like to read the original concept in this old blog post.

Saturday, September 28, 2019

Analyzing DNS-over-HTTPS And DNS-over-TLS Privacy and Security Claims

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) are two new protocol options available for secure DNS transport. Of which DoH has been pretty controversial with strong opposition from notable people in the DNS community. There have been questions raised for even the existence of IETF DoH standard when DoT standard was already an option.

Firefox has builtin DoH support with Cloudflare DNS configured that is being rolled out as a default for all users in the USA. This has consequences of subverting local network policies of organizations or private networks. Firefox has announced a canary domain name that can be blocked locally to prevent Firefox to use DoH by default making the entire effort vulnerable to downgrade attacks.

There have been serious concerns raised about DoH as a means for centralization of the DNS infrastructure. There are only a few public DoH and DoT service providers and thus it attempts to centralize the DNS infrastructure. Sending a handful of DNS providers all your DNS traffic does not really improve your overall privacy. It is a trade-off that each user needs to decide on his/her own.

DNS is one important control planes in a network. It essentially allows network administrators to block content based on domain names making it quite useful tool in the arsenal. It is being widely used to provide content filtering services, parental controls, and to block known malware command and control. Its so popular that a lot of people install a locally running DNS server on their home networks to block Internet Ads using block lists.

Applications or devices using DoH by default will bypass all the local control measures configured by the network administrator. The argument for applications to use DoH is that it allows users to bypass censorship, and provide security and privacy. However, this might not be what the user expects without a consent.

But, are users of DoT or DoH really being protected? Lets first understand the default DNS-over-UDP/TCP (Do53), DoH and DoT protocols in technical terms.

Do53 is the core protocol that is used by the entire DNS infrastructure. By default all DNS queries use UDP protocol since it is more efficient for simple request/response queries. TCP is usually used only when the response is expected to be large enough to not be suitable for UDP. Do53 does not provide any security or privacy as anyone on network path can see all DNS requests and even manipulate responses essentially doing a man-in-the-middle attack. This has been exploited in many malware attacks that compromise routers and change DNS settings to use attacker's DNS server to spread further or to compromise users further. Many ISPs have also tried to hijack DNS to show advertisements when user enters a non-existent domain name in the web browser.

DoT protocol is really just DNS-over-TCP tunneled inside TLS. Thus it provides all the features from the core protocol with addition of on path security and privacy. DoT uses default TCP 853 port and thus is easy to block with any network firewall.

DoH uses HTTPS protocol to send and receive DNS data in wire format. This means that DoH server is really a standard web server with a back end web application reading the DNS requests and proxying them to a configured DNS server. DoH can also be directly supported by a DNS server using a built in web server. DoH, just like DoT, also provides on path security and privacy. Since DoH uses the same TCP 443 port that HTTPS uses, it becomes almost impossible to block it with a network firewall since firewall cannot distinguish between normal HTTPS traffic and DoH.

Since both DoT and DoH use TLS for security, they essentially look similar over network. In fact, if DoT is configured on port 443 instead of its default port 853, it too would become difficult to block with a network firewall. Thus the only benefit of DoH seems to be that it allows the service to be hosted using a standard web server where the same IP address and port is shared with multiple other HTTPS websites.

Even though both DoT and DoH claim to provide security and privacy there are multiple catches. Both DoT and DoH provide security only from client to the recursive DNS server thus they do not provide any end-to-end security. Client is essentially trusting a configured recursive DNS server.

Even when DNS requests are encrypted, you are still leaking domain names of website you visit due to TLS Server Name Indication (SNI) extension. SNI essentially allows a web server running on a single IP address to host multiple HTTPS websites. SNI extension includes the domain name of the website you visit so that the web server can use correct SSL/TLS certificate that is configured for that domain name. SNI thus can reliably be used as an option to block websites combined with DNS based filtering.

SNI extension is being upgraded to Encrypted SNI (ESNI) that will encrypt the entire SNI extension in the TLS request. But practically speaking, even when ESNI becomes generally available on all web servers and web browsers, it will take many many years before significant amount of HTTPS websites configure ESNI for their domain name. Its been more than 3 year now that free SSL/TLS certificates are available to be used by any website but still there are a lot of websites that do not have HTTPS deployed (link requires login).

Even when DNS request are encrypted and TLS ESNI extension is used, most websites can still be identified by the IP address they are hosted on. Thus privacy provided by all these measures is still inadequate.

What about DNSSEC? DNSSEC is designed to provide security such that a recursive DNS server can validate responses before responding to client requests. It does not provide end-to-end security as clients never really perform validations and rely totally on the configured recursive DNS server. Another issue with DNSSEC is that its not widely deployed with only a small percentage of domain names have it configured. Most popular websites on the internet still do not have DNSSEC deployed making DNSSEC not really useful for most end users.

With all these technical issues in mind, its clear that both DoT and DoH are not really safe to be used by people to bypass censorship. Anyone with serious concerns with privacy is better off using Tor Browser or use a decent VPN service.

DoT and DoH are still useful as they protect users from man-in-the-middle attacks by on path network attackers. DoH however is really designed with an aim to bypass local network policies. Both are capable from hiding your DNS traffic on private network or from ISP.

A better way for many people is to run their own local DNS server that does recursive resolution. Locally running recursive DNS server will cache most common name servers records which usually have long TTL values configured in days and only query them when records are required or expired. This prevents DNS queries from going to centralized networks and avoid getting logged on ISP DNS server. Having authoritative DNS servers support DoT by default will add much value to running recursive DNS servers as it will dramatically improve security and privacy over the network.

All major ISPs deploying DoT and major Operating Systems (OS) supporting DoT will significantly help improve privacy and security as well as maintain the decentralization. Newer Android mobile devices have already started supporting DoT. Once the entire ecosystem supports and deploys DoT, it will improve the current state that DNS is in.


Tuesday, January 1, 2019

Turn Raspberry Pi Into Network Wide DNS Server

Turn your Raspberry Pi into a network wide DNS server for security, privacy and blocking Internet Ads on your private network!

Raspberry Pi 3 Model B+

With Technitium DNS Server version 2.2 release, it is now possible to run it on Raspberry Pi (Raspbian Stretch) using .NET Core and we have a single line automatic installer ready to make it easy to get it running.

Install DNS Server

Just connect to your Raspberry Pi using SSH and run the command below to install the DNS server:

curl -sSL https://download.technitium.com/dns/install.sh | sudo bash

You can install the software manually too if you do not wish to directly run the install script. You will need to first manually install .NET Core on your Raspberry Pi and then use these steps to install the DNS Server.

Once the installation is complete, open the DNS Server web console to view the dashboard and customize the settings.

Technitium DNS Server web console on Raspberry Pi 3 Model B+

Configure Your Router

To use it as a network wide DNS server, you need to configure your network router's DHCP settings and add your Raspberry Pi's IP address as a custom DNS server. You may also need to configure the WAN settings to override the default ISP provided DNS servers with your Raspberry Pi one. Check your router's manual for the configuration details.

Do make sure that your Raspberry Pi has a static IP address so that it does not change later causing issues with failed domain resolutions on the entire network. Also make sure to install heat sinks for your Raspberry Pi to prevent overheating issues since you will be running it round the clock.

If you have any queries or feedback, do comment below to let me know. You can also email your queries to support@technitium.com.