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

[Patrik Fältström <[e-mail]>]

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.

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 ;-)

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?

2. Support of more application layer aliases

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?

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?

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?

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...)

Now beat me up!

   Patrik