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

[Mark Andrews <marka@isc.org>]

In message <200911031505.QAA20276@TR-Sys.de>, Alfred =?hp-roman8?B?SM5uZXM=?= w
rites:
> 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.

A cache is free to use other critera to expire records.  The only
requirement is that the record MUST NOT be used after the TTL
expires.
 
>     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.

No, GLUE address records regularly get replaced by NXDOMAINs from the
zone.

> (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                     |
> +------------------------+--------------------------------------------+
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org