Pekka Savola (pekkas) writes:
>
> Thanks for the interesting link. This certainly shows that "use hostnames
> everywhere" idiom that the IETF has been repeating doesn't quite work as
> intended in the real life :-)
Yes it does, it's not a bug, it's a feature. It does exactly the right
thing from the point of view of the implementation. This is, in my
opinion, the same problem scope as IDN homographic attacks, just one
level of interaction (App <-> DNS, as opposed to User <-> APP).
Section 5.2 of the paper suggests:
"Instead of trying to prevent a host name from rebinding
from one IP address to another -- a fairly common event --
a different approach to defending against rebinding is to
prevent the attacker from naming the target server."
IMHO the problem is there, i.e.: fix the application (browser
javascript/sandboxing mechanisms), don't blame DNS for doing exactly
what it was intended to do.
It'd be even more stupid to look up IPs once and stick to those
during the life of the application (== execution of the Flash code,
or JS code, which can be anything from a few milliseconds to several
hours). The problem is the same as for traditional (read: standalone)
applications which lookup IPs once and never look them up again.
Other solutions are outlined such as blocking direct DNS queries to
the outside world, and/or using DNS software that refuses to relay
replies containing internal IP addresses from the outside. That's
just spoofing protection at the DNS level.
The section on Host Name authorization is interesting, but it's
a hack.
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
