Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Domaine de premier niveau / suffixe de domaine pour un réseau privé ?

ayi

At our office, we have a local area network with a purely internal DNS setup, on which clients all named as <code>whatever.lan</code>. I also have a VMware environment, and on the virtual-machine-only network, I name the virtual machines <code>whatever.vm</code>.
Currently, this network for the virtual machines isn’t reachable from our local area network, but we’re setting up a production network to migrate these virtual machines to, which will be reachable from the LAN. As a result, we’re trying to settle on a convention for the domain suffix/TLD we apply to the guests on this new network we’re setting up, but we can’t come up with a good one, given that <code>.vm</code>, <code>.local</code> and <code>.lan</code> all have existing connotations in our environment.
So, what’s the best practice in this situation? Is there a list of TLDs or domain names somewhere that’s safe to use for a purely internal network?
<hr>
Source : <a href="https://www.rfc-editor.org/rfc/rfc6761" rel="noopener nofollow ugc">Server Fault</a>

ayi_2

Since the previous answers to this question were written, there have been a couple of RFCs that alter the guidance somewhat. <a href="https://www.rfc-editor.org/rfc/rfc6761">RFC 6761</a> discusses special-use domain names without providing specific guidance for private networks. <a href="https://www.rfc-editor.org/rfc/rfc6762">RFC 6762</a> still recommends not using unregistered TLDs, but also acknowledges that there are cases where it will be done anyway. Since the commonly used .local conflicts with Multicast DNS (the main topic of the RFC), <a href="https://www.rfc-editor.org/rfc/rfc6762#appendix-G">Appendix G. Private DNS Namespaces</a> recommends the following TLDs:
<ul>
<li>
intranet
</li>
<li>
internal
</li>
<li>
private
</li>
<li>
corp
</li>
<li>
home
</li>
<li>
lan
</li>
</ul>
IANA appears to <a href="https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml">recognize both RFCs</a> but does not (currently) incorporate the names listed in Appendix G.
In other words: you shouldn’t do it. But when you decide to do it anyway, use one of the above names.
Update 1/2024: We’re getting closer to having some definitive guidance on this. IANA has made a provisional determination that ICANN has opened up for <a href="https://www.icann.org/en/public-comment/proceeding/proposed-top-level-domain-string-for-private-use-24-01-2024">public comment</a> (the recommendation is to use .internal)
Update 8/2024: ICANN has <a href="https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-special-meeting-of-the-icann-board-29-07-2024-en#section2.a">officially reserved .INTERNAL (note: all caps) for private use</a>.