Technitium DNS Server is an open source authoritative as well as recursive DNS server that can be used for self hosting a DNS server for privacy & security. It works out-of-the-box with no or minimal configuration and provides a user friendly web console accessible using any modern web browser.
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 websites you visit even when you use a different DNS provider like Google DNS or Cloudflare DNS. Having Technitium DNS Server configured to use DNS-over-TLS, DNS-over-HTTPS, or DNS-over-QUIC encrypted DNS protocols with forwarders, these privacy & security issues can be mitigated very effectively.
Be it a home network or an organization's network, having a locally running DNS server gives you more insights into your network and helps to understand it better using the DNS logs and stats. It improves overall performance since most queries are served from the DNS cache making web sites load faster by not having to wait for frequent DNS resolutions. It also gives you an additional control over your network allowing you to block domain names network wide and also allows you to route your DNS traffic securely using encrypted DNS protocols.
The keymgr utility serves for manual key management in Knot DNS server.
Functions for DNSSEC keys and KASP (Key And Signature Policy) management are provided.
The DNSSEC and KASP configuration is stored in a so called KASP database. The database is backed by LMDB.
This utility sends Dynamic DNS update messages to a DNS server. Update content is read from a file (if the parameter filename is given) or from the standard input.
The format of updates is textual and is made up of commands. Every command is placed on the separate line of the input. Lines starting with a semicolon are comments and are not processed.
This program controls a running knotd process using a socket.
If an action is specified, it is performed and knotc exits, otherwise the program is executed in the interactive mode.
Knot DNS is a high-performance open-source DNS server. It implements only the authoritative domain name service. Knot DNS can reliably serve TLD domains as well as any other zones.
Knot DNS benefits from its multi-threaded and mostly lock-free implementation which allows it to scale well on SMP systems and operate non-stop even when adding or removing zones.
The server itself is accompanied by several utilities for general DNS operations or for maintaining the server.
For more info and downloads see www.knot-dns.cz.
Unbound is a validating, recursive, caching DNS resolver. It is designed to be fast and lean and incorporates modern features based on open standards.
dnsdist is a highly DNS-, DoS- and abuse-aware loadbalancer. Its goal in life is to route traffic to the best server, delivering top performance to legitimate users while shunting or blocking abusive traffic.
dnsdist is dynamic, its configuration language is Lua and it can be changed at runtime, and its statistics can be queried from a console-like interface or an HTTP API.
In 2010, it was an easy decision to use a commercial DNSSEC signer to deploy DNSSEC on APNIC’s reverse zones. Because much of the signer’s management was automated, we only had to worry about updating the parent delegation signer (DS) record separately.
So, even though we had to consider the scheduled Key Signing Key (KSK) rollover, updating the parent DS record on time was never an issue, since it would not roll-off the old key unless the new DS record had been updated in the parent zone.
In 2019, RFC 8624 (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) was released. The minimum recommended DNSKEY algorithm changed to RSASHA256, and there was a strong recommendation to use ECDSAP256SHA256 as it provides more cryptographic strength with a shorter signature length than either RSASHA256 or RSASHA512.
RSASHA1 was APNIC’s DNSKEY algorithm for almost 10 years, so the need to upgrade was it was inevitable. When it was time to upgrade, algorithm rollover was supported and well documented.
Following the recommendations in RFC 8624, we decided to migrate APNIC’s existing DNSKEY algorithm from RSASHA1 to ECDSAP256SHA256. The whole process took about a week to complete, without breaking the DNSSEC chain of trust.
Once we’d migrated, it was great to see the new (short) signatures from our zones.
What else could we ask for?
This document describes a method for automatic DNS zone provisioning among DNS primary and secondary nameservers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones.
Computer networks use the Domain Name System (DNS) to determine the IP address associated with a domain name. This process is also known as forward DNS resolution. Reverse DNS (rDNS) is the inverse process of this: the resolution of an IP address to its designated domain name. This document explains how reverse DNS works and how to configure it for your zone.
IPv4
One or more /24 type zones need to be created if your address space has a prefix length between /17 and /24. If your prefix length is between /16 and /9 you will have to request one or more delegations for /16 type zones.
For example, if you have been allocated 10.155.16.0/22, you need to create four reverse zones:
16.155.10.in-addr.arpa.
17.155.10.in-addr.arpa.
18.155.10.in-addr.arpa.
19.155.10.in-addr.arpa.IPv6
If you have been allocated an IPv6 block that is not on a nibble boundary, you will need to go down to the next nibble and create multiple zones to cover the entire block.
For example, an allocation such as 2001:db8::/29 will result in eight reverse zones of /32 each:
8.b.d.0.1.0.0.2.ip6.arpa.
9.b.d.0.1.0.0.2.ip6.arpa.
a.b.d.0.1.0.0.2.ip6.arpa.
b.b.d.0.1.0.0.2.ip6.arpa.
c.b.d.0.1.0.0.2.ip6.arpa.
d.b.d.0.1.0.0.2.ip6.arpa.
e.b.d.0.1.0.0.2.ip6.arpa.
f.b.d.0.1.0.0.2.ip6.arpa.Dnspython is a DNS toolkit for Python. It can be used for queries, zone transfers, dynamic updates, nameserver testing, and many other things.
Dnspython provides both high and low level access to the DNS. The high level classes perform queries for data of a given name, type, and class, and return an answer set. The low level classes allow direct manipulation of DNS zones, messages, names, and records. Almost all RR types are supported.
dnspython originated at Nominum where it was developed for testing DNS nameservers.
acme.sh --issue -d example.com --dns \
--yes-I-know-dns-manual-mode-enough-go-ahead-please
acme.sh --renew -d example.com \
--yes-I-know-dns-manual-mode-enough-go-ahead-pleaseSetting up and bootstrapping the zone catalog feature. The requierments are:
- a running knot dns server verion >= 3.0
- configured remote, acl and key sections for a primary/secondary zone transfer setup
Assumptions:
- nsp.domain.tld is the primary nameserver.
- ns1.domain.tld is the secondary nameserver
- There exist valid remote, acl and key configurations for this hosts on the other side
- special catalog zone is name "zone.catalog"
-
Create a zone template for the zones, which will be created on this zone catalog feature
- For the primary nameserver:
- id: "catalog-zone-template"
...
notify: ns1
acl: ns1
...- For the secondary nameserver:
- id: "catalog-zone-template"
...
notify: nsp
acl: nsp
... -
Create the special catalog zone for this feature
- For the primary nameserver:
zone:
- domain: "zone.catalog."
...
notify: ns1
acl: ns1
catalog-role: "interpret"
catalog-template: "catalog-zone-template"- For the secondary nameserver:
zone:
- domain: "zone.catalog."
...
notify: nsp
acl: nsp
catalog-role: "interpret"
catalog-template: "catalog-zone-template" -
Create the content for the special catalog zone. We need to have at least a SOA, NS and TXT resource record:
cat<<EOT | su -c "/usr/bin/knotc" knot
zone-begin zone.catalog
zone-set zone.catalog @ 60 NS nsp.REDACTED.DOM.
zone-set zone.catalog @ 60 SOA nsp.REDACTED.DOM. hostmaster.REDACTED.DOM. 1 16384 2048 1048576 2560
zone-set zone.catalog version 0 TXT "2"
zone-commit zone.catalog
EOT -
Create on the primary nameserver member zone in the special catalog zone.
- Create an unique id for the first member zone:
ZUID="id-$RANDOM-$RANDOM" # generate a random id string
# ZUID="id-$(pwgen -AB 8 1)" # or other method of generating a random id string- And create this zone with the knotc command as user knot:
NEWDOMAIN="my-first-domain.invalid"
cat<<EOT | su -c "/usr/bin/knotc" knot
zone-begin zone.catalog
zone-set zone.catalog id-${ZUID}.zones 0 IN PTR ${NEWDOMAIN%.}.
zone-commit zone.catalog
EOT- The easy thing to oversee is ".zones" part in the in the PTR resource record.
-
Last step: Setup the new domain content.
NEWDOMAIN="my-first-domain.invalid"
cat<<EOZ | su -c /usr/bin/knotc knot
zone-begin ${NEWDOMAIN%.}
zone-set ${NEWDOMAIN%.} @ 60 SOA nshp.REDACTED.DOM. hostmaster.REDACTED.DOM. 1 16384 2048 1048576 2560
zone-set ${NEWDOMAIN%.} @ 60 NS nshp.REDACTED.DOM.
zone-commit ${NEWDOMAIN%.}
EOZ -
Check this new domain content on your secondary nameserver:
NEWDOMAIN="my-first-domain.invalid"
su -c "/usr/bin/knotc zone-read ${NEWDOMAIN%.}." knot
If you’re into DNSSEC, you’ll probably have to troubleshoot or at least to verify it. While there are some good online tools such as DNSViz, there is also a command-line tool to test DNSSEC signatures onsite: delv.
This is an introductory howto to get DNSSEC running with BIND >=9.9 on Debian >=8 (jessie). We assume an "clean", freshly installed bind9 here.
This document provides introductory information on how DNSSEC works, how to configure BIND 9 to support some commonDNSSEC features, as well as some basic troubleshooting tips. The chapters are organized as such:
Chapter 1 covers the intended audience for this document, assumed background knowledge, and a basic introduction to
the topicof DNSSEC.
Chapter 2 covers various requirements that are needed before implementing DNSSEC, such as software
versions, hardwarecapacity, network requirements, and security changes.
Chapter 3 walks through setting up a validating resolver, more information on the validation process, as well as
examples ofusing tools to verify that the resolver is validating answers.
Chapter 4 walks through setting up a basic signed authoritative zone, explains the relationship with the parent zone,
and on-goingmaintenance tasks.
Chapter 5 provides some tips on how to analyze and diagnose DNSSEC-related problems.
Chapter 6 covers several topics, from key generation, key storage, key management, NSEC and NSEC3, to
disadvantages ofDNSSEC.
Chapter 7 provides several working examples of common solutions, with step-by-step details
DNS servers optionally log queries on demand by formatting a message and storing that in a file, sending it through syslog, etc. This is an I/O-intensive operation which can dramatically slow down busy servers, and the biggest issue is we get the query but not the associated response.
Automate all your cryptographic needs!
Goals
- Zero downtime
- Automatic certificate renewal
- Spam protection
- Updated DNS records
Configure once and always stay up to date.
Use cases
- Renew letsencrypt certicates
- Derive all kinds of data from the signature
- Ensure everything is secure
Knot DNS 2.1 introduced support for DNSSEC signing using PKCS #11. PKCS #11 (also called Cryptoki) is a standard interface to access various Hardware Security Modules (HSM). Such devices are usually used to improve protection of private key material. The interface is rather flexible and gives the HSM vendors huge amount of freedom, which unfortunately makes its use a bit tricky. There are often surprising differences between individual implementations.
Knot DNS is a high-performance authoritative-only DNS server which supports all key features of the modern domain name system.