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

[Phillip Hallam-Baker <[e-mail]>]

2011/2/27 Patrik Fältström <[e-mail]>:

> 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?

I would say not.

The legacy HTTP protocol requires that the name presented in the Host
header be the name that is present in the URL. There is no provision
for rewriting as far as I am aware.

Let us imagine we want a mapping a.com = b.com and the name a.com is
presented. There are two design choices:

1) The client performs the rewrite.

The best way to achieve this in my view would be to present a Host
header for b.com and add in a new header to tell the server that the
original origin was a.com

This is compatible with legacy servers but not legacy clients.

2) The Server performs the rewrite.

This is really hard to achieve as it requires the server to know that
the mapping even exists.

Typically a server is responding to hundreds of domains. Even large
production servers do this. If a server receives a request for a.com
it has no means of knowing that it 'should' map that to b.com unless
the DNS configuration is somehow mapped to the Web administration.

This is quite straightforward to handle administratively when the
mapping is www.b.com to b.com because the source and target are in the
same administrative zone. But this is not going to work if the mapping
is being controlled by a TLD.


3) Don't support the aliasing requirement.

'nuff said.


Note that in both cases the administrative model is only practical if
there is a mapping of one name to another. It is futile to attempt to
make the names 'the same' without nominating a canonical form.



The legacy of Web servers is far more complex and difficult to change
than legacy user applications. Web services are a different matter.


Writing a Web browser is rather complex and there is a pretty high
bar. There is very little demand for Web browsers that are not as good
as Firefox or Chrome or IE or Safari or Opera (that is not an
exhaustive list but most other browsers out there have a lot of common
code with the above) There is a huge demand for Web servers that are
smaller and lighter than Apache.

To give you an idea of just how embedded these web servers are, you
can get an ethernet socket that looks just like a regular socket but
interfaces to an RS232/422 port and has a Web server and TCP/IP stack
built into the plug. It is a cheap way to add ethernet connectivity to
SCADA equipment. There are more brands of that type of connector than
major web browser.

There are a lot of cruddy Web browsers on phones but I don't think
they get used more than a few times and they function so poorly that
breaking them worse does not really matter much. The good mobile
browsers all come from companies that are actively developing them.


Web services are trickier. At one level they are quite easy because
people who write mashups are already using pretty unfriendly URLs to
identify service endpoints. But I think that has to be a temporary
condition. We should be using SRV and other advanced discovery to make
these connections.

So with this in mind, I think that there is a brief window of
opportunity in which we could make this change for Web Services
applications. Over the past few weeks I have been discussing my ESRV
scheme with principles in the Web Services platform space at major
vendors who control and drive the relevant platforms.

Since any Web Services support infrastructure would have to be buried
deep in the scripting libraries used for making mashups, it would not
be difficult to add in an aliasing requirement. But we have to be very
quick if that is going to happen. The window is going to close very
soon.



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

Skill in HTTP will probably only provide a better understanding of the
range of constraints.

There is 18 years of legacy here and a lot more complexity than in DNS.


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