[dnsext] conclusions drawn in draft-wang-dns-inconsis-ncache-00

[Alfred Hönes <ah@TR-Sys.de>]

The recent I-D, draft-wang-dns-inconsis-ncache-00,
proposes a significant re-interpretation of DNS caching behavior.

I seriously doubt that the conclusions drawn in Section 4 of that
draft are compatible with the DNS architecture.

1)  The DNS is a *loosely* coupled distributed database.
    There's no guarantee of instantaneous consistency at large
    between authoritative servers, recursive resolvers, and
    potential local (stub) caches.

2)  Tolerant behavior when facing inconsistencies has always been
    a major target of DNS protocol specifiations and its
    implementations.

3)  Authoritative servers are responsible for resolving temporary
    inconsistencies over time, not resolvers.

4)  TTL is the basic mechanism to resolve inconsistencies in caches
    over time.  Zone administrators have to decide under operational
    considerations which TTL values to publish, and in doing so,
    they enter into some kind of contract with the potential clients
    to undertake efforts to maintain the correctness of RRsets for
    the duration of their TTL.
    That's why important change processes in zones should be started
    with reducing relevant TTL values to an amount of time that can
    be guaranteed for the old and new content to be valid.  That's
    "make before break" as a paradigm for good zone administration.

5)  Whenever an authoritative server hands out an RRset to a resolver
    (end system or caching recursive resolver), it equally enters
    into a contract with its client stating that the authoritative
    answer is to be regarded as valid for this client, for the TTL
    value(s) reported in the answer.
    A recursive caching resolver similarly enters into a contract
    with its clients when it hands out the (remaining) TTL values
    for RRsets.

6)  There's no mechanism in DNS to "revoke" such contracts.
    Cached RRsets remain valid for the remaining TTL.
    RFC 1035 explicitely mentions only TTL expiry as a reason to
    purge cache entries.

    You can enter into a new "contract negotiation" by asking an
    authority again but that does not immediately invalidate
    previous "contracts".

Therefore, IMHO the correct method for dealing with apparent
inconsistencies is to let each RRset time out independently and
apply the "most specific answer first" principle for cache lookup.

In the example in the draft, a cache has unexpired entries for

  (1)  www.example.com  IN  A     NODATA
  (2)  www.example.com  IN  AAAA  4321:0:1:2:3:4:567:89ab

and later receives on a q=MX query:

  (3)  www.example.com  IN  NXDOMAIN

In this case (assuming all validity checks passed), (3) is to be
used to construct the answer to the stub resolver whose query had
triggered the outbound q=MX query, and if the negative answer is
cacheable (as per RFC 2308), (3) is to be cached as well,
independently, and will be used to answer queries for any QTYPE
(and CLASS=IN) for the given QNAME, with the exception of those
that can be matched with (1) and (2), i.e. QTYPE=A and QTYPE=AAAA
-- until these cache entries expire.

(IIRC, during the FR debate last year it had even be proposed to
apply a more stringent caching paradigm, which would cause using
cached answer (3) _only_ for answering future queries for the same
(q=MX, CLASS=IN, QNAME) tuple.)

This strategy also seems to be important from a security and
resilience point of view:
Letting NXDOMAIN responses expunge existing cache entries would
make such reponses much more valuable vehicles for cache poisoning
attacks, and it would increase the potential damage resulting from
(temporal) operational/administrative errors.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+