Opened 12 years ago

Closed 10 years ago

#13 closed defect (fixed)


Reported by: ran.atkinson@… Owned by: jon.peterson@…
Priority: major Milestone: milestone1
Component: draft-iab-dns-applications Version: 1.0
Severity: Active WG Document Keywords:

Description (last modified by bernard_aboba@…)

From: Ran Atkinson ran.atkinson@…
Sent: Tuesday, October 19, 2010 6:15 AM
To: Olaf Kolkmann; jon.peterson@…; Hannes.Tschofenig@…; Bernard Aboba
Cc: Randall Atkinson
Subject: draft-iab-dns-applications-00



The citation of [rfc3401] and the expansion of the "DDDS"
acronym both really need to be moved forward -- to the
very first time the acronym is used. I read about 8 pages
into this I-D before the acronym was explained and the
reference was provided.

Technical, on page 16, use of the DNS when either

  • more than 2 queries might be required to one's answer,

or * the data are "highly volatile"
or * the answers are "Location- or Identitity-dependent"

appears to be discouraged.

I think I must somehow be misreading your words or
at least misunderstanding your intended meaning in
Section 5.

Operational experience (including some DNS experiments)
indicate that none of those 3 properties are necessarily
problematic for the DNS.

Virtually all DNS queries are "identity based" in that they
seek data associated with some specific identity (i.e.
DNS FQDN used in the DNS query). Even PTR lookups,
which don't use the FQDN in the query, arguably are
identity-based in that the IP address is commonly
(if erroneously) used as an identifier.

Access to many large content providers today already requires
multiple DNS queries. Purely as an example, a web site whose
content is distributed from Akamai typically has ~3 levels of
indirection (e.g. CNAME records), and then finally an A record
(which is the datum required by a web browser). 554 IN CNAME 255 IN CNAME 255 IN CNAME 95 IN A

Note also that all 4 of these DNS records are "highly volatile",
having a time to live value under 5 minutes. Folks at Akamai
also tell me that those answers are also highly "Location-dependent".
That is, different queries for the same target from different
locations within the Internet (queries sent at the same time)
will receive different answers.

There is also a well-known MIT trace-driven simulation study indicating
that DNS caching (other than NS records and the A records associated
with closer-to-the-root or root DNS name servers) is largely ineffective.
In turn, this means that "highly volatile" answers (e.g. data having
short DNS TTL values so that the served value might be changed rapidly)
are not problematic.

"DNS Performance and the Effectiveness of Caching"

  1. Jung, E. Sit, H. Balakrishnan, & R. Morris ACM/IEEE Transactions on Networking, Vol. 10 No. 5 October 2002, ISSN 1063-6692.

Beyond that, there is recent experimental validation of the above paper.
The experimental results indicate that DNS caching actually works less well
than the above paper predicted. The most accessible reference to this work
(for the moment) likely is via the recent NANOG Lightning Talk by Prof Bhatti
at U. St Andrews, Scotland. I understand that a more formal academic paper
is being prepared. This speaks to both "highly volatile" data and
identity-dependent data being quite suitable for DNS deployment.


So I would hope that Section 5 (page 16) of your I-D would be
revised and clarified. These two references that I just mentioned
seem like they might also be suitable for addition as Informational
references. A broader search of the academic/research literature
might also be helpful. I realise that DNS experimental work is a
bit scarce these days, but there is a bit out there if one digs around.


Change History (5)

comment:1 Changed 12 years ago by bernard_aboba@…

  • Component changed from dns-applications to draft-iab-dns-applications
  • Description modified (diff)

comment:2 Changed 12 years ago by jon.peterson@…

  • Resolution set to fixed
  • Status changed from new to closed

responded to author, fixing nits and expanding section 5 bullets to try to reflect more specific principles, as the existing bullets are overly broad and don't really speak to principles exemplified by the preceding text.

comment:3 Changed 11 years ago by bernard_aboba@…

  • Description modified (diff)
  • Resolution fixed deleted
  • Status changed from closed to reopened

While my comments are partly resolved, I am afraid that at least one
of the attempted resolutions is very confusing to me. In particular,
I have no idea what this phrase (from Page 17 of the latest I-D) means:

"Highly volatile data that synchronizes with the

state of applications external to the DNS"

Perhaps the above means this ?

"Highly volatile application-layer data that depends

upon the state of applications other than the DNS"

I also find the phrase just prior to that quote very confusing,

(perhaps because it isn't obvious to me that confidentiality is
EVER a property provided by the DNS), where the second confusing
phrase (also page 17 of the current I-D) is:

"The sensitivity of the data, especially preserving its

confidentiality from unauthorized queries in a multilateral


Would it be accurate to rewrite the above as this ?

"Confidentiality of data stored in & provided by the DNS"

or perhaps something like this ?

"Selective confidentiality of data stored in & provided by the DNS"

In parallel with the above items of confusion, and for the avoidance

of doubt in readers of your document, I would be appreciative if the
document would note clearly and explicitly that (edit to taste):

"Nothing in this document is intended to discourage either the

implementation, deployment, or use of Secure DNS Dynamic Updates

[RFC-2136,RFC-3007] to the DNS system, DNS Security [RFC-4033, RFC4034,

and RFC-4035], or the use of Secure DNS Dynamic Updates in combination

with DNS Security."

Thank you very much.


Ran Atkinson

comment:4 Changed 11 years ago by jon.peterson@…

Good comments, definitely taking the last two recommended text fives more or less as given. As for the first, "highly volatile" has been a problem since we started the doc - really, all of these points of guidance have been placeholder text. As we're getting the rest of the doc into better shape, we hope to rip a lot of these out soon and replace them with more specific recommendations. You're definitely correct to be squinting at these, though.

comment:5 Changed 10 years ago by jon.peterson@…

  • Resolution set to fixed
  • Status changed from reopened to closed

The guidance text is much changed from this revision, and now makes considerably more narrow statements. The guidance on DNSSEC is hopefully now unambiguous as well.

Note: See TracTickets for help on using tickets.