DNS service

1. About

The Domain Name System (DNS) is the naming system used to identify computers reachable through the network. It maps human-friendly domain names to the numerical IP addresses computers need to locate each other.

Note: The DNS service consists of recursive resolvers only, for authoritative nameserver see NS service instead.

2. Systems

2.1 Frontend

FQDN IPv6 IPv4
dns.bfh.info 2a07:6b40::10 147.87.0.10
ipv6.dns.bfh.info 2a07:6b40::10
ipv4.dns.bfh.info 147.87.0.10

2.2 Backend

Warning
Always use the frontend IP address

Never use the backend nodes directly:

  • backend may change without notice at any time (e.g. IP addresses, DNS records, configuration, etc.)
  • backend has no legacy support or grace periods, changes are implemented instantly
  • backend can be rebootet without notice at any time
  • backend access will soon be restricted

FQDN IPv6 IPv4
node1.dns.bfh.info 2a07:6b40::11 147.87.0.11
node2.dns.bfh.info 2a07:6b40::12 147.87.0.12
node3.dns.bfh.info 2a07:6b40::13 147.87.0.13
node4.dns.bfh.info 2a07:6b40::14 147.87.0.14
FQDN IPv6 IPv4
dns.bfh.info 2a07:6b40::10 147.87.0.10
node1.proxy.dns.bfh.info 2a07:6b40::16 147.87.0.16
node2.proxy.dns.bfh.info 2a07:6b40::17 147.87.0.17
node3.proxy.dns.bfh.info 2a07:6b40::18 147.87.0.18
node4.proxy.dns.bfh.info 2a07:6b40::19 147.87.0.19

3. Features

3.1 Protocols

  • DNS (UDP/TCP) on port 53 (frontend and backends)

  • DNS over TLS on port 853 (frontend and backends)

  • DNS over HTTPS on port 443 (frontend and backends)

3.2 ACLs

  • queries are accepted from 2a07:6b40::/29, 147.87.0.0/16 and 10.0.0.0/8 only, everything else is denied (!= drop)

3.3 TTL, Cache

  • global TTL of 1m is enforced server-side (caveat see #127 and #736)

  • queries to frontend are not cached on purpose

  • queries to frontend for own zones (that have no CNAMEs) are not cached on purpose and directly stub-forwarded to NS servers

  • queries to backend for own zones are not cached on purpose and directly forwarded to NS servers

  • queries for expiring and frequent records are automatically prefetched

  • cached (round-robin) records are answered with randomized order of records to workaround “dumb” clients

3.4 Forwarding

  • forwarded queries to resolver backends are hashed to get answers for same records from one backend cache

  • forwarded queries to authoritative backend are based on least outstanding connection count

3.5 Static hints

  • Microsoft Active Directory at BFH unfortunately is named bfh.ch instead of e.g. ad.bfh.ch, hence static hints are used to let bfh.ch internally resolv to AD instead of the bfh.ch-Homepage

  • all static hints have a TTL of 1m configured

3.6 Details

  • both frontend and backends use SO_REUSEADDR and SO_REUSEPORT

  • backends use QNAME minimization

  • backends do DNSSEC validation, i.e. query to zones with invalid signatures will return empty answers with SERVFAIL

4. Operations

4.1 Troubleshooting

4.1 Clear DNS cache on DNS resolvers


    ssh node1.dns.bfh.info sudo kresd-cache-clear
    ssh node2.dns.bfh.info sudo kresd-cache-clear
    ssh node3.dns.bfh.info sudo kresd-cache-clear
    ssh node4.dns.bfh.info sudo kresd-cache-clear
  

4.2 Statistics

4.2.1 Console statistics


    ssh dns.bfh.info

    sudo dnsdist-console
    > showServers()
    > dumpStats()
    > showBinds()
    > getPool('dns.bfh.info'):getCache():printStats()
  

4.2.2 Webserver statistics

4.3 BEnet

FQDN IPv6 IPv4 Zones
ns1.net.be.ch 2a07:2904:fff0:2f00::6:1 10.251.201.4
  • be.ch, 251.10.in-addr.arpa
  • bedag.ch, 144.159.in-addr.arpa
ns2.net.be.ch 2a07:2904:fff0:2f00::6:2 10.251.201.6
  • be.ch, 251.10.in-addr.arpa
  • bedag.ch, 144.159.in-addr.arpa
ns3.net.be.ch 2a07:2904:fff0:1403::1:3 10.251.10.21
  • be.ch, 251.10.in-addr.arpa
  • bedag.ch, 144.159.in-addr.arpa
FQDN IPv6 IPv4 Zones
hsbsr020-dc1.sap-hsb.infra.be.ch 10.252.43.20
  • sap-hsb.infra.be.ch, 43.252.10.in-addr.arpa
  • 42.252.10.in-addr.arpa
hsbsr020-dc2.sap-hsb.infra.be.ch 10.252.43.21
  • sap-hsb.infra.be.ch, 43.252.10.in-addr.arpa
  • 42.252.10.in-addr.arpa

6. Backlog

Legacy

  • remove node{1,2}.dns.net.bfh.ch [after Cisco]

  • regenerate containers with Debian 12

  • upgrade to current knot-resolver/dnsdist

  • also forward 172.16.0.0/12 from knot-resolvers to knots

Setup

  • moving dnsdist webfrontend behind apache with ldap auth

  • restricting backend subnet access to frontend and management only

  • dynamic rate limiting

  • review hints und redirect configs

  • document dnssec validation and how to (temporarily) disable it

  • move other disastery-recovery methods currently placed in the config to some document

  • KeyTrap Vulnerability

  • automatically trigger kresd config updates when pushing to ns repositories

  • add priming hints so that local zones are forwarded when there’s no internet connectivity

Features

  • hyperlocal root zone deployment

  • kresd cache prefill module

  • verify if using redis as a central cache for all knot-resolver instances is a good idea

  • verify if using kresd http module is any good

  • anycasting dns.bfh.info instead of HA loadbalancing

  • enable DNScrypt once it has been standardized

  • test environment

  • benchmarking

Known issues

  • upstream: enforce artifically lowered TTL to clients consistently for all queries (#127, #736 for kresd; SetMaxTTLResponseAction for dnsdist)

  • upstream: dnsdist does not support forward, only stub-resolving queries send to backends. For answers with CNAMEs, the records are not resolved to A/AAAA records. Therefore sending queries for own zones that have CNAMEs not to the authoritiative servers but to the resolvers.

  • downstream: when priming fails due to loss of internet connection, local forwards don’t work either, needs evaluation of super priming vs local root.