Subject: [dnsext] Working on a WK record as a replacement for URI (and SRV)

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 18 Jan 2013 12:35:17 -0500

At the moment, discovery is a mess. We currently use:

* Well known ports (not scalable to current needs)
* SRV (does not work well for Web services)
* URI (not currently used)
* SRV + TXT (used in bonjour)
* NAPTR (is meta-discovery, not service discovery, involves regular
expressions)

After discussions with Patrik I now realize that URI has almost all the
functionality I would like to have in a discovery scheme except for being
able to express policy statements such as the minimum protocol version a
protocol supports, the security enhancements required (TLS, IPSEC, CMS,
WS-*, etc.)

This led me to the following as the ideal format of DNS entry to describe a
service entry:

_omnibroker._wk.example.com WK 1 1 https://w1.example.com/
_omnibroker._wk.example.com WK 1 1
https://old.example.com<https://w1.example.com/>
/ "max=1"
_omnibroker._wk.example.com WK 1 1
https://new.example.com<https://w1.example.com/>
/ "min=2.0"
_omnibroker._wk.example.com WK 1 1 coap://w4.example.com<http://w1.example.com/>
/ "ipsec"

The first entry is semantically equivalent to the current URI record. It
tells us where we can find the service but nothing more. Note that since
the target URI is https we effectively get a 'must use TLS' policy
statement.

The second and third entries show a protocol version transition in
progress. The site has deployed services that support the v1 and v2 of the
protocol but these are on two separate machines. Expressing this
information in the same DNS record where we declare the service endpoint is
by far the least error prone approach for administrators.

The fourth illustrates offering coap as an alternative to http transport.

So far we have only seen Web Service type examples where the application is
layered onto the transport using HTTP or the like. That probably accounts
for 95% or more of the protocols being designed today. But we can if
necessary support a direct IP binding easily enough by introducing an IP
URI as follows:

ip:tcp:evil.example.com;666

That is a direct tcp transport to port 666 on evil.example.com

So the question for this group here is whether making the policy field
optional in the presentation format of the record is going to be
acceptable. I know that there are existing records with optional fields. In
fact there are records with much more complex syntaxes.

-- 
Website: http://hallambaker.com/

---

From: Tony Finch <[email-masked]>
Date: Fri, 18 Jan 2013 18:27:35 +0000

Phillip Hallam-Baker <[email-masked]> wrote:
> acceptable. I know that there are existing records with optional fields.
> In fact there are records with much more complex syntaxes.

It's a bad idea since it makes it harder to use generic parsing /
serializing code (and it's bad for John Levine's dnsextlang project).
I believe the existing RR types that have optional fields are all obsolete:
ISDN, NSAP, A6.

Best to keep it as simple as possible.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 18 Jan 2013 16:10:49 -0500

At first I thought about the NAPTR record which needs an empty string ("") to signify no regex (and a default domain of . after that field in some cases).  But then I thought - what about the TXT record?  That allows for as many strings as desired, each up to 256 octets long, up to the max length that can be in RDATALEN.

Not saying that NAPTR or TXT is right for the job, just looking at them for the precedent of optional strings.

On Jan 18, 2013, at 13:27, Tony Finch wrote:

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

From: Doug Barton <[email-masked]>
Date: Fri, 18 Jan 2013 19:40:06 -0800

> * SRV (does not work well for Web services)

Can you elaborate, or provide a reference?

Doug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 22 Jan 2013 09:21:45 -0500

OK so looks like the optional policy string is not a good idea. At least as
far as the normal form goes.

> Can you elaborate, or provide a reference?

The problem with SRV and Web services is that a typical Web Server
deployment supports multiple Web Services, some of which are only going to
be called maybe five times a day, if that. So the Web Services actually
make use of the stem part of the URI to identify the location on the Web
Server.

So to use SRV to announce a Web Service you need some way to specify the
location on the Web Server. One approach is to specify a .well-known
location for the service but that is rather less flexible than many
deployments will accept and it stops a server having two different versions
of the same protocol running in parallel - something you are very likely to
want to do if you are witching between protocol versions or implementation
versions.

---

From: Tony Finch <[email-masked]>
Date: Wed, 23 Jan 2013 11:40:19 +0000

Edward Lewis <[email-masked]> wrote:

> At first I thought about the NAPTR record which needs an empty string
> ("") to signify no regex (and a default domain of . after that field in
> some cases).  But then I thought - what about the TXT record?  That
> allows for as many strings as desired, each up to 256 octets long, up to
> the max length that can be in RDATALEN.

Yes, TXT is a bit special, but there is already code to support it, and
the same layout is used by SPF records, and it's likely that there will be
more RRtypes along those lines. HIP records also have a multiple field
(the list of rendezvous servers) but it has other features that prevent it
from being handled with generic code, specifically detaching the length
fields from the data they cover.

The ideal for new RRtypes is to use only subfield types which are
already used by other RRtypes, and ensure the presentation format and wire
format are in the same order.

Tony.