[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dnsext] Re:conclusions drawn in draft-wang-dns-inconsis-ncache-00
[ Moderators note: Post was moderated, either because it was posted by
a non-subscriber, or because it was over 20K.
With the massive amount of spam, it is easy to miss and therefore
delete relevant posts by non-subscribers.
Please fix your subscription addresses. ]
Thank you for your insightful comments, but I do not think my views really touch
the fundamental part of the DNS specifications.
I agree with you that DNS is a loosely coupled distributed database and
instantaneous consistency is generally impossible. However, one of the basic goals
of DNS architecture design is to minimize the data inconsistency. That is,
recursive resolvers, and stub resolvers should try to maintain strong consistency
with authoritative servers. As a tradeoff between consistency degree and incurred
cost, TTL based cache mechanism is currently used. The only ¡°contract¡± hold by
recursive resolvers is that the record MUST NOT be used after the TTL (as Mark
Andrews said), which poses no limitation on dropping or substituting records
before the TTL expires.
Although inconsistency arises not only in the negative caching, the negative
caching does introduce fresh scenarios. This proposal is simply a call for
attention to the varied inconsistency scenarios and their related solutions.
Best regards
In your mail:
>From: Alfred HÎnes <ah@TR-Sys.de>
>Reply-To:
>To: wangzheng@cnnic.cn
>Subject: conclusions drawn in draft-wang-dns-inconsis-ncache-00
>Date:Tue, 3 Nov 2009 16:05:27 +0100 (MEZ)
>
>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 |
> +------------------------+--------------------------------------------+
>
>
------------------------------
Zheng Wang
CNNIC Labs
_________________________________________________________
China Internet Network Information Center
Phone: (8610)-58813212
Fax: (8610)-58812666-123
Email: wangzheng@cnnic.cn
Address: 4, South 4th Street, Zhongguancun
Haidian District, Beijing
P.R.China 100190
________________________________________