Subject: [dnsext] Enhanced Discovery and Optimization

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 10 Nov 2010 15:11:22 -0500

Two of the issues that came up at the meeting last night were the URI
proposal and the performance optimization proposal aimed at eliminating the
need for dual A/AAAA lookups.

I suggest that these two issues are actually linked and that it is
counterproductive to try to unlink them. Most engineering tasks are best
approached by reduction and modular approaches. Security and optimization
are the exceptions. If you want efficiency you have to consider the whole
system.

I think that what we need to do is to get the discovery system understood
first and then look at how to optimize. In particular we need to consider
what the API presented to the applications is going to look like.

The traditional sockets approach was to call gethostbyname and then plug the
IP address returned into the open () call.

A much better approach in my view is to start by looking at an object
oriented language and see what the most abstract API we would use in that
context would look like. Then look at ways of mapping the data needed to
service that query to a DNS 'super-request'.

At an abstract level, I want a discovery system in which I have an
'InternetClient' object that exposes the following options for starting a
connection:

Open (string domain, integer port)
Open (string domain, string service)
Open (string domain, string service, integer port)
Retry ()

So to make an HTTP connection a client would present:

Open ("example.com", "_http._tcp", 80)

If (and it is a big if) we need to optimize the communication between the
client and the resolver, I would give the client the ability to tell the
resolver what the parameters it was presented with were and then have the
resolver perform however many queries were required to perform discovery.

Some important design constraints that flow from this approach are:

1) The discovery process must be standard across all protocols.
2) The discovery process cannot involve processing of regular expressions or
other matching rules.

Amongst the issues raised on the URI draft were:

1) What about the problems of using prefixes (CNAME, wildcards)
2) How does it relate to other discovery schemes (SRV, NAPTR, UNAPTR etc.)
3) Should it use the same prefix registry?
4) Web services use HTTP URIs which may employ SRV (or NAPTR) discovery,
which governs?

Introducing a meta-discovery mechanism such as ESRV allows all of these
issues to be dealt with in a coherent fashion.

The first ESRV lookup would be for an unprefixed record. At the end of that
first lookup we are guaranteed to be dealing with a canonical name and can
use prefixes without the problems caused by aliasing and/or wildcards.

The first ESRV lookup can either give us all the meta discovery information
we need or tell us the range extended discovery options that are supported.

So for example, the maps service at example.com might be configured as
follows:

$ORIGIN example.com
maps       CNAME example.com
.          ESRV disc prefix
_maps._ws  ESRV disc srv
_maps._ws  ESRV disc uri
_maps._ws  ESRV tls required
_maps._ws  SRV  1 1 443 host1.example.com
_maps._ws  SRV  1 1 443 host2.example.com
_maps._ws  URI  1 1 443 https://host1.example.com/_wks/_ws/_maps/
_maps._ws  URI  1 1 443 https://host2.example.com/_wks/_ws/_maps/
host1      A  10.1.1.1
host2      A  10.1.1.2
host2      AAAA .....

Here we have a configuration file that advertises two equivalent means of
discovering the maps service. The application can choose to use either SRV
or URI discovery. The results should be the same. The result will also be
the same regardless of whether the client attempts to resolve for
example.com or www.example.com.

I think that it is pretty clear that in this example, the client does not
want to be performing meta-discovery to resolve the URL in the URI method.
These should be canonical just like every other right hand side in a DNS
file.

It is also clear from this example that the prefix space should apply to all
extended discovery mechanisms, SRV, URI, NAPTR, etc. It should be one space
and belong to the ESRV level.

Now returning to the performance issue. Let us consider how we might tweak
this at the resolver level.

Without some form of super-query, the client rather than the resolver is
doing the discovery complexity. That has a performance impact but more
significantly has a functionality impact. It is not possible to deploy a
clever new discovery scheme by tweaking the discovery implementation in the
resolver.

If on the other hand, the client could ask something like

MESRV  _maps._ws.example.com

The resolver can break the query down according to decidable rules and
collect up all the information that the client requires in one big answer.

OK so we get a performance boost. But that is not the real payoff, the real
advantage is functional, the resolver can introduce support for extended
discovery beyond SRV, URI, etc. For example we could have discovery that
takes geographic location into account or directs account based services
according to the account.

This is only possible if the resolver is not required to keep track of which
protocol uses which discovery mechanism.

This approach also plays nice with administration considerations. If I have
a large infrastructure with hundreds of Web services, I can authorize
individual Web services to update their specific domain name and no other.

The enhanced discovery mechanism can be used to deliver detail at
progressive levels of granularity - domain - service - service-host.

This need not cause excessive numbers of queries however since all the
records at the service and service-host level can be presumed to be
relevant. So the client can ask for all the records at the node rather than
specific RR types.

-- 
Website: http://hallambaker.com/
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext