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

dns.bfh.info 2a07:6b40::10
ipv6.dns.bfh.info 2a07:6b40::10

2.2 Backend

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

node1.dns.bfh.info 2a07:6b40::11
node2.dns.bfh.info 2a07:6b40::12
node3.dns.bfh.info 2a07:6b40::13
node4.dns.bfh.info 2a07:6b40::14
dns.bfh.info 2a07:6b40::10
node1.proxy.dns.bfh.info 2a07:6b40::16
node2.proxy.dns.bfh.info 2a07:6b40::17
node3.proxy.dns.bfh.info 2a07:6b40::18
node4.proxy.dns.bfh.info 2a07:6b40::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, and 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. Backlog

4.1 Legacy

  • 2023: remove node{1,2}.dns.net.bfh.ch

4.2 Features

  • 2023: moving dnsdist webfrontend behind apache with ldap auth

  • 2023: restricting backend subnet access to frontend and management only

  • 2023: dynamic rate limiting

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

  • 2023: verify if using kresd http module is any good

  • 2023: anycasting dns.bfh.info instead of HA loadbalancing

  • ????: enable DNScrypt once it has been standardized

  • ????: benchmarking

4.3 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.