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?

  • 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 3:57

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.

  • To clarify: "internal-only" means it is not a subdomain of a public facing domain, correct? – minghua Oct 29 '15 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.