Opened 10 years ago

Closed 10 years ago

#210 closed defect (fixed)

Comments regarding draft-iab-dns-applications-05

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


To whom it may concern,

I have read this draft and have a number of serious concerns and comments.

At a high level, I think periodic reflection on how we use and evolve the
Internet's core systems and protocols is very healthy. However, in doing
these reflections, I think it is important to remember a couple of things:
1 - The Internet has continued to be a valuable staple in our lives, in
large part, because of its flexibility and our ability to adapt its form
and function to our ever changing needs.
2 - Those protocols that have endured the longest offer great evolutionary
lessons (the mere fact that they have endured suggests a robustness
against the Internet's tumultuous setting), but we should be very
circumspect in drawing deep conclusions from shallow, or overly specific
examples. Such optimism can teach the wrong lessons if the motivating
observation space is too small.

These two comments underlie the specific concerns I have with the draft:

High Level:
The authors seem to unfold a theme that the DNS is not an appropriate
place for some set of innovation and application behavior that has been
pushed (or is being pushed) into it. However, many of their supporting
examples seem to be either refutable, such as: DNS does not have some
features (when it already does), or some of the features it has are not
good (but they exist and are useful and not causing any cited harm), or
that it should not be extended because a specific example was overly
complicated. Overall, the authors make a number of good points about
ENUM, but fail to motivate that the shortcomings in this work teach
lessons as broad as they claim. In fact, the lessons they outline seem
detrimental in that they range from not well thought out, to overly
reactive, to cases where they seem reactionary (especially the treatise
about EDNS0 and reflector attacks). Section 3.2.1 raises some very
serious concerns, and I have commented about them specifically, below.

It seems that if the authors were to just detail the problems they
experienced with ENUM, the results could be ingested and interpreted by
engineers. The prescriptive nature of this work suggests that its
findings should be better justified and they should not be refutable by
existing best practices if they are going to be stated as mandates.


s/have raised questions/have caused us to raise questions here/

The abstract is presuming facts that are not in evidence yet. As such, I
think it's fair to claim concern here, but less fair to claim the
existence of some broader un-cited concern.

Section 1:

  • 3rd paragraph: w.r.t. confidentiality: what about split horizon and private DNS (which is mentioned later in the draft)? These common examples that are considered critical by many DNS users seem to refute this claim.
  • 3rd para: wrt to no authentication mechanism, what about TSIG and SIG(0)? Again, the existence of these examples refutes the claim being made.
  • 3rd para: In regards to security only being applied after a resolved service is contacted, this seems to be much more by consequence than by design. That is, applications _could_ do this ahead of time. Perhaps this document could outline that security facilities available in DNS should be applied (instead of claiming that there is a deficiency where there does not appear to be one)?

Section 2.1:

  • 1st para: I think the authors might be taking too narrow of a view of DNS' role. The service location function it provides (for MX, SRV, or whatever) actually underscores that it is a _mapping_substrate_. That is, it decouples the name from the functionality of a resource, and provides a critical layer of indirection. This is critically different than a naming convention. A naming convention (such as the cited, implicitly defines name, cardinality, role, etc. A mapping service makes all of these (and more) dynamic. I think this mischaracterization exemplifies a number of the problems in this draft. To quote Butler Lampson, Any problem in computer science can be solved with another level of indirection... Indeed, DNS' mapping is a level of indirection, a naming convention is not.
  • 3rd para: The authors call the reliance on MX records a convenience, but (re: the above comment), I think this is much more a mandate of indirection.

Section 2.3:

  • 3rd para: To be fair, it seems important to also recognize (in addition to the reasons cited) that DKIM chose to put keys into DNS because mail delivery required the DNS mapping substrate to begin with lookups there anyway. This not only reduces the systemic dependencies over any other approach that would add new system elements to ensure this lookup, but also (correspondingly) reduces the overall attack surface.

Section 3:

  • 1st para: The authors emphasize that many of the innovations described in the preceding section did describe departures from name to IP mapping. However, they fail to also note that these changes still befit a name mapping substrate, and that many of the cited changes constitute vital components of today's DNS, and that they have not been shown to be detrimental to the DNS.
  • 2nd para: Regarding authentication and ACLs, filtering based on key (such as TSIG) is possible in modern name servers, like BIND.
  • 2nd para: The authors introduce very strange notions that DNS is going to need to support complex relational queries. This is a huge leap that is not supported by examples or conventional wisdom. There are, in fact, many types of database beyond RDBMSes, and a database does not necessarily need to be relational (DNS is actually not the only example of this). The authors' claim that applications will consider DNS to be a general DB, and _therefore_ will try to augment its design with relational queries seems a lot like fud. Proposals to do this would simply not fly, but it is false logic to expect to see such proposals just because we treat DNS as a generic name mapping substrate.
  • 2nd para: The authors go on to claim that treating DNS as a general purpose database will mean that we have to deal with questions about the structure. Once again, the authors are making bold assertions without supporting evidence. Why would this necessarily be the case? The causal relationship implied by the text seems quite reactionary. Any fundamental alteration to [DNS'] model. would be subject to working group review. This is where each instance ought to be addressed. Making a blanket restriction on innovation is much more detrimental than examining changes as the requirements of the Internet evolve.
  • 2nd para: This text actually outlines the overall claims of this document (this document concludes), and certainly at this point, none of the claims are supported. Moreover, it's not clear how well they actually map to today's Internet.
  • 2nd para: The final sentence is entirely too broad.

Section 3.1:

  • 1st para: The text seems oddly non-specific about DNS information. Is this software versions, number of name servers per zone, etc?

s/DNS information/DNS RRsets/

  • 1st para: The text asserts a very purist view of DNS, regarding _all_ RRsets being _globally_ uniquely identified by <name, type, class>. However, today we can see a great many businesses and users that rely on exceptions to this. One example is geo-loadbalancing. The authors use the word traditional, and it's not clear to the reader if this is meant to excuse or indict common behaviors like geo-loadbalancing.
  • 1st para: The authors introduce two terms without defining them, and then hang much of their remaining arguments on them: compound, and relational search. It is not clear what these terms mean, or if they are even exemplified by any modern usage of DNS. As a result of the omitted definition, it is not clear if these are even detrimental. The remainder of this review will try to presume their meaning.
  • 2nd para: The authors mention that some applications may need to make multiple queries. It is not clear why this is so bad (especially for the global DNS, instead of specific applications that use it).
  • 2nd para: The conclusion of this paragraph seems to be far too general for this draft. Based on the supporting text, it seems a reasonable indictment of ENUM, but not as a general review of all applications that may use the DNS in remotely similar ways.
  • 3rd para: The authors seem to be using EDNS0 as a negative example, in some way. They claim that it requires changes to both name servers and resolvers (true), but fail to acknowledge that it is incrementally deployable, and that is has existed as a standard for many years, and has a high level of deployment today. It is not at all clear why the authors frame it in such a negative light (as it is critical to many accepted applications of DNS, including DNSSEC).
  • 3rd para: The authors go on to claim that the ENDS0 OPT records must never be forwarded, but it's (again) not clear why this is framed in such a negative tone.
  • 3rd para: The authors (again) use, compound queries, without defining the term.
  • 3rd para: The authors next claim that EDNS0 is only intended to, discriminate actual DNS data rather than to facilitate transport layer handling. This calls into question the relevance of these statements as it is patently false. EDNS0 OPT records include (among other fields) the senders UDP payload size field that specifically negotiates the transport buffer sizes of both the resolver and the name server. This really calls into question the relevance of these opinions when their supporting discussions so flatly mischaracterizes common elements of DNS. Moreover, even if this were true, it's not clear to the reader what would be so alarming about that.
  • 3rd para: Why does this discussion of ENDS0 result in a recommendation _not_to_use_it_? This seems completely unclear, counter to many existing uses of DNS, and unmotivated.
  • 4th para: This whole paragraph seems quite alarmist. It is, again, espousing opinions that do not seem to be supported by the preceding text. It ignores commonly used DNS techniques (like geo-loadbalancing), it outlines a failure mode that would really only affect a candidate application, it would be immediately visible to that application's engineers, and it would not affect other applications and infrastructure (name servers and resolvers) if it were unsuccessful. It's not clear if the authors are trying to say that they don't want non-working applications to be standards (agreed), or they are saying that innovation should be squelched by overly draconian mandates (disagree).

Section 3.1.1:

  • 1st para: In this paragraph, the authors attempt to draw a distinction between using an IP to discriminate DNS answers, and using (basically) any other information in the same way. This distinction seems very artificial in the text. It does not seem like there should be a distinction here, and the authors very much fail to motivate anything to the contrary.
  • 1st para: The authors try to support their claim with the statement that using IP addresses to discriminate is ok because what could the harm be, and they cite a web portal. As proof by contradiction: what if that web portal allows access to government information to remote countries, should we not provide defense in depth because it does not seem palatable? The whole discussion seems a little forced.
  • 1st para: This paragraph directly violates the advice espoused in the covering section (3.1) by suggesting a use for EDNS0. Specifically, a draft for client subnet information in EDNS0 is cited.
  • 1st para: The authors make a flatly false statement at the end of this paragraph claiming that this technology is of no utility until it is both bilaterally and ubiquitously deployed. In fact, the former is true (bilateral deployment is a prerequisite), but it can be incrementally deployed. For example, that's why the root servers can serve responses to queries regardless of whether the queries have OPT records. Again, it is this type of mischaracterization of existing work that undermines the relevance and reported insights of this work's findings.
  • 2nd para: This whole discussion of split horizon: 1) comes after the authors original claims that applications needing private DNS data should not be allowed, and 2) proves (through its existence) that these uses are in the mainstream already. Are the authors proposing to legislate a rollback of functionality?
  • 3rd para: This paragraph seems to take a very narrow view of DNS (in general). DNS is, among other things, a wireline protocol. The existence of the technologies described in this paragraph refutes its own statements. It's expected that, in the Internet's heterogeneous deployment environment, not all software is implemented the same. If nothing else, there is legacy software, not to mention custom appliances (like RBLs) that use the existing infrastructure and perform application-specific semantics at the leafs.
  • 3rd para: The goal of full feature parity betrays a strong disconnect with certain operational realities in the Internet. You cannot have a flag day for software, so whenever _any_change_ is rolled out you will be w/o full feature parity. This fundamental misalignment between the statements in this paragraph and common operational practices suggests a further disconnect between this document and its goal to provide general guidance to all DNS applications.

Section 3.2:

  • 1st para: The authors describe certain limitations in DNS. These all make sense, but the statement that DNS, therefore, does not fit all applications seems a little obvious. What is the goal of this paragraph? These limitations would be clear as soon as an application developer tried to violate them, and any attempt at standardization would allow the working group to explain this.

Section 3.2.1:
This section contains some very loose, underspecified, and in some cases
incorrect characterizations of DNS reflector/amplification attacks. There
are detailed comments below, but I think this level of discussion and
these erroneous comments are dangerous as their advice is not supported by
the claims, and many of the claims are not correct.

  • 1st para: The comment the DNS will (eventually) resort to TCP is not always true. s/will/MAY/. Dropped packets do not always trigger a TCP fallback, and TCP is not the mandated fallback by the EDNS0 RFC (2671).
  • 2nd para:

s/in which the attacker sends DNS/in which the attacker sends UDP only


  • 2nd para: This paragraph does not seem to add anything constructive to the document, and seems very alarmist. The notion that EDNS0 needs to be feared because of amplification attacks is fud. Avoiding EDNS0 causes many more problems than it may solve, and does not address reflector attacks, it just changes their amplification factor. That is not a sufficient change to warrant cutting off DNS' nose to spite its face.
  • 4th para: Having a discussion about amplification attacks and their damages just to raise alarm seems irresponsible. Why not talk about remediation and the role of infrastructure providers in combatting the attacks instead/in addition? As written, this level of alarmism greatly detracts from the work, as it casts it in a very irresponsible light.
  • 5th para: This paragraph is dangerous, and should be removed. The idea that a statement that is issued by the IAB would prescribe an artificial/uninformed hard limit on the ratio between request size and answer based solely on fud and loose intuition is quite alarming. Not only is this false limit going to affect all traffic (if implemented), but it doesn't even address the reported problem. It most likely will hurt non-attack traffic more than attack traffic. Many similar problems were foreseen and occurred when people artificially limited their EDNS0 response sizes from their name servers, to avoid fragmentation. The result was unnecessary truncations and server artifacts, and (as with this) it didn't even address the real problem.
  • 6th para: Here, the authors reflect on their own earlier advice about minimizing amplification. They then go on to admit that they do not (and cannot) know what limits to set (after mandating that there should be limits). This, again, betrays a level of naivety and suggests that the findings (themselves) should be viewed with the highest level of skepticism.

Section 3.3:

  • 2nd para: The authors claim that large data sets and values could mean that the tried and true AXFR and IXFR mechanisms will no longer suffice in the future. However, the authors do not support these concerns with any numbers or even any specific intuition. Their concerns (as stated) seem (again) to be far too bold, especially considering that we have been using AXFR and IXFR at various TLDs for years.
  • 3rd para: Based on the fact that the reason .com is only about 100M zones is because it does not host any SLDs, the conclusion of this paragraph seems to have missed an important point. There is a configuration/management tradeoff here. DNS is perfectly able to scale and support this type of behavior, and the tradeoffs are left to operators. As the text reads, it seems to ignore these facts and reads a little too heavy on the opinion side.
  • 6th para: The authors' discussion about address portability doesn't seem to support their arguments. Based on the fact that we already have PI addresses now, why is their example a counter point?
  • 6th para: Also, the authors' point seems too reactionary (again). What's the problem if clients have trouble with bad assumptions?

Section 3.3.1:
This whole section just seems to be a referendum on why ENUM has issues.
I know the authors are using a strawman to illustrate a point, but it
reads as being extremely specific to _just_ ENUM. I was not able to see
these as generic lessons, at all.

  • 1st para; delegative is not a word.

Section 3.4:

  • 1st para: I would claim DNS redirection is done through CNAMEs and DNAMEs. The indirection of SRVs is more application level.
  • 2nd para: This paragraph seems alarmist again. The authors claim that it is not possible to securely implement redirection in DNS, and then add that you _could_ use DNSSEC. In fact, this is exactly what DNSSEC can do for you by securing both the target and the CNAME target. If someone doesn't deploy a security protection that is available, that's their operational decision. This reads more like there is no option.
  • 2nd para: The authors contrast the DNSSEC case with using HTTPS, but don't cite corresponding failures in that model (like DigiNotr?, sslstripping, etc.). Either they should address DNSSEC as the operationally viable option that it is, or impugn each approach equally (though it's clear that the former is better option).
  • 3rd para: Rather than start off by saying that other approaches exist in the absence of DNSSEC (since it is an operational reality and should be deployed by these sorts of zones), the authors should embrace the conventional wisdom (not rebuff it). Say something more like: DNSSEC protects zones but if a zone admin/operator does not deploy it, the some secondary measures may exist.
  • 4th para: This paragraph is (again) way too generalized and not supported by the examples.
  • 4th para: I did not see where all of these app-level measures were attempting to mirror the delegation of administration. I don't think the apps seemed to care who ran .com, or how many delegations existed, etc. This text has been talking about content, not provisioning.
  • 4th para: The discusion about certificates and delegations was very confusing. Is this the CERT RR type? If so, what does that have to do with delegations? Based on the text, it is not at all clear why changing a delegation point would require a change in a cert. The cert has a CN for the name, not the delegation. Is the name changing, or the delegation, or something else? I think this text does not make sense.
  • 4th para: With the root/.com/.net/.org and about 100 other TLDs having deployed DNSSEC, is it _so_ hard to imagine that a zone can deploy DNSSEC to protect itself now? Why is there such a strong anti-DNSSEC sentiment here?

Section 4:

  • 3rd para:

s/The most complex/Some/

  • 5th para: Separating queries and trees is different that calling a protocol proprietary. That is, if all of my multi-vendor queries stay internal to my network, I still may want a multi-vendor, standards based, system. This is a conflation in the text. Standards exist for many reasons (Internet protocols can exist in intranets). Moreover, if these are not disruptive to existing DNS usage, what's the problem with standardizing them?
  • 5th para: Citation needed for leaking.
  • 6th para: The suffix discussion seems far too alarmist. If applications (or even just configurations, as in the case of the example), apply a suffix to queries and get back responses they don't expect, so what? 1) This is just a naming change, not an extension. 2) this only impacts the poorly configured clients and no one else. Why does this prompt us to want to legislate something?

Section 5:
This section tries to digest what has been discussed into general
principles and guidance. Specific comments are below, but at a high-
level, these do not have nearly enough support in the preceding text to be
made into general principles and guidance. At best, they are lessons
learned from (mostly) just one protocol extension attempt (ENUM). While
the lessons that can be learned from that work may have broad
implications, these items are not at all supported by it, and they have
(as written) the potential to cause harm to future innovation _and_
current operations.

  • 1st para: The DNS is _not_ loosely coherent. If nothing else, the existence and wide-scale deployment of geo-loadbalancing and split horizon prove the negative here.
  • 3rd para: Why would we legislate that data being propagated and cached must follow any specific semantics? This is what dnsext is for (reviewing changes). Again, geo-loadbalancing is a counterexample to this para.
  • 4th para [Data indexed]: Not supported by examples. Currently data is indexed by _at_least_ <name, type, value> (and sometimes more). Where is this coming from, and why is it here as a general rule?
  • 5th para [complete names]: Again, this is not supported by examples. It seems (at best) the text has shown that this may not always be a good idea. There's no indication in the examples that this should be generalized.
  • 6th para [answering by app layer ID]: Again, why is this being generalized? There are already-deployed counter examples in this draft (geo-loadbalancing).
  • 7th para [Communicate with the domain name queried]: The SRV example, illustrated in this draft, refutes this. That example has a domain name under map to a name under This is common today (and thus necessary, by implication).
  • 9th para [Populating metadata]: This text seems far too prescriptive. How do we know what applications will need, and why does putting metadata _specifically_for_those_applications_ in the DNS hurt anyone else? If this is meant to be a helpful suggestion, then perhaps it should just outline some of the problems that might happen, but reserve judgement, or refrain from giving generic advice.
  • 10th para [semantics/admin]: The motivation for this statement seems unclear. Also, it seems to be stated so broadly that it's not very clear what it's getting at (on its own). We just got a requirement not to rely on the administrative model of the DNS tree, and now it seems we're being told that we have to?
  • 10th para:

s/share a semantics or administrative/share semantics or an


  • 11th para [confidentiality]: We already have this in today's DNS. Why would be choose to outlaw it here?
  • 12th para [EDNS0]: This advice seems very inappropriate, is not supported by the examples in the text, and is dangerous advice that will almost certainly have negative impacts on DNS' necessary evolution. The claims by the authors that this advice will, in any way, help reflective amplification attacks are baseless. Moreover, any remediation should be per-site configuration, not enshrined here for everyone, and remediation for those attacks is beyond the scope of what innovation is appropriate for DNS. This is a harsh conflation of separate considerations that has the potential to cause palpable harm.
  • 13th para: First sentence: Why are they better? How do we define this or measure it?
  • 13th para: Second sentence: This is not true (as stated); DNS is a mapping substrate and required by many application transactions. HTTP is not designed to be a mapping substrate, so you are proposing to overload HTTP with the job DNS was designed for, and you are (thereby) adding new systemic dependencies to all Internet applications, and adding corresponding attack surface area.
  • 13th para: 4th sentence: DNS has these too.
  • 13th para: 5th sentence: but DNS is the only global mapping substrate that is operationally deployed, and in use today.
  • 14th para: Counter example: if I require mapping, why not use the de facto mapping substrate of the Internet?

Section 6:

  • 1st para: Again, the EDNS0 advice seems quite wrong, and very dangerous.
  • 2nd para: The use of TSIG and SIG(0) seem to overcome some the reported limitations.



Change History (1)

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

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

Responded to these comments (October 21, 2012) and implemented fixes in the -06. Also later comments from Danny helped to clarify some of these issues and a lot of the text surrounding EDNS0 and amplification attacks has been accordingly softened. Hopefully this helps.

Note: See TracTickets for help on using tickets.