Right? Public DNS for a private IP doesn't get me anything I don't already know, right?
I mentioned that public DNS is for networking only to point out that there's a mismatch here between the problem and the solution, but there are still attack vectors here.
One vector would be your ability to intercept anything that's being sent to the development server by a browser or IDE, which could include debug information, API keys, fragments of the stack, or even chunks of source code. It depends on the tools the developer is using.
> How would I get the IP of your development server other than 127.0.0.1?
The client IP. Many default configurations of local servers will use or bridge port 80, which means external requests will be routed to the local development server. The client IP, as well as permissive firewall settings, would allow an attacker to access the development server.
> When you request local.computer, it's not sending me your IP, it's requesting one.
With a very low TTL, you could still get the client IP pretty reliably. This is how DNS rebinding attacks work.
So as long as users don't use it for connecting to their local server are they safe?
Don't most people connect to local servers via Vagrant or docker shared volumes, anyway?
Not sure why anyone would use it for accessing their local machine when there are existing methods for that.
Thanks for the details.
I've recently started to add a local. record to the DNS of the project which points to the statically defined local Vagrant IP, as you often need to add dev and staging records anyway.