Last week, after speaking with a member of ICANN’s Security and Stability Advisory Committee, Bill Smith and I authored a letter to ICANN expressing our concern with the proposed and potential delegation of certain names, such as “.corp” or “.internal”, that are currently in wide use as de facto internal network names. You can read the full text of the letter here:
http://forum.icann.org/lists/bc-gnso/pdfNFDozNA9Ka.pdf
For many years it has been common practice to configure network services inside the organizational perimeter with suffixes not in the set of publicly-delegated top-level domains. This practice has been recommended by various large software vendors and experts for security, manageability and conflict avoidance. Unfortunately for those who heeded that advice, times are changing, and their internal names may soon conflict with the public DNS.
Not only will the public delegation of these names create operational issues for internal networks, it may impose serious security risks on unprepared systems. Even if network operators block external resolution of these delegations within their networks, they need to consider what may happen when a corporate laptop roams to a public network at a WiFi hotspot or on a user’s home Internet connection.
Such systems are typically configured with automatic connectivity to a variety of services, including email, instant messaging, agent-based monitoring and maintenance, directory and policy services, and a variety of web applications. These server endpoints are often authenticated using TLS, and any certificate that chains to a root in the trust store will be treated as valid. As a consequence, when such a system roams off the internal network to a public one, it may soon find itself connecting to servers owned by the public registrant, considering them valid, and sending confidential information, including emails, sensitive files, passwords, HTTP cookies, and other authentication tokens. A maliciously operated server could likely force damaging state changes on clients in addition to harvesting sensitive data.
ICANN has identified the top ten such names currently being queried against the public roots, and RFC 6762 identifies another partially overlapping set of names recommended for Multicast DNS. It is our hope that ICANN and the applicants for these names will be able to agree on an appropriate course of action to protect the security and stability of the many systems currently relying on these names. We recommend that at least these most commonly used names be permanently reserved for internal-only use, and individual applications be considered on a case-by-case basis for their impact in this regard.
Regardless of the outcome at ICANN, such network configurations should no longer be considered a best practice. Rather than reducing risk to enterprise systems, they will soon increase it. Though few of the most-commonly used names have been applied for in the current round of new delegations, administrators should verify that no conflicts exist with the particular names in use on their networks: http://newgtlds.icann.org/en/program-status/application-results/strings-1200utc-13jun12-en
Even if no conflicting name is proposed for delegation in the current round, such conflicts may arise in the future. Changing existing networks configured in this manner will likely take several years, and administrators should begin the process of migrating away from reliance on “internal TLDs” as soon as possible.
-Brad Hill
