Opened 12 years ago

Closed 11 years ago

#33 closed defect (fixed)


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


My own experience with the IETF starts around the time of SPF and its various successors, nearly all of which use the DNS to store some variants of policy or key data, so this is a topic near and dear to most of my endeavors, and there are more coming.

A couple of other recommendations of my own:

  • Where the document enumerates requirements incompatible with the DNS, suggested alternatives might be wise to include, with some (perhaps brief, perhaps not) description of why/how the alternative is more appropriate.
  • The issue of detecting administrative boundaries in the DNS keeps reappearing. This might be good fodder for another document, since that topic plus that of the idea of "public suffix lists" has been recurring with increasing frequency.
  • IETF 80's training day included a session about how to go about extending the DNS by registering new types rather than overloading existing ones. Some of the material presented there might be useful to include here.

Change History (1)

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

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

Good comments, to the specific points:

1) We do hesitate here to make a concrete proposal about the alternatives to the pitfalls we enumerate, since that seems to be more the job of the community than the IAB. In general the intended remedy is not doing these things in the DNS, but instead reusing some existing application protocol or possibly inventing a new one. We do mention HTTP as a possible strawman, but we've had some pushback on that from other reviewers already since it really is nothing more than a strawman. Probably we will err on the side of leaving the potential remedies open.

2) Definitely agreed that the issue of administrative boundaries is tough, and something that merits more examination. We've already discussed the possibility of branching off a separate document to highlight some more general DNS issues that have come to light as a result of this effort - split horizon is another. Probably this discussion would live there.

3) Probably not likely that we'd refer to the presentation material directly, but certainly we should refer to the underlying RFCs that give that guidance.

Note: See TracTickets for help on using tickets.