Subject: RE: SRV records considered dubious (was: Re: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Nov 2006 08:11:29 -0800

> From: Keith Moore [mailto:[email-masked]] 

> > We are currently seeing an explosion of new protocol 
> development using 
> > Web Services. It is long past time to declare UDDI a failure and 
> > recognize that it isn't going to happen. But Web Services are 
> > predicated on the existence of a signaling infrastructure.
> 
> if SRV works well for Web Services, fine, but that doesn't 
> mean SRV is appropriate for everything.  and as far as I can 
> tell, DNS is poorly suited to be an application signaling 
> infrastructure.

I don't expect there to be very many standards based protocols in the future that are not Web Services. 

Angle brackets are now as inescapable as ASCII was twenty years ago. The only real design choice is whether to layer on SOAP and WS-* or to layer directly onto HTTP and SSL.

The point here is not to 'use DNS' but to 'involve DNS'. We are agreed that you certainly do not want to put every possible piece of protocol configuration data into the DNS. This is particularly the case in Business 2 Business Web services where you want a really strong bilateral connection and thus a 'fat handshake' is really appropriate (think the purchasing dept of Ford Motor Co talking to TRW).

The point is that if you use a DNS Domain Name as the index you want to use the DNS as part of the distribution mechanism. In simple cases this may be call by value but in cases with more than 64 bytes worth of complexity you really need to think about call by reference.

Storing pointers to policy in the DNS means that the DNS remains the one authoritative source for DNS information.

There are three levels of policy

1) Trivial 'I always sign with DKIM'

	We could put a pointer to the policy distribution in the DNS but the policy is essentially only a boolean.

2) Complex Static 'I support WREURF 1.2 through 2.4.3, I support WREURF 1.0 through 1.1.2 on a deprecated basis and will withdraw support on 2006-12-25, you must use AES-256 with SHA-3242b...'

	We could define an escape mechanism to encode several kb in the DNS but this would be a bad idea. I think that SPF is more complex than I would like to see policy for in DNS but not objectionably so.

	Write an XML document describing the policy, put the link to the policy in the DNS. This has the additional benefit that the policy can be updated without reference to the DNS.

3) Complex Dynamic/Context Dependent 'Alice can use protocol X, Bob can use protocol Y'

	This level of policy is certainly desirable but the DNS is certainly not the protocol to use whether on the same port or a different one.

	Write a Web Service and put a pointer to the service in the DNS.

The point about using the DNS to distribute the location information is that it ensures that when example.com changes hands that ALL the services associated with example.com do as well.

Using prefixed policy and SRV records rather than host names is important because what we care about is the services not the hosts that happen to be supporting them at one point in time.

The hosts will change, possibly dynamically. The services the hosts provide are persistent.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Nov 2006 12:54:31 -0500

> future that are not Web Services.

I've seen lots of fads come and go, and so far I've seen nothing to
convince me that Web Services is not yet another fad.  Time will tell.

> Angle brackets are now as inescapable as ASCII was twenty years ago.

Only for people who can't actually evaluate the consequences of protocol
design decisions at the presentation layer.

Admittedly, some things do get chosen by evolution.  We have 
power-of-two word sizes now, and all hardware these days has to deal 
reasonably efficiently with eight-bit bytes.  That's because these were 
found to work well over several decades of experience.  But there are 
lots of reasons to avoid representing all data in a format that requires 
all of that data to be examined looking for delimiters, sometimes 
multiple times, by every machine that touches it.

> The point is that if you use a DNS Domain Name as the index you want
> to use the DNS as part of the distribution mechanism.

The point is that the distributed information store that we currently 
know as DNS is separable from the protocol that we call DNS, and we can 
(if we are careful) design a new protocol that will let us access that 
information store more flexibly while still keeping the views consistent 
between the DNS protocol and the new protocol.

> Storing pointers to policy in the DNS means that the DNS remains the
> one authoritative source for DNS information.

This seems to presume that DKIM signing policy is DNS information.  It's 
not, at least not inherently so.

Keith

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Nov 2006 10:13:02 -0800

Keith Moore wrote:
> reasonably efficiently with eight-bit bytes.  That's because these 
> were found to work well over several decades of experience.  But there 
> are lots of reasons to avoid representing all data in a format that 
> requires all of that data to be examined looking for delimiters, 
> sometimes multiple times, by every machine that touches it.
>
> know as DNS is separable from the protocol that we call DNS, and we 
> can (if we are careful) design a new protocol that will let us access 
> that information store more flexibly while still keeping the views 
> consistent between the DNS protocol and the new protocol.
Sure, but is the trust anchor that DNS more importantly provides? On today's
internet with all of the vested interests could the devil we don't know 
possibly
be any better than the one we do? I can imagine the only reasonable name for
a working group that attempts that is BLACKHELICOPTERS.

       Mike

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Nov 2006 13:35:41 -0500

>> The point is that the distributed information store that we 
>> currently know as DNS is separable from the protocol that we call 
>> DNS, and we can (if we are careful) design a new protocol that will
>>  let us access that information store more flexibly while still 
>> keeping the views consistent between the DNS protocol and the new 
>> protocol.

> Sure, but is the trust anchor that DNS more importantly provides? On 
> today's internet with all of the vested interests could the devil we 
> don't know possibly be any better than the one we do?

so we shouldn't try to improve the Internet at all for fear that it
might end up being worse than what we have?

I'll offer a different point of view - the Internet is constantly being
degraded by those "vested interests" and also suffering from limitations
of its original design.  If intelligent, conscientious people aren't
continually contributing to its evolution in an open forum, the devil
that we do know will get worse and worse.

> I can imagine the only reasonable name for a working group that
> attempts that is BLACKHELICOPTERS.

random paranoia doesn't impress me.  if you have a specific threat you 
want to discuss, by all means bring it up - though maybe you'd want to 
wait for an actual proposal before trying to model the threats?

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Nov 2006 13:35:41 -0500

Keith