tag:blogger.com,1999:blog-80653766186116324992024-03-19T14:17:48.975+05:30Technitium BlogPush The LimitsShreyas Zarehttp://www.blogger.com/profile/01269575365702781881noreply@blogger.comBlogger63125tag:blogger.com,1999:blog-8065376618611632499.post-34875470679359127832024-02-04T22:27:00.011+05:302024-02-05T13:07:42.272+05:30Technitium DNS Server v12 Released!<p>
I am happy to announce the release of
<a href="https://technitium.com/dns/" target="_blank"
>Technitium DNS Server v12</a
>, a cross-platform, free, open source software that can be used by anyone, be
it a novice or an expert user. It features an easy to use web based GUI and
works with default config that allows the server to run out-of-the-box.
</p>
<p>
<a href="https://technitium.com/dns/" target="_blank">Download</a> the latest
update for Windows, Linux, macOS, or Raspberry Pi!
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/technitium-dns-server-v12-dashboard.png"
style="margin-left: auto; margin-right: auto;"
><img
alt="Technitium DNS Server"
border="0"
data-original-height="739"
data-original-width="1115"
height="424"
width="640"
src="https://technitium.com/img/blog/technitium-dns-server-v12-dashboard.png"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Technitium DNS Server v12
</td>
</tr>
</tbody>
</table>
<p>
This is a major release that now runs on ASP.NET Core 8 Runtime and adds many
new features and options. This release also adds two new DNS apps. The DNS
Rebinding Protection app protects your networks from
<a href="https://en.wikipedia.org/wiki/DNS_rebinding" target="_blank"
>DNS rebinding attacks</a
>. The NX Domain Override app allows you to override NX domain response with
custom A/AAAA answer response.
</p>
<p>
The release also adds
<a
href="https://shreshtait.com/blog/2024/02/recently-registered-domains-download/"
target="_blank"
>Newly Registered Domains</a
>
Community Feed by
<a href="https://shreshtait.com/" target="_blank">Shreshta</a>. You can read
more on
<a
href="https://shreshtait.com/blog/2024/01/what-are-newly-registered-domain-names/"
target="_blank"
>Newly Registered Domains</a
>
to understand how it protects you better.
</p>
<p>
Read the
<a
href="https://github.com/TechnitiumSoftware/DnsServer/blob/master/CHANGELOG.md"
target="_blank"
>change log</a
>
to know full details about this latest update.
</p>
<p>
Any comment or feedback is really appreciated and helps a lot in adding new
features and fixing bugs. Send your feedback or support requests to
<a href="mailto:support@technitium.com" target="_blank"
>support@technitium.com</a
>. You can also post on
<a href="https://www.reddit.com/r/technitium/" target="_blank"
>/r/technitium</a
>
on Reddit for community support. For any feature request or reporting bugs,
create an issue on
<a
href="https://github.com/TechnitiumSoftware/DnsServer/issues"
target="_blank"
>GitHub</a
>.
</p>
<p>
The DNS Server source code is available under
<a href="https://go.technitium.com/?id=24" target="_blank"
>GNU General Public Licence (GPL) v3</a
>
on
<a href="https://github.com/TechnitiumSoftware/DnsServer" target="_blank"
>GitHub</a
>.
</p>
<p>
Make a contribution to the project and help in developing new software,
updates and adding more features possible.<br />
<a href="https://go.technitium.com/?id=35" target="_blank">Donate Now!</a>
</p>
Shreyas Zarehttp://www.blogger.com/profile/01269575365702781881noreply@blogger.com2Mumbai, Maharashtra, India19.0759837 72.8776559-9.2342501361788472 37.721405899999993 47.386217536178847 108.0339059tag:blogger.com,1999:blog-8065376618611632499.post-39779709615784755962023-05-14T16:38:00.001+05:302023-09-06T16:12:04.441+05:30For DNSSEC And Why DANE Is Needed<p>
You probably may have read an influential blog post
<a
href="https://sockpuppet.org/blog/2015/01/15/against-dnssec/"
target="_blank"
>Against DNSSEC</a
>
and another one that follows it
<a
href="https://sockpuppet.org/blog/2016/10/27/14-dns-nerds-dont-control-the-internet/"
target="_blank"
>14 DNS Nerds Don't Control The Internet</a
>
by
<a href="https://infosec.exchange/@tqbf" target="_blank">Thomas H. Ptacek</a>
and may have dismissed DNSSEC as unnecessary. I am calling it influential
since this blog post comes up frequently at any debates that you may find
online regarding DNSSEC, is
<a
href="https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#External_links"
target="_blank"
>listed in wiki articles</a
>, and also had an influence on me. If you haven't read both of them, I would
highly recommend that you read them before reading this blog post to help to
understand a lot of context. There is also a
<a href="https://sockpuppet.org/stuff/dnssec-qa.html" target="_blank"
>FAQ blog post</a
>
for the original Against DNSSEC blog post that is also recommended to be read.
There is also a recent
<a href="https://twitter.com/tqbf/status/1583496922970877952" target="_blank"
>Twitter thread</a
>
by
<a href="https://twitter.com/tqbf" target="_blank">Thomas H. Ptacek</a>
which is a good read.
</p>
<p>
You may also like to read this recent
<a href="https://hachyderm.io/@dalias/109938621525149398" target="_blank"
>Mastodon thread</a
>
by
<a href="https://hachyderm.io/@dalias" target="_blank">Rich Felker</a> who
argues for DNSSEC and also an old
<a href="https://easydns.com/blog/2015/08/06/for-dnssec/" target="_blank"
>For DNSSEC</a
>
blog post by Zach Lym which is a rebuttal to the "Against DNSSEC" blog post.
</p>
<p>
In this blog post, based on my experience of implementing DNSSEC, I am
attempting to make an argument for DNSSEC taking points from the original
<a
href="https://sockpuppet.org/blog/2015/01/15/against-dnssec/"
target="_blank"
>Against DNSSEC</a
>
blog post while comparing it with
<a
href="https://en.wikipedia.org/wiki/Public_key_infrastructure"
target="_blank"
>Public Key Infrastructure (PKI)</a
>, and make a case for
<a
href="https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities"
target="_blank"
>DNS-based Authentication of Named Entities (DANE)</a
>
adoption.
</p>
<p>
Note that DNSSEC and DANE are an alternative to PKI system and both of them
use the same
<a
href="https://en.wikipedia.org/wiki/Transport_Layer_Security"
target="_blank"
>Transport Layer Security (TLS)</a
>
for security.
</p>
<h3>But First, What Is DANE?</h3>
<p>
Before discussing DNSSEC, lets take a look at DANE to better understand the
arguments being made. Many people know about DNSSEC but are unaware about DANE
and even when they are aware, they do not know about its features or have
misconceptions about it. Lets see what DANE is about in brief.
</p>
<ul>
<li>
DANE is an alternative for the PKI system that can co-exists with it. DANE
uses TLSA resource record in the DNS which can include hash values for a PKI
certificate or the hash value of its public key component. DANE TLSA records
are signed by DNSSEC and are validated by clients before connecting to the
TLS service. Implementing DANE support does not mean removing PKI support
for any software or service. Which means, a website can implement PKI
certificate, or DANE, or both together.
</li>
<li>
The TLSA record can contain a full certificate but the common usage is to
just store the hash values for either the full certificate or just the
public key so as to prevent IP fragmentation of the UDP DNS response.
</li>
<li>
<a
href="https://www.rfc-editor.org/rfc/rfc7671.html#section-5"
target="_blank"
>DANE provides 4 modes of operation</a
>
by publishing a TLSA record for a domain name:
<ol>
<li>
<b>PKIX-TA: </b> This mode allows specifying which 3rd party PKI
Certificate Authorities (CA) are allowed to issue certificates for the
service the client is connecting to. The client also needs to perform
PKI certificate chain validation. This may look similar to the
<a
href="https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization"
target="_blank"
>CAA record</a
>
but is actually validated by the client before making the TLS
connection. Whereas CAA record is checked by a CA to know if they are
allowed to issue a certificate for the domain name to prevent
mis-issuance.
</li>
<li>
<b>PKIX-EE: </b> This mode allows specifying the end entity certificate,
that is, the certificate deployed by the service. The client has to
match the received certificate with DANE TLSA record and also perform
usual PKI certificate chain validation.
</li>
<li>
<b>DANE-TA: </b> This mode allows specifying a Trust Anchor for a CA
certificate that may not be listed in the client's collection of
installed certificates. Using this, an enterprise running their own
internal root CA can be validated by the clients without requiring to
install the root CA certificate locally. The client is required to
perform PKI certificate chain validation below the specified Trust
Anchor.
</li>
<li>
<b>DANE-EE: </b> This is known as "domain-issued certificate" since it
allows for a domain owner to issue a certificate for a service without
involving a 3rd party CA. The TLS certificate on the service must match
with the DANE TLSA record and PKI certificate chain validation is not
required to be performed by the client.
</li>
</ol>
</li>
<li>
When using DANE-EE mode, its possible for a web server to
<a
href="https://www.rfc-editor.org/rfc/rfc7671.html#section-5.1"
target="_blank"
>host one or more web sites</a
>
with a single TLS self-signed certificate. This is since, the domain in the
URL is not matched with the subject in the certificate for DANE-EE but only
the certificate or its public key is validated. This means that a web
browser supporting DANE does not technically need to include a
<a
href="https://en.wikipedia.org/wiki/Server_Name_Indication"
target="_blank"
>Server Name Indication (SNI)</a
>
extension in the TLS handshake with DANE-EE and thus there is no need for
using
<a
href="https://blog.cloudflare.com/encrypted-client-hello/"
target="_blank"
>Encrypted Client Hello (ECH)</a
>, a new extension that is being
<a
href="https://datatracker.ietf.org/doc/draft-ietf-tls-esni/"
target="_blank"
>standardized</a
>, for such a deployment.
</li>
<li>
The most useful feature of DANE that PKI cannot provide is that it protects
email by ensuring that SMTP protocol uses TLS preventing downgrade attacks.
Websites can be authenticated based on the CA certificate that was issued
for the domain name but, such mechanism does not work with email since SMTP
uses opportunistic encryption (STARTTLS) which an on-path attacker can
easily downgrade to force transmission of email in plain text. When a domain
owner deploys DANE for their email gateways, the sender can validate the
DANE TLSA record and will attempt to send email only with TLS (STARTTLS)
after ensuring that the certificate received is valid as per DANE TLSA
record.
</li>
</ul>
<h3>Is DNSSEC Unnecessary?</h3>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
All secure crypto on the Internet assumes that the DNS lookup from names to IP
addresses are insecure. Securing those DNS lookups therefore enables no
meaningful security. DNSSEC does make some attacks against insecure sites
harder. But it doesn’t make those attacks infeasible, so sites still need to
adopt secure transports like TLS. With TLS properly configured, DNSSEC adds
nothing.<br />
<br />
-
<a
href="https://sockpuppet.org/blog/2015/01/15/against-dnssec/"
target="_blank"
>Against DNSSEC</a
>
</blockquote>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
If the secret DNSSEC keys leaked on Pastebin tomorrow, it’s unlikely that
anything would break.<br />
<br />
-
<a
href="https://sockpuppet.org/blog/2016/10/27/14-dns-nerds-dont-control-the-internet/"
target="_blank"
>14 DNS Nerds Don't Control The Internet</a
>
</blockquote>
<p>
This argument is kind of true at the moment since DNSSEC is not being
effectively used as its is not mass adopted yet for various reasons. While all
of the web today is protected by PKI despite a lot of problems with it.
</p>
<p>
There are hundreds of Root Certificate Authorities (CA) that are trusted by
major web browsers and Operating Systems. Many of them are based in countries
of questionable intent. A single compromised CA is capable of issuing
certificates for any domain name, allowing
<a
href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack"
target="_blank"
>Man In The Middle (MITM)</a
>
attacks that effectively makes the entire PKI system fragile.
</p>
<p>
The most recent example being a little known Panama registered company called
TrustCor Systems which was a root CA trusted by major web browsers, that
<a
href="https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addresses-government-connections/"
target="_blank"
>has ties with U.S. intelligence and law enforcement</a
>. Not just that, they have been
<a href="https://twitter.com/v0max/status/1589938654935666690" target="_blank"
>accused of distributing malware SDK in Google Play Store</a
>. This revelation caused it to be dropped by
<a
href="https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/yLohoVqtCgAJ?pli=1"
target="_blank"
>Mozilla</a
>
and
<a
href="https://www.theregister.com/2022/12/02/mozilla_microsoft_trustcor/"
target="_blank"
>Microsoft</a
>
recently. This is not a first instance of such a compromise but only a recent
one.
</p>
<p>
Another popular example is that of
<a href="https://en.wikipedia.org/wiki/DigiNotar" target="_blank"
>DigiNotar</a
>
discovered in 2011 which clearly indicates that this has been a known and
unfixed issue since a long time.
</p>
<p>
There are several problems with how
<a
href="https://en.wikipedia.org/wiki/Domain-validated_certificate"
target="_blank"
>Domain Validated (DV) certificates</a
>
are issued. Earlier, the most common way to issue a DV certificate was to
verify email address for the domain name while the SMTP protocol used to send
email, was itself known to be insecure. The current popular method uses plain
text HTTP challenge or DNS challenge to prove domain name ownership where you
need to prove that you either control port 80 with HTTP protocol for the
domain name, or that you can add a TXT record in DNS for it. No matter what
method is used, it ultimately depends upon DNS infrastructure in one way or
the other for verification.
</p>
<p>
You don't have to be NSA or GCHQ to be able to acquire a DV certificate for a
domain name. An attacker in position of being on-path, that is, between the CA
and the domain owner's DNS or web server will be able to get himself issued a
DV certificate. This is not an imaginary scenario and such kind of
<a
href="https://arstechnica.com/information-technology/2022/09/how-3-hours-of-inaction-from-amazon-cost-cryptocurrency-holders-235000/"
target="_blank"
>attacks have already occurred</a
>
that used BGP attacks and could have been prevented with DNSSEC and DANE. Yes,
contrary to what is
<a href="https://twitter.com/tqbf/status/1583499950645981184" target="_blank"
>believed</a
>, DNSSEC with DANE is not affected by BGP attacks. This is due to the fact
that even if the attacker is able to hijack your IP addresses, they still do
not have access to the DNSSEC private keys to be able to break DANE. Whereas,
in the mentioned attack, the attackers were able to obtain new TLS
certificates from a CA using the hijacked IP addresses.
</p>
<h3>Is DNSSEC A Government-Controlled PKI?</h3>
<p>
To understand this, you need to know who controls the private keys used to
sign the zone. The Root zone is managed by
<a href="https://en.wikipedia.org/wiki/ICANN" target="_blank">ICANN</a>
and they hold the keys and organize
<a
href="https://www.cloudflare.com/dns/dnssec/root-signing-ceremony/"
target="_blank"
>Root Signing Ceremony</a
>
to ensure transparency. The Root zone signs DS records for each signed
<a href="https://en.wikipedia.org/wiki/Top-level_domain" target="_blank"
>Top-level Domain (TLD)</a
>
that holds the hash value of their public keys published as DNSKEY records in
the DNS.
</p>
<p>
The TLD zone's private keys are managed by the company operating it. For a
<a
href="https://en.wikipedia.org/wiki/Country_code_top-level_domain"
target="_blank"
>Country Code Top-Level Domain (ccTLD)</a
>, the government of the country will be managing the key. For popular TLDs
like .COM or .NET, it will be the U.S. government through the operator
<a href="https://en.wikipedia.org/wiki/Verisign" target="_blank">Verisign</a>.
For popular ccTLD .IO, it is the government of British Indian Ocean Territory.
</p>
<p>
The private keys for an individual domain name are managed by the domain owner
either directly or via the DNS provider hosting their domain name.
</p>
<p>
With DNSSEC, it is pretty clear who controls the private keys and also keeps
the risks involved distributed. Which means while China holds private keys for
.cn ccTLD, it can only sign domain names under it.
</p>
<p>
With PKI, any Root CA can sign a certificate for any domain name. And there
are hundreds of such Root CA that you have never heard of that your web
browser trusts. And to add to that, your ISP or the network operator, that you
run your web server with can get a DV certificate issued for your domain name
easily using HTTP challenge which you may never know of unless you manually
check using
<a
href="https://en.wikipedia.org/wiki/Certificate_Transparency"
target="_blank"
>Certificate Transparency</a
>
logs. PKI system is open to all kinds of attackers in position to exploit it.
</p>
<p>
Its possible for a government that runs a ccTLD to get a DV certificate issued
irrespective of DNSSEC status of the ccTLD. I mean, they control the parent
ccTLD zone and can easily answer with name server (NS) delegation records of
their choice when a CA is trying to validate domain ownership.
</p>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled
BIT.LY’s TLS keys.<br />
<br />
-
<a
href="https://sockpuppet.org/blog/2015/01/15/against-dnssec/"
target="_blank"
>Against DNSSEC</a
>
</blockquote>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
Libya has no authority over BIT.LY’s TLS certificates.<br />
<br />
-
<a href="https://sockpuppet.org/stuff/dnssec-qa.html" target="_blank"
>Questions and Answers from "Against DNSSEC"</a
>
</blockquote>
<p>
When Muammar Gaddafi was alive, he controlled BIT.LY already and could have
easily managed to get a DV certificate issued for himself if he wanted to. So,
the argument that he had no authority over BIT.LY's TLS certificate is invalid
since he could have had a valid DV certificate issued for any use he wished.
</p>
<p>
The Thomas H. Ptacek's FAQ blog post accepts that the PKI system is broken and
needs to be replaced, but argues that DNSSEC is not better while suggesting
solutions like
<a
href="https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning"
target="_blank"
>Key Pinning</a
>
that can fix issues with the CA system. The Key Pinning system however has
been obsoleted in favor of
<a
href="https://en.wikipedia.org/wiki/Certificate_Transparency"
target="_blank"
>Certificate Transparency</a
>
due to several issues with it.
</p>
<p>
It needs to be understood clearly by everyone that DNS is a government
controlled naming system by definition. Whereas, PKI is controlled by private
companies all over the world and thus controlled by them, their governments,
and any attacker on the network able to get a DV certificate issued. DNSSEC
limits the control to only the governments who already and anyways have been
controlling the DNS system. Political problems cannot be solved with technical
solutions.
</p>
<h3>Is DNSSEC Cryptographically Weak?</h3>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
The original DNSSEC design is two decades old; the first drafts I can find are
from 1994. Real-world DNSSEC therefore relies on RSA with PKCS1v15 padding.
The deployed system is littered with 1024-bit keys.<br />
<br />
No cryptosystem created in 2015 would share DNSSEC’s design. A modern PKI
would almost certainly be based on modern elliptic curve signature schemes,
techniques for which have coalesced only in the last few years.<br />
<br />
-
<a
href="https://sockpuppet.org/blog/2015/01/15/against-dnssec/"
target="_blank"
>Against DNSSEC</a
>
</blockquote>
<p>
The original article Against DNSSEC was published in 2015 and it was true that
DNSSEC was littered with 1024 bit RSA keys. Today, the Root zone and most TLDs
use
<a
href="https://stats.dnssec-tools.org/#/?top=parameters&dnssec_param_tab=2"
target="_blank"
>2048 bit keys</a
>
but you may still find some domain names using 1024 bit Key Signing Keys
(KSK). The Zone Signing Keys (ZSK) for many domain names still use 1024 bit
keys to reduce the size of DNS response but these keys are very frequently
changed.
</p>
<p>
DNSSEC now supports RSA, ECDSA P-256, ECDSA P-384, Ed25519, and Ed448
algorithms of which
<a
href="https://stats.dnssec-tools.org/#/?top=parameters&dnssec_param_tab=0"
target="_blank"
>ECDSA P-256 is the second most (45%) popularly deployed</a
>
algorithm after RSA (51%). RSA with a sufficient key size still has no issues
and experts say that
<a
href="https://arstechnica.com/information-technology/2023/01/fear-not-rsa-encryption-wont-fall-to-quantum-computing-anytime-soon/"
target="_blank"
>quantum attacks against it are very much exaggerated</a
>.
</p>
<p>
Applications like web browsers already display warning messages for
certificate issues which can be similarly used when implementing DANE where a
user will see warning when the website using DANE uses weak key sizes or
algorithms. This would in effect force the domain owners to increase the key
size to make the warnings go away.
</p>
<h3>Is DNSSEC Expensive To Adopt?</h3>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
Today, DNS lookups either succeed or fail. And there are generally two reasons
a lookup fails: the name doesn’t exist, or the requestor lacks connectivity to
the Internet. Network software is built around those assumptions. <br />
<br />
DNSSEC changes all of that. It adds two new failure cases: the requestor could
be (but probably isn’t) under attack, or everything is fine with the name
except that its configuration has expired. Virtually no network software is
equipped to handle those cases.<br />
<br />
-
<a
href="https://sockpuppet.org/blog/2015/01/15/against-dnssec/"
target="_blank"
>Against DNSSEC</a
>
</blockquote>
<p>
The original argument is that DNSSEC adds two new failure cases for DNS where
you cannot be sure of the reason when a domain name does not resolve. It can
be that there are network failures, or it can be that there is an active
attack causing DNSSEC validation failure. An application like a web browser
wont be able to know the exact reason to display to the user in such cases.
</p>
<p>
However, there is a solution available currently for this problem called
<a href="https://www.rfc-editor.org/rfc/rfc8914.html" target="_blank"
>Extended DNS Errors (RFC 8914)</a
>. This standard adds a reasoning for why the response has failed and can
clearly indicate the underlying issue. A DNS client implementation can thus
easily find out the exact reason for failure and any software implementation
can provide correct failure description to the user. This has already been
deployed by DNS providers like Cloudflare and by many DNS Server software
vendors. You can test it out using this
<a
href="https://dnsclient.net/#Cloudflare%20%7B1.1.1.1%7D/ok.bogussig.ok.bad-dnssec.wb.sidnlabs.nl/A/UDP/true"
target="_blank"
>online DNS Client</a
>
website which will show you the exact Extended DNS Error that was received for
the given test domain name.
</p>
<p>
Many web browsers have started to include a built-in DNS client to
<a
href="https://support.mozilla.org/en-US/kb/firefox-dns-over-https"
target="_blank"
>support encrypted DNS protocols</a
>
like DNS-over-HTTPS. There is even a recommendation to include a DNS client
with caching support to implement the new
<a
href="https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-12.html#name-performance-optimizations"
target="_blank"
>SVCB and HTTPS DNS resource records</a
>
that are being deployed. For web browsers to include support for DANE, they
simply need to use this already available built-in DNS client and include
DNSSEC validation for it. Using DNSSEC validation combined with Extended DNS
Errors, the web browser will now be in a position to show the correct failure
messages to the user.
</p>
<h3>Is DNSSEC Expensive To Deploy?</h3>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
DNSSEC is harder to deploy than TLS. TLS is hard to deploy (look how many
guides sysadmins and devops teams write to relate their experience doing it).
It’s not hard to find out what a competent devops person makes. Do the
math.<br />
<br />
-
<a
href="https://sockpuppet.org/blog/2015/01/15/against-dnssec/"
target="_blank"
>Against DNSSEC</a
>
</blockquote>
<p>
DNSSEC used to be hard to deploy due to lack of tooling available. Today, a
lot of DNS providers support DNSSEC that a domain name owner can enable just
by clicking a single button. The
<a href="https://github.com/TechnitiumSoftware/DnsServer" target="_blank"
>DNS server project</a
>
that I maintain can
<a
href="https://blog.technitium.com/2022/07/how-to-secure-your-domain-name-with-.html"
target="_blank"
>enable DNSSEC in just a few clicks</a
>.
</p>
<p>
To be clear, using managed DNS services means that the private keys are
managed by the DNS provider directly and are not in the domain owner's
exclusive control. Though this is no different from the current PKI scenario
where a lot of managed hosting providers do the same by automatic certificate
provisioning and have access to your certificate's private keys. A lot of CDN
network providers already deploy certificates on behalf of their clients by
default and thus hold their private keys too.
</p>
<p>
If a domain owner wants to keep the private keys in its control, be it DNSSEC
keys or PKI certificate keys, they have to manage their own servers. Deploying
DNSSEC is similar to deploying PKI certificate if not harder. With DNSSEC, its
even possible for the domain name owner to maintain an independent, hidden
primary DNS server which holds the DNSSEC private keys and then publish the
pre-signed zone safely to 3rd party secondary DNS servers that actually answer
the DNS queries for the domain name.
</p>
<h3>Is DNSSEC Incomplete?</h3>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
You’d think, for all its deployment expense, the forklifting out of
incompatible networking code, and the required adoption of a government PKI
running 1990s crypto, DNSSEC would at least nail its marginally valuable core
use case.<br />
<br />
Nope.<br />
<br />
DNSSEC doesn’t secure browser DNS lookups.<br />
<br />
In fact, it does nothing for any of the “last mile” of DNS lookups: the link
between software and DNS servers. It’s a server-to-server protocol.<br />
<br />
-
<a
href="https://sockpuppet.org/blog/2015/01/15/against-dnssec/"
target="_blank"
>Against DNSSEC</a
>
</blockquote>
<p>
The original argument is that DNSSEC validation is not done at the client end
point is practically true base on how things are usually deployed. Any
implementation of DNSSEC validation is usually done at the DNS resolver level
and client end points just trust the configured resolver by their network
provider.
</p>
<p>
But, DNSSEC validation is indeed end-to-end and not server-to-server like its
<a href="https://infosec.exchange/@tqbf/109938525731567458" target="_blank"
>believed</a
>. Nothing prevents a web browser to include a built-in DNS client that does
DNSSEC validation and then use it to add support for DANE. Web browsers today
have already added
<a
href="https://support.mozilla.org/en-US/kb/firefox-dns-over-https"
target="_blank"
>support for encrypted DNS protocols</a
>
like DNS-over-HTTPS so its very much feasible to include DNSSEC validation
support with it.
</p>
<h3>Is DNSSEC Unsafe?</h3>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
DNSSEC builds on the original DNS database. So applications will need to
distinguish between secure DNSSEC records and or insecure DNS records. To
solve this problem, DNSSEC provides a cryptographically-secure “no such host”
response.<br />
<br />
But DNSSEC is designed for offline signers; it doesn’t encrypt on the fly.
Meanwhile, there are infinite nonexistent hostnames. But all you can sign
offline are the hostnames that do exist. So to provide authenticated denial,
those signed records “chain”. You cryptographically verify that a record
doesn’t exist by observing that no other record chains to it.<br />
<br />
-
<a
href="https://sockpuppet.org/blog/2015/01/15/against-dnssec/"
target="_blank"
>Against DNSSEC</a
>
</blockquote>
<p>
The argument that DNSSEC exposes all the sub domain names in a zone is valid.
This can be an issue for some deployments while can be a non-issue for others.
</p>
<p>
DNSSEC can sign records that exists but to prove non-existence of a sub domain
name or a record requires a solution like NSEC and NSEC3 that chains all sub
domain names to prove that a name does not exists between given two sorted
names in the chain. With NSEC, all the sub domain names are available in clear
text while using NSEC3, the names are hashed but an attacker with sufficient
resources can crack the hashes to find out the original names.
</p>
<p>
But, there is already a solution available to this problem that requires
online DNSSEC key signing feature where the DNS server generates
<a href="https://www.rfc-editor.org/rfc/rfc4470.html" target="_blank"
>"white lies"</a
>
or
<a
href="https://datatracker.ietf.org/doc/draft-ietf-dnsop-compact-denial-of-existence/"
target="_blank"
>"compact lies"</a
>
NSEC records on the fly to prove non-existence of a name and thus does not
expose all the sub domain names in a zone.
</p>
<p>
This is also not an unique issue with DNSSEC. The
<a
href="https://en.wikipedia.org/wiki/Certificate_Transparency"
target="_blank"
>Certificate Transparency</a
>
system that is deployed today already exposes all your domain names that you
have issued a certificate for. You can check this publicly available data
using websites like
<a href="https://crt.sh/" target="_blank">crt.sh</a> for your domain names.
</p>
<h3>Is DNSSEC Architecturally Unsound?</h3>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
A casual look at the last 20 years of security history backs this up:
effective security is almost invariably application-level and receives no real
support from the network itself.<br />
<br />
-
<a
href="https://sockpuppet.org/blog/2015/01/15/against-dnssec/"
target="_blank"
>Against DNSSEC</a
>
</blockquote>
<p>
If an application like a web browser wants to add support for DANE with its
own DNSSEC validation then it will be doing end-to-end validation and wont be
relying on anything else.
</p>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
Can’t end-systems validate DNSSEC records themselves rather than trusting
servers?<br />
<br />
Sure they can. Everyone can also just run their own caching server. They
don’t, though, because the protocol was designed with the expectation that
they wouldn’t (this squares with the overall design of the DNS, in which stub
resolvers cooperate to reduce traffic to DNS authority servers by relying on
caching servers). DNSSEC deployment guides go so far as to recommend against
deployment of DNSSEC validation on end-systems. So significant is the
inclination against extending DNSSEC all the way to desktops that an
additional protocol extension (TSIG) was designed in part to provide that
capability.<br />
<br />
-
<a href="https://sockpuppet.org/stuff/dnssec-qa.html" target="_blank"
>Questions and Answers from "Against DNSSEC"</a
>
</blockquote>
<p>
A web browser with a built-in DNS client that is capable of DNSSEC validation
is very much feasible. This does not require anyone to run their own caching
server either. DNS is distributed and cached at all levels which means a lot
of home users with WiFi routers are hitting the DNS cache on the router itself
when they query DNS. Also, as already mentioned, the new
<a
href="https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-12.html#name-performance-optimizations"
target="_blank"
>SVCB and HTTPS DNS record</a
>
standard recommends clients to have support for caching to improve
performance.
</p>
<p>
The claim that
<a href="https://www.rfc-editor.org/rfc/rfc8945.html" target="_blank">TSIG</a>
was designed as an alternative to DNSSEC or "to extending DNSSEC all the way
to desktops" is also incorrect. TSIG was designed to allow performing
authenticated Dynamic Updates, zone transfer, and queries to recursive name
serves in limited scenarios. TSIG is not deployed to end-systems at scale
anywhere and nobody is planning for it either. TSIG only provides transaction
authentication while DNSSEC provides integrity which are completely different
properties to be interchanged.
</p>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
How can DNSSEC be hard to deploy? Isn’t it easier than TLS?<br />
<br />
This site tracks DNSSEC outages. The most important DNS zones on the Internet
don’t seem to be able to get it right. What makes us believe that the IT
department of, say, the country’s 13th biggest insurance firm will do
better?<br />
<br />
-
<a href="https://sockpuppet.org/stuff/dnssec-qa.html" target="_blank"
>Questions and Answers from "Against DNSSEC"</a
>
</blockquote>
<p>
It is true that this is one of the issues with DNSSEC where a TLD having
DNSSEC outage can cause all domain names under it to fail to validate. But
website outages due to invalid PKI certificate issues is like extremely common
and has occurred too many times to even keep track of and thus no different.
</p>
<p>
The solution to DNSSEC outage issues is better tooling and automation that can
prevent a DNS operator from making mistakes.
</p>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
Can’t DNSSEC support Elliptic Curve as well as RSA?<br />
<br />
DNSSEC has little-used support for ECDSA using the NIST P-256 curve. The roots
and TLDs, upon which the security of the rest of the DNSSEC hierarchy depends,
don’t use it. And according to APNIC, in a post cautioning operators not to
use ECC DNSSEC, fully 1/3rd of DNSSEC-validating resolvers can’t handle ECDSA
signatures.<br />
<br />
-
<a href="https://sockpuppet.org/stuff/dnssec-qa.html" target="_blank"
>Questions and Answers from "Against DNSSEC"</a
>
</blockquote>
<p>
DNSSEC today also supports Ed25519 and Ed448 in addition to RSA and ECDSA
algorithms. While it is true that a lot of resolvers do not support all
algorithms but if an application like a web browser wants it, it can add its
own DNSSEC validation with support for all algorithms. Note that DNSSEC
validation can be done end-to-end at the application level and is not limited
by what algorithm the resolver on the network, or DNS stub resolver in home
WiFi router supports.
</p>
<h3>Does MTA-STS Replace DNSSEC And DANE?</h3>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
The other thing DNSSEC can theoretically do on an all-HTTPS Internet is help
ensure that SMTP connections use TLS: downgrade attacks on SMTP are something
people worry about. But the major mail providers came up with MTA-STS, which
works like HSTS, to replace DNSSEC.<br />
<br />
-
<a href="https://twitter.com/tqbf/status/1583499071838638080" target="_blank"
>Thomas H. Ptacek on Twitter</a
>
</blockquote>
<p>
<a
href="https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#SMTP_MTA_Strict_Transport_Security"
target="_blank"
>SMTP MTA Strict Transport Security (MTA-STS)</a
>
is a technology similar to
<a
href="https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security"
target="_blank"
>HTTP Strict Transport Security (HSTS)</a
>
where an email gateway can discover and cache a strict transport security
policy for each domain name for sending outbound emails. This is where the
similarities end.
</p>
<p>
While HSTS relies on "HSTS preloaded list", which is a list of domain names
that a web browser has preloaded and can also add a domain name to its list
when an user simply navigates to a website with a "https://" scheme in its URL
with a HSTS header in response, there is no such mechanism available for
MTA-STS. This is because with email, there is no concept of an URL and thus no
concept of an URL scheme that an user can enter while sending an email. An
user simply enters an email address of the recipient in their email client and
sends the email not knowing how the message will get routed to the
destination.
</p>
<p>
The fundamental problem with MTA-STS is that it relies upon the DNS to
discover the MTA-STS policy. If not for DNSSEC, an attacker who can control
DNS protocol at the network level of the outbound email gateway can easily
foil any protection that MTA-STS aims to provide. In fact, MTA-STS was
invented so that an attacker at the network level is prevented from performing
downgrade attack but the same attacker can control DNS too in many cases.
</p>
<p>
The first attack an adversary controlling DNS can perform on MTA-STS is to
filter any TXT requests for "_mta-sts.example.com", where "example.com" is the
domain name of the email recipient. This would prevent the outbound email
gateway from being able to discover MTA-STS policy that is being published for
the recipient's mail exchange (MX) servers. With this attack, the entire
MTA-STS security is foiled and the attacker can perform Man in the Middle
attack on the outbound SMTP connection and perform downgrade attack for
STARTTLS command.
</p>
<p>
The second attack can foil protection that MTA-STS intends to provide when a
security policy for a domain name is already in cache of the outbound email
gateway.
</p>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
If a valid TXT record is found but no policy can be fetched via HTTPS (for any
reason), and there is no valid (non-expired) previously cached policy, senders
MUST continue with delivery as though the domain has not implemented
MTA-STS.<br />
<br />
-
<a
href="https://www.rfc-editor.org/rfc/rfc8461.html#section-3.3"
target="_blank"
>RFC 8461 Section 3.3</a
>
</blockquote>
<p>
With such an implementation that follows the RFC, all an attacker has to do is
block the domain name "mta-sts.example.com" from being resolved so that the
email gateway fails to download the policy from the standard
"https://mta-sts.example.com/.well-known/mta-sts.txt" well known URL. The
attacker now just has to wait for the previously cached policy to expire after
which the email gateway will continue delivering pending emails as though the
domain has not implemented MTA-STS as per the RFC's requirements.
</p>
<p>
This second attack is very much feasible considering the "max age" published
by many services is inadequate. For example, the "max age" value published by
Google for
<a href="https://mta-sts.gmail.com/.well-known/mta-sts.txt" target="_blank"
>Gmail</a
>
is just 86400 seconds (1 day). Comparing that to HSTS, the domain
"mail.google.com" uses "strict-transport-security: max-age=10886400;
includeSubDomains" header which has max age set to 10886400 seconds (126
days). Websites publishing max age for HSTS as large as 6 months or 1 year is
quite common.
</p>
<p>
Combining both the attacks, any protection that MTA-STS provides can be
effectively defeated. The only defense that is available is with logging and
using
<a href="https://www.rfc-editor.org/rfc/rfc8460" target="_blank"
>SMTP TLS Reporting</a
>
which is expected to be configured with MTA-STS by the recipient's email
administrator. The email gateway sending the outbound email is expected to
send a report of failures to the receiving email gateway's administrators
using either HTTPS or email transport.
</p>
<p>
A report via email transport is useless in such cases since an attacker
capable of performing downgrade attack can be expected to filter this report
email too. Thus the only secure transport for the report is HTTPS which not
everyone would have configured, for example,
<a
href="https://dnsclient.net/#Recursive%20Query%20%7Brecursive-resolver%7D/_smtp._tls.gmail.com/TXT/UDP/true"
target="_blank"
>Gmail has configured email transport</a
>
(v=TLSRPTv1;rua=mailto:sts-reports@google.com). A receiver of such a report is
also not capable of doing anything to fix the security issues at the sender's
end. The administrator of the sender's email gateway is expected to watch out
for logs/alerts and try to fix them.
</p>
<p>
Clearly, MTA-STS is not in a position to be a replacement for DNSSEC and DANE.
</p>
<h3>"Disadvantages of DNSSEC"</h3>
<p>
The DNS Institute has published
<a
href="https://dnsinstitute.com/documentation/dnssec-guide/dnssec-guide.html"
target="_blank"
>DNSSEC Guide</a
>
which discusses
<a
href="https://dnsinstitute.com/documentation/dnssec-guide/ch06s06.html"
target="_blank"
>"Disadvantages of DNSSEC"</a
>
which I believe are no longer valid today but are still believed by many
people.
</p>
<ol>
<li>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
Increased, well, everything: With DNSSEC, signed zones are larger, thus
taking up more disk space; for DNSSEC-aware servers, the additional
cryptographic computation usually results in increased system load; and
the network packets are bigger, possibly putting more strains on the
network infrastructure.<br />
<br />
-
<a
href="https://dnsinstitute.com/documentation/dnssec-guide/ch06s06.html"
target="_blank"
>"Disadvantages of DNSSEC"</a
>
</blockquote>
Disk space and computing power surely was an issue in 1990s or early 2000s
but its 2023 and is a non-issue today. There is
<a
href="https://en.wikipedia.org/wiki/Extension_Mechanisms_for_DNS"
target="_blank"
>Extension Mechanisms for DNS (EDNS(0))</a
>
which is a required feature for implementing DNSSEC. EDNS(0) allows a DNS
request over UDP protocol to be greater than the 512 bytes limit it earlier
had. This makes it feasible to transport DNSSEC related records without
issues for most use-cases. Even when a response does not fit into UDP and
requires retransmission over TCP, its important to remember that any DNS
response that was received is cached and thus is reused many times before it
expires.
</li>
<li>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
Different security considerations: DNSSEC addresses many security
concerns, most notably cache poisoning. But at the same time, it may
introduce a set of different security considerations, such as
amplification attack and zone enumeration through NSEC. These new concerns
are still being identified and addressed by the Internet community.<br />
<br />
-
<a
href="https://dnsinstitute.com/documentation/dnssec-guide/ch06s06.html"
target="_blank"
>"Disadvantages of DNSSEC"</a
>
</blockquote>
Amplification attack has nothing to do with DNSSEC specifically. These are
already possible without DNSSEC with just plain old DNS. There are already
mitigations against such attacks like query rate limiting and dropping known
amplification requests. Zone enumeration through NSEC already has more than
one solutions like using NSEC3 or using online signing with "white lies" or
"compact lies".
</li>
<li>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
More complexity: If you have read this far, you probably already concluded
this yourself. With additional resource records, keys, signatures,
rotations, DNSSEC adds a lot more moving pieces on top of the existing DNS
machine. The job of the DNS administrator changes, as DNS becomes the new
secure repository of everything from spam avoidance to encryption keys,
and the amount of work involved to troubleshoot a DNS-related issue
becomes more challenging.<br />
<br />
-
<a
href="https://dnsinstitute.com/documentation/dnssec-guide/ch06s06.html"
target="_blank"
>"Disadvantages of DNSSEC"</a
>
</blockquote>
Any technology adds complexity with it. Even PKI adds complexity which
everyone has become accustomed with. DNSSEC is solving a complex problem and
no one has yet come up with a better/easier way to solve the same problem
that DNSSEC does. There are better tooling options already available that
makes DNS administrator's job easier.
</li>
<li>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
Increased fragility: The increased complexity means more opportunities for
things to go wrong. In the absence of DNSSEC, DNS was essentially "add
something to the zone and forget". With DNSSEC, each new component -
re-signing, key rollover, interaction with parent zone, key management -
adds more scope for error. It is entirely possible that the failure to
validate a name is down to errors on the part of one or more zone
operators rather than the result of a deliberate attack on the DNS.<br />
<br />
-
<a
href="https://dnsinstitute.com/documentation/dnssec-guide/ch06s06.html"
target="_blank"
>"Disadvantages of DNSSEC"</a
>
</blockquote>
The re-signing, key rollover, interaction with parent zone, key management,
etc. tasks are already automated and require limited intervention. In fact,
I am managing my signed zones by just adding some records to the zone and
just forgetting about it.
</li>
<li>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
New maintenance tasks: Even if your new secure DNS infrastructure runs
without any hiccups or security breaches, it still requires regular
attention, from re-signing to key rollovers. While most of these can be
automated, some of the tasks, such as KSK rollover, remain manual for the
time being.<br />
<br />
-
<a
href="https://dnsinstitute.com/documentation/dnssec-guide/ch06s06.html"
target="_blank"
>"Disadvantages of DNSSEC"</a
>
</blockquote>
KSK rollover is a manual task but its usually done just once a year and
there is no expiry date attached to it like a TLS certificate. There are
mechanisms like
<a href="https://www.rfc-editor.org/rfc/rfc8078" target="_blank"
>CDS/CDNSKEY
</a>
currently being worked on to automate it too. Remember that before
<a href="https://en.wikipedia.org/wiki/Let%27s_Encrypt" target="_blank"
>Let's Encrypt CA</a
>
was available, everyone were used to buying TLS certificates from various
CA, manually renewing them every year, and replacing the certificates on
each and every web server/email gateway that was deployed. This also caused
extremely common issue with expired certificates which is not a case with
DNSSEC.
</li>
<li>
<blockquote
style="background-color: rgb(250, 250, 250); border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 10px;"
>
Not enough people are using it today: while it's estimated as of late
2016, that roughly 28% of the global Internet DNS traffic is validating
[5] , that doesn't mean that many of the DNS zones are actually signed.
What this means is, if you signed your company's zone today, only less
than 30% of the Internet users are taking advantage of this extra
security. It gets worse: with less than 1% of the .com domains signed, if
you enabled DNSSEC validation today, it's not likely to buy you or your
users a whole lot more protection until these popular domains names decide
to sign their zones.<br />
<br />
-
<a
href="https://dnsinstitute.com/documentation/dnssec-guide/ch06s06.html"
target="_blank"
>"Disadvantages of DNSSEC"</a
>
</blockquote>
DNSSEC
<a
href="https://pulse.internetsociety.org/blog/dnssec-validation-in-2022-africa-leads-with-amazing-growth"
target="_blank"
>adoption</a
>
is
<a
href="https://stats.dnssec-tools.org/#/?top=dane&trend_tab=0"
target="_blank"
>increasing</a
>
and the reasoning that not enough people use it so you should not bother is
a weak argument. If 1/3 users worldwide are validating DNSSEC then it still
makes sense to sign your domain names. It does not matter how many % of .com
domain names are signed, what matters is that your domain names are signed
and that many of your users do DNSSEC validation.
</li>
</ol>
<h3>Conclusion</h3>
<p>
It has taken a more than a decade for DNSSEC to be designed (and redesigned)
and the root zone being signed. It has been more than a decade that root zone
is signed and yet not all TLDs are signed. DNSSEC adoption is low but has been
steadily
<a
href="https://stats.dnssec-tools.org/#/?top=dane&trend_tab=0"
target="_blank"
>increasing</a
>
in last few years. The low adoption rate is simply due to not many
applications that implement it. Having popular applications like web browsers
adopt DNSSEC and DANE will result in significantly increase the adoption rate.
Many website would then start supporting PKI combined with DANE which will
immediately have an impact.
</p>
<p>
DANE surely wont displace the PKI system completely but there will be an
alternative option available for everyone which includes being able to deploy
both PKI and DANE together. This will allow people to decide on their own if
they want to use PKI, DANE, or both for their websites and services. Mass
adoption of DANE for
<a href="https://www.rfc-editor.org/rfc/rfc7672.html" target="_blank"
>sending email</a
>
will help to make sure that the email is protected from downgrade attacks and
is always encrypted in transit. DANE can also be useful for enterprises to
secure their intranet resources without need to deploy an enterprise wide root
CA.
</p>
<p>
Modern Operating Systems already include a DNS stub resolver service
(Microsoft Windows has a DNS Client service, and many Linux distros have
dnsmasq or systemd-resolved daemons). These DNS stub resolvers should start
supporting DNSSEC validation by default and standards like Extended DNS Errors
if they do not currently. They should also be standardized to listen on
loopback (127.0.0.1) address so that applications like web browsers can query
the local DNS stub resolver to perform DNSSEC validation by itself and use the
Extended DNS Errors signaling. This would also help with caching DNS records
at the OS level such that each application individually does not have to
maintain a separate cache. Such a standardized local DNS stub resolver service
will help applications to support DNSSEC and DANE with ease.
</p>
<p>
DNS is the basis for Internet security which systems like PKI depend upon when
issuing certificates. DNSSEC and DANE fixes the key security issues that have
been ignored for too long. A lot of problems that DNSSEC have had in the past
are already solved today and it is quite feasible to be implemented and
deployed at scale.
</p>
<p>
So, are you for or against DNSSEC and DANE? Let me know your thoughts in the
comments section below.
</p>
Shreyas Zarehttp://www.blogger.com/profile/01269575365702781881noreply@blogger.com2Mumbai, Maharashtra, India19.0759837 72.8776559-9.2342501361788472 37.721405899999993 47.386217536178847 108.0339059tag:blogger.com,1999:blog-8065376618611632499.post-27461494371948036512023-03-25T18:09:00.000+05:302023-03-25T18:09:00.281+05:30How To Auto Renew SSL Certificates With Certbot Using DNS Challenge<p>
If you have used
<a href="https://certbot.eff.org/" target="_blank">certbot</a> for automatic
renewal of SSL certificates for your website using the HTTP challenge and are
also running
<a href="https://technitium.com/dns/" target="_blank"
>Technitium DNS Server</a
>
to host your domain names then you can use certbot with DNS challenge to auto
renew your SSL certificates. DNS challenge for certificate renewal has many
advantages over HTTP challenge:
</p>
<ul>
<li>
DNS challenge allows renewing wildcard certificate for your domain like
*.example.com. This allows hiding your subdomain names such that they are
not listed in publicly available
<a
href="https://en.wikipedia.org/wiki/Certificate_Transparency"
target="_blank"
>Certificate Transparency</a
>
logs. If you are not familier with this then do check your domain name on
<a href="https://crt.sh/" target="_blank">crt.sh</a> website.
</li>
<li>
It allows renewing certificates for your internal servers i.e. servers in
private LAN that are not accessible over the Internet to use the HTTP
challenge. In fact, you do not even need to have a web server running to get
the certificate issued.
</li>
</ul>
<p>
The only constraint with using DNS challenge is to have either API access or
<a href="https://www.rfc-editor.org/rfc/rfc2136" target="_blank"
>Dynamic Updates (RFC 2136)</a
>
access to your DNS provider. If you are using Technitium DNS Server to host
your domain names, you have access to both. In this post we will discuss both
the options you have and their pros and cons.
</p>
<p>
This post is written for <b>Ubuntu Linux</b> but, you can easily follow
similar steps on your favorite distro.
</p>
<h3>Using HTTP API</h3>
<p>
Technitium DNS Server provides HTTP API which can be used to perform all the
tasks that you can perform using the DNS web console. In fact, the DNS web
console itself uses the same HTTP API. Certbot provides manual option for
certificate renewal which also includes
<a
href="https://eff-certbot.readthedocs.io/en/stable/using.html#hooks"
target="_blank"
>auth hook and cleanup hook</a
>
options that you can utilize to create DNS records and remove them during the
renewal process. We will be using these options to run a small bash script
that will use the DNS server's HTTP API.
</p>
<p>
Follow the steps below to setup certbot that will use the DNS HTTP API to
handle DNS challenge:
</p>
<p></p>
<ol>
<li>
Generate an API Token for the DNS Server HTTP API from the web console. To
do that, login to the web console, click on the top right user menu and
click the Create API Token menu item. Enter the user's password, give an
appropriate token name to help you identify it later, and click Create
button. The API token will be generated and displayed immediately.<br />
<br />
<b>Note!</b> The API token is displayed only once and not available later.
Thus, copy the token string somewhere temporarily to use in the later
steps.<br />
<br />
<b>Warning!</b> It is recommended that you do not generate the API token for
the DNS web console's "admin" user. Instead, create a separate user and edit
the zone's permissions to give View and Modify access to it. This is
necessary since in an event of the API token getting compromised the impact
will be limited.
</li>
<li>
Login using SSH on your web server (for which you wish to setup certbot) as
the root user or use <b>sudo su</b> to get root user access before
proceeding.
</li>
<li>
Create a <b>/root/certbot-auth.sh</b> bash script using your favourite text
editor with contents as shown below:
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
#!/bin/bash
# Generate API token from DNS web console
API_TOKEN="your-api-token"
# Create challenge TXT record
curl "http://dns-server:5380/api/zones/records/add?token=$API_TOKEN&domain=_acme-challenge.$CERTBOT_DOMAIN&type=TXT&ttl=60&text=$CERTBOT_VALIDATION"
# Sleep to make sure the change has time to propagate from primary to secondary name servers
sleep 25</pre
>
</li>
<li>
Similarly create a <b>/root/certbot-cleanup.sh</b> bash script using your
favourite text editor with contents as shown below:
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
#!/bin/bash
# Generate API token from DNS web console
API_TOKEN="your-api-token"
# Delete challenge TXT record
curl "http://dns-server:5380/api/zones/records/delete?token=$API_TOKEN&domain=_acme-challenge.$CERTBOT_DOMAIN&type=TXT&text=$CERTBOT_VALIDATION"</pre
>
</li>
<li>
Make both the bash scripts executable and only accessible to the root user
as shown below:
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
chmod 700 /root/certbot-auth.sh
chmod 700 /root/certbot-cleanup.sh</pre
>
</li>
<li>
Install certbot if you do not have it already installed.
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
apt update
apt install certbot</pre
>
</li>
<li>
Run the certbot command as shown below to start the initial certificate
request for your domain name.
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
certbot certonly \
--manual \
--preferred-challenges=dns \
--manual-auth-hook /root/certbot-auth.sh \
--manual-cleanup-hook /root/certbot-cleanup.sh \
-d example.com \
-d *.example.com</pre
>
</li>
<li>
Once the certbot command completes successfully, you will find the generated
certificates in <i>/etc/letsencrypt/live/example.com</i> folder.
</li>
</ol>
<p>
The HTTP API provides powerful ways to automate tasks as shown above but it
has some issues that needs to be considered:
</p>
<ul>
<li>
Using the HTTP API requires that the DNS server's web console needs to be
accessible so that it can be used with automation scripts which may not be
desirable in all scenarios.
</li>
<li>
The sample certbot auth/cleanup bash scripts that use the HTTP API uses HTTP
links which are not secure. Thus you need to setup SSL certificate for the
DNS server's web console before deploying certbot as described above in
production.
</li>
<li>
If the API token saved in the bash scripts is compromised, an attacker will
be able to perform all HTTP API calls with the priviledge of the API token's
user. Thus its needed to be made sure that the user has limited access to
only the zones that are required.
</li>
<li>
The API token allows modifying all the records in the zone since there is no
granular permission available for each record. So, any compromise of the
token can cause issues for the entire zone.
</li>
</ul>
<h3>Using Dynamic Updates (RFC 2136)</h3>
<p>
Technitium DNS Server supports Dynamic Updates (RFC 2136) for primary zones
which can be used with Certbot's
<a
href="https://certbot-dns-rfc2136.readthedocs.io/en/stable/"
target="_blank"
>certbot-dns-rfc2136</a
>
plugin.
</p>
<p>
Dymamic Updates is a DNS standard which means it uses the DNS protocol itself
to work and thus there is no requirement for configuring SSL certificate for
your DNS server's web console like in the case of HTTP API.
</p>
<p>
Also a special thing about Dynamic Updates is that it allows authentication
using TSIG standard and allows specifying a Security Policy wherein you can
explicitly configure which record and record type can be
created/modified/deleted using the TSIG key.
</p>
<p>
This means that Dynamic Updates option is much better compared to the HTTP API
option from security perspective. Thus its recommended to be used in
production over the HTTP API option described earlier.
</p>
<p>
Follow the steps below to setup certbot to use certbot-dns-rfc2136 plugin to
handle DNS challenge:
</p>
<ol>
<li>
Login using SSH on your web server (for which you wish to setup certbot) as
the root user or use <b>sudo su</b> to get root user access before
proceeding.
</li>
<li>
Install certbot and python3-pip if you do not have it already installed.
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
apt update
apt install certbot python3-pip -y</pre
>
</li>
<li>
Install the certbot-dns-rfc2136 plugin as shown below.
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
python3 -m pip install certbot-dns-rfc2136</pre
>
</li>
<li>
Login to the DNS server's web console and navigate to
<b>Settings > TSIG</b> section. Click on the Add button on the top right
side to add a new entry. Enter an appropriate TSIG key name to help you
identify it later, keep the Shared Secret empty, select the algorithm as
HMAC-SHA256, and click Save Settings button at the bottom left corner. This
will generate a TSIG key with a randomly generated Shared Secret which will
be shown after you have saved the settings. Use the TSIG key name and the
generated Shared Secret in the next step.
</li>
<li>
Create a <b>/root/certbot-rfc2136.ini</b> text file using your favourite
text editor with contents as shown below:
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
# Target DNS server (IPv4 or IPv6 address, not a hostname)
dns_rfc2136_server = 192.168.10.2
# Target DNS port
dns_rfc2136_port = 53
# TSIG key name
dns_rfc2136_name = YOUR-TSIG-KEY-NAME.
# TSIG key secret
dns_rfc2136_secret = YOUR-TSIG-SHARED-SECRET
# TSIG key algorithm
dns_rfc2136_algorithm = HMAC-SHA256</pre
>
</li>
<li>
Set file permissions so that the ini file is only accessible to the root
user.
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
chmod 600 /root/certbot-rfc2136.ini</pre
>
</li>
<li>
Configure the zone, for which you wish to generate the SSL certificate, to
enable Dynamic Updates. To do so, switch to the DNS server's web console and
navigate to the <b>Zones</b> section. Find your zone and click on it to open
the zone edit view. Find the <b>Options</b> button at the top and click it
to open the Zone Options dialog. Navigate to the
<b>Dynamic Updates (RFC 2136)</b> tab to configure it. In there select the
"Allow" option to allow Dynamic Updates then scroll down to create a
Security Policy. Click on the Add button to add a new security policy entry.
Here select the TSIG key name that you had created earlier, enter
"_acme-challenge.example.com" as the domain name, enter "TXT" as the Allowed
Record Types, and click Save button to complete the config.
</li>
<li>
Run the certbot command as shown below to start the initial certificate
request for your domain name.
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
certbot certonly \
--dns-rfc2136 \
--dns-rfc2136-credentials /root/certbot-rfc2136.ini \
--dns-rfc2136-propagation-seconds 25 \
-d example.com \
-d *.example.com</pre
>
</li>
<li>
Once the certbot command completes successfully, you will find the generated
certificates in <i>/etc/letsencrypt/live/example.com</i> folder.
</li>
</ol>
<h3>Testing Auto Renewal</h3>
<p>
Once you have the SSL certificate generated with certbot, it will be
automatically renewed using the same config that you used to request the
initial certificate. To test the certbot renewal process, you can try the dry
run command shown below. If there are no errors reported during the dry run
then it means the renewal mechanism is working as expected.
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
sudo certbot renew --dry-run
</pre>
<h3>Configuring Your Web Server</h3>
<p>
You can now configure your web server or any other server that requires the
SSL certificate to complete the setup. When the SSL certificate is renewed,
your web server may need to be reloaded to allow it to load the new
certificate. To do that you can create a
<b>/etc/letsencrypt/renewal-hooks/post/reload.sh</b> bash script using your
favourite text editor with the sample script below that will reload nginx web
server in this example.
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
#!/bin/sh
systemctl reload nginx
echo "nginx reloaded!"</pre
>
<p>Make the reload script executable as shown below.</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
chmod +x /etc/letsencrypt/renewal-hooks/post/reload.sh</pre
>
<p>
The above script will be automatically executed by certbot when the SSL
certificate is renewed.
</p>
<p>
If you have any queries do let me know in the comments section below or send
an email to
<a href="mailto:support@technitium.com" target="_blank"
>support@technitium.com</a
>.
</p>
Shreyas Zarehttp://www.blogger.com/profile/01269575365702781881noreply@blogger.com0Mumbai, Maharashtra, India19.0759837 72.8776559-9.2342501361788472 37.721405899999993 47.386217536178847 108.0339059tag:blogger.com,1999:blog-8065376618611632499.post-88394718669229417732023-02-19T17:56:00.014+05:302024-02-24T11:47:55.287+05:30Configuring DNS-over-QUIC and HTTPS/3 For Technitium DNS Server<p><i>Updated: 14 Jul 2023</i></p>
<p>
Technitium DNS Server is a cross-platform, free, open source software that is
easy to deploy and use yet pack powerful features. Starting with the version
11.0 release, the DNS server now supports
<a href="https://www.ietf.org/rfc/rfc9250.html" target="_blank"
>DNS-over-QUIC</a
>
encrypted DNS protocol in addition to existing DNS-over-TLS and DNS-over-HTTPS
encrypted DNS protocols. With this update, you will be able to use
DNS-over-QUIC protocol with a forwarder or connditional forwarder, or host
your own DNS-over-QUIC service.
</p>
<p>
The DNS server has also added support for HTTP/3 for both its web console and
DNS-over-HTTPS service. Since HTTP/3 also uses QUIC tranport protocol, the
requirements and configuration mentioned in this post also applies to it.
</p>
<p>
Let's see how to configure the DNS server to use the new QUIC transport
protocol.
</p>
<p>
<b>Requirements</b>
</p>
<p>
The DNS-over-QUIC protocol uses a very new QUIC transport protocol which is
not yet available on all platforms. Currently it is available only on Windows
and Linux platforms. The .NET Runtime relies on the <b>msquic</b> library
which is an implementation of QUIC protocol by Microsoft.
</p>
<p>
<b>For Windows</b>
</p>
<p>
The support for QUIC on Windows is only available on following Windows
versions:
</p>
<ul>
<li>Windows 11 (build 22000 or later)</li>
<li>Windows Server 2022</li>
</ul>
<p>
The above supported Windows version have <b>msquic</b> already installed and
thus there is no additional installation needed. There is no option yet to use
the QUIC protocol on Windows 10 or older versions. However, it is possible to
use it on Windows 10 by using docker container deployments.
</p>
<p>
<b>For Linux</b>
</p>
<p>
On Linux, you need to install <b>libmsquic</b> to enable QUIC protocol
support. You can install it using
<a
href="https://learn.microsoft.com/en-us/windows-server/administration/linux-package-repository-for-microsoft-software"
target="_blank"
>Microsoft Software Repository for Linux</a
>. You can follow the instructions given in the link to add the software
repository on your distro as shown in examples below:
</p>
<ul>
<li>
Ubuntu 22.04<br />
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
curl -sSL https://packages.microsoft.com/keys/microsoft.asc | sudo tee /etc/apt/trusted.gpg.d/microsoft.asc
sudo apt-add-repository https://packages.microsoft.com/ubuntu/22.04/prod
sudo apt-get update
</pre
>
</li>
<li>
Raspberry Pi OS<br />
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
curl -sSL https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
sudo apt-add-repository https://packages.microsoft.com/debian/12/prod
sudo apt-get update
</pre
>
</li>
</ul>
<p>
Once you have the Microsoft Software Repository installed on your distro, you
can proceed to install <b>libmsquic</b> library as shown below:
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
sudo apt-get install libmsquic -y
</pre>
<p>
Now restart the DNS server so that it loads the newly installed libmsquic
library. Once the DNS server is available, you can use the DNS-over-QUIC
protocol with forwarder or conditional forwarder configuration, or with the
DNS Client tab in the DNS server web console. If you wish to run your own
DNS-over-QUIC service, you can enable it from the Settings > Optional
Protocols section similar to how you would enable the other encrypted DNS
protocols.
</p>
<p>
If you have enabled HTTPS and HTTP/3 options, and configured a TLS certificate
for the DNS web console, the web service will enable HTTP/3 support which will
be available on UDP port 443.
</p>
<p>
If you have any comments or queries, do let me know in the comments section
below or send an email to
<a href="mailto:support@technitium.com">support@technitium.com</a>.
</p>
Shreyas Zarehttp://www.blogger.com/profile/01269575365702781881noreply@blogger.com10Mumbai, Maharashtra, India19.0759837 72.8776559-9.2342501361788472 37.721405899999993 47.386217536178847 108.0339059tag:blogger.com,1999:blog-8065376618611632499.post-32102091783098003262023-02-18T18:13:00.004+05:302023-02-18T18:13:52.264+05:30Technitium DNS Server v11 Released!<p>
I am happy to announce the release of
<a href="https://technitium.com/dns/" target="_blank"
>Technitium DNS Server v11</a
>, a cross-platform, free, open source software that can be used by anyone, be
it a novice or an expert user. It features an easy to use web based GUI and
works with default config that allows the server to run out-of-the-box.
</p>
<p>
<a href="https://technitium.com/dns/" target="_blank">Download</a> the latest
update for Windows, Linux, macOS, or Raspberry Pi!
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/technitium-dns-server-v9-dashboard.png"
style="margin-left: auto; margin-right: auto;"
><img
alt="Technitium DNS Server"
border="0"
data-original-height="736"
data-original-width="1115"
height="422"
width="640"
src="https://technitium.com/img/blog/technitium-dns-server-v9-dashboard.png"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Technitium DNS Server v11
</td>
</tr>
</tbody>
</table>
<p>This is a major release that now runs on ASP.NET Core 7 Runtime as the DNS server now uses Kestrel web server for both its web console and also for DNS-over-HTTPS service. With this change, the DNS server now supports HTTP/2 and HTTP/3 for both DNS-over-HTTPS service and also for the DNS web console. It also now supports DNS-over-QUIC encrypted DNS protocol and many new features.</p>
<p>
Read the
<a
href="https://github.com/TechnitiumSoftware/DnsServer/blob/master/CHANGELOG.md"
target="_blank"
>change log</a
>
to know full details about this latest update.
</p>
<p>
Any comment or feedback is really appreciated and helps a lot in adding new
features and fixing bugs. Send your feedback or support requests to
<a href="mailto:support@technitium.com" target="_blank"
>support@technitium.com</a
>. You can also post on
<a href="https://www.reddit.com/r/technitium/" target="_blank"
>/r/technitium</a
>
on Reddit for community support. For any feature request or reporting bugs,
create an issue on
<a
href="https://github.com/TechnitiumSoftware/DnsServer/issues"
target="_blank"
>GitHub</a
>.
</p>
<p>
The DNS Server source code is available under
<a href="https://go.technitium.com/?id=24" target="_blank"
>GNU General Public Licence (GPL) v3</a
>
on
<a href="https://github.com/TechnitiumSoftware/DnsServer" target="_blank"
>GitHub</a
>.
</p>
<p>
Make a contribution to the project and help in
developing new software, updates and adding more features possible.<br/>
<a href="https://go.technitium.com/?id=35" target="_blank"
>Donate Now!</a
>
</p>
Shreyas Zarehttp://www.blogger.com/profile/01269575365702781881noreply@blogger.com4Mumbai, Maharashtra, India19.0759837 72.8776559-9.2342501361788472 37.721405899999993 47.386217536178847 108.0339059tag:blogger.com,1999:blog-8065376618611632499.post-43210247254937557082022-11-26T15:07:00.000+05:302022-11-26T15:07:12.807+05:30Technitium DNS Server v10 Released!<p>
I am happy to announce the release of
<a href="https://technitium.com/dns/" target="_blank"
>Technitium DNS Server v10</a
>, a cross-platform, free, open source software that can be used by anyone, be
it a novice or an expert user. It features an easy to use web based GUI and
works with default config that allows the server to run out-of-the-box.
</p>
<p>
<a href="https://technitium.com/dns/" target="_blank">Download</a> the latest
update for Windows, Linux, macOS, or Raspberry Pi!
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/technitium-dns-server-v9-dashboard.png"
style="margin-left: auto; margin-right: auto;"
><img
alt="Technitium DNS Server"
border="0"
data-original-height="736"
data-original-width="1115"
height="422"
width="640"
src="https://technitium.com/img/blog/technitium-dns-server-v9-dashboard.png"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Technitium DNS Server v10
</td>
</tr>
</tbody>
</table>
<p>This is a major release that now runs on .NET 7 Runtime and adds a lot of features like Dynamic Updates Security Policy, DANE TLSA record, SSHFP record, EDNS Client Subnet, DNS64, and more.</p>
<p>
Read the
<a
href="https://github.com/TechnitiumSoftware/DnsServer/blob/master/CHANGELOG.md"
target="_blank"
>change log</a
>
to know more details about this latest update.
</p>
<p>
Any comment or feedback is really appreciated and helps a lot in adding new
features and fixing bugs. Send your feedback or support requests to
<a href="mailto:support@technitium.com" target="_blank"
>support@technitium.com</a
>. You can also post on
<a href="https://www.reddit.com/r/technitium/" target="_blank"
>/r/technitium</a
>
on Reddit for community support. For any feature request or reporting bugs,
create an issue on
<a
href="https://github.com/TechnitiumSoftware/DnsServer/issues"
target="_blank"
>GitHub</a
>.
</p>
<p>
The DNS Server source code is available under
<a href="https://go.technitium.com/?id=24" target="_blank"
>GNU General Public Licence (GPL) v3</a
>
on
<a href="https://github.com/TechnitiumSoftware/DnsServer" target="_blank"
>GitHub</a
>.
</p>
<p>
You can make a contribution to the project by becoming a Patron and help in
developing new software, updates and adding more features possible.
<a href="https://go.technitium.com/?id=35" target="_blank"
>Become a Patron now!</a
>
</p>
Shreyas Zarehttp://www.blogger.com/profile/01269575365702781881noreply@blogger.com19Mumbai, Maharashtra, India19.0759837 72.8776559-9.2342501361788472 37.721405899999993 47.386217536178847 108.0339059tag:blogger.com,1999:blog-8065376618611632499.post-62838685483426456452022-09-24T18:02:00.000+05:302022-09-24T18:02:54.506+05:30Technitium DNS Server v9 Released!<p>
I am happy to announce the release of
<a href="https://technitium.com/dns/" target="_blank"
>Technitium DNS Server v9</a
>, a cross-platform, free, open source software that can be used by anyone, be
it a novice or an expert user. It features an easy to use web based GUI and
works with default config that allows the server to run out-of-the-box.
</p>
<p>This is a major release that adds multi-user role based access support.</p>
<p>
<a href="https://technitium.com/dns/" target="_blank">Download</a> the latest
update for Windows, Linux, macOS, or Raspberry Pi!
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/technitium-dns-server-v9-dashboard.png"
style="margin-left: auto; margin-right: auto;"
><img
alt="Technitium DNS Server"
border="0"
data-original-height="736"
data-original-width="1115"
height="422"
width="640"
src="https://technitium.com/img/blog/technitium-dns-server-v9-dashboard.png"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Technitium DNS Server v9
</td>
</tr>
</tbody>
</table>
<p>
Read the
<a
href="https://github.com/TechnitiumSoftware/DnsServer/blob/master/CHANGELOG.md"
target="_blank"
>change log</a
>
to know more details about this latest update.
</p>
<p>
Any comment or feedback is really appreciated and helps a lot in adding new
features and fixing bugs. Send your feedback or support requests to
<a href="mailto:support@technitium.com" target="_blank"
>support@technitium.com</a
>. You can also post on
<a href="https://www.reddit.com/r/technitium/" target="_blank"
>/r/technitium</a
>
on Reddit for community support. For any feature request or reporting bugs,
create an issue on
<a
href="https://github.com/TechnitiumSoftware/DnsServer/issues"
target="_blank"
>GitHub</a
>.
</p>
<p>
The DNS Server source code is available under
<a href="https://go.technitium.com/?id=24" target="_blank"
>GNU General Public Licence (GPL) v3</a
>
on
<a href="https://github.com/TechnitiumSoftware/DnsServer" target="_blank"
>GitHub</a
>.
</p>
<p>
You can make a contribution to the project by becoming a Patron and help in
developing new software, updates and adding more features possible.
<a href="https://go.technitium.com/?id=35" target="_blank"
>Become a Patron now!</a
>
</p>
Shreyas Zarehttp://www.blogger.com/profile/01269575365702781881noreply@blogger.com2Mumbai, Maharashtra, India19.0759837 72.8776559-9.2342501361788472 37.721405899999993 47.386217536178847 108.0339059tag:blogger.com,1999:blog-8065376618611632499.post-26453042043958440222022-07-10T16:24:00.009+05:302023-11-02T16:40:13.089+05:30How To Secure Your Domain Name With DNSSEC<p>
The
<a
href="https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions"
target="_blank"
>Domain Name System Security Extension (DNSSEC)</a
>
is an extension that allows you to digitally sign DNS records for your domain
name. This allows a DNS client that supports DNSSEC validation to authenticate
all the DNS responses for your domain name. It is important to note that
DNSSEC provides authentication but does not encrypt the data in transit. Thus
it is possible for an attacker on the network to log the DNSSEC requests and
responses, or block them all together.
</p>
<p>
This blog post is a continuation of the
<a
href="https://blog.technitium.com/2022/06/how-to-self-host-your-own-domain-name.html"
target="_blank"
>previous blog post</a
>
that was about self hosting your own domain name. In this blog post we will
take a look at how you can sign your self hosted domain name with DNSSEC. But
first lets find out why you should sign your domain name and understand how
DNSSEC validation works.
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/technitium-dns-server-v8-dashboard.png"
style="margin-left: auto; margin-right: auto;"
><img
border="0"
data-original-height="422"
data-original-width="640"
height="422"
src="https://technitium.com/img/blog/technitium-dns-server-v8-dashboard.png"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Technitium DNS Server Supports Both DNSSEC Signing And Validation
</td>
</tr>
</tbody>
</table>
<p><b>Why You Should Sign You Domain Name</b></p>
<p>
This is a genuine question that comes up in everyone's mind considering that
SSL/TLS certificates already protect your website from Man In The Middle
(MiTM) attacks and also protect the data being transferred by encrypting
it.
</p>
<p>
Even then, there are many reasons to consider to sign your domain name, some
of which are:
</p>
<ul style="text-align: left;">
<li>
Most SSL/TLS certificates are issued based on domain name validation. This
means an unsigned domain name that is vulnerable to spoofing, will allow an
attacker to get a certificate issued for your domain name by spoofing
responses to a Certificate Authority (CA) DNS requests during the
certificate issue process. A signed domain name will prevent such attacks.
</li>
<li>
The
<a
href="https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization"
target="_blank"
>CAA</a
>
records that are used to indicate which CAs are authorized to issue a
certificate for your domain name are secured when the domain name is signed.
This prevents an attacker to get a certificate issued from unauthorized CAs
by spoofing CAA responses.
</li>
<li>
Your HTTPS website is protected with SSL/TLS certificate since a user
entering the domain name in the web browser that is matched with the
certificate's subject. But your emails are not protected in that same
manner. When an email is sent, the sender's mail server queries for MX
records for your domain name to find out the mail servers that receive email
for your domain name. If the domain name is unsigned, its possible to spoof
the MX response to redirect your email to an attacker controlled mail server
which then forwards the emails to your mail servers keeping a copy of all
your emails.
</li>
<li>
Even when your domain name is signed, its possible for an attacker on the
network path to downgrade a
<a
href="https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol"
target="_blank"
>SMTP</a
>
session such that
<a href="https://en.wikipedia.org/wiki/Opportunistic_TLS" target="_blank"
>STARTTLS</a
>
fails causing your email to be transmitted in clear text. A signed domain
name that has
<a
href="https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities"
target="_blank"
>DANE</a
>
configured for your mail servers will prevent such attacks.
</li>
<li>
DNS is also used to prove ownership of the domain name for many services
that is usually done by publishing a TXT record with a given challenge
string. An attacker can abuse such processes by spoofing TXT responses for
unsigned domain name to prove ownership.
</li>
<li>
A signed domain name also protects itself from
<a href="https://en.wikipedia.org/wiki/DNS_spoofing" target="_blank"
>cache poisoning</a
>
attacks on recursive resolvers that do DNSSEC validation.
</li>
</ul>
<p>
Signing your domain name thus protects your domain name as an owner from abuse
or hijacks which otherwise are possible for an attacker with enough resources
and motivation. Take a look at
<a href="https://www.youtube.com/watch?v=exy5JwAU8qk" target="_blank"
>this video</a
>
that explains how an attacker was able to performed an attack to hijack IMAP
service that DNSSEC would have prevented.
</p>
<p><b>How Does DNSSEC Validation Work?</b></p>
<p>
DNSSEC uses
<a
href="https://en.wikipedia.org/wiki/Public-key_cryptography"
target="_blank"
>public key cryptography</a
>
to digitally sign the DNS records. The most commonly used algorithm is
<a href="https://en.wikipedia.org/wiki/RSA_(cryptosystem)" target="_blank"
>RSA</a
>
but new algorithms like
<a
href="https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm"
target="_blank"
>ECDSA</a
>,
<a href="https://en.wikipedia.org/wiki/EdDSA#Ed25519" target="_blank"
>Ed25519</a
>, and
<a href="https://en.wikipedia.org/wiki/EdDSA#Ed448" target="_blank">Ed448</a>
are also standardized.
</p>
<p>
The primary name server that hosts a DNSSEC signed zone has access to the
secret private key being used to sign the zone while the corresponding public
key is available as public <b>DNSKEY</b> record in the zone. Each record set
in the zone, which is a group of records of same type, including the DNSKEY
record set, is signed using the private key and the signature is stored as a
<b>RRSIG</b> record. So, a DNS client can validate each record set by
requesting for the DNSKEY records and use the public key from them to verify
the signature in the RRSIG records in the DNS response.
</p>
<p>
To make sure that the DNSKEY records received by the DNS client itself are
genuine, the DNS client has to fetch another set of <b>DS</b> (delegation
signer) records from the parent zone. The DS record contains the hash of the
DNSKEY record which the DNS client can use to validate the DNSKEY record that
it has received. The DNSKEY which has a corresponding DS record published in
the parent zone has a flag called <b>Secure Entry Point (SEP)</b> set to
indicate that. The DS records from the parent zone itself are signed which the
DNS client has to again validate against the DNSKEY records from the parent
zone. The DNS client is configured with either DS records or DNSKEY records of
the ROOT zone which acts as the
<a href="https://en.wikipedia.org/wiki/Trust_anchor" target="_blank"
>trust anchor</a
>
allowing the DNS client to validate a domain name and its parent zones up to
the ROOT zone. This is called a
<a href="https://en.wikipedia.org/wiki/Chain_of_trust" target="_blank"
>chain of trust</a
>
where having a trusted ROOT zone's DS records is sufficient for a DNS client
to validate all domain names recursively.
</p>
<p>
The RRSIG records allow the DNS client to validate an existing record set but
how does the signed zone prove that the requested type of record set or the
sub domain name itself does not exists? This problem is solved using the
<b>NSEC</b> (next secure) records which adds a level of complexity to DNSSEC.
The signed zone has NSEC records for each sub domain names including the
zone's apex and contains the domain name of the next NSEC record forming a
kind of linked list that is sorted in an alphabetic order (canonical order).
The last NSEC record contains the domain name of the first NSEC record. The
NSEC records also lists the type of record sets that exist for that particular
sub domain name. A DNS client using the NSEC records received for a request
can validate if the requested domain does not exists (NXDOMAIN) or if there
are no records for the requested type (NODATA).
</p>
<p>
The problem with the NSEC records, used to prove non-existence of domain name
or a record type, is that the zone's entire structure gets published and thus
anyone can use a technique called "zone walking" to list out all the sub
domain names and all the record types for the zone. This is since NSEC records
form a linked list and so the first NSEC record at the zone apex tells you the
sub domain name of the next NSEC record which can be similarly followed to
know all the sub domain names in that zone. This can be a problem if a zone
contains private or internal records that must not be publicly disclosed. To
fix this issue, another record type called <b>NSEC3</b> (next secure 3) was
introduced that uses hashing technique to mask the domain names that are
visible in NSEC records. The NSEC3 record is also a kind of linked list
similar to NSEC that can be used in similar way to prove non-existence of a
domain or record set but the hashing of domain names in it adds another layer
of complexity. The NSEC3 record makes it difficult for an attacker to perform
"zone walking" but is not impossible for someone determined with resources to
spare.
</p>
<p><b>Configuration</b></p>
<p>
The most common way to configure a signed zone is to have two sets of key
pairs called <b>Key Signing Key (KSK)</b> and <b>Zone Signing Key (ZSK)</b>.
The KSK is the key pair for which a DS record is added in the parent zone and
is used to sign only the DNSKEY records in the zone. While ZSK is the key pair
that is used to sign all other types of records in the zone. This scheme of
key management allows you to replace the ZSK (rollover the key) without the
need to update any DS record at the parent zone making it possible to
frequently change the ZSK. This also allows the private keys corresponding to
KSK to be stored securely in a
<a
href="https://en.wikipedia.org/wiki/Hardware_security_module"
target="_blank"
>Hardware Security Module (HSM)</a
>
which is only used when key rollover operation is required to be performed
preventing KSK from being compromised. Technitium DNS Server implements KSK
and ZSK keys to sign a zone but does not yet support HSM and thus all the
private keys are stored in the zone file itself.
</p>
<p>
The most common reason for a signed domain name to fail validation and thus
become inaccessible to users of validating DNS resolvers is misconfiguration
caused during key rollover. The DNS records are highly cached at all levels.
This means a record that has been deleted from the zone can still exists in
caches of recursive resolvers, DNS proxies, OS, and even applications like web
browsers. This makes it error prone to perform DNSSEC operations without help
of proper tooling. The DNSSEC implementation done in Technitium DNS Server
ensures that its easy and error free to configure and maintain a signed zone.
</p>
<p>
There are a few minimum requirements that you must check before proceeding to
sign your zone:
</p>
<ol style="text-align: left;">
<li>
Check whether your Top Level Domain (TLD) is itself signed. You can only
sign your zone if the parent zone too is signed. To check this, you can use
the <a href="https://dnsclient.net/" target="_blank">DNS Client</a> tool to
query for the TLD domain name with type set to DS. For example, if you
domain is <b>example.com</b>, you should query for <b>com</b> as the domain
name with type as <b>DS</b>. If you see one or more DS records in the answer
section of the response then it means your TLD is signed and you can thus
sign your zone.
</li>
<li>
Make sure your zone does not use any proprietary <b>ANAME</b> or
<b>APP</b> records. This is since those records generate a dynamic response
which is not supported by the DNSSEC implementation. If you have any such
records for a sub domain name then create another zone for the sub domain
name for these type of records which will allow you to sign your main domain
name independently. This ensures that your zone is signed except for those
dynamic type of records in the sub domain zone.
</li>
<li>
Check that all of your secondary name servers support DNSSEC. If you chose
to use NSEC3 as the non-existence proof for your zone then make sure that
NSEC3 too is supported by your secondary name servers.
</li>
</ol>
<p>
Once you have confirmed all of the above requirements, you can proceed to sign
your zone.
</p>
<p><u>Signing Your Primary Zone</u></p>
<p>Proceed with the the steps below to sign your zone:</p>
<ol style="text-align: left;">
<li>
Login to the DNS web console, go to the Zones section and click on the Edit
button for your primary zone.
</li>
<li>
In the zone view, click on the <b>DNSSEC</b> button at the top right corner
to get a drop down menu. Click on the <b>Sign Zone</b> menu item to get the
Sign Zone dialog box. <br /><br />
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/primary-zone-dnssec-sign-zone-menu.png"
style="margin-left: auto; margin-right: auto;"
><img
border="0"
data-original-height="475"
data-original-width="1183"
height="256"
src="https://technitium.com/img/blog/primary-zone-dnssec-sign-zone-menu.png"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
The Primary Zone DNSSEC Drop Down Menu
</td>
</tr>
</tbody>
</table>
</li>
<li>
In the Sign Zone dialog box, select the recommended <b>ECDSA</b> algorithm
as the DNSKEY algorithm and <b>P256</b> as the ECDSA Curve. <br /><br />
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/primary-zone-dnssec-sign-zone-dialog.png"
style="margin-left: auto; margin-right: auto;"
><img
border="0"
data-original-height="645"
data-original-width="771"
height="535"
src="https://technitium.com/img/blog/primary-zone-dnssec-sign-zone-dialog.png"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
The Sign Zone Dialog Box
</td>
</tr>
</tbody>
</table>
</li>
<li>
Select the recommended <b>NSEC</b> as the
<b>Proof Of Non-Existence</b> option. If your zone contains private/internal
sub domain name records then you may use the <b>NSEC3</b> option to hide
them.
</li>
<li>
Select a suitable <b>DNSKEY TTL</b> value which by default is set to 3600
sec (1 hour). A lower value allows quick addition or rollover of DNS keys
but will cause frequent requests for the DNSKEY records.
</li>
<li>
Select a suitable <b>ZSK Automatic Rollover</b> value which is the frequent
at which the DNS server will rollover the ZSK to a new key automatically.
</li>
<li>
After you have confirmed all the above values, click on the
<b>Sign Zone</b> button to start the zone signing process.
</li>
</ol>
<p>
When the zone signing process completes, you will see DNSSEC related records
populated in the zone. Click on the <b>DNSSEC</b> button on the top right
corner of the zone view and you will see a new drop down menu pop up. Click on
the <b>Properties</b> menu item to see the <b>DNSSEC Properties</b> dialog box
which shows you all the options that you entered while signing the zone to
allow changing them later.
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/primary-zone-dnssec-properties-dialog.png"
style="margin-left: auto; margin-right: auto;"
><img
border="0"
data-original-height="645"
data-original-width="933"
height="442"
src="https://technitium.com/img/blog/primary-zone-dnssec-properties-dialog.png"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
The DNSSEC Properties Dialog Box
</td>
</tr>
</tbody>
</table>
<p><u>Adding DS Record</u></p>
<p>
Your zone is now signed but since you haven't added a DS record in the parent
zone, the zone still cannot be validated by DNS clients and is still insecure.
The next step is to add a DS record in the parent zone so that your zone can
be validated and become secure. To do that, click on the <b>DNSSEC</b> button
on the top right corner of the zone view and click on the
<b>View DS Info</b> menu item to see the View DS Info dialog box. The View DS
Info popup shows all the details required to add the DS record. But, before
you add the DS record ensure that the <b>Key State</b> value shows
<b>Ready</b>. If the DNSKEY was just published, you will see the Key State as
<b>Published</b> with a "ready by" timestamp in brackets. The timestamp tells
you when the Key State will switch from <b>Published</b> to
<b>Ready</b> state. Once the Key State becomes <b>Ready</b>, you can proceed
to add the DS record for your zone.
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/primary-zone-view-ds-info.png"
style="margin-left: auto; margin-right: auto;"
><img
border="0"
data-original-height="597"
data-original-width="933"
height="409"
src="https://technitium.com/img/blog/primary-zone-view-ds-info.png"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
The Primary Zone View DS Info Dialog Box
</td>
</tr>
</tbody>
</table>
<p>
<b>WARNING!</b> The most important thing to remember about signing the zone is
that you MUST wait until the <b>Key State</b> of the DNSKEY with Secure Entry
Point (SEP) flag becomes <b>Ready</b> before adding the DS record in the
parent zone. If you do not wait, you risk your zone to fail validation for
recursive resolvers that have old records still in their cache. The wait time
to Ready state ensures that all the caches have expired.
</p>
<p>
Once the DNSKEY record's Key State becomes <b>Ready</b>, login to your domain
registrar's web panel, find your domain name and click on the Manage option to
view the domain details. Find the <b>DNSSEC Management</b> option in there
which may be inside the Manage Nameservers option. Here you will find options
to create DS records that will be automatically updated by your registrar into
the parent zone.
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/create-ds-record-form.png"
style="margin-left: auto; margin-right: auto;"
><img
border="0"
data-original-height="332"
data-original-width="876"
height="242"
src="https://technitium.com/img/blog/create-ds-record-form.png"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
The Create DS Record Form (For name.com Registrar)
</td>
</tr>
</tbody>
</table>
<p>
The View DS Info popup displays all required values i.e. <b>Key Tag</b>,
<b>Algorithm</b>, <b>Digest Type</b>, and <b>Digests</b>. For adding the DS
record, use the provided <b>Key Tag</b> value, select the
<b>Algorithm</b> number 13 i.e. <b>ECDSAP256SHA256</b> that was used to sign
your zone, the <b>Digest Type</b> as <b>SHA-256</b>, and <b>Digest</b> value
provided against the digest type <b>SHA256</b>. Ensure that you have correctly
entered all the values and proceed to create the DS record.
</p>
<p>
<b>WARNING!</b> If you make a mistake in adding the DS record then it will
cause validation errors to resolve your domain name resulting in down time for
your clients who use a DNS resolver with DNSSEC validation enabled. Thus its
recommended that you cross check all the values a couple of times before
proceeding to add the DS record.
</p>
<p>
<b>NOTE!</b> You need to add only one DS record per DNSKEY that has a Secure
Entry Point (SEP) flag. You do not need to add DS record for each Digest Type
hash values that you see in the zone for the DNSKEY record.
</p>
<p>
The DNS server keeps a watch on the DS record automatically every 15 minutes
by querying the parent zone for it. Once it find the published DS record, the
Key State of the DNSKEY will get changed from <b>Ready</b> to
<b>Active</b> indicating that the zone can now be validated using the KSK
DNSKEY record.
</p>
<p><u>Testing Your Domain</u></p>
<p>
You can now check for the DS record that was added using the
<a href="https://dnsclient.net/" target="_blank">DNS Client</a> tool by
querying for your domain name with type set to DS. For example, if your domain
name is <b>example.com </b>use the same to query with the type as <b>DS</b>.
If you get a response with DS record in the answer section then you can
confirm once again the values it shows. Note that it may take a while for the
DS record to be published by your Top Level Domain (TLD) so you should wait
and try again after a while if you get an empty response for the DS query.
</p>
<p>
Once you see the DS record for your domain name in the DNS Client tool, you
can proceed to test DNSSEC validation for your domain name. Check the
<b>Enable DNSSEC Validation</b> option in the DNS Client tool, enter your
domain name, select the record type as A, and click on the
<b>Resolve</b> button. If everything is right then you will see response with
answer section containing the A records with <b>DnssecStatus</b> property set
to <b>Secure</b>.
</p>
<p>
Note! Do not use the DNS Client tab that is built into the DNS web console for
the above test, instead use the
<a href="https://dnsclient.net/" target="_blank">DNS Client</a> website to
test since the built-in tool automatically trusts your local zones and thus
will always validate the DNS records in the response as Secure hiding any
issues that you may have with the DS record.
</p>
<p>
You can also try the
<a href="https://dnsviz.net/" target="_blank">DNSViz</a> tool that will show
you the signed zone's details visually as a diagram and will also show you any
errors that you may have in your overall configuration.
</p>
<p><u>Backup</u></p>
<p>
Once you have your zone signed and tested it to be validating correctly, you
MUST take a backup of your zone files since the private key that was used to
sign your zone is stored in the zone file. In case your server hosting the
zone crashes causing loss of data, you will face operational issues that can
cause downtime for your domain name.
</p>
<p>
Take a backup using the <b>Backup Settings</b> option that you will find at
the bottom right side in the <b>Settings</b> section of the DNS web console.
You must select at least the <b>DNS Zone Files</b> check box to create the
backup zip file that contains all of the zone files.
</p>
<p>
Since the private keys are stored in the zone files, the backup zip file must
be stored securely to prevent the private keys from leaking to unauthorized
people. The backup zip file will help you restore your zones in a cases of
hardware failure.
</p>
<p>
It is recommended to take a periodic backup of your DNS server to make it easy
to restore your server quickly in case of any failures.
</p>
<p>
<b>Key Rollover</b>
</p>
<p>
Similar to how SSL/TLS certificates have an expiry date upon which you need to
renew them, you need to perform a key rollover operation for your KSK and ZSK
in your signed zones too. You have to define a policy that tells the number of
days to keep the keys and make an operating procedure to rollover the keys.
</p>
<p>
The key rollover operation generates a new key pair and retires the existing
key pair. The process is automatic for ZSK as per the configuration you have
in the DNSSEC properties for the zone. The number of days that you have set
for rollover for the ZSK will be used by the DNS server to automatically
trigger the rollover process.
</p>
<p>
For KSK, you have to manually trigger the rollover since you have to manually
add the DS records in the parent zone for the new DNSKEY record. It is
recommended that you do the KSK rollover once every year as a policy.
</p>
<p>
For ZSK type keys, you can start the key rollover process manually too if you
wish from the <b>DNSSEC Properties</b> dialog by clicking on the
<b>Rollover</b> button for the key that you wish to rollover. Once you click
the <b>Rollover</b> button, the DNS server will automatically generate and add
a new key pair with Key State as <b>Published</b>. Once the new Key's State
becomes <b>Active</b>, the old key will be retired and removed automatically.
Since ZSK type keys have automatic rollover feature available, you would never
require to manually trigger the rollover operation.
</p>
<p>For KSK rollover, follow the steps given below:</p>
<ol style="text-align: left;">
<li>
Open the <b>DNSSEC Properties</b> dialog and click on the
<b>Rollover</b> button for the KSK key to start the process manually. This
will cause the DNS server to generate and add a new key pair with Key State
as <b>Published</b>.
</li>
<li>
Note the <b>Key Tag</b> number for the new KSK and close the
<b>DNSSEC Properties</b> dialog. Click on the refresh icon that you see next
to your zone's name to refresh the displayed records. Find the new DNSKEY
record corresponding to the new KSK using the noted Key Tag number displayed
as <b>Computed Key Tag</b> for the DNSKEY record.
</li>
<li>
Check the <b>Key State</b> for the DNSKEY record which will be
<b>Published</b> with a "ready by" timestamp in the brackets, just like you
had it when you first signed the zone. Similar to how you had to wait for
the Key State to become <b>Ready</b> the first time, you have to wait again
for the same. The timestamp will tell you when to come back to expect the
Key State to become Ready.
</li>
<li>
When the <b>Key State</b> for the DNSKEY record becomes <b>Ready</b>, you
can login to your domain registrar's web panel and create a new DS record
for the new DNSSEC record similar to how you added the first DS record.
</li>
<li>
Once you have added the new DS record, find the old DS record and remove it.
Make sure to confirm that you are removing the old DS record by matching its
<b>Key Tag</b> value with the ones that you see in the zone's
<b>DNSSEC Properties</b> dialog.
</li>
</ol>
<p>
Once you have added the new DS record and removed the old DS record, the DNS
server will automatically check for the updated DS record every 15 minutes by
querying the parent zone. Once it finds the new DS record published, it will
set the Key State for the new DNSKEY record from <b>Ready</b> to
<b>Active</b> and the old DNSKEY record will be automatically retired and
eventually removed.
</p>
<p>
You can again test once the new changes using
<a href="https://dnsclient.net/" target="_blank">DNS Client</a> or
<a href="https://dnsviz.net/" target="_blank">DNSViz</a> tools like you did
earlier.
</p>
<p><b>Conclusion</b></p>
<p>
It is highly recommended for every domain owner to sign their domain names
with DNSSEC to make them secure. Self hosting your domain name using
Technitium DNS Server is easy and secure with DNSSEC. Technitium DNS Server's
DNSSEC implementation makes it easy and error free to configure and manage
your signed zones. With an easy to use key rollover process, there is no scope
to have any misconfiguration issues that can cause downtime.
</p>
<p>
If you have any comments or queries, do let me know in the comments section
below or send an email to
<a href="mailto:support@technitium.com">support@technitium.com</a>.
</p>
Shreyas Zarehttp://www.blogger.com/profile/01269575365702781881noreply@blogger.com15Mumbai, Maharashtra, India19.0759837 72.8776559-9.2342501361788472 37.721405899999993 47.386217536178847 108.0339059tag:blogger.com,1999:blog-8065376618611632499.post-64632485291093608192022-06-25T14:14:00.002+05:302022-07-10T16:34:37.985+05:30How To Self Host Your Own Domain Name<p>
A lot of people self host their own blogs or websites but its rare for someone
to host their own domain name. For most people, the domain name hosting
provided by the domain name registrar is sufficient for their use case. People
who need more control and features usually use popular services like AWS,
Cloudflare, etc. In this blog post, we will see how to host and configure your
own name servers for self hosting all your domain names.
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/technitium-dns-server-v8-dashboard.png"
style="margin-left: auto; margin-right: auto;"
><img
border="0"
data-original-height="422"
data-original-width="640"
height="422"
src="https://technitium.com/img/blog/technitium-dns-server-v8-dashboard.png"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Technitium DNS Server Is Both Authoritative And Recursive DNS Server
</td>
</tr>
</tbody>
</table>
<p><b>Should You Really Self Host?</b></p>
<p>
The first question that may come to your mind is that if you should really be
self hosting your own domain names? Self hosting is not a solution for
everyone and you need to evaluate your reasons before coming to a decision on
it.
</p>
<p>You should self host your own domain name if:</p>
<ul>
<li>
You are looking to learn how to self host domain names so doing it will make
sure that you learn all the aspects that come with it. This will help you
learn how DNS works in general in a practical way.
</li>
<li>
You are a hobbyist and interested in self hosting but don't have anything
critical being hosted.
</li>
<li>
You are an advanced user and want full control over your setup. You know
exactly what you are looking for and are capable to handle any operational
issues that may occur.
</li>
</ul>
<p><b>Pros And Cons Of Self Hosting</b></p>
<p>
Self hosting your domain name gives you complete control over its setup and
can use advanced features that may not be available elsewhere. But, like
always this comes with its own pros and cons.
</p>
<p>
Some of the cons to self host your domain names that you may need to consider
are:
</p>
<ul>
<li>
You are solely responsible for your name servers. Which means you need to
regularly monitor the setup to make sure things are working well. Any
failure can cause your website to stop resolving and your email from from
being delivered and received.
</li>
<li>
You need to have redundancy such that when your primary name server hosting
your domain name fails, you have secondary name servers that can keep your
domain name working.
</li>
<li>
Someone can easily take down your name servers with a DDoS attack. This
equally applies to other self hosted services like web servers running your
blog or website. But there are mitigations available that we will discuss.
</li>
<li>
Your name servers can be used for DNS amplification attacks. But for this
too, there are mitigations like query rate limiting available to make such
attacks useless.
</li>
</ul>
<p>
But these pros to self host your domain names may want you to go ahead with
it:
</p>
<ul>
<li>
You get absolute control over your domain name and can configure it to work
anyway you wish.
</li>
<li>
You get access to advanced features not available otherwise. You can also
develop custom plugins that answer for your domain names as per your own
business logic.
</li>
<li>
Unlike hosting web servers, if one of your names servers is down, your
domain name will still resolve. With web servers its a bit complex to manage
this but with DNS, you don't have to worry about it that much. This is
since, you need at least one of your name servers to be online so that your
domain name resolves.
</li>
<li>
You can sign your domain name for DNSSEC which may not be available with
your current DNS provider. But not all Top Level Domain (TLD) names support
DNSSEC so you may want to check that first. While this blog post does not
cover DNSSEC signing,
<a
href="https://blog.technitium.com/2022/07/how-to-secure-your-domain-name-with-.html"
target="_blank"
>this subsequent blog post</a
>
explains how to sign your domain name with DNSSEC.
</li>
<li>
You get access to DNS logs and live stats which may not be available with
your current DNS provider.
</li>
</ul>
<p><b>Minimum Requirements</b></p>
<p>
Now that you have made a decision to proceed, lets see the minimum
requirements for the complete setup. To host you own name server, you need a
server with a static IP address. You can host the server in-house but its
recommended to use a cloud hosting provider like
<a href="https://m.do.co/c/76bf7a823e9f" target="_blank"
>Digital Ocean (referral link)</a
>. This is since, hosting a server in-house requires you to have an
Uninterrupted Power Supply (UPS) setup to make sure the server keeps running
during power outage and also have a stable Internet connection, which may be
one of the most challenging thing to have in your region. Using a cloud
hosting provider, all these challenges are outsourced so that you do not have
to worry about downtime and backups.
</p>
<p>
A server with basic config like single core CPU and 1GB RAM can be sufficient
for most cases. Such a server will will cost as low as $5/mo with
<a href="https://m.do.co/c/76bf7a823e9f" target="_blank"
>Digital Ocean (referral link)</a
>.
</p>
<p>
For redundancy, you should have at least one secondary name server so that if
your primary name server does down for any reason, your domain keeps resolving
via your secondary name servers. Ideally, the secondary name server must be in
a different region so that any issue affecting the primary name server does
not affect the secondary name server too. There are some free and paid
secondary DNS hosting options available too that you can choose from which we
will see later.
</p>
<p>
Another important requirement is that your domain's Top Level Domain (TLD)
must support configuring "child name servers". A child name server is a
feature that allows you to register a subdomain name of your own domain to be
used as your own name server. For example, if your domain name is
"example.com", a child name server domain will be something like
"ns1.example.com" or "ns2.example.com". This allows you to use something like
"ns1.example.com" as the domain name for your primary name server that is
hosting your "example.com" zone.
</p>
<p>
If you have a .com or .net domain name then these TLDs support this feature
but other TLDs may not support it. In such case, you need to buy a domain name
whose TLD supports child name servers and use that domain for all you other
domain names as the name server. To know if your TLD supports child name
servers, just login to your domain registrar's DNS panel and find if there is
a "child name server" or "register name server" option to configure in your
domain's advanced settings.
</p>
<p><b>The Plan</b></p>
<p>
In this blog post, we will setup one primary name server and optionally
another one to act as the secondary name server for redundancy. You can add
any number of secondary name servers as you wish depending on your
requirements or plan to get a secondary DNS hosting provider.
</p>
<p>
To move further with installation and the configuration, its important and
helpful that you understand how DNS servers do recursive resolution. There are
different types of DNS servers that perform different functions but, a single
DNS server software can support to perform all of these functions.
</p>
<p>The common types of DNS servers are:</p>
<ol>
<li>
<b>Authoritative Name Servers</b>
<p>
These are the DNS servers that host a domain name. The domain name is
hosted as a zone which means that any request for the domain name and its
subdomain names can be answered by this server. Which is why its called as
the authoritative name server for that domain. To self host your domain
name, we are going to setup authoritative name servers.
</p>
<p>
An authoritative name server will respond with an answer to request only
for the domain names it has a zone hosted for. A zone is a collection of
DNS records that the authoritative name server must answer to. Any request
with domain name not hosted will be responded with a REFUSED response code
to indicate that the authoritative name server does not know an answer for
the question.
</p>
<p>
There can be one or more authoritative name server for a domain name. One
of them is the primary name server while the rest of the other are
secondary name servers. You can update DNS records only on the primary
name servers and any changes you make are automatically synced to the
secondary name servers.
</p>
</li>
<li>
<b>Recursive Name Servers</b>
<p>
These are the DNS servers that are commonly hosted by ISPs or public DNS
providers like Google DNS, Cloudflare DNS, or Quad9. Internet client
devices send a request to these servers when they want to resolve a
specific domain name. Its the task of these servers to perform recursive
resolution which is a process to discover the list of authoritative name
servers for the domain name and then query them to find the answers
requested by the client.
</p>
<p>
A recursive name server has a preconfigured list of 13 root servers. These
root servers are spread across the world and contain list of all Top Level
Domains (TLDs) with their authoritative name server domain names and their
IP addresses (known as glue addresses). The recursive resolution process
first queries one of the root servers for the domain name to be resolved
for which it receives a list of authoritative name servers for the
domain's TLD. The recursive resolver then proceeds by sending a 2nd
request to these new list of authoritative name servers for which it now
receives another list of authoritative name servers for the domain name in
the request. The recursive resolver again proceeds by sending a 3rd
request to these authoritative name servers for the domain name to receive
the final answer to the original question. This answer is cached to avoid
repeating the recursive resolution process over and over again.
</p>
</li>
<li>
<b>Stub Resolvers</b>
<p>
These are the DNS servers that are commonly running on your WiFi routers
and also on your device's operating system. These DNS servers forward any
request they receive to Recursive Name Servers and cache the responses in
memory to avoid frequent queries over network and to improve performance.
</p>
<p>
So, when you enter a website's address in your web browser, the domain
resolution request is first received by the stub resolver running on your
device which then forwards the request to the DNS server IP addresses that
are configured on your network adapter which usually will be the IP
address of your Internet WiFi router. This router's stub resolver then
forwards the request to the DNS server IP address configured in its WAN
settings by your ISP which are the Recursive name servers.
</p>
</li>
</ol>
<p>
Now that you have a fair understanding of the plan and some basic concepts
that we can proceed with the installation.
</p>
<p><b>Installation</b></p>
<p>
We will install Technitium DNS Server on your server and call it as the
primary name server. You can optionally choose to create one or more secondary
name servers by following the exact same installation steps.
</p>
<p>
We will be using Ubuntu server here but you can choose any distro of your
choice and follow similar instructions. You can choose to use a different OS
for your server but its recommended to use a Linux based OS to keep the
hosting costs to a minimum.
</p>
<p>
Connect to your server using SSH and run the single line installation command
given below to install the DNS server. You can also install it as a docker
image or manually install the DNS server by following the detailed
<a
href="https://blog.technitium.com/2017/11/running-dns-server-on-ubuntu-linux.html"
target="_blank"
>install instructions</a
>.
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
$ curl -sSL https://download.technitium.com/dns/install.sh | sudo bash
</pre>
<p>
Once the installation is complete, you can access the DNS server's web console
at http://<server-ip-address>:5380/ and quickly setup a strong admin
password.
</p>
<p><b>Configuration</b></p>
<p>
Before proceeding with the configuration, you must decide the domain names to
be used for your primary and secondary name servers (if any). For example, if
your domain name is "example.com" then you should select something like
"ns1.example.com" as the domain name for your primary name server,
"ns2.example.com" as the domain name for your secondary name server, and so
fourth if you wish to have more than one secondary name servers.
</p>
<p>
If your domain's TLD does not support registering child name servers, then you
need to first host a domain name which supports it. If you don't own such a
domain name then you need to buy one before proceeding.
</p>
<p>
Make a list of the selected domain names for your name servers with their
corresponding IP addresses as shown in the example below to help with the
configuration:
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
ns1.example.com <primary name server's ip address>
ns2.example.com <secondary name server's ip address>
</pre>
<p>
If your server hosting provider supports IPv6 then enable IPv6 for your server
and enter the IPv6 address too in the above said list.
</p>
<p>
<u>Configuring Primary Name Server:</u>
</p>
<p>
We will now proceed to configure the primary name server. Login to the primary
name server's DNS web console and follow the steps below:
</p>
<ol>
<li>
Go to the Settings > General section, set the selected primary name
server's domain name as the "DNS Server Domain", and click on Save Settings
button at the bottom.
</li>
<li>
Go to the Zones section, and click on the Add Zone button. Enter your domain
name that you want to self host in the Add Zone window, keep the Type as
Primary Zone and click on Add button to create a primary zone for your
domain name.
</li>
<li>
Once you have created the primary zone, you will see only one NS record and
an SOA record. Edit the SOA record and enter a valid email address as the
"Responsible Person" on which you can receive emails and save the record.
</li>
<li>
Add NS records for all of the secondary name servers that you have planned.
You do not need to enter any glue address for adding the NS records.
</li>
<li>
Add A records for all the name servers based on the list of name servers you
prepared before starting the configuration. Each NS record's domain name
must have a corresponding A record in the zone. If your name servers have
IPv6 address, add AAAA records too for them corresponding to each NS record.
</li>
<li>
Add all the other records for the primary zone manually by referring at your
existing DNS provider's panel. Once you have added all the records, the
primary zone is ready for the next step.
</li>
</ol>
<p>
<u>Switching Domain's Name Servers:</u>
</p>
<p>
Now that the primary zone is ready with all the records, we can proceed to
make it live so that other recursive name servers on the Internet can find it
to resolve the domain name. To do that, login to your domain registrar's DNS
panel and follow the steps below:
</p>
<ol>
<li>
Find your domain name in the registrar's DNS panel and click on it to see
the details section.
</li>
<li>
Find option in the domain details section that says something like
"Nameserver Registration" or "Child Nameservers". Once you find the correct
option, enter the child name server domain names from the list of name
servers (e.g. ns1.example.com) and their corresponding static IP addresses.
Once you save the changes, the registrar will update your TLD's name servers
with the details of the child name servers and their IP addresses (glue
addresses).
</li>
<li>
Find option in the domain details section that says something like "Manage
Nameservers". Once you find the correct option, enter the domain names of
all your name servers that were registered in the previous step. Remove any
previously existing name server entries that you see in there and keep just
the ones you have entered. Once you save these changes, you will start
seeing traffic coming on your primary name server as soon as the the name
server (NS) records changes are updated to your TLD name servers. This can
be as quick as a few seconds or may take a while for some TLDs depending on
how they have implemented the update process.
</li>
</ol>
<p><u>Testing Primary Name Server:</u></p>
<p>
You can test your setup to confirm if your primary name server is indeed
answering requests for your domain using the DNS Client website. Just go to
<a href="https://dnsclient.net/" target="_blank">dnsclient.net</a>, keep the
Server option to Recursive Query, enter your domain name, and click on Resolve
button. In the response that you get, you should see the "Metadata.NameServer"
set with the domain name of your primary name server. If its still showing you
one of the the domain names of your old name servers then it means that the
changes have still not updated and you should wait for some more time to test
it again.
</p>
<p><u>Configuring Secondary Name Servers:</u></p>
<p>
Once you have made sure that the primary name server is resolving the domain
name, you can then configure one or more optional secondary name servers. Its
recommended to have at least one secondary name server but if you do not wish
to have one, you can skip this part. Login to the secondary name server's DNS
web console and follow the steps below:
</p>
<ol>
<li>
Go to the Settings > General section, set the secondary domain name as
the "DNS Server Domain", and click on Save Settings button at the bottom.
</li>
<li>
Go to the Zones section, and click on the Add Zone button. Enter your domain
name in the Add Zone window, select the type as Secondary Zone, and click on
Add button to create the secondary zone. To add secondary zone, primary name
server addresses were not needed since the domain name is publicly
resolvable and so the DNS server will find out the primary name server
automatically.
</li>
<li>
Once the zone is created, the DNS server will try to perform zone transfer
to sync all the DNS records from the primary zone into the secondary zone.
The zone status will show as Expired till the records are synced. You can
click on the refresh icon next to the domain name in the zone to check if
the records have been synced. If the records didn't sync and the zone status
is still Expired after a minute, you should check the DNS server's logs from
the web console to see if there are any errors.
</li>
</ol>
<p>
When you see the records populate in the secondary zone, the configuration for
it is completed. Repeat the same steps for any other secondary name servers
that you may have planned. Since, we had added registered all the name server
domain names in the domain registrar's panel, the secondary name server will
too start seeing traffic for your domain name soon.
</p>
<p><b>Self Hosting Another Domain Name</b></p>
<p>
Now that you have one of your domain names self hosted, you can add one or
more of your other domain names to self host. Follow the steps below for self
hosting your other domain names:
</p>
<ol>
<li>Login to your primary name server's DNS web console.</li>
<li>
Go to Zones section and add a new primary zone for your second domain name.
</li>
<li>
Once the primary zone is created, you will see one NS and an SOA record.
Edit the SOA record with a valid email address that you can receive emails
on.
</li>
<li>
Add NS records for your secondary name servers that you wish to be used for
this second domain name. You do not need to provide any glue addresses for
these NS records.
</li>
<li>
Add all other records in the primary zone to complete the primary zone
configuration.
</li>
<li>Login to your secondary name server's DNS web console.</li>
<li>
Go to the Zones section and add a new secondary zone for your second domain
name.
</li>
<li>
The secondary name server will perform automatic zone transfer to sync all
the records from your primary name server.
</li>
<li>Login to your domain registrar's web panel.</li>
<li>
Find the second domain name and click on it to see the details section.
</li>
<li>
Find option in the domain details section that says something like "Manage
Nameservers". In this option, remove the existing name servers and add the
domain names of your primary and secondary name servers. Once you save these
changes, you will soon start seeing traffic coming on your primary and
secondary name servers for your second domain name.
</li>
</ol>
<p><b>Additional Configuration</b></p>
<p>
Apart from the configuration to host the zones, there are a few things that
must be configured too:
</p>
<ul>
<li>
<b>Enable HTTPS for DNS Web Console</b><br />
You should enable HTTPS for the DNS web console for security reasons. The
bare minimum option is to enable HTTPS with self signed TLS certificate
option in Settings > Web Service section. A better option is to configure
certbot to renew Let's Encrypt certificate and configure it in the Settings
> Web Service section.
</li>
<li>
<b>Query Rate Limiting</b><br />
To mitigate from attacks that use your DNS server for DNS amplification
attacks, you should configure the Queried Per Minute (QPM) options in
Settings > General section to rate limit queries per client subnet.
</li>
<li>
<b>Drop Requests App</b><br />
Install the Drop Requests DNS App from the Apps section's App Store option.
This app will allow you to drop requests that match from the given list of
names and/or types. Take a look at the app's json config to see how certain
names or types can be blocked.
</li>
<li>
<b>Backup</b><br />
Once all the config is complete you should take backup for the entire DNS
server from Backup Settings option in the bottom right of the Settings
section. It is recommended to take regular backups this way so that you can
quickly restore from the latest backup when your DNS server requires
rebuilding due to any issues. Enabling backup option with your cloud hosting
provider is also highly recommended.
</li>
</ul>
<p><b>Configuring 3rd Party Secondary DNS Provider</b></p>
<p>
There are 3rd party DNS hosting providers that allow you to host secondary
zones with them. Most of them are paid services but if you are hosting your
personal project domain names then you can use the free secondary DNS service
provided by <a href="https://ns-global.zone/" target="_blank">NS-Global</a>.
Follow the sign-up instructions on their website to add a secondary name
server for your domain names. Note, that you will need to use the Zone Options
to configure zone transfer and notify for setting up the secondary zone with
NS Global.
</p>
<p>
Once you have the secondary zone created with NS Global, you can update the
name servers for your domain from the domain registrar's panel to allow
discovering the new secondary name server.
</p>
<p><b>Conclusion</b></p>
<p>
With some efforts to learn DNS concepts, its possible for anyone determined to
self host their own domain names. Technitium DNS Server allows easy
installation, configuration, and maintenance of DNS zones with minimal
efforts. With 3rd party secondary DNS service, you can add more redundancy and
reliability to your setup.
</p>
<p>
If you have any comments or queries, do let me know in the comments section
below or send an email to
<a href="mailto:support@technitium.com">support@technitium.com</a>.
</p>
Shreyas Zarehttp://www.blogger.com/profile/01269575365702781881noreply@blogger.com17Mumbai, Maharashtra, India19.0759837 72.8776559-9.2342501361788472 37.721405899999993 47.386217536178847 108.0339059tag:blogger.com,1999:blog-8065376618611632499.post-77331851644708842342022-03-26T17:54:00.002+05:302022-07-23T09:32:50.223+05:30Technitium DNS Server v8 Released!<p>
I am happy to announce the release of
<a href="https://technitium.com/dns/" target="_blank">Technitium DNS Server v8</a>, a cross-platform, free, open source software that can be used by anyone, be
it a novice or an expert user. It features an easy to use web based GUI and
works with default config that allows the server to run out-of-the-box.
</p>
<p>
This is a major release that adds many core DNS features like support
for DNSSEC validation and signed zones.
</p>
<p>
<a href="https://technitium.com/dns/" target="_blank">Download</a> the latest
update for Windows, Linux, macOS, or Raspberry Pi!
</p>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;">
<tbody>
<tr>
<td style="text-align: center;">
<a href="https://technitium.com/img/blog/technitium-dns-server-v8-dashboard.png" style="margin-left: auto; margin-right: auto;"><img alt="Technitium DNS Server" border="0" data-original-height="560" data-original-width="850" height="422" src="https://technitium.com/img/blog/technitium-dns-server-v8-dashboard.png" style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;" width="640" /></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Technitium DNS Server v8
</td>
</tr>
</tbody>
</table>
<p>Some of the notable features that were added to this latest update are:</p>
<ul style="text-align: left;">
<li>
DNSSEC validation support for both recursive resolution, forwarders, and
conditional forwarders.
</li>
<li>
DNSSEC validation support for all DNS transport protocols (Do53, DoT, DoH,
& DoH JSON).
</li>
<li>Support to allow hosting primary and secondary DNSSEC signed zones.</li>
<li>Support for all RSA and ECDSA DNSSEC algorithms.</li>
<li>
EDNS(0) [<a href="https://datatracker.ietf.org/doc/html/rfc6891" target="_blank">RFC 6891</a>] support.
</li>
<li>
Extended DNS Errors [<a href="https://datatracker.ietf.org/doc/html/rfc8914" target="_blank">RFC 8914</a>] support.
</li>
<li>Codebase upgrade to .NET 6 runtime.</li>
</ul>
<p>
Read the
<a href="https://github.com/TechnitiumSoftware/DnsServer/blob/master/CHANGELOG.md" target="_blank">change log</a>
to know more details about this latest update.
</p>
<p>
Any comment or feedback is really appreciated and helps a lot in adding new
features and fixing bugs. Send your feedback or support requests to
<a href="mailto:support@technitium.com">support@technitium.com</a>. You can
also post on
<a href="https://www.reddit.com/r/technitium/" target="_blank">/r/technitium</a>
on Reddit for community support. For any feature request or reporting bugs,
create an issue on
<a href="https://github.com/TechnitiumSoftware/DnsServer/issues" target="_blank">GitHub</a>.
</p>
<p>
The DNS Server source code is available under
<a href="https://go.technitium.com/?id=24" target="_blank">GNU General Public Licence (GPL) v3</a>
on
<a href="https://github.com/TechnitiumSoftware/DnsServer" target="_blank">GitHub</a>.
</p>
<p>
You can make a contribution to the project by becoming a Patron and help in
developing new software, updates and adding more features possible.
<a href="https://go.technitium.com/?id=35" target="_blank">Become a Patron now!</a>
</p>
Anonymousnoreply@blogger.com2Mumbai, Maharashtra, India19.0759837 72.8776559-9.2342501361788472 37.721405899999993 47.386217536178847 108.0339059tag:blogger.com,1999:blog-8065376618611632499.post-82533276154991196422021-07-25T20:03:00.010+05:302023-10-31T14:44:54.416+05:30[Updated] Running A Root Server Locally On Your DNS Resolver<p>
<b>Update (June 11, 2022):</b> The previous blog post instructed how to run a
secondary root zone locally without DNSSEC considerations since the Technitium
DNS Server version before v8.0 did not support DNSSEC. Now that DNSSEC is
supported, it is highly recommended to update your local root zone deployments
as per the the new instructions in this blog post. The new configuration
changes comply with all the requirements in RFC 8806.
</p>
<p><b>Introduction</b></p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
To prevent these issues and to improve resiliency there is a good option to
run a Root Server locally on your DNS resolver.
</p>
<p>There are several advantages of running a Root Server locally:</p>
<ul style="text-align: left;">
<li>
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.
</li>
<li>
Since the Root zone is running locally, queries for non existent top level
domain (TLD) names are resolved locally.
</li>
<li>
This also improves resiliency since the Root zone is local and thus there is
no immediate dependency on the Root Servers for recursive resolution.
</li>
</ul>
<p>There are a few disadvantages too:</p>
<ul style="text-align: left;">
<li>
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.
</li>
<li>
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.
</li>
</ul>
<p>
Considering both the advantages and disadvantages, its good to have a Root
zone locally for a recursive resolver.
</p>
<p><b>Sourcing The Root Zone</b></p>
<p>
The root zone is available from ICANN DNS servers via zone transfer
(AXFR-over-TCP):
</p>
<ul style="text-align: left;">
<li>xfr.cjr.dns.icann.org (192.0.47.132, 2620:0:2830:202::132)<br /></li>
<li>xfr.lax.dns.icann.org (192.0.32.132, 2620:0:2d0:202::132) <br /></li>
</ul>
<p>The following Root Servers also support zone transfer (AXFR-over-TCP):</p>
<ul style="text-align: left;">
<li>b.root-servers.net (199.9.14.201, 2001:500:200::b)<br /></li>
<li>c.root-servers.net (192.33.4.12, 2001:500:2::c)<br /></li>
<li>d.root-servers.net (199.7.91.13, 2001:500:2d::d)<br /></li>
<li>f.root-servers.net (192.5.5.241, 2001:500:2f::f)<br /></li>
<li>g.root-servers.net (192.112.36.4, 2001:500:12::d0d)</li>
<li>k.root-servers.net (193.0.14.129, 2001:7fd::1)</li>
</ul>
<p>
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.
</p>
<p><b>Configuration</b></p>
<p>
It is assumed here that you already have Technitium DNS Server installed and
running on your server. To run the root zone locally, we need to run another
instance of Technitium DNS Server on the same server. This second, local
instance of the DNS server will answer requests only on loopback interface and
thus wont be accessible from the network. The second DNS server instance will
host the root secondary zone. Your currently running DNS server instance will
query this second DNS server instance when root zone records are required.
</p>
<p>
While this blog post focuses on running the root server instance locally on
the same server that is currently running your DNS server instance, it is
possible to run it on a different server such that two or more DNS servers can
be configured to use that single root server instance. The only thing that
must be taken care of is to make sure that the root server instance is not
used as a DNS server for normal domain lookups.
</p>
<p>
<b>Note:</b> Before proceeding, make sure to take a backup of the DNS server
instance that you already have running in case you want to start over. You can
create a backup zip file by clicking Backup Settings at the bottom right of
the Settings section.
</p>
<p><b>Creating A Second Local DNS Server Instance</b></p>
<p>
Since, we need two DNS server instances running, the admin web console which
runs by default on TCP 5380 port will cause a conflict. To prevent this, the
second instance needs to be configure to run on a different port so we choose
TCP 5381 for it. Follow the steps below to get the second instance running.
</p>
<p>On Linux Installation:</p>
<ol>
<li>
Create a systemd service for running the second DNS server instance by
following the steps below: <br />
Copy the <b>systemd.service</b> template as a new
<b>dns2.service</b> systemd service:
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
$ sudo cp /opt/technitium/dns/systemd.service /etc/systemd/system/dns2.service
</pre
>
Edit the <b>dns2.service</b> file in nano:
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
$ sudo nano /etc/systemd/system/dns2.service
</pre
>
Explicitly specify a different config folder to use
<b>/etc/dns2</b> as shown below:
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
[Unit]
Description=Technitium DNS Server
[Service]
WorkingDirectory=/opt/technitium/dns
ExecStart=/usr/bin/dotnet /opt/technitium/dns/DnsServerApp.dll /etc/dns2
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dns-server-2
[Install]
WantedBy=multi-user.target
</pre
>
Exit nano saving the <b>dns2.service</b> file.
</li>
<li>
Login to the first DNS server instance by opening the url
<b>http://<server-ip-address>:5380/</b>, go to Settings > Web
Service section and change the <b>Web Service HTTP Port</b> to
<b>5379</b> so that the default port is available temporarily for the second
instance. Click on Save Settings button and the web console will
automatically redirect you to the new DNS web console URL. Keep this tab
open for later use.
</li>
<li>
Start the second DNS server instance:
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
$ sudo systemctl enable dns2.service
$ sudo systemctl start dns2.service
</pre
>
</li>
<li>
Open the url <b>http://<server-ip-address>:5380/</b> to access the web
console of the second instance. Go to Settings > General section and set
<b>127.0.0.2</b> as the <b>DNS Server Local End Points</b> replacing any
existing values. Go to Settings > Web Service section and edit the
<b>Web Service HTTP Port</b> to <b>5381</b> and click on Save Settings. The
web console will automatically redirect you to the new URL.
</li>
<li>
Switch to the first DNS server's web console tab that was kept open. Go to
Settings > General section and set <b>127.0.0.1</b> and
<b><server-ip-address></b> (use your actual server's IP address) as
the <b>DNS Server Local End Points</b> replacing any existing values. Go to
Settings > Web Service section and change the
<b>Web Service HTTP Port</b> back to <b>5380</b> now that the second DNS
server instance is running on port 5381. Click on Save Settings button and
the web console will automatically redirect you to the new DNS web console
URL.
</li>
</ol>
<p>On Windows Installation:</p>
<ol>
<li>
Click on Start, type <b>cmd</b>, right click on the command prompt item and
click <b>Run as administrator</b> to open CMD as an administrator.
</li>
<li>
Run the following command in CMD to create a Windows service for running the
second DNS server instance and explicitly provide the path to a different
config folder
<b>C:\Program Files (x86)\Technitium\DNS Server\config2\</b> for use:
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
C:\Windows\system32> sc create DnsService2 binPath= "C:\Program Files (x86)\Technitium\DNS Server\DnsService.exe \"C:\Program Files (x86)\Technitium\DNS Server\config2\"" DisplayName= "Technitium DNS Server 2" start= auto
</pre
>
</li>
<li>
Login to the first DNS server instance by opening the url
<b>http://<server-ip-address>:5380/</b>, go to Settings > Web
Service section and change the <b>Web Service HTTP Port</b> to
<b>5379</b> so that the default port is available temporarily for the second
instance. Click on Save Settings button and the web console will
automatically redirect you to the new DNS web console URL. Keep this tab
open for later use.
</li>
<li>
Start the second DNS server instance:
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
C:\Windows\system32> sc start DnsService2
</pre
>
</li>
<li>
Open the url <b>http://localhost:5380/</b> to access the web console of the
second instance. Go to Settings > General section and set
<b>127.0.0.2</b> as the <b>DNS Server Local End Points</b> replacing any
existing values. Go to Settings > Web Service section and edit the
<b>Web Service HTTP Port</b> to <b>5381</b> and click on Save Settings. The
web console will automatically redirect you to the new URL.
</li>
<li>
Switch to the first DNS server's web console tab that was kept open. Go to
Settings > General section and set <b>127.0.0.1</b> and
<b><server-ip-address></b> (use your actual server's IP address) as
the <b>DNS Server Local End Points</b> replacing any existing values. Go to
Settings > Web Service section and change the
<b>Web Service HTTP Port</b> back to <b>5380</b> now that the second DNS
server instance is running on port 5381. Click on Save Settings button and
the web console will automatically redirect you to the new DNS web console
URL.
</li>
</ol>
<p><b>Note:</b> On Windows Server 2022, ensure that you do not enable the HTTP/3 protocol option from Settings > Web Service section. This is since the DNS server keeps thousands of UDP sockets open and it may happen that the port used for HTTP/3 may clash with an open UDP socket from the root zone instance causing the main DNS instance to fail to bind the web service on the same port when HTTP/3 is enabled.</p>
<p>On Docker:</p>
<ol>
<li>
Create a <b>docker-compose.yml</b> file in a folder with contents as show
below to create the first DNS server instance:
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
version: "3"
services:
dns-server:
container_name: dns-server
hostname: dns-server
image: technitium/dns-server:latest
ports:
- "5380:5380/tcp" #DNS web console
- "127.0.0.1:53:53/udp" #DNS service
- "127.0.0.1:53:53/tcp" #DNS service
- "<server-ip-address>:53:53/udp" #DNS service
- "<server-ip-address>:53:53/tcp" #DNS service
environment:
- DNS_SERVER_DOMAIN=dns-server #The primary domain name used by this DNS Server to identify itself.
volumes:
- config:/etc/dns
restart: unless-stopped
volumes:
config:
</pre
>
Note: You can edit your existing <b>docker-compose.yml</b> file that you
used to run your existing container with above port changes and rebuild it.
</li>
<li>
Click on Start, type <b>cmd</b>, right click on the command prompt item and
click <b>Run as administrator</b> to open CMD as an administrator. Navigate
to the folder where the <b>docker-compose.yml</b> exists using the
<b>CD <folder-path></b> command. Run the following command to create
the docker container:
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
docker-compose up -d
</pre
>
</li>
<li>
Create a <b>docker-compose.yml</b> file in another folder with contents as
show below to create the second DNS server instance:
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
version: "3"
services:
dns-server:
container_name: dns-server-2
hostname: dns-server-2
image: technitium/dns-server:latest
ports:
- "5381:5380/tcp" #DNS web console
- "127.0.0.2:53:53/udp" #DNS service
- "127.0.0.2:53:53/tcp" #DNS service
environment:
- DNS_SERVER_DOMAIN=dns-server-2 #The primary domain name used by this DNS Server to identify itself.
volumes:
- config2:/etc/dns
restart: unless-stopped
volumes:
config2:
</pre
>
</li>
<li>
Click on Start, type <b>cmd</b>, right click on the command prompt item and
click <b>Run as administrator</b> to open CMD as an administrator. Navigate
to the folder where the <b>docker-compose.yml</b> exists using the
<b>CD <folder-path></b> command. Run the following command to create
the docker container:
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
docker-compose up -d
</pre
>
</li>
</ol>
<p>
<b>Configuring The Root Zone</b>
</p>
<p>
To configure the root zone, open the second instance web console at
<b>http://<server-ip-address>:5381/</b> and go to the Zones section.
Click on the Add Zone button to create a secondary zone for <b>.</b> as the
zone name. Enter the primary name server addresses as shown in the screenshot
below:
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/configuring-local-secondary-root-zone.png"
imageanchor="1"
style="margin-left: auto; margin-right: auto;"
><img
border="0"
data-original-height="628"
data-original-width="772"
height="520"
src="https://technitium.com/img/blog/configuring-local-secondary-root-zone.png"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Configuring Local Secondary Root Zone<br />
</td>
</tr>
</tbody>
</table>
<p>
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.
</p>
<p>
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 in the DNS zone:
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/local-secondary-root-zone.png"
style="margin-left: auto; margin-right: auto;"
><img
border="0"
data-original-height="708"
data-original-width="1121"
height="404"
src="https://technitium.com/img/blog/local-secondary-root-zone.png"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Local Secondary Root Zone<br />
</td>
</tr>
</tbody>
</table>
<p>
Now, open the first instance web console at
<b>http://<server-ip-address>:5380/</b> and go to the Zones section.
Click on the Add Zone button to create a Conditional Forwarder Zone for
<b>.</b> as the zone name and with the <b>Use "This Server"</b> option
enabled. Once the zone is created, click Add Record to add a record of NS
type, with <b>localhost</b> as the Name Server, and <b>127.0.0.2</b> as the
Glue Address. You can now delete the FWD record that you see. Once done, you
should have the conditional forwarder zone config as shown below:
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/local-static-stub-root-zone.png"
style="margin-left: auto; margin-right: auto;"
><img
border="0"
data-original-height="347"
data-original-width="1119"
height="198"
src="https://technitium.com/img/blog/local-static-stub-root-zone.png"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Local Static Stub Root Zone<br />
</td>
</tr>
</tbody>
</table>
<p>
This NS record will now make the conditional forwarder zone act as a static
stub zone such that it will now query the specified name server when
performing recursive resolution.
</p>
<p>
In case you had decided to run the root server instance on another server,
just use its domain name as the name server and it's IP address as the glue
address for the NS record to complete the configuration.
</p>
<p><b>References</b></p>
<ul style="text-align: left;">
<li>
<a href="https://www.rfc-editor.org/rfc/rfc8806.html" target="_blank"
>RFC 8806 - Running a Root Server Local to a Resolver</a
>
</li>
</ul>
<p>
If you have any queries do write in the comments section below or send an
email to
<a href="mailto:support@technitium.com">support@technitium.com</a>.
</p>
Anonymousnoreply@blogger.com39Mumbai, Maharashtra, India19.0759837 72.8776559-9.2342501361788472 37.721405899999993 47.386217536178847 108.0339059tag:blogger.com,1999:blog-8065376618611632499.post-73950786385596974522021-03-14T17:08:00.004+05:302022-06-08T13:10:58.182+05:30Creating And Running DNS Apps On Technitium DNS Server<p>
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.
</p>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/technitium-dns-server-v6-dashboard.png" style="margin-left: auto; margin-right: auto;"><img alt="Technitium DNS Server v6" border="0" data-original-height="562" data-original-width="850" height="424" src="https://technitium.com/img/blog/technitium-dns-server-v6-dashboard.png" style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;" title="Technitium DNS Server v6" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Technitium DNS Server v6</td></tr></tbody></table>
<p>
<b>DNS Apps</b>
</p>
<p>
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 <a href="https://github.com/TechnitiumSoftware/DnsServer/tree/master/Apps" target="_blank">GitHub</a> which can be forked and modified as required.
</p>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/technitium-dns-server-with-default-app-installed.png" style="margin-left: auto; margin-right: auto;"><img alt="Technitium DNS Server With The Default DNS App Installed" border="0" data-original-height="568" data-original-width="1125" height="324" src="https://technitium.com/img/blog/technitium-dns-server-with-default-app-installed.png" style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;" title="Technitium DNS Server With The Default DNS App Installed" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Technitium DNS Server With The Default DNS App Installed</td></tr></tbody></table>
<p>
<b>APP Record</b>
</p>
<p>
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.
</p>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/the-app-record-configuration.png" style="margin-left: auto; margin-right: auto;"><img alt="Technitium DNS Server APP Record Configuration" border="0" data-original-height="632" data-original-width="596" height="400" src="https://technitium.com/img/blog/the-app-record-configuration.png" style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;" title="Technitium DNS Server APP Record Configuration" width="378" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">The APP Record Configuration</td></tr></tbody></table>
<p>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.</p>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/a-sample-dns-zone-with-app-records.png" style="margin-left: auto; margin-right: auto;"><img alt="A Sample DNS Zone With APP Records" border="0" data-original-height="802" data-original-width="1125" height="456" src="https://technitium.com/img/blog/a-sample-dns-zone-with-app-records.png" style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;" title="A Sample DNS Zone With APP Records" width="640" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">A Sample DNS Zone With APP Records</td></tr></tbody></table>
<p>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. </p><p>To try it, you can query for <b>mydns.home.zare.im</b> 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 <b>ns1.technitium.net</b>, you will get a response back with your own public IP address. You can see the source code of this DNS App <a href="https://github.com/TechnitiumSoftware/DnsServer/blob/master/Apps/WhatIsMyDnsApp/App.cs" target="_blank">here</a>.
</p>
<p>
<b>Creating DNS Apps</b>
</p>
<p>
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, <b>DnsApplicationCommon.dll</b> and <b>TechnitiumLibrary.Net.dll</b>. 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.
</p>
<p>
Once you have the class library project ready with the two DLL references added, you can now create a class which implements <b>IDnsApplicationRequestHandler</b> interface. In here, there are two important functions to implement.
</p>
<p>
The first is <b>InitializeAsync()</b> 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.
</p>
<p>
The second and the most important function is <b>ProcessRequestAsync()</b> 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.
</p>
<p>
The implementation uses Task based Async programming to allow you to scale the DNS application easily.
</p>
<p>
The <b>IDnsApplicationRequestHandler</b> interface also requires implementing two properties. The <b>Description</b> property allows you to provide a description for the app which gets displayed on the web console. And the <b>ApplicationRecordDataTemplate</b> 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.
</p>
<p>
You can always refer to the code from the Default DNS App on <a href="https://github.com/TechnitiumSoftware/DnsServer/blob/master/Apps/SplitHorizonApp/SimpleAddress.cs" target="_blank">GitHub</a> to get your app working.
</p>
<p>
<b>Deploying DNS Apps</b>
</p>
<p>
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.
</p>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/install-dns-app.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="Technitium DNS Server Install DNS App" border="0" data-original-height="246" data-original-width="594" height="166" src="https://technitium.com/img/blog/install-dns-app.png" style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;" title="Technitium DNS Server Install DNS App" width="400" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Installing DNS App</td></tr></tbody></table>
<p>
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.
</p>
<p>
<b>Conclusion</b>
</p>
<p>
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.
</p>
<p>
If you have any queries or comments, do write them below. You can also email your queries to <a href="mailto:support@technitium.com">support@technitium.com</a> or discuss them on <a href="https://www.reddit.com/r/technitium/" target="_blank">/r/technitium</a> on Reddit.
</p>Anonymousnoreply@blogger.com5Mumbai, Maharashtra, India19.0759837 72.8776559-9.2342501361788472 37.721405899999993 47.386217536178847 108.0339059tag:blogger.com,1999:blog-8065376618611632499.post-16236996375862297902020-10-10T19:21:00.012+05:302023-02-28T11:27:47.221+05:30How To Host Your Own DNS-over-HTTPS, DNS-over-TLS, And DNS-over-QUIC Services<i>Updated: 26 Feb 2023</i>
<p>
With
<a href="https://technitium.com/dns/" target="_blank">Technitium DNS Server</a
>, you can not just consume DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), or
DNS-over-QUIC (DoQ) services using forwarders but you can also host these
services yourself. There can be several reasons to host your own DoH, DoT, or
DoQ service. You may wish to have better privacy by not sharing your data with
public DNS providers. Or your network or ISP blocks popular DoQ, DoT, and DoH
services and also interferes with unencrypted DNS traffic.
</p>
<p>
In this post, we will setup DoQ, 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.
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/home-network-doh-setup.png"
style="margin-left: auto; margin-right: auto;"
><img
border="0"
data-original-height="276"
data-original-width="564"
src="https://technitium.com/img/blog/home-network-doh-setup.png"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">Home Network</td>
</tr>
</tbody>
</table>
<p>
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.
</p>
<p>
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.
</p>
<p><span style="font-size: large;">Requirements</span></p>
<p>
You need a domain name which you can get from any domain name registrar like
<a href="https://www.name.com/referral/22346b" target="_blank"
>Name.com (referral link)</a
>. 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
<a href="https://www.name.com/pricing" target="_blank">pricing here</a>.<br />
</p>
<p>
You need a Linux server which you can get from any cloud hosting provider like
<a href="https://m.do.co/c/76bf7a823e9f" target="_blank"
>Digital Ocean (referral link)</a
>. 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.
</p>
<p><span style="font-size: large;">Installation </span><br /></p>
<p>
We will be using Ubuntu server in this blog post but you can choose any distro
of your choice and follow similar instructions.
</p>
<p>
You can install Technitium DNS Server using the single line installation
command as shown:
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
curl -sSL https://download.technitium.com/dns/install.sh | sudo bash
</pre>
<p>
If the above command fails since you do not have curl installed, install it as
shown below and try the above command again:
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
sudo apt update
sudo apt install curl
</pre>
<p>
You can also manually install the DNS server by following the
<a
href="https://blog.technitium.com/2017/11/running-dns-server-on-ubuntu-linux.html"
target="_blank"
>install instructions</a
>.
</p>
<p>
We will be using
<a href="https://letsencrypt.org/" target="_blank">Let's Encrypt</a> TLS
certificate and will be using certbot which does automatic certificate renewal
for Let's Encrypt. Run the commands below to install certbot:
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
sudo apt update
sudo apt install certbot
</pre>
<p><span style="font-size: large;">Configuration</span></p>
<p>
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 <code>http://1.2.3.4:5380/</code> in your web
browser. Chrome, Firefox and Edge web browsers are supported well.
</p>
<p>
The first configuration to be done is to enable Optional DNS Server Protocol
DNS-over-HTTP in the DNS server Settings as shown below. Save the settings by
clicking <b>Save Settings</b> button at the bottom. This will start the DoH service on port 80 to allow renewing the TLS certificate with HTTP challenge.
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/optional-dns-server-protocols.png"
style="margin-left: auto; margin-right: auto;"
><img
alt="Optional DNS Server Protocols"
border="0"
data-original-height="327"
data-original-width="966"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
height="216"
src="https://technitium.com/img/blog/optional-dns-server-protocols.png"
title="Optional DNS Server Protocols"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Optional DNS Server Protocols
</td>
</tr>
</tbody>
</table>
<p>
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
<code>/etc/letsencrypt/renewal-hooks/post/pkcs12convert.sh</code> using
<code>nano</code> editor.
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
sudo mkdir -p /etc/letsencrypt/renewal-hooks/post/
sudo nano /etc/letsencrypt/renewal-hooks/post/pkcs12convert.sh
</pre>
<p>
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.
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
#!/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!"
</pre>
<p>
Save the script by exiting the editor using <code>CTRL+X</code> keys. We need
to make this script excutable by using the following command:
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
sudo chmod +x /etc/letsencrypt/renewal-hooks/post/pkcs12convert.sh
</pre>
<p>
This <code>pkcs12convert.sh</code> script will be automatically executed by
certbot after renewing the certificate.
</p>
<p>
Now, we can run certbot command with the webroot plugin to issue the TLS
certificate as shown below:
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
sudo certbot certonly --agree-tos --email admin@example.com --webroot -w /opt/technitium/dns/dohwww -d dns.example.com
</pre>
<p>
<b>Note:</b> 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.
</p>
<p>
Once the certbot command succeeds, you will see the path of the certificate
that was generated in the output which should be in the
<code>/etc/letsencrypt/live/<your-domain>/</code> directory.
</p>
<p>Below is the output that you should see if the certbot command succeeds.</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
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 /opt/technitium/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
</pre>
<p>
Since the certificate has been issued for the first time, we need to manually
executed our <code>pkcs12convert.sh</code> script once to generate the pfx
certificate.
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
sudo /etc/letsencrypt/renewal-hooks/post/pkcs12convert.sh
</pre>
<p>
We can now configure the DNS server with the pfx certificate file path and enable the DNS-over-TLS, DNS-over-HTTPS, and DNS-over-QUIC protocols (as per your requirements) in the
settings as shown below:
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/optional-dns-server-protocols-with-certificate.png"
style="margin-left: auto; margin-right: auto;"
><img
alt="Optional DNS Server Protocols With TLS Certificate"
border="0"
data-original-height="699"
data-original-width="965"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
height="463"
src="https://technitium.com/img/blog/optional-dns-server-protocols-with-certificate.png"
title="Optional DNS Server Protocols With TLS Certificate"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Optional DNS Server Protocols With TLS Certificate<br />
</td>
</tr>
</tbody>
</table>
<div class="separator" style="clear: both; text-align: center;"></div>
<p>
Type in the same password that you had used while generating the pkcs12
certificate for the TLS Certificate Password option. <br />
</p>
<p>
Save the settings by clicking the <b>Save Settings</b> button at the bottom so
that the DNS server can start the DoQ, 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.
</p>
<p><span style="font-size: large;">Testing The Service</span></p>
<p>
For DoQ and DoT service, you need to use the domain name that was used to
generate the certificate with port 853. Thus your DoQ or DoT configuration for
clients will be
<code>tls-certificate-domain:853.</code>
</p>
<p>
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
<code>https://tls-certificate-domain/dns-query</code>.
</p>
<p>
You can test the DoH, DoT, and DoQ services using the
<a href="https://dnsclient.net/" target="_blank">DNS Client</a> tool. Put in
the DoQ/DoT address <code>tls-certificate-domain:853</code> or the DoH url
<code>https://tls-certificate-domain/dns-query</code> as the Server in the DNS
Client, type in a domain name, select an appropriate protocol either QUIC,
TLS, or HTTPS and click Resolve to test both the services.
</p>
<p>
<b>Note:</b> 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 enable the "Allow Recursion" option to be able to use these services from the public Internet.
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/recursive-resolver-options.png"
style="margin-left: auto; margin-right: auto;"
><img
alt="Recursive Resolver Options"
border="0"
data-original-height="253"
data-original-width="816"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
height="198"
src="https://technitium.com/img/blog/recursive-resolver-options.png"
title="Recursive Resolver Options"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Recursive Resolver Options<br />
</td>
</tr>
</tbody>
</table>
<p>
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.
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/doh-forwarder-configuration.png"
style="margin-left: auto; margin-right: auto;"
><img
alt="Technitium DNS Server Forwarder Configuration"
border="0"
data-original-height="396"
data-original-width="753"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
height="336"
src="https://technitium.com/img/blog/doh-forwarder-configuration.png"
title="Technitium DNS Server Forwarder Configuration"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Technitium DNS Server Forwarder Configuration
</td>
</tr>
</tbody>
</table>
<p>
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.
</p>
<p>
To configure Firefox with custom DoH, go to <b>Options > General</b> and
scroll down to find <b>Network Settings</b>. Click on the
<b>Settings</b> button and find the DoH option at the bottom as shown below:
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/firefox-doh.png"
imageanchor="1"
style="margin-left: auto; margin-right: auto;"
><img
alt="Firefox Custom DoH Option"
border="0"
data-original-height="237"
data-original-width="763"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
height="198"
src="https://technitium.com/img/blog/firefox-doh.png"
title="Firefox Custom DoH Option"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Firefox Custom DoH Option<br />
</td>
</tr>
</tbody>
</table>
<p><span style="font-size: large;">Auto Renewing TLS Certificate</span></p>
<p>
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
<code>pkcs12convert.sh</code> 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.
</p>
<p>
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.
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
sudo certbot renew --dry-run
</pre>
<p>
<span style="font-size: large;">Running DoH With Another Web Server</span>
</p>
<p>
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.
</p>
<p>
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
<code>http://127.0.0.1:8053/dns-query</code> and enable only the DNS-over-HTTP
optional DNS server protocol with its port set to 8053 as shown below:
</p>
<table
align="center"
cellpadding="0"
cellspacing="0"
class="tr-caption-container"
style="margin-left: auto; margin-right: auto;"
>
<tbody>
<tr>
<td style="text-align: center;">
<a
href="https://technitium.com/img/blog/optional-dns-server-protocols-with-dns-over-http.png"
style="margin-left: auto; margin-right: auto;"
><img
alt="Optional DNS Server Protocols With TLS Certificate"
border="0"
data-original-height="330"
data-original-width="967"
style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;"
height="218"
src="https://technitium.com/img/blog/optional-dns-server-protocols-with-dns-over-http.png"
title="Optional DNS Server Protocols With TLS Certificate"
width="640"
/></a>
</td>
</tr>
<tr>
<td class="tr-caption" style="text-align: center;">
Optional DNS Server Protocols With TLS Certificate
</td>
</tr>
</tbody>
</table>
<p>
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
<code>127.0.0.1:53</code> and also provide DoT service through it.
</p>
<p>
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
<a
href="https://www.nginx.com/blog/using-nginx-as-dot-doh-gateway/"
target="_blank"
>using nginx as a DoT or DoH gateway</a
>.
</p>
<pre
style="background-color: whitesmoke; border-radius: 4px; border: 1px solid rgb(204, 204, 204); font-size: 13px; padding: 9.5px; white-space: pre-wrap;"
>
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;
}
}
</pre>
<p><span style="font-size: large;">Conclusion</span></p>
<p>
Using Technitium DNS Server combined with certbot, you can setup DoH, DoT, and
DoQ 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 DoH, DoT, and DoQ
services on the same server.
</p>
<p>
If you have any queries do let me know in the comments below or send an email
to
<a href="mailto:support@technitium.com" target="_blank"
>support@technitium.com</a
>.
</p>
Anonymousnoreply@blogger.com15Mumbai, Maharashtra, India19.0759837 72.8776559-9.2342501361788472 37.721405899999993 47.386217536178847 108.0339059tag:blogger.com,1999:blog-8065376618611632499.post-18398892188967197212020-07-19T19:31:00.001+05:302022-06-08T13:15:30.251+05:30How To Disable Firefox DNS-over-HTTPS On Your NetworkFirefox includes a quite useful option since more than a year now that enables the web browser to use <a href="https://support.mozilla.org/en-US/kb/firefox-dns-over-https" target="_blank">DNS-over-HTTPS (DoH)</a> 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 <a href="https://en.wikipedia.org/wiki/DNS_over_HTTPS" target="_blank">DoH protocol</a> also protects your DNS requests from Man In The Middle (MITM) attacks which are possible with the default unencrypted UDP based DNS requests.<br />
<br />
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 <a href="https://wiki.mozilla.org/Security/DOH-resolver-policy" target="_blank">Trusted Recursive Resolver (TRR)</a> program which lists these providers directly into the web browser's DoH options. The controversy is Firefox enabling DoH for users automatically with an <a href="https://support.mozilla.org/en-US/kb/firefox-dns-over-https#w_opt-out" target="_blank">opt-out policy</a>.<br />
<br />
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 <a href="https://blog.chromium.org/2019/09/experimenting-with-same-provider-dns.html" target="_blank">upgrade</a>
to use DoH protocol if you are already using a public DNS provider that
supports DoH protocol. Microsoft is experimenting with a similar <a href="https://techcommunity.microsoft.com/t5/networking-blog/windows-insiders-can-now-test-dns-over-https/ba-p/1381282" target="_blank">DoH upgrade</a> approach with Windows 10 insider builds.<br />
<br />
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.<br />
<br />
To help network administrators, Firefox has introduced a <a href="https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet" target="_blank">Canary domain</a> to <a href="https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https" target="_blank">disable DoH</a> 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.<br />
<pre style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;"><b>Note:</b> 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.
</pre>
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.<br />
<br />
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:<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/firefox-canary-domain-zone-config.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="Firefox Canary Domain Zone Configuration" border="0" data-original-height="456" data-original-width="932" height="312" src="https://technitium.com/img/blog/firefox-canary-domain-zone-config.png" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;" title="Firefox Canary Domain Zone Configuration" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Firefox Canary Domain Zone Configuration</td></tr>
</tbody></table>
With this configuration, you can ensure that Firefox on your network wont automatically switch to using DoH protocol bypassing your local network DNS servers.<br />
<br />
Let me know if you have any queries in the comments below or send an email to <a href="mailto:support@technitium.com">support@technitium.com</a>.Anonymousnoreply@blogger.com1Mumbai, Maharashtra, India19.0759837 72.877655918.5957917 72.232208899999989 19.556175699999997 73.5231029tag:blogger.com,1999:blog-8065376618611632499.post-73256349916876194662020-07-19T17:03:00.001+05:302022-06-08T13:17:13.940+05:30Technitium DNS Server And Mesh Archived In Arctic Code VaultI just discovered this exciting news that <a href="https://github.com/TechnitiumSoftware/DnsServer" target="_blank">Technitium DNS Server</a> and <a href="https://github.com/TechnitiumSoftware/Mesh" target="_blank">Technitium Mesh</a> has been archived by the <a href="https://github.blog/2020-07-16-github-archive-program-the-journey-of-the-worlds-open-source-code-to-the-arctic/" target="_blank">GitHub Archive Program</a> in the <a href="https://www.youtube.com/watch?v=fzI9FNjXQ0o" target="_blank">Arctic Code Vault</a>!<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/arctic-code-vault.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="Arctic Code Vault" border="0" data-original-height="630" data-original-width="1200" height="420" src="https://technitium.com/img/blog/arctic-code-vault.png" style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;" title="" width="800" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">GitHub Arctic Code Vault</td></tr>
</tbody></table>
<br />
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.<br />
<br />
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.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/arctic-code-vault-contributor.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="238" data-original-width="522" src="https://technitium.com/img/blog/arctic-code-vault-contributor.png" style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Arctic Code Vault Contributor <a href="https://github.com/ShreyasZare" target="_blank">Badge</a>!</td></tr>
</tbody></table>
<br />
To recognize and celebrate the contributions of all the software developers, GitHub now shows a badge on the <a href="https://github.com/ShreyasZare" target="_blank">GitHub profile page</a>. Hovering on the badge shows some of the repositories that were included
in the archive.<br />
<br />
I hope they do the archive again in coming years since the current archive contains old version with quite a few bugs!Anonymousnoreply@blogger.com2Mumbai, Maharashtra, India19.0759837 72.877655918.5957917 72.232208899999989 19.556175699999997 73.5231029tag:blogger.com,1999:blog-8065376618611632499.post-85643752385432073252020-07-12T17:17:00.001+05:302022-06-08T13:20:16.687+05:30How To Enforce Google Safe Search And YouTube Restricted Mode On Your NetworkWith the release of <a href="https://technitium.com/dns/" target="_blank">Technitium DNS Server</a> v5, a new feature called ANAME resource record has been introduced. ANAME resource record implementation is similar to the <a href="https://tools.ietf.org/html/draft-ietf-dnsop-aname-04" target="_blank">IETF draft</a> 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/add-new-conditional-forwarder-zone.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="545" data-original-width="767" height="454" src="https://technitium.com/img/blog/add-new-conditional-forwarder-zone.png" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Add New Conditional Forwarder Zone</td></tr>
</tbody></table>
<br />
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.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/google-force-safe-search.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="398" data-original-width="1115" height="225" src="https://technitium.com/img/blog/google-force-safe-search.png" style="box-shadow: rgb(136, 136, 136) 2px 3px 15px 1px; margin-bottom: 10px;" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Enforcing Google Safe Search</td></tr>
</tbody></table>
<br />
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.<br />
<br />
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.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/enforcing-youtube-restricted-mode.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="394" data-original-width="1120" height="224" src="https://technitium.com/img/blog/enforcing-youtube-restricted-mode.png" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Enforcing YouTube Strict Restricted Mode</td></tr>
</tbody></table>
<br />
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.<br />
<br />
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.<br />
<br />
If you have any queries, do let me know in the comments section below. For any feedback or support do send an email to <a href="mailto:support@technitium.com">support@technitium.com</a>.Anonymousnoreply@blogger.com0Mumbai, Maharashtra, India19.0759837 72.877655918.5957917 72.232208899999989 19.556175699999997 73.5231029tag:blogger.com,1999:blog-8065376618611632499.post-44321071958550935012020-07-05T18:30:00.003+05:302022-06-08T13:22:10.531+05:30Technitium 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. <a href="https://technitium.com/dns/" target="_blank">Download</a> the latest update now!<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/technitium-dns-server-v5-dashboard.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="552" data-original-width="850" height="415" src="https://technitium.com/img/blog/technitium-dns-server-v5-dashboard.png" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Technitium DNS Server v5</td></tr>
</tbody></table>
<br />
<a href="https://technitium.com/dns/" target="_blank">Technitium DNS Server</a> 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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. <br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/add-conditional-forwarder-zone.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="549" data-original-width="775" height="280" src="https://technitium.com/img/blog/add-conditional-forwarder-zone.png" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Conditional Forwarder Zone</td></tr>
</tbody></table>
<br />
Features that you may find interesting in this release:<br />
<ul>
<li><a href="https://tools.ietf.org/html/draft-ietf-dnsop-rfc7816bis-04" target="_blank">QNAME minimization</a> support in recursive resolver for privacy.</li>
<li>ANAME propriety record support to allow using CNAME like feature at zone root.</li>
<li>Primary and Secondary zone support with <a href="https://tools.ietf.org/html/rfc1996" target="_blank">NOTIFY</a> implementation and zone transfer support. </li>
<li>Stub zone support that allows the DNS server to keep track of the name servers of the zone.</li>
<li>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.</li>
<li>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.</li>
<li>Concurrent querying with more than one forwarder allows to get fastest response from multiple forwarders.</li>
<li>Option to change the DNS Server local ports for TCP and UDP protocols. </li>
</ul>
Read the <a href="https://github.com/TechnitiumSoftware/DnsServer/blob/master/CHANGELOG.md" target="_blank">change log</a> to know more in details about the latest release. <br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/google-force-safe-search.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="398" data-original-width="1115" height="226" src="https://technitium.com/img/blog/google-force-safe-search.png" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Conditional Forwarder Zone with Overridden Records For Google Force Safe Search</td></tr>
</tbody></table>
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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 <a href="mailto:support@technitium.com">support@technitium.com</a>. For any feature request or reporting bug, do create an issue on <a href="https://github.com/TechnitiumSoftware/DnsServer/issues" target="_blank">GitHub</a>.<br />
<br />
The DNS Server code is available under <a href="https://go.technitium.com/?id=24" target="_blank">GNU General Public Licence (GPL) v3</a> on <a href="https://github.com/TechnitiumSoftware/DnsServer" target="_blank">GitHub</a>.<br />
<br />
You can now make your contributions to Technitium by becoming a Patron and help in developing new software, updates and adding more features possible. <a href="https://go.technitium.com/?id=35" target="_blank">Become a Patron now!</a>Anonymousnoreply@blogger.com5Mumbai, Maharashtra, India19.0759837 72.877655918.5957917 72.232208899999989 19.556175699999997 73.5231029tag:blogger.com,1999:blog-8065376618611632499.post-84926035839446600482019-12-08T20:51:00.001+05:302022-06-08T13:22:58.730+05:30Technitium Mesh Released!<p>
<a href="https://mesh.im/" target="_blank">Technitium Mesh</a>, a successor to the <a href="https://github.com/TechnitiumSoftware/BitChatClient" target="_blank">Bit Chat</a> project, has been released and is available to download directly from the Mesh website.
</p>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/mesh-screenshot.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="454" data-original-width="805" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;" src="https://technitium.com/img/blog/mesh-screenshot.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Technitium Mesh</td></tr>
</tbody></table>
<div class="separator" style="clear: both; text-align: center;"></div>
<p>
<h3>Introduction</h3>
Mesh is a secure, anonymous, peer-to-peer (p2p), open source instant messenger that provides end-to-end encryption with <a href="https://en.wikipedia.org/wiki/Forward_secrecy" target="_blank">Perfect Forward Secrecy (PFS)</a>. 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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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 <a href="https://en.wikipedia.org/wiki/Distributed_hash_table" target="_blank">Distributed Hash Tables (DHT)</a>.
</p>
<p>
Mesh now allows creating anonymous profiles that use <a href="https://www.torproject.org/" target="_blank">Tor Network</a>. 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.
</p>
<p>
Read more technical details on the <a href="https://mesh.im/faq.html" target="_blank">Frequently Asked Questions (FAQ)</a> page.
</p>
<p>
<h3>Features</h3>
<ul>
<li>Completely decentralized, peer-to-peer architecture that works even on offline private LAN networks. No centralized profile registration is needed.</li>
<li>End-to-end encryption with <a href="https://en.wikipedia.org/wiki/Forward_secrecy" target="_blank">Perfect Forward Secrecy (PFS)</a>.</li>
<li>Allows you to create anonymous profiles that use <a href="https://www.torproject.org/" target="_blank">Tor Network</a>.</li>
<li>Multiple profile support allows you to create many profiles and use all of them simultaneously. </li>
<li>Allows creating private chat and group chat with file transfer support.</li>
<li>User profiles are stored locally using strong encryption protected by passphrase. </li>
<li>Works peer-to-peer with IPv4 as well as IPv6 networks. </li>
<li>Automatic port forwarding using your router's UPnP feature.</li>
</ul>
</p>
<p>
<h3>Open Source</h3>
Mesh is open source and source code is available under <a href="https://mesh.im/license.html" target="_blank">GNU General Public License v3</a> on <a href="https://github.com/TechnitiumSoftware/Mesh" target="_blank">GitHub</a>. The software code is made open source to increase confidence in the security that we intend to provide.
</p>
<p>
<h3>Alpha Version</h3>
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 <a href="mailto:support@technitium.com">support@technitium.com</a>. For any issues, feedback, or feature request you may create an issue on <a href="https://github.com/TechnitiumSoftware/Mesh/issues" target="_blank">GitHub</a>.
</p>
</p>
Further, you may like to read the original concept in this old <a href="http://blog.technitium.com/2011/07/bitchat-peer-to-peer-instant-messaging.html" target="_blank">blog post</a>.
</p>Anonymousnoreply@blogger.com2Mumbai, Maharashtra, India19.0759837 72.87765590000003618.5957917 72.232208900000032 19.556175699999997 73.52310290000004tag:blogger.com,1999:blog-8065376618611632499.post-66532686785179483022019-09-28T17:14:00.000+05:302019-09-30T15:10:10.120+05:30Analyzing DNS-over-HTTPS And DNS-over-TLS Privacy and Security Claims<a href="https://en.wikipedia.org/wiki/DNS_over_HTTPS" target="_blank">DNS-over-HTTPS (DoH)</a> and <a href="https://en.wikipedia.org/wiki/DNS_over_TLS" target="_blank">DNS-over-TLS (DoT)</a> are two new protocol options available for secure DNS transport. Of which DoH has been pretty controversial with <a href="https://twitter.com/paulvixie/status/1053765281917661184" target="_blank">strong opposition from notable people</a> in the DNS community. There have been questions raised for even the existence of <a href="https://tools.ietf.org/html/rfc8484" target="_blank">IETF DoH standard</a> when <a href="https://tools.ietf.org/html/rfc7858" target="_blank">DoT standard</a> was already an option.<br />
<br />
Firefox has builtin DoH support with Cloudflare DNS configured that is being rolled out as a <a href="https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/" target="_blank">default for all users in the USA</a>. This has consequences of subverting local network policies of organizations or private networks. Firefox has announced a <a href="https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnet" target="_blank">canary domain name</a> that can be blocked locally to prevent Firefox to use DoH by default making the entire effort vulnerable to downgrade attacks.<br />
<br />
There have been <a href="https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-for-privacy-in-2019-and-beyond/" target="_blank">serious concerns raised</a> 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.<br />
<br />
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 <a href="https://blog.technitium.com/2018/10/blocking-internet-ads-using-dns-sinkhole.html" target="_blank">block Internet Ads using block lists</a>.<br />
<br />
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. <br />
<br />
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.<br />
<br />
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 <a href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack" target="_blank">man-in-the-middle attack</a>. This has been exploited in many <a href="https://blog.trendmicro.com/trendlabs-security-intelligence/dns-changer-malware-sets-sights-on-home-routers/" target="_blank">malware attacks that compromise routers</a> and change DNS settings to use attacker's DNS server to spread further or to compromise users further. Many ISPs have also tried to <a href="https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_ISPs" target="_blank">hijack DNS</a> to show advertisements when user enters a non-existent domain name in the web browser.<br />
<br />
DoT protocol is really just DNS-over-TCP tunneled inside <a href="https://en.wikipedia.org/wiki/Transport_Layer_Security" target="_blank">TLS</a>. 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Even when DNS requests are encrypted, you are still leaking domain names of website you visit due to TLS <a href="https://en.wikipedia.org/wiki/Server_Name_Indication" target="_blank">Server Name Indication (SNI)</a> 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.<br />
<br />
SNI extension is being upgraded to <a href="https://tools.ietf.org/html/draft-ietf-tls-esni" target="_blank">Encrypted SNI (ESNI)</a> 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 <a href="https://www.shodan.io/search?query=port%3A80+http.status%3A200" target="_blank">do not have HTTPS deployed (link requires login)</a>.<br />
<br />
Even when DNS request are encrypted and TLS ESNI extension is used, most websites can still be <a href="https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an-ip-address/" target="_blank">identified by the IP address</a> they are hosted on. Thus privacy provided by all these measures is still inadequate.<br />
<br />
What about <a href="https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions" target="_blank">DNSSEC</a>? 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.<br />
<br />
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.<br />
<br />
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 <a href="https://twitter.com/paulvixie/status/1053886628832382977" target="_blank">bypass local network policies</a>. Both are capable from hiding your DNS traffic on private network or from ISP.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<br />Anonymousnoreply@blogger.com2tag:blogger.com,1999:blog-8065376618611632499.post-15615761507433995812019-01-01T16:12:00.001+05:302022-06-08T13:26:39.174+05:30Turn Raspberry Pi Into Network Wide DNS Server<p>
Turn your <a href="https://www.raspberrypi.org/" target="_blank">Raspberry Pi</a> into a network wide DNS server for <a href="https://blog.technitium.com/2018/06/configuring-dns-server-for-privacy.html" target="_blank">security</a>, <a href="https://blog.technitium.com/2018/06/configuring-dns-server-for-privacy.html" target="_blank">privacy</a> and <a href="https://blog.technitium.com/2018/10/blocking-internet-ads-using-dns-sinkhole.html" target="_blank">blocking Internet Ads</a> on your private network!
</p>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/raspberry-pi-small.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="534" data-original-width="800" height="426" src="https://technitium.com/img/blog/raspberry-pi-small.png" width="640" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;"/></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Raspberry Pi 3 Model B+</td></tr>
</tbody></table>
<p>
With <a href="https://technitium.com/dns/" target="_blank">Technitium DNS Server</a> 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.
</p>
<h3>Install DNS Server</h3>
<p>
Just connect to your Raspberry Pi using SSH and run the command below to install the DNS server:
<pre style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;">
curl -sSL https://download.technitium.com/dns/install.sh | sudo bash
</pre>
</p>
<p>
You can install the software manually too if you do not wish to directly run the install script. You will need to first manually <a href="https://blog.technitium.com/2019/01/quick-and-easy-guide-to-install-net.html" target="_blank">install .NET Core on your Raspberry Pi</a> and then use <a href="https://blog.technitium.com/2017/11/running-dns-server-on-ubuntu-linux.html" target="_blank">these steps</a> to install the DNS Server.
</p>
<p>
Once the installation is complete, open the DNS Server web console to view the dashboard and customize the settings.
</p>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/dns-pi-dashboard2.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" data-original-height="770" data-original-width="1140" height="432" src="https://technitium.com/img/blog/dns-pi-dashboard2.png" width="640" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;"/></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Technitium DNS Server web console on Raspberry Pi 3 Model B+</td></tr>
</tbody></table>
<h3>Configure Your Router</h3>
<p>
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.
</p>
<p>
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.
</p>
<p>
If you have any queries or feedback, do comment below to let me know. You can also email your queries to <a href="mailto:support@technitium.com">support@technitium.com</a>.
</p>Anonymousnoreply@blogger.com23tag:blogger.com,1999:blog-8065376618611632499.post-58220640797799798792019-01-01T13:38:00.001+05:302022-06-08T13:27:15.537+05:30Quick And Easy Guide To Install .NET Core On Raspberry Pi<p>
.NET Core is a cross-platform runtime available for x64 and ARM processors that can be used to run ASP.NET Core web applications and standalone .NET Core console applications on Windows, Linux and macOS.
</p>
<p>
<a href="https://dotnet.microsoft.com/download" target="_blank">Installing .NET Core</a> is straight forward for most Desktop platforms with clear instructions available on the download website. However, many would find it trickier to install it on something like Raspberry Pi which uses ARM based processor. So, here is a quick and easy guide to install .NET Core 2.2 on Raspberry Pi 3 Model B+ with the latest <a href="https://www.raspberrypi.org/downloads/raspbian/" target="_blank">Raspbian</a> that is based on Debian 9 (Stretch).
</p>
<p>
Connect to your Raspberry Pi using SSH and get started!
<p>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/raspberry-pi-small.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="534" data-original-width="800" height="425" src="https://technitium.com/img/blog/raspberry-pi-small.png" width="640" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;"/></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Raspberry Pi 3 Model B+</td></tr>
</tbody></table>
<h3>Installing Dependencies</h3>
<p>
First you need to install a few dependencies required by the .NET Core runtime:
<pre style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;">
sudo apt-get -y update
sudo apt-get -y install curl libunwind8 gettext apt-transport-https
</pre>
</p>
<h3>Installing .NET Core</h3>
<p>
Go to the <a href="https://dotnet.microsoft.com/download?initial-os=linux" target="_blank">.NET Core download</a> page and download the Linux ARM32 runtime. Or you could just copy the download URL from there to use with <b>wget</b> like I did and follow these steps:
<pre style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;">
wget https://download.visualstudio.microsoft.com/download/pr/860e937d-aa99-4047-b957-63b4cba047de/da5ed8a5e7c1ac3b4f3d59469789adac/aspnetcore-runtime-2.2.0-linux-arm.tar.gz
sudo mkdir -p /opt/dotnet
sudo tar -zxf aspnetcore-runtime-2.2.0-linux-arm.tar.gz -C /opt/dotnet
sudo ln -s /opt/dotnet/dotnet /usr/bin
</pre>
</p>
<p>
Now just enter <b>dotnet</b> on the command line to confirm.
</p>
<h3>Its Done!</h3>
<p>
Now you are ready to run ASP.NET Core or .NET Core console apps on your Raspberry Pi!
</p>Anonymousnoreply@blogger.com0tag:blogger.com,1999:blog-8065376618611632499.post-49759457967961452722018-12-25T18:04:00.001+05:302021-02-21T20:57:28.521+05:30Configuring DNS-over-TLS and DNS-over-HTTPS with any DNS Server<p>
The new <a href="https://en.wikipedia.org/wiki/DNS_over_TLS" target="_blank">DNS-over-TLS (DoT)</a> and <a href="https://en.wikipedia.org/wiki/DNS_over_HTTPS" target="_blank">DNS-over-HTTPS (DoH)</a> protocols are available for enabling end user's privacy and security given the fact that most DNS clients use UDP or TCP protocols which are prone to eavesdropping, vulnerable to Man-in-the-Middle (MitM) attacks and, are frequently abused by ISPs in many countries with Internet censorship.
</p>
<p>
Public DNS providers like Cloudflare & Quad9, have already deployed these
protocols and web browsers like Mozilla Firefox has built in DoH
support. However, most operating systems and applications do not support them but, end users can still use these protocols on their computer by installing <a href="https://technitium.com/dns/" target="_blank">Technitium DNS Server</a> locally and <a href="https://blog.technitium.com/2018/06/configuring-dns-server-for-privacy.html" target="_blank">configuring any DoT or DoH provider as a forwarder</a> to bypass ISP's control over DNS.
</p>
<p>
Both these protocols are IETF standards and are equally secure considering the fact that HTTPS itself runs over TLS. However, both protocols have slightly different ideas and there are a lot of arguments between engineers over the reason why DoH protocol exists in first place when a superior DoT protocol exists that implements <a href="https://tools.ietf.org/html/rfc7766" target="_blank">RFC 7766</a> guidelines. The argument of having DoH is more political since DNS requests over DoH look just like normal HTTPS traffic over port 443 and thus hard to stop unlike DoT running on port 853. This makes DoH protocol desirable to users in countries with Internet censorship.
</p>
<p>
In this post we will explore configuring both these protocols for any DNS server that you already have running on your network. Both these services require SSL certificates which can be obtained for free using <a href="https://letsencrypt.org/" target="_blank">Let's Encrypt</a> certificate authority which is trusted by all major web browsers. You can configure <a href="https://certbot.eff.org/" target="_blank">Certbot</a> for automatic Let's Encrypt certificate renewal or manually generate one using <a href="https://technitium.com/ssl/" target="_blank">Get HTTPS For Free</a> utility.
</p>
<h3>DNS-over-TLS (DoT)</h3>
<p>
DNS-over-TLS standard is specified in <a href="https://tools.ietf.org/html/rfc7858">RFC 7858</a> which is very straight forward to implement. Essentially, the standard specifies to use the existing DNS-over-TCP protocol support, that most DNS servers already have and, add TLS to it. DoT support can be available as a addon feature in your DNS server software or you can use Nginx web server to enable it.
</p>
<p>
Nginx supports <a href="https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-tcp/" target="_blank">SSL termination for TCP upstream</a> which I will be using to enable DoT to use with Technitium DNS Server. I am using Ubuntu Server 18.04 LTS for this setup but, you should be able to do similar config on any Linux distro.
</p>
<p>
First install the nginx web server:
<pre style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;">
sudo apt-get -y install nginx
</pre>
</p>
<p>
Now all you need to configure DoT is to copy the following stream config block in your <b>/etc/nginx/nginx.conf</b> file and save
the certificate and key files to path given as in the config. Don't forget to update the upstream DNS server IP addresses to your existing DNS servers.
<pre style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;">
stream {
upstream dns-servers {
server 10.10.1.5:53;
server 10.10.1.6:53;
}
server {
listen 853 ssl;
proxy_pass dns-servers;
ssl_certificate /etc/nginx/ssl/dot-server.crt;
ssl_certificate_key /etc/nginx/ssl/dot-server.key;
ssl_protocols TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_handshake_timeout 10s;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 4h;
}
}
</pre>
</p>
<p>
Once done, reload nginx web server to finish the configuration:
<pre style="background-color: whitesmoke; border-radius: 4px; border: 1px solid #ccc; font-size: 13px; padding: 9.5px; white-space: pre-wrap;">
sudo service nginx reload
</pre>
</p>
<h3>DNS-over-HTTPS (DoH)</h3>
<p>
DNS-over-HTTPS standard is specified in <a href="https://tools.ietf.org/html/rfc8484" target="_blank">RFC 8484</a> and is a bit different to implement since it uses HTTP protocol. The DNS queries are send in wire format as a HTTP POST method or as a base64 encoded HTTP GET parameter. Using GET method allows caching of the response which may be undesirable considering that the DNS protocol controls expiry using TTL values which may get overridden by a HTTP based cache server.
</p>
<p>
Technitium has released <a href="https://github.com/TechnitiumSoftware/DNS-over-HTTPS" target="_blank">DNS-over-HTTPS (DoH)</a> open source web application that can be used with any DNS server. The ASP.NET 5 web application can be deployed on any supported platforms (Windows/macOS/Linux). Just follow the instructions on the <a href="https://github.com/TechnitiumSoftware/DNS-over-HTTPS" target="_blank">project's GitHub page</a> to get the DoH service running on your server.
</p>
<h3>And Its Ready!</h3>
<p>
You can now use the DoT service (dot.example.com:853) or DoH service (https://doh.example.com/dns-query) with any supported DNS client or as a forwarder with Technitium DNS Server.
</p>
<p>
If you have any queries or feedback, do comment below to let me know. You can also email your queries to <a href="mailto:support@technitium.com">support@technitium.com</a>.
</p>Anonymousnoreply@blogger.com3tag:blogger.com,1999:blog-8065376618611632499.post-6200573647658094752018-10-27T20:20:00.004+05:302022-06-08T13:32:29.750+05:30Blocking Internet Ads Using DNS Sinkhole<a href="https://technitium.com/dns/" target="_blank">Technitium DNS Server</a> is an open source software that can be effectively used to block Internet Advertisements (Ads), adware, and malware on your computer or your local network using publicly available block lists.<br />
<br />
Combined with <a href="https://en.wikipedia.org/wiki/DNS_over_TLS" target="_blank">DNS-over-TLS</a> and <a href="https://en.wikipedia.org/wiki/DNS_over_HTTPS" target="_blank">DNS-over-HTTPS</a>, Technitium DNS Server provides a good level <a href="https://blog.technitium.com/2018/06/configuring-dns-server-for-privacy.html" target="_blank">security and privacy</a> from network level DNS attacks and from adware. This makes it a must have tool if you are a privacy and security conscious person.<br />
<br />
Technitium DNS Server is cross platform and works on Windows, Linux or macOS.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/technitium-dns-server-v2-dashboard.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="504" data-original-width="855" height="377" src="https://technitium.com/img/blog/technitium-dns-server-v2-dashboard.png" width="640" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;"/></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Technitium DNS Server v2.0</td></tr>
</tbody></table>
<br />
<b>How Does It Work?</b><br />
The Ad blocking feature works using the <a href="https://en.wikipedia.org/wiki/DNS_sinkhole" target="_blank">DNS Sinkhole</a> method. With this feature enabled, for all the blocked domain names, the DNS Server will respond with <b>0.0.0.0</b> IPv4 address and <b>::</b> for IPv6 address making the Ads fail to load making the website you visit free from Ads. This can not only block Ads but also adware, malware, social networks, porn etc. based on the block lists you configure in settings.<br />
<br />
On your computer, you need to install the DNS Server and configure your network adapter's DNS settings to use the locally hosted DNS server. Once this is done, you need to configure the Block List URL settings to start blocking Ads. Once the DNS Server loads the block lists, it would respond with <b>0.0.0.0</b> IP address for the blocked websites making them fail to load.<br />
<br />
You may also install the DNS Server on any spare computer on your network and configure your home or office router with IP address of this spare computer as DNS server in DHCP settings. With this setup, all your computers and devices like mobile phones would use the installed DNS Server blocking Ads and malware domains on all devices without installing any additional software on them.<br />
<br />
<b>Configuring Block Lists</b><br />
To enable Ad blocking, you need to configure Block List URLs in the settings. Known and popular block lists are already listed in the <b><i>Quick Add</i></b> drop down list from where you can just click and add those URLs.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/technitium-dns-server-blocklist-config.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="199" data-original-width="723" height="176" src="https://technitium.com/img/blog/technitium-dns-server-blocklist-config.png" width="640" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;"/></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Technitium DNS Server Block List Configuration</td></tr>
</tbody></table>
<br />
If you are not sure, just select the <b>Default</b> option from the <i><b>Quick Add</b></i> drop down list and a default set of block list URLs would get configured.<br />
<br />
Once done, click the <b>Save Settings</b> button at the bottom of the page to save the changes and start the block list download background process. These configured block lists are automatically downloaded every 24 hours to keep the DNS Server blocked zone updated.<br />
<br />
If you have the DNS server installed directly on your computer then don't forget to configure your network adapter's DNS server settings to 127.0.0.1 (for IPv4) and ::1 (for IPv6). Without these network configuration changes, the DNS Server wont get any queries to respond to and things wont work as intended.<br />
<br />
If you setup the DNS server to be used on the network by all devices then do configure your router's DHCP config and set the IP address of the computer running the DNS server as the DNS for your network. By configuring the router's DHCP, you don't need to manually configure any of your devices on the network.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/dns-ipv4-config.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="455" data-original-width="400" height="400" src="https://technitium.com/img/blog/dns-ipv4-config.png" width="350" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;"/></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">IPv4 DNS Server Network Configuration</td></tr>
</tbody></table>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/dns-ipv6-config.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="455" data-original-width="541" height="336" src="https://technitium.com/img/blog/dns-ipv6-config.png" width="400" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;"/></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">IPv6 DNS Server Network Configuration</td></tr>
</tbody></table>
<br />
<b>That's It!</b><br />
Once the configuration is done, just check the Dashboard on the web console after a couple of minutes to see the number of blocked domains in the Blocked Zones widget. If there are too many block list URLs configured, it may take few more minutes for all of them to get downloaded and loaded.<br />
<br />
If you have any further queries, do write them below as comments or send an email to <a href="mailto:support@technitium.com">support@technitium.com</a>.Anonymousnoreply@blogger.com34Mumbai, Maharashtra, India19.0759837 72.87765590000003618.5957917 72.232208900000032 19.556175699999997 73.52310290000004tag:blogger.com,1999:blog-8065376618611632499.post-40896030784988093142018-06-23T16:09:00.001+05:302022-06-08T13:36:51.521+05:30Configuring DNS Server For Privacy & Security<a href="https://technitium.com/dns/" target="_blank">Technitium DNS Server</a> is an open source tool that can be used for <a href="https://blog.technitium.com/2018/10/blocking-internet-ads-using-dns-sinkhole.html" target="_blank">blocking Internet Ads</a> using <a href="https://en.wikipedia.org/wiki/DNS_sinkhole" target="_blank">DNS Sinkhole</a>,
self hosting a local DNS server for privacy & security or, used for
experimentation/testing by software developers on their computer. It works out-of-the-box with no or minimal configuration and provides a user friendly web console accessible using any web browser.
<br />
<br />
With the release of <a href="https://technitium.com/dns/" target="_blank">Technitium DNS Server</a> version 1.3 which adds support for <a href="https://en.wikipedia.org/wiki/DNS_over_TLS" target="_blank">DNS-over-TLS</a> & <a href="https://en.wikipedia.org/wiki/DNS_over_HTTPS" target="_blank">DNS-over-HTTPS</a> forwarders, it is now a good solution to be used by anyone concerned with privacy & security for domain name resolution on their Internet connection for Windows 10, Linux or macOS.
<br />
<br />
If you are not clear about what DNS is then read on. Domain Name System (DNS) is a decentralized system that allows you to find out the Internet Protocol (IP) address of any website (like www.technitium.com). So, when you enter a website domain name into your web browser, the web browser uses DNS to find out the IP address of that website. Once the IP address is known, the web browser can then connect to the web server on that IP address using TCP/IP protocols and download webpages and other embedded resources to display on to your screen. DNS servers don't just store IP address records but also store different types of records like mail exchange (MX) records which tell email servers where to deliver email for the recipient user of a given domain.
<br />
<br />
DNS servers and client use UDP or TCP protocol to exchange requests and responses which are not encrypted. This allows anyone on the network to see those requests and even hijack requests by sending back spoofed responses. There have been many instances reported in media of DNS hijacking done by malware, hacked home wifi routers or even by many Internet Service Providers (ISPs). ISPs in certain places have been found to redirect users to "custom" search pages instead of Google Search or even blatantly injecting Ads on websites that are not using HTTPS security. In some countries, ISPs often use their DNS servers to block websites to enforce government censorship orders.
<br />
<br />
To mitigate these issues, <a href="https://en.wikipedia.org/wiki/DNS_over_TLS" target="_blank">DNS-over-TLS</a> and <a href="https://en.wikipedia.org/wiki/DNS_over_HTTPS" target="_blank">DNS-over-HTTPS</a> protocols have been developed and are currently available to be used by a few DNS providers notably <a href="https://blog.cloudflare.com/dns-resolver-1-1-1-1/" target="_blank">Cloudflare</a>, <a href="https://developers.google.com/speed/public-dns/" target="_blank">Google</a> and <a href="https://www.quad9.net/" target="_blank">Quad9</a>. But, currently, no operating system, applications or web browsers have built in support for these protocols.
<br />
<br />
With Technitium DNS Server installed on your computer (or on your network), you can make all your applications indirectly use these DNS providers with the new secure protocols hiding all your DNS traffic from your ISP. Lets see how to configure the DNS Server to use these services to take control and secure domain name resolution on your computer or private networks.
<br />
<br />
Technitium DNS Server is not configured out-of-the-box with these settings since you have to make a choice yourself of which DNS provider to use. All public DNS providers have their own privacy policies that you must understand before choosing it.
<br />
<br />
Cloudflare <a href="https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/" target="_blank">privacy policy</a> promises that DNS query logs are only maintained for 24 hours with not personally identifiable data. They also promise to not sell the data to 3rd parties.
<br />
<br />
Google's <a href="https://developers.google.com/speed/public-dns/privacy" target="_blank">privacy policy</a> claims to maintain a temporary log for 24 to 48 hours which contains user's full IP address details. And a permanent log which redacts the personally identifiable data. There are no details mentioned how this data is used or whom its shared with.
<br />
<br />
Quad9's <a href="https://www.quad9.net/privacy/" target="_blank">privacy policy</a> promises that they do not keep any logs but, only anonymized statistical data on specific domain names which contains things like domain name, timestamp, geolocation, total hits, etc.
<br />
<br />
Below is a list of DNS providers grouped by the protocol they support. You can configure one or more DNS providers as forwarders but they must use the same protocol. <br />
<br />
DNS-over-TLS protocol providers:<br />
<ul>
<li>Cloudflare IPv4 {cloudflare-dns.com (1.1.1.1:853), cloudflare-dns.com (1.0.0.1:853)}</li>
<li>Cloudflare IPv6 {cloudflare-dns.com ([2606:4700:4700::1111]:853), cloudflare-dns.com ([2606:4700:4700::1001]:853)}</li>
<li>Google IPv4 {dns.google (8.8.8.8:853), dns.google (8.8.4.4:853)}</li>
<li>Google IPv6 {dns.google ([2001:4860:4860::8888]:853), dns.google ([2001:4860:4860::8844]:853)}</li>
<li>Quad9 Secure IPv4 {dns.quad9.net (9.9.9.9:853)}</li>
<li>Quad9 Secure IPv6 {dns.quad9.net ([2620:fe::fe]:853))</li>
</ul>
<br />
DNS-over-HTTPS protocol providers:<br />
<ul>
<li>Cloudflare (https://cloudflare-dns.com/dns-query)</li>
<li>Google (https://dns.google/dns-query)</li>
<li>Quad9 Secure (https://dns.quad9.net/dns-query)</li>
</ul>
<br />
DNS-over-HTTPS (JSON) protocol providers:<br />
<ul>
<li>Cloudflare (https://cloudflare-dns.com/dns-query)</li>
<li>Google (https://dns.google/resolve)</li>
<li>Quad9 Secure (https://dns.quad9.net/dns-query)</li>
</ul>
<br />
To make the configuration quick, easy and error free, there is <b>Quick Select</b> drop down list available which lists all the above options. Just selecting the desired option in the <b>Quick Select</b> list will populate the settings automatically for you.<br />
<br />
See these examples below to know how the configuration looks like:<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/dns-over-tls-example.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="DNS-over-TLS Using Cloudflare" border="0" data-original-height="362" data-original-width="922" height="249" src="https://technitium.com/img/blog/dns-over-tls-example.PNG" title="" width="640" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;"/></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">DNS-over-TLS Using Cloudflare</td></tr>
</tbody></table>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/dns-over-tls-ipv6-example.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="DNS-over-TLS Using Quad9 For IPv6 Internet" border="0" data-original-height="360" data-original-width="908" height="252" src="https://technitium.com/img/blog/dns-over-tls-ipv6-example.PNG" title="" width="640" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;"/></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">DNS-over-TLS Using Quad9 For IPv6 Internet</td></tr>
</tbody></table>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/dns-over-https-example.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="DNS-over-HTTPS Using Cloudflare" border="0" data-original-height="361" data-original-width="899" height="256" src="https://technitium.com/img/blog/dns-over-https-example.PNG" title="" width="640" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;"/></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">DNS-over-HTTPS Using Cloudflare</td></tr>
</tbody></table>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/dns-over-https-json-example.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="359" data-original-width="904" height="254" src="https://technitium.com/img/blog/dns-over-https-json-example.PNG" width="640" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;"/></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">DNS-over-HTTPS (JSON) Using Google</td></tr>
</tbody></table>
<br />
As you may have noticed, Cloudflare provides support for all three protocols. Not only that, it is possible to use <a href="https://blog.cloudflare.com/welcome-hidden-resolver/" target="_blank">Cloudflare DNS over Tor hidden service</a> too! Technitium DNS Server v1.3 adds support for configuring proxy server which can of course be made to use Tor running on your computer and use Cloudflare DNS hidden service because <b>WHY NOT?!</b><br />
<br />
You just need to configure <b>dns4torpnlfs2ifuz2s2yf3fc7rdmsbhm6rw75euj35pac6ap25zgqad.onion</b> hidden service address as forwarder and since all hidden service requests over Tor network are inherently end-to end encrypted, you can use DNS-over-TCP protocol with it. Tor is not included with the software so you will need to install Tor separately and configure it as a SOCKS5 proxy.<br />
<br />
This option hides your query from your ISP as well as hides your identity from Cloudflare. But seriously, if you are really that paranoid, just use <a href="https://www.torproject.org/" target="_blank">Tor Browser</a> for all your web browsing.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/dns-over-tor-example.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img alt="DNS-over-Tor Config For Cloudflare DNS Hidden Service" border="0" data-original-height="716" data-original-width="1009" height="454" src="https://technitium.com/img/blog/dns-over-tor-example.PNG" title="" width="640" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;"/></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">DNS-over-Tor Config For Cloudflare DNS Hidden Service</td></tr>
</tbody></table>
<br />
Once you have configured forwarders, make use of the DNS Client on the web console to test the setup by making a test query to "this-server". If everything is configured correctly, you will see the IP address for the test domain you entered inside the "Answers" section of the JSON formatted output.
<br />
<br />
Finally, to make all your computers and applications to use Technitium DNS Server, you need to configure it on your Ethernet or WiFi network adapter. You just need to setup loopback IP address (127.0.0.1 for IPv4 & ::1 for IPv6) as DNS Server in your network adapter settings as shown below:<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/dns-ipv4-config.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="455" data-original-width="400" height="400" src="https://technitium.com/img/blog/dns-ipv4-config.png" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;" width="351" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">IPv4 DNS Server Network Configuration</td></tr>
</tbody></table>
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/dns-ipv6-config.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="455" data-original-width="541" height="336" src="https://technitium.com/img/blog/dns-ipv6-config.png" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">IPv6 DNS Server Network Configuration</td></tr>
</tbody></table>
<br />
For more queries, write comments below or send an email to <a href="mailto:support@technitium.com">support@technitium.com</a>.
Anonymousnoreply@blogger.com88Mumbai, Maharashtra, India19.0759837 72.87765590000003618.5957917 72.232208900000032 19.556175699999997 73.52310290000004tag:blogger.com,1999:blog-8065376618611632499.post-71805357276513268842018-06-23T16:04:00.001+05:302022-06-08T13:38:45.374+05:30Technitium DNS Server v1.3 Released!<a href="https://technitium.com/dns/" target="_blank">Technitium DNS Server</a> is an open source tool that can be used for self hosting a local DNS server for privacy & security or, used for experimentation/testing by software developers on their computer. It works out-of-the-box with no or minimal configuration and provides a user friendly web console accessible using any web browser.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://technitium.com/img/blog/dns-zones.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="652" data-original-width="1140" height="366" src="https://technitium.com/img/blog/dns-zones.png" width="640" style="box-shadow: 2px 3px 15px 1px #888888; margin-bottom: 10px;" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Technitium DNS Server v1.3</td></tr>
</tbody></table>
<br />
Version 1.3 adds following awesome new features:<br />
<ul>
<li> <a href="https://en.wikipedia.org/wiki/DNS_over_TLS" target="_blank">DNS-over-TLS</a> and <a href="https://en.wikipedia.org/wiki/DNS_over_HTTPS" target="_blank">DNS-over-HTTPS</a> forwarder protocol support.</li>
<li>HTTP and SOCKS5 network proxy support.</li>
</ul>
<br />
The DNS Server is cross platform and can be deployed on Windows 10, Linux or macOS (using .NET Core or Mono Framework). Read <a href="https://blog.technitium.com/2017/11/running-dns-server-on-ubuntu-linux.html" target="_blank">this blog post</a> to learn how to run DNS Server on Ubuntu.<br />
<br />
Nobody really bothers about domain name resolution since it works automatically behind the scenes and is complex to understand. Most computer software use the operating system's DNS resolver that usually query the configured ISP's DNS server using UDP protocol. This way works well for most people but, your ISP can see and control what website you can visit even when the website employ HTTPS security. Not only that, some ISPs can redirect, block or inject content into non-HTTPS websites you visit even when you use a different DNS provider like Google DNS or Cloudflare DNS. Having Technitium DNS Server configured to use <a href="https://en.wikipedia.org/wiki/DNS_over_TLS" target="_blank">DNS-over-TLS</a> or <a href="https://en.wikipedia.org/wiki/DNS_over_HTTPS" target="_blank">DNS-over-HTTPS</a> forwarders, these privacy & security issues can be mitigated very effectively.<br />
<br />
Developers regularly use the hosts file for configuring an IP address for a domain under testing. However, using the hosts file is cumbersome at times and can only be used to resolve domain name to an IP address. With a fully configurable DNS server running on your local machine, you can configure not just simple A records (for IP address) but, also configure other types of records like CNAME or MX etc. This allow you to have more control and power when you want to do testing that simulates the exact configuration that you have running on production.<br />
<br />
Technitium DNS Server is open source and available under <a href="https://github.com/TechnitiumSoftware/DnsServer/blob/master/LICENSE" target="_blank">GNU General Public Licence (GPL) v3</a> on <a href="https://github.com/TechnitiumSoftware/DnsServer" target="_blank">GitHub</a>.<br />
<br />
Comments and feedback are things that help push new features and improve usability, and thus are most welcome. Send your feedback to <a href="mailto:support@technitium.com">support@technitium.com</a> or write your comments below. Anonymousnoreply@blogger.com4Mumbai, Maharashtra, India19.0759837 72.87765590000003619.0759837 72.877655900000036 19.0759837 72.877655900000036