> you should be in control of a DNS the user relies on
You always are when a users visits your domain – you control the DNS of your domain.
> Access-Control-Allow-Origin: *
You don't need access-control headers, because you stay on the same domain.
> Your server should be enabled to respond to mypage.com host header
Most servers listening on localhost ignore the host header.
I meant you need to control the poisoned DNS
If I use 8.8.8.8 as DNS you can only work on the domains you already control, which is kinda useless
> You don't need access-control headers, because you stay on the same domain.
No, you don't
My localhost server only respond to localhost and 127.0.0.1 host header
Not to mypage.com
Nginx does taht too by default
https://github.com/nginx/nginx/blob/master/conf/nginx.conf#L...
But even if you did, you still haven't resolved the issue: you can't make a call to a different domain without access-control headers, unless it's the same domain
you can't load mypage.com and then fetch from www.mypage.com, even if you resolve www.mypage.com to 127.0.0.1 the browser won't let you do it
> you can't load mypage.com and then fetch from www.mypage.com, even if you resolve www.mypage.com to 127.0.0.1 the browser won't let you do it
In this part you’re confusing what a rebinding attack is: by serving a DNS response with a short TTL an attacker is able to associate two different IPs to the same query, thus it'd be mypage.com and mypage.com (not www.mypage.com).. bypassing the same origin restrictions of the browsers.
But it doesn't really work.
I query my DNS, on my home router, not your DNS.
And the DNS on my home router query the ISP's DNS, which caches requests.
I bet you can't go below few minutes resolution.
I had this problem when validating the Letsencrypt DNS challenge, I had to let certbot run for almost 20 minutes before my home router picked up the new value.
When I'm at work, I use the company's DNS, which ignores non standard TTLs and caches the first answer forever (well... almost) and disallow external domains that resolve to reserved IP addresses.
> Time to live minimum for RRsets and messages in the cache. Default is 0. If the the minimum kicks in, the data is cached for longer than the domain owner intended, and thus less queries are made to look up the data. Zero makes sure the data in the cache is as the domain owner intended, higher values, especially more than an hour or so, can lead to trouble as the data in the cache does not match up with the actual data any more.
Which is one of the reasons I think this is manly effective against home networks.
But in my case my network is configured to always reach the in house DNS first, to keep latency low
[1] https://github.com/letsencrypt/boulder/blob/8167abd5e3c7a142...
It's useful against vulnerable IoT devices or home routers, but is it still effective to breach enterprise perimeters?