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

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

OK, I am not yet convinced that this is acceptably secure, but I withdraw my
earlier objection, see below.


2011/3/3 Tony Finch <[e-mail]>:
> On Tue, 1 Mar 2011, Phillip Hallam-Baker wrote:
>>
>> 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.
>
> On the contrary, this is trivial for the server to do by dynamically
> looking up a.com and seeing if it is a BNAME pointing at b.com.

That would not meet my definition of 'straightforward'. From a security
point of view, having my server mappings controlled by BNAMES in the TLD...


> However the server administrator probably does not want the server to
> accept requests for arbitrary domains just because they have a BNAME
> pointer.

So it is straightforward but stupid, OK we seem to agree here.


> So there has to be a list of valid aliases somewhere accessible to the
> server, either in the DNS for b.com (used like "paranoid" reverse DNS
> checking) or in the server's configuration.
>
> Given the existence of HTTP redirects, I'm not entirely sure that it is
> reasonable to forbid DNS aliasing. But server administrators are free to
> choose between loose dynamic configurations and tight explicit
> configurations without affecting clients.

There is a big difference between a redirect issued by the administrator of
the target and a redirect issued by a third party.


> The question for this group is if we specify something like BNAME if we
> should also specify how to put the corresponding back-references in the
> canonical domain.

That could help the situation. It could be quite efficiently encoded as a
circular list. Each alias would have a link to the canonical name and the
next alias in the list.

This would also act to prevent an alias being effected without the consent
of the target domain since they would have to recognize the list.

Consider the following.

let canonical.tld be the target and alias.tld and alias.atld be the aliases.
An appropriate configuration would be:


! Records maintained by admin for tld and atld

canonical.tld       NS   <blah>
canonical.tld       xlnk   alias.tld
alias.tld           xname  canonical.tld
alias.tld           xlnk   alias.atld
alias.atld          xname  canonical.tld
alias.atld          xlnk   canonical.tld


! Records maintained locally
canonical.tld       A      10.0.0.1
canonical.tld       AAAA   1:00:1
canonical.tld       clnk   www.canonical.tld
canonical.tld       xx
www.canonical.tld   cname  canonical.tld
www.canonical.tld   clnk   canonical.tld


I can see a fairly strong separation of control there.

This mechanism could in principle be used by either clients or servers. It
could also be used by resolvers synthesizing up a dynamic HTTP response.
That would give us a chance of getting a deployment to actually happen.

So an aware resolver needs to be able to know if the server is capable of
accepting the request or not. If the server accepts this type of alias it
can simply return the records and get out of the way. Otherwise an HTTP
redirect is going to be required.

The resolver could do this by pinging the Web server, but it is better to
have that information in the zone. Hence the need for the xx record which is
basically a way to say 'this zone handles this extension'.

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