Re: [dnsext] the same in old days, was making names the same NEED protocol changes?

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

John is completely right here and it really demonstrates the need to
have application level input into this discussion.


Modern application protocols bind to DNS names and NOT to IP
addresses. As far as we are concerned a DNS name is the only essential
part of the Internet architecture.

Applications do not and should not care about IP addresses. The few
protocols that do rely on IP addresses break on modern NAT-ed networks
as a result unless there is specific protocol level fixup.


So attempting to make two names resolve alike without change at either
the application client or the application server is a fools errand. It
is not going to work because that is simply not how the applications
see the world.

If someone wants a2.com to work in exactly the same way as a1.com,
then either the application client has to know to substitute a1 for a2
when it makes the request or the application server has to know to
redirect a2 to a1.


The security model of Web applications is complex and convoluted
enough as it is. We have had almost 20 years now of protocol
extensions being thrown in by people whose idea of a security
consideration is 'tell me why it might be bad, too late its deployed'.
And this proposal seems to be more of the same.

I know that there are some people who will have just written in their
response to the above something along the lines 'well thats their
issue' or 'well they should fix it'. And that is exactly the type of
thinking that got us into this problem. Security is real easy when you
decide the hard part is someone else's problem.


If we are going to change the security model we have to change the
application client or things are going to break.

If we decide we can change the application client, this whole problem
becomes pretty straightforward. Either adopt the 'did you mean'
pointer style approach or allow domains to nominate mappings of one
charset to another.


On Sun, Feb 27, 2011 at 3:00 PM, John R. Levine <[e-mail]> wrote:
>> I think I'm being thick here. Doesn't the BNAME reference go the
>> wrong way to autoconfigure a server based on it in a manner where
>> there can be a security problem as a result?
>
> You're quite right.  SHADOW goes the right way, but requires a zone cut
> everywhere that there's aliases.
>
> I'm not seeing any particularly pretty ways to fix BNAME to tell which ones
> are approved.  It's not unlike the rDNS problem.
>
> Regards,
> John Levine, [e-mail], Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. http://jl.ly
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>



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