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 (DoT) on port 853 (RFC 7858; frontend and backends)

  • DNS over HTTPS (DoH) on port 443 (RFC 8484; 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 (= reject)

  • queries without the RD bit are denied (= reject).

3.3 TTL, Cache

  • global TTL of 10s to 1h is enforced server-side

  • 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 1h 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

  • in case upstream servers for foreign zones are not answering, stale records are served

4. Operations

4.1 Troubleshooting

4.1 Clear DNS cache on DNS resolvers


    ssh node1.dns.bfh.info sudo kresctl cache clear .
    ssh node2.dns.bfh.info sudo kresctl cache clear .
    ssh node3.dns.bfh.info sudo kresctl cache clear .
    ssh node4.dns.bfh.info sudo kresctl 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

  • rebinding protection once it has been implemented to allow excluding subnets

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.