Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

[Niall O'Reilly <[e-mail]>]

On 27/02/11 20:08, Patrik Fältström wrote:
> There are a few things I think makes this discussion hard...and that
> is that the overall usability is a requirement in the usability,
> manageability etc while what we talk about is "only" what we do in
> DNS. What we should (and can) do in DNS must then match whatever
> application layer/protocol behaviour, which in turn depends on how
> the protocol works.

	Or, should we look at the use cases at a higher level,
	and identify which components, including (but not limited to)
	the DNS, need to be adjusted to achieve the desired result?

	In this case, the question becomes no longer one of matching
	the DNS to how the other components actually work, but to
	how they will work in the future to support a coherent, rather
	than a fragmented, "aliasing" concept.

	I'm pretty sure that solving "the aliasing problem", whatever
	it is, cannot be done by adjusting only the DNS.

> What I *think* could be interesting is one of these things as very
> high level issues to look at, that btw I think sort of is written in the
> draft, but using DNS terminology ;-)

	I'm not sure quite what you're saying.

	Expressing higher-level issues in DNS terminology can either
	help us to visualize those issues, or blind us to the non-DNS
	aspects;  perhaps both of these effects occur at the same time.

> 1. Aliases
> 
> 1.1. If we today have two delegations, we do have a risk that one of
> the delegations changes holder while the other does not. Can one of the
> two be an alias to the other, and the two then bundled by policy in the
> registry so we absolutely know one and only one holder controls the data
> for the names (plural)?
> 
> 1.2. If we today have two delegations, synchronization of the two
> delegations imply provisioning systems must place the same records in
> two zones. Can we solve the problem in different ways?

	I believe that this is one strong attraction of the BNAME
	concept.  Performing pseudo-delegation in parallel with
	traditional delegation in the parent zone leaves the
	registrant/deleg[at]ee with just a canonical instance of
	the child zone to look after.  But this only applies when
	there is a common (bundle of) parent zone(s).  So, it would
	work for example[+/-final_sigma+/-tonos].gr, but not for the
	vixie.sf.ca.us/vix.com bundle mentioned in Paul's slides of
	almost a year ago.  That this is so is not intrinsically
	problematic, as the motivations are different in each case.
	In the .gr (also .cn, IIUC) case, the motivation appears (to
	me) to arise from a desire on the part of the TLD registry to
	provide a coherent offering to customers (registrants) in
	support of what might be called "naturally arising" bundles.
	Paul's example is rather "bottom-up" than "top-down", and
	is driven by the customer rather than by the provider (or the
	provider's politico-regulatory circumstances).

> 2. Support of more application layer aliases

	More in terms of quantity, or just "more coherent"?

> 2.1. In HTTP and a few other protocols, we have the ability to do a
> redirect inside the application layer protocol itself. We do not have
> that in all protocols. In other we have things like the MX records. Do
> we with IDN etc need more of these, and do we need a mechanism in DNS
> that "help" such redirect in a "lower" layer in the resolution algorithm?

	SMTP has MX; others have SRV; HTTP is an outlier in that it
	avoids this kind of assistance from the DNS.  It's a significant
	and pathological outlier because of the way HTTPS works.

> 2.2. When using HTTP HOST header, and SSL where the DN of the cert
> is matched with the domain name used, it is kind of problematic to match
> the application layer with what originally was entered by the user. Is
> there some need for DNS layer aliases that changes what later is matched
> in the application layer comparisons?

	2.3 (?)
	It may be worth examining the semantics of distinct, but
	seductively similar, elements in different URL schemes.

	For example, in the "mailto:" URL scheme, there is a "domain
	part" which is essentially a reference to a naming authority.
	In contrast, the "http:" scheme uses a superficially similar
	component strictly as a reference to a host.  This is arguably
	an incoherence at the semantic level between the different URL
	schemes which, if resolved, could eliminate the difficulty
	which arises today from matching the DN of the cert to the
	"host" component of a URL whose scheme is "http:".

	I'm suggesting that this incoherence should be resolved by
	having the application exploit already available DNS
	mechanisms.  New DNS-layer aliasing seems to be un-necessary.

	Re-writing the definition of the "http" URL scheme so that
	not only

		'http' ':' '//' host [: port] '/' ...

	but also

		'http' ':' '//' domain-part '/' ...

	would be allowed, might lead to a resolution based on SRV
	records.

	I suggest that this approach is worth following, and will be
	no more painful than transitions we have already chosen (or been
	forced) to face, as between A and MX, or between A and AAAA
	records.  If we want the omelette, we can't insist on not
	breaking the eggs.

	With this approach the DN of the SSL cert would match the
	target host of each SRV record.

> 3. Comparison algorithm
> 
> 3.1. We can not change the matching algorithm in DNS
> 
> 3.2. Given we can not change the matching algorithm in DNS, do we
> need something in DNS that matches some new(?) matching algorithm in the
> application layer so that the two together produce the result we are after?

	For example, in the case where the HTTP HOST header refers
	to a domain-part for which the server is not configured, the
	server might query the DNS for a matching [BCD]NAME record,
	and use the URL corresponding to the corresponding canonical
	name (which it could cache) as the key to its document store.

	Alternatively, in the same circumstances, the server could
	send the browser a "please canonicalize" error response.

	Either of these approaches, if feasible, would appear to
	eliminate the need to pre-configure an application server
	for all of the potential "equivalent keys" which might
	appear in an incoming request.

> 4. How do we ensure skilled apps people manage to work with skilled
> DNS people so that the end result is optimal? (something IETF is not
> always very good at...)

	Pass ... 8-)

	IHTH, but I'm not at all sure.  I think we're still in a
	brainstorming phase, so "off-the-wall" is (so I hope) not
	necessarily "bad".

	Niall