Opened 12 years ago

Closed 10 years ago

#15 closed defect (fixed)

Sections 4.3.1 and 5

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

Description


From: Eliot Lear lear@…
Sent: Friday, October 22, 2010 5:26 AM
To: Olaf M. Kolkman; jon.peterson@…; Hannes Tschofenig; Bernard Aboba
Cc: Murray S. Kucherawy; Dave Crocker; J.D. Falk
Subject: commens on draft-iab-dns-applications-00

Hi Jon, Hannes, Oalf, and Bernard,

This draft is timely, because it relates to a problem that has been on
the minds of those of us who have worked on DKIM and ADSP. I like most
of the text as far as it goes, but I see two specific issues with the
draft, both relating to §4.3.1 and §5.

One of the key issues we had with DKIM and ADSP, and one that has become
a deployment barrier, is this matter of administrative structure.
Enterprises may have many thousands of hosts, all of which really should
have an ADSP policy associated with them. To do this today in DNS would
require a record per host. There are two reasons for this- the first is
that TXT records were used, and the use of a wildcard combined with TXT
is not advisable, because of the impact this could have on other
applications, assuming we even got it right for DKIM/ADSP. Given the
inability to use wildcards, the next thing we would want to do is state
a policy for a zone. Unfortunately, even if one could state a policy
for a zone, finding the zone cut is something of a problem in itself,
requiring a backwards among labels, in search for either a specific
record like SOA or NS, followed by a query for a specific record (be it
another TXT encoded record or a new RR). This has its own limitations
from a performance standpoint, and we got quite a lot of guff in
discussions around this some time back from the DNS community, where I
think I heard echos of Paul Vixie saying “[DNS] are not the droids
you're looking for.” You called this out when you wrote:

Trying to establish domain boundaries within the tree - the
delegation point in the DNS is something that applications should
in general not be aware off

It would certainly be helpful to understand why you are providing this
advice. Perhaps it's for the above reasons. Perhaps you did and I
missed it. Perhaps, however, it exposes an opportunity to improve the DNS.

This leads me to the second issue relating to this draft. When Fred
Baker, Ralph Droms and I did RFC 4192, we provided specific guidance in
§4 for future work to the IETF because we believed, and I believe, that
there is room for improvement within the Internet Architecture. I
believe this draft could benefit from a similar section from people who
Really Ought To Know where that work should be done. Who better to
write such work than DNS experts?

Editorial Nit:

In §5 2nd para, 2nd list item:

Answers are only depended on the question (name and type), not on

---

Change to:

v

Answers only depended on the question (name and type), not on

the location or identity of the entity doing the query

Thanks for your contributions and leadership on this issue,

Eliot

Change History (4)

comment:1 Changed 12 years ago by bernard_aboba@…

  • Component changed from dns-applications to draft-iab-dns-applications

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

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

responded to author, adding text to reflect DKIM experience with inferring zone cuts and expanding surrounding text to clarify motivation

comment:3 Changed 11 years ago by bernard_aboba@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

There is something still troubling in the current draft, albeit by
degrees. It has always bothered me that a zone cut could not be
determined, traversing toward the root. The DNS folk think this is a
feature. To enterprises, it's a major nightmare, and IMHO, contributing
to the limited deployment of protocols such as ADSP. Having to restate
a policy on EVERY record may indeed be necessary under the current
architecture, but that doesn't make that aspect of the architecture the
best thing since sliced bread.

Anyway, make what you will of that comment...

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

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

We now allude to this nightmare in the draft in more detail, for example to the "publicsuffix" problem of figuring out the scope of cookies.

Note: See TracTickets for help on using tickets.