0

In two of the SO questions here and there the prevailing opinions are that using .local for internal network is a bad idea.

One of the comment however points out:

However: don't use a real domain name that you have already used for public-facing production services. There are various interactions that are allowed between www.example.com and *.internal.example.com that are not allowed between www.example.com and *.example.net, most notably cross-site cookie setting. Running internal and external services on the same domain increases the risk that a compromise of a public service will give some ingress to the internal services, and conversely that an insecure internal service could provoke internal misuse of an external service. – bobince

Can this be interpreted as a benefit of using .local for internal network? What are the other options to mitigate the security risk?

Community
  • 1
minghua
  • 171
  • 1
  • 1
  • 8
  • 1
    The reasons in those examples are not security reasons, but they are valid. The other example kind of over complicates things. – Ryan Babchishin Oct 25 '15 at 03:57

1 Answers1

3

Using .local is a security risk. As per RFC 6762 section 3, that top-level domain name is reserved for multicast DNS. This means that if you use it for your own machines, any Android, Linux, iOS or OSX devices on your network may (legally and correctly) be responding to queries. Having no idea where your internal DNS answers come from is not a good move, from a security point of view.

Instead of .local, use an internal-only subdomain to a perfectly normal domain that is properly registered to you.

Community
  • 1
Calle Dybedahl
  • 2,083
  • 12
  • 17