Zum Hauptinhalt springen

2. Regeln (Rules)

Wenn ein iterativer caching DNS-Resolver ein NXDOMAIN empfängt, SOLLTE (SHOULD) er es in seinem Cache speichern, und dann SOLLTEN (SHOULD) alle Namen und Ressourcendatensatzgruppen (RRsets) auf oder unterhalb dieses Knotens als unerreichbar betrachtet werden. Nachfolgende Anfragen für solche Namen SOLLTEN (SHOULD) sofort mit NXDOMAIN beantwortet werden.

When an iterative caching DNS resolver receives an NXDOMAIN, it SHOULD store it in its cache and then all names and resource record sets (RRsets) at or below that node SHOULD be considered unreachable. Subsequent queries for such names SHOULD be answered with NXDOMAIN immediately.

Wenn ein Resolver jedoch eine NXDOMAIN-Antwort erhält und einen Cache-Eintrag für einen Namen unterhalb dieses Namens hat, der auf eine andere Quelle verweist (z. B. eine lokale Datei wie /etc/hosts oder ein anderes "statisches" Mapping), MUSS (MUST) er den Cache-Eintrag behalten und die NXDOMAIN-Information für diesen spezifischen Namen ignorieren. Dies erlaubt es Administratoren, lokale Überschreibungen zu definieren.

However, if a resolver receives a NXDOMAIN response and has a cache entry for a name below that name that points to a different source (e.g., a local file such as /etc/hosts or another "static" mapping), it MUST keep the cache entry and ignore the NXDOMAIN information for that specific name. This allows administrators to define local overrides.

Aber wenn die NXDOMAIN-Antwort DNSSEC-signiert und validiert ist, dann ist sie vertrauenswürdiger als jeder lokale Cache-Eintrag (es sei denn, der lokale Eintrag ist auch DNSSEC-validiert oder stammt aus einer vertrauenswürdigen Quelle, die DNSSEC überschreibt).

But if the NXDOMAIN response is DNSSEC-signed and validated, then it is more trustworthy than any local cache entry (unless the local entry is also DNSSEC-validated or comes from a trusted source that overrides DNSSEC).