How-To
Services
Internal
Historical
External Tools
After frequent issues with the Old Hierarchical DNS system in early 2018, work has started to build a new and more reliable DNS system. The main goals are:
It is strongly recommended to run your own resolver for security and privacy reasons. Setting it up and maintaining it should be easy, see services/dns/Configuration.
If running your own resolver is not possible or undesirable, you can choose one or more instances from dns/recursive-servers.dn42 in the registry. Please make sure you fully understand the consequences and fully trust these operators.
You can also use the globally anycasted a.recursive-servers.dn42 but you won't have any control over which instance you get. This is a very bad idea from a security standpoint.
The new DNS system has two different components:
These are simple resolvers capable of resolving dn42 domains. Every operator gets a single letter name pointing to addresses assigned from their own address space and is strongly encouraged to use anycasting across multiple nodes to improve reliability. There is also the global anycast a.recursive-servers.dn42 which includes some/all other instances. Whether an *.recursive-servers.dn42 can resolve clearnet queries or not is decided by its operator but all a.recursive-servers.dn42 instances MUST resolve clearnet queries correctly. It is explicitely not supported to use clearnet nservers for dn42 zones and dn42 nservers for clearnet zones.
These are simple authoritative servers for the dn42 zone, rDNS and a few DNS infrastruture zones. Every operator gets a single letter name pointing to addresses assigned from thier own address space and is strongly encouraged to use anycasting across multiple nodes to improve reliability. There is no anycast instance because that would make debugging much harder and *.recursive-servers.dn42 instances should do loadbalancing/failover across all instances listed in the registry.
These instances do not serve any clients. They poll the registry regularly and rebuild and resign (DNSSEC) the zones as needed. If any zone changes, all *.delegation-servers.dn42 instances are notified (RFC1996) which then load the new zone data over AXFR (RFC5936). The pool of masters is intentionally kept very small because of its much higher coordination needs and also the lacking support of a multi-master mode in many authoritative server implementations. The masters are only reachable over dedicated IPv6 assignments which are set up in a way that any master operator can hijack the address of a problematic master without having to wait for its operator to fix something.
burble is providing monitoring for the new DNS system. It does simple checks on all instances every minute and also logs all changes into #dn42-dns@hackint.
Also, gatuno provides another simple dns checker for all the top level domains in the registry. If you want to check whatever a domain is resolving or not, this tool may be useful. The tool gets in sync with the registry every 12 hours. You can schedule checks for any domain.
There are currently two KSKs managed by BURBLE-MNT and JRB0001-MNT. They are used once per quarter to sign the DNSKEY RRset. Each master operator has one ZSK which is used to sign the zones (except for the DNSKEY RRset). This setup leads to bigger responses but allows each KSK holder to solve emergencies independently. The signatures of the DNSKEY RRset are valid until the end of the first month of the next quarter to give enough time for coordinating the next siging. All other signatures are valid for 3 days and replaced at least once per day.
The set of valid KSKs can be found in the registry.
Hosted by: BURBLE-MNT, GRMML-MNT, XUU-MNT, JAN-MNT, LARE-MNT, SARU-MNT, ANDROW-MNT, MARK22K-MNT | Accessible via: dn42, dn42.dev, dn42.eu, wiki.dn42.us, dn42.de (IPv6-only), dn42.cc (wiki-ng), dn42.wiki, dn42.pp.ua, dn42.obl.ong
Last edited by lare, 2023-04-08 21:53:12