Opened 12 years ago

Closed 10 years ago

#38 closed defect (fixed)

Comments on draft-iab-dns-applications-01

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

Description

From: "John Levine" <johnl@…>
To: ietf@…
Reply-to: johnl@…
Subject: Re: Comments surrounding draft-iab-dns-applications-01
X-RSN: 1/0/933/10054/56286

It's hard to make comments on a document whose mission is not at all
clear. The problem I have is that the document has a faulty baseline
and incorrectly assesses extensions and variations. ...


My experience with the DNS is nowhere near as deep as Ed's but having
done my share of DNS hackery (production special purpose DNS servers
written in perl), I have to agree with him. This document starts by
conflating the DNS and applications built on top of the DNS, and goes
downhill from there. I agree that there have been some pretty crufty
applications built on top of the DNS, but that cruftitude doesn't
affect the simple query and answer that the DNS does underneath.

The two points that do seem to apply to the DNS are, as Ed said,
larger responses and split horizon DNS. Both of those have been
around for at least a decade without causing the world to collapse,
and neither is going away, particularly as DNSSEC becomes real, so
I don't understand what problem is to be solved.

So my advice would be to back up and write down in one or two
sentences what problem this document is supposed to fix or at least
describe, and then see how much of the rest of it might be salvaged.

This might be also a good time to write a DNS architecture document
analogous to Dave Crocker's mail architecture, that shows the layering
of the queries to authoritative servers, queries to caches, and the
applications built on top of them such as locating mail servers and
doing whatever NAPTR and DDNS do.

Regards,
John Levine, johnl@…, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

Change History (3)

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

Definitely agreed that we need a better statement of purpose at the start of the draft, since from some of the reviews obviously people are seeing the draft as making statements its authors did not intend. I don't think the document conflates the DNS with the applications built on top of it, but it is very concerned to provide guidance to people building application architectures and protocols that use the DNS in ways that do not play to its strengths. One of the difficulties we've discovered as we've gone down this path is that the distinction between using the DNS and extending the DNS isn't always so easy to draw, and that because of the extensibility properties of the DNS some usages have profound architectural consequences. You can argue, for example, that the cruftitude does not affect the underlying protocols, but what about when the cruftitude tries to add security features like authentication to the DNS, and tries to do so using open extensibility mechanisms like eDNS0 query extensions? We will try to get a better problem statement up front in the doc.

This document does not argue against using split horizon - the section on private DNS acknowledges its existence, and although it questions the proprietary of standardizing split horizon, but certainly acknowledges that split horizon deployments satisfy the requirements they set out to. Similarly, there are obviously large DNS responses in the world that are not bringing the Internet to its knees - however, I'm not sure that we've completely resolved the question of how to prevent large DNS responses from participating in amplification DDoS attacks. The existence of these things in the wild does not necessarily elevate them above architectural consideration, and we will be trying to make the problem statements here more clear.

Ultimately, we do agree that a document discussing the general DNS issues of split horizon would be useful, and there's some will to start that project in the IAB now. We do think that would be separate from the current dns-applications document, which is really directed more at the applications community than the DNS community.

Thanks!

comment:2 Changed 11 years ago by johnl@…

The new version is better, but it still has significant problems.

I would suggest restructuring it to start by saying what characteristics
make an application suitable for the DNS, based on the material in section
4, then perhaps reuse some of the rants to illustrate applications that do
or don't match those characteristics.

Some of the advice is clearly right, e.g., encoding part of the query or the
cache client's IP as an EDNS option is a terrible idea. Some strikes me as
myopic, e.g., the complaint in 3.2 about leaf zones wantting to populate
information in a parent makes unwarranted assumptions about the ways that zones
are or can be managed. Or in 3.3.1, the large data genie is out of the bottle with
DNSSEC, and it looks silly to tell people not to do what DNSSEC already does.
Some strikes me as just wrong, e.g. 3.4 saying that every dot should be an
administrative delgation point (or if that's not what they mean, they need
to rewrite it to say what they mean.)

So even though it's better, it's still nowhere near ready to publish.

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

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

Based on John's later and more favorable comments about the much-changed -05, closing this ticket.

Note: See TracTickets for help on using tickets.