coredns-rfc2136/tsig.go
Ryan Malloy 1d2d919728 Phase 1.4: UPDATE opcode handler + TSIG verification
Replaces the Phase-1.3 refuseUpdate() stub with a real RFC 2136 handler.
Caddy via caddy-dns/rfc2136 can now inject and remove records.

UPDATE message handling (update.go):
- Zone section validation: must be exactly one SOA-typed record naming
  a zone we're authoritative for. Returns FORMERR/NOTAUTH otherwise.
- Prerequisites (§3.2): name-exists, RRset-exists, name-NOT-exists,
  RRset-NOT-exists semantics implemented. First failure short-circuits
  with the spec's rcode (NXDOMAIN/NXRRSET/YXDOMAIN/YXRRSET).
- Updates (§3.4.2): add RR, delete RRset (CLASS=ANY+RDLEN=0), delete
  all RRsets at name (CLASS=ANY+TYPE=ANY), delete specific RR (CLASS=
  NONE).
- Apex SOA/NS protected: synthetic and cannot be added or removed via
  UPDATE. Apex wipe (TYPE=ANY at apex) also refused.
- Default TTL applied to incoming records with TTL=0.

TSIG (tsig.go + setup.go):
- setup() now populates dnsserver.Config.TsigSecret so the underlying
  dns.Server auto-verifies signatures via miekg/dns.
- checkTSIG() in ServeDNS gates UPDATEs: rejects if no TSIG, unknown
  key name, algorithm-downgrade attempt, or w.TsigStatus() != nil.
- No TSIG keys configured → all UPDATEs refused (safety default).
- Algorithm pinning prevents downgrade attacks (e.g. forced HMAC-MD5).

Tests (update_test.go): 11 new cases covering happy paths and every
error rcode. Total: 35 top-level test passes, 0 failures.

ServeDNS dispatch now calls handleUpdate after auth gate. The
refuseUpdate() stub is gone. UPDATE end-to-end via nsupdate requires
the custom CoreDNS image (Phase 2) to verify TSIG plumbing on the
dns.Server side.
2026-05-21 10:51:18 -06:00

68 lines
2.4 KiB
Go

package rfc2136
import (
"fmt"
"strings"
"github.com/miekg/dns"
)
// checkTSIG verifies that the incoming UPDATE message is properly signed
// with a TSIG key we know about. The actual signature math has already
// been done by the underlying dns.Server (because setup.go registered
// our keys in dnsserver.Config.TsigSecret); this function just inspects
// the result and the key identity.
//
// Behavior matrix:
//
// No TSIG keys configured → updates are unauthenticated. Caller may
// still allow if it deems the network safe;
// we conservatively reject (REFUSED) since
// the practical use case (Caddy) always
// signs.
// TSIG keys configured but message has no TSIG → reject.
// TSIG present, key name not in our map → reject.
// TSIG present, signature failed at dns.Server → reject (TsigStatus()).
// All good → nil.
func (p *RFC2136) checkTSIG(w dns.ResponseWriter, r *dns.Msg) error {
tsig := r.IsTsig()
if len(p.TSIGKeys) == 0 {
return fmt.Errorf("no TSIG keys configured; refusing all UPDATEs as a safety default")
}
if tsig == nil {
return fmt.Errorf("TSIG required but not present")
}
keyName := strings.ToLower(tsig.Hdr.Name)
if !strings.HasSuffix(keyName, ".") {
keyName += "."
}
key, known := p.TSIGKeys[keyName]
if !known {
return fmt.Errorf("unknown TSIG key %q", keyName)
}
// Algorithm pinning: the incoming TSIG can in theory use any
// algorithm miekg/dns supports, but we only honour the one declared
// in Corefile. Rejecting algorithm-downgrade attempts is a small
// but important hardening — without this, an attacker who somehow
// got a key could downgrade to HMAC-MD5 (which we don't even
// configure but miekg/dns understands).
if !strings.EqualFold(tsig.Algorithm, key.Algorithm) {
return fmt.Errorf("TSIG algorithm mismatch: incoming=%s expected=%s", tsig.Algorithm, key.Algorithm)
}
// The underlying dns.Server verifies the TSIG MAC for us when it
// has the secret in its TsigSecret map (which setup.go wires up).
// A nil from TsigStatus means verification succeeded; any non-nil
// error means the signature was invalid, the time was outside the
// fudge window, or some other auth failure.
if status := w.TsigStatus(); status != nil {
return fmt.Errorf("TSIG verification failed for key %q: %w", keyName, status)
}
return nil
}