DNSサフィックスとはなんなのか

DNSサフィックスとは、短いホスト名をDNSで名前解決するときに、OSが自動的に末尾へ補うドメイン名のことです。

たとえば、社内ネットワークに次のようなサーバーがあるとします。

fileserver.example.local

このとき、PCにDNSサフィックスとして次の値が設定されている場合、

example.local

ユーザーが

fileserver

とだけ入力しても、PCは内部的に

fileserver.example.local

として名前解決を試みます。

つまりDNSサフィックスは、「server01」や「fileserver」のような短い名前を、正式なDNS名に補完するための設定です。

社内LAN、VPN、Active Directory環境などでは、サーバー名やプリンター名を短く入力してアクセスしたい場面が多いため、DNSサフィックスがよく使われます。

DNSサフィックスを理解するために必要なFQDNの知識

FQDNとは

DNSサフィックスを理解するには、まず FQDN を押さえておくとわかりやすいです。

FQDNとは、Fully Qualified Domain Nameの略で、日本語では完全修飾ドメイン名と呼ばれます。

たとえば、次のような名前がFQDNです。

www.example.com
mail.google.com
fileserver.example.local
pc01.sales.company.co.jp

FQDNは、DNS上で対象を一意に指定できる正式な名前です。

社内ネットワークのサーバーであれば、

fileserver.example.local

のように、ホスト名とドメイン名を組み合わせた形になります。

FQDNと短いホスト名の違い

FQDNが正式な名前であるのに対して、短いホスト名は一部だけを省略した名前です。

たとえば、正式な名前が次のようなサーバーだとします。

fileserver.example.local

この場合、

fileserver

は短いホスト名です。

人間にとっては短い名前のほうが入力しやすいですが、DNSで正確に名前解決するには、本来はFQDNが必要です。

そこで、短いホスト名に対して自動的にドメイン名を補う仕組みとして、DNSサフィックスが使われます。

厳密なFQDNでは末尾にドットが付くこともある

DNSの厳密な表記では、FQDNの末尾にルートを表すドットを付けて、

www.example.com.

のように書くこともあります。

ただし、通常の設定画面や説明では末尾のドットを省略して、

www.example.com

と表記することが一般的です。

そのため、実務上は www.example.com のような表記をFQDNとして扱うことが多いです。

DNSサフィックスの基本的な仕組み

短い名前にドメイン名を補って問い合わせる

DNSサフィックスが設定されているPCでは、短いホスト名を入力したときに、OSが自動的にDNSサフィックスを補って名前解決を試みます。

たとえば、DNSサフィックスとして次の値が設定されているとします。

example.local

この状態でユーザーが、

server01

にアクセスしようとすると、PCは内部的に次の名前を試します。

server01.example.local

そしてDNSサーバーに対して、

server01.example.local のIPアドレスを教えてください

と問い合わせます。

DNSサーバーに該当するレコードが登録されていれば、IPアドレスが返され、対象のサーバーへ接続できます。

DNSサフィックスがある場合の例

たとえば、社内DNSに次のようなレコードが登録されているとします。

fileserver.example.local = 192.168.1.10

PCにDNSサフィックスとして、

example.local

が設定されていれば、ユーザーは次のように短い名前でアクセスできます。

fileserver

PCはこれを内部的に、

fileserver.example.local

として名前解決し、192.168.1.10 に接続します。

DNSサフィックスがない場合の例

DNSサフィックスが設定されていない場合、fileserver.example.local のような補完は行われにくくなります。

そのため、

fileserver

と入力しても、DNS上で正しく名前解決できないことがあります。

この場合は、次のようにFQDNで指定すれば接続できる可能性があります。

fileserver.example.local

ただし、DNSサフィックスがなくても、環境によっては別の名前解決方式で短い名前が解決されることもあります。

たとえば、hostsファイル、LLMNR、NetBIOS名解決、mDNSなどが関係する場合です。

そのため、短い名前でアクセスできるかどうかは、DNSサフィックスだけでなく、ネットワーク全体の名前解決設定にも左右されます。

DNSサフィックスの主な用途

社内サーバーへ短い名前でアクセスする

DNSサフィックスの代表的な用途は、社内サーバーへ短い名前でアクセスできるようにすることです。

たとえば、正式なサーバー名が次のような場合、

fileserver.office.example.com

毎回この名前を入力するのは手間がかかります。

DNSサフィックスとして、

office.example.com

が設定されていれば、ユーザーは次のように入力するだけでアクセスできます。

fileserver

PC側で自動的に、

fileserver.office.example.com

として名前解決してくれるため、ユーザーの入力負担を減らせます。

VPN接続時に社内システムへアクセスしやすくする

DNSサフィックスはVPN接続時にも重要です。

自宅や外出先から会社のVPNに接続したとき、社内システムへ次のような短い名前でアクセスしたいことがあります。

intranet
portal
fileserver

VPN接続時に適切なDNSサーバーとDNSサフィックスが設定されていれば、PCはこれらの短い名前を、

intranet.company.example.com
portal.company.example.com
fileserver.company.example.com

のように補完して名前解決できます。

一方で、VPN接続時にDNSサフィックスが正しく設定されていないと、FQDNで指定すればアクセスできるのに、短い名前ではアクセスできないというトラブルが起こります。

Active Directory環境で名前解決を安定させる

Windowsの企業ネットワークでは、Active DirectoryとDNSが密接に関係しています。

たとえば、Active Directoryドメインが次のような名前だとします。

ad.example.com

この場合、ドメイン参加PCやドメインコントローラー、社内サーバーは、次のようなFQDNで管理されます。

pc001.ad.example.com
dc01.ad.example.com
file01.ad.example.com

DNSサフィックスが適切に設定されていれば、

dc01
file01

のような短い名前でも、対象のサーバーを名前解決しやすくなります。

Active Directoryでは、ドメインコントローラーの探索、ログオン、グループポリシー、ファイル共有などでDNSが重要な役割を持ちます。

そのため、DNSサフィックスやDNSサーバー設定が誤っていると、ドメイン環境でさまざまな不具合が発生することがあります。

DNSサフィックスの種類

プライマリDNSサフィックス

プライマリDNSサフィックスとは、PC自体に設定される基本的なDNSサフィックスです。

たとえば、PCのホスト名が、

PC001

で、プライマリDNSサフィックスが、

ad.example.com

の場合、そのPCのFQDNは次のようになります。

PC001.ad.example.com

つまり、PC自身の完全な名前は、

コンピューター名 + プライマリDNSサフィックス

で構成されます。

Active Directoryドメインに参加しているWindows PCでは、ADドメイン名がプライマリDNSサフィックスとして使われることがあります。

接続固有のDNSサフィックス

接続固有のDNSサフィックスとは、ネットワークアダプターごとに設定されるDNSサフィックスです。

たとえば、PCには複数のネットワーク接続が存在することがあります。

有線LAN
Wi-Fi
VPN
仮想ネットワークアダプター

それぞれの接続に対して、異なるDNSサフィックスが設定される場合があります。

例として、次のような構成です。

Wi-Fi: home.local
有線LAN: office.example.com
VPN: vpn.company.example.com

このように、どのネットワークに接続しているかによって、使われるDNSサフィックスが変わることがあります。

特にVPNでは、VPNアダプターに適切な接続固有DNSサフィックスが設定されているかどうかが、社内サーバーへの短い名前でのアクセスに影響します。

DNSサフィックス検索一覧

DNSサフィックス検索一覧とは、複数のDNSサフィックスを順番に試すためのリストです。

たとえば、DNSサフィックス検索一覧に次の値が設定されているとします。

tokyo.example.com
osaka.example.com
example.com

この状態で、ユーザーが次の名前にアクセスしようとした場合、

server01

PCは指定された順番で、次のような名前解決を試みます。

server01.tokyo.example.com
server01.osaka.example.com
server01.example.com

最初に名前解決できた候補が使われます。

DNSサフィックス検索一覧が明示設定されている場合の注意点

Windowsでは、DNSサフィックス検索一覧が明示的に設定されている場合、その一覧が優先的に使われます。

つまり、プライマリDNSサフィックスや接続固有DNSサフィックスが設定されていたとしても、検索一覧が明示的に指定されていると、指定された検索一覧の挙動が優先されることがあります。

たとえば、次のような設定があるとします。

プライマリDNSサフィックス: corp.example.com
接続固有DNSサフィックス: vpn.example.com
DNSサフィックス検索一覧: sales.example.com, example.com

この場合、短い名前 server01 に対して、必ずしもすべてのサフィックスを試すわけではありません。

検索一覧が明示されている場合は、次のように検索一覧に指定されたものが優先的に使われることがあります。

server01.sales.example.com
server01.example.com

そのため、Windows環境で名前解決トラブルを調査する場合は、プライマリDNSサフィックスだけでなく、DNSサフィックス検索一覧の有無も確認する必要があります。

DNSサフィックスとドメイン名の違い

ドメイン名とは

ドメイン名とは、DNS上の名前空間を表す名前です。

たとえば、次のようなものがドメイン名です。

example.com
company.co.jp
ad.example.com

Webサイト、メール、社内ネットワーク、Active Directoryなど、さまざまな場面で使われます。

DNSサフィックスとは

DNSサフィックスは、短いホスト名を名前解決するときに補完されるドメイン名です。

たとえば、

example.com

という文字列は、文脈によってはドメイン名でもあり、DNSサフィックスでもあります。

違いは、文字列そのものではなく使われ方です。

example.com がDNS上の名前空間を指している場合はドメイン名です。

一方で、server01 という短い名前に補われて、

server01.example.com

として名前解決するために使われる場合は、DNSサフィックスと呼ばれます。

検索ドメインとの違い

Windowsでは「DNSサフィックス」という表現がよく使われます。

一方、macOS、Linux、ルーター、VPN設定などでは、次のような表現が使われることがあります。

検索ドメイン
search domain
DNS search domain
domain search list

これらは、実質的にはDNSサフィックスと近い意味で使われます。

たとえば、検索ドメインに、

example.com

が設定されている場合、

server01

を、

server01.example.com

として探しに行く、という動きになります。

DNSサフィックスとDHCPの関係

DHCPでDNS関連情報が配布されることがある

DHCPとは、PCやスマートフォンなどの端末に、IPアドレスなどのネットワーク設定を自動的に配布する仕組みです。

一般的に、DHCPでは次のような情報を配布できます。

IPアドレス
サブネットマスク
デフォルトゲートウェイ
DNSサーバー
ドメイン名

この「ドメイン名」が、クライアント側では接続固有のDNSサフィックスとして扱われることがあります。

たとえば、社内LANに接続したときに、DHCPによって次のような情報が配布される場合があります。

DNSサーバー: 192.168.1.10
接続固有のDNSサフィックス: office.example.com

この場合、PCは社内ネットワーク上で短い名前を解決するときに、

server01.office.example.com

のような名前を試すことがあります。

DHCPで検索一覧まで配布できるとは限らない

注意したいのは、DHCPで配布されるDNSサフィックスと、複数のDNSサフィックス検索一覧は分けて考えたほうがよいという点です。

DHCPでは、接続固有のDNSサフィックスに相当するドメイン名を配布できることがあります。

しかし、複数のDNSサフィックス検索一覧をどのように配布・管理できるかは、OS、DHCPサーバー、VPNクライアント、グループポリシー、MDMなどの実装によって異なります。

そのため、企業環境ではDNSサフィックス検索一覧を、DHCPだけでなく、次のような方法で管理することがあります。

グループポリシー
VPNクライアントの設定
MDM
手動設定
ネットワーク構成管理ツール

DNSサフィックス関連のトラブルを調査するときは、「DHCPから配られているはず」と決めつけず、実際に端末側でどのような値が設定されているか確認することが重要です。

DNSサフィックスとActive Directoryの関係

Active DirectoryではDNSが重要

Active Directory環境では、DNSが非常に重要です。

ドメイン参加PCは、ドメインコントローラーや各種サービスを見つけるためにDNSを利用します。

たとえば、Active Directoryドメインが次のような名前の場合、

ad.example.com

ドメインコントローラーやファイルサーバーは、次のようなFQDNで登録されます。

dc01.ad.example.com
file01.ad.example.com

DNSサフィックスが適切に設定されていれば、

dc01
file01

のような短い名前でも、対象のサーバーを見つけやすくなります。

DNSサフィックスの誤設定がADトラブルにつながることがある

Active Directoryでは、DNSサーバーやDNSサフィックスの設定が誤っていると、次のようなトラブルにつながることがあります。

ドメインに参加できない
ログオンに時間がかかる
グループポリシーが適用されない
ドメインコントローラーを見つけられない
ファイルサーバーに短い名前でアクセスできない

特に、クライアントPCが社内DNSではなく外部DNSを参照している場合、Active Directory関連の名前解決ができず、さまざまな問題が発生します。

AD環境では、DNSサフィックスだけでなく、参照しているDNSサーバーが正しいかどうかも重要です。

DNSサフィックスとVPNの関係

VPNではDNSサフィックスの設定が重要

VPN接続時に社内リソースへアクセスする場合、DNSサフィックスの設定が重要になります。

たとえば、社内ポータルの正式名称が次のような場合、

portal.company.example.com

VPN接続時にDNSサフィックスとして、

company.example.com

が設定されていれば、ユーザーは次の短い名前でアクセスできる可能性があります。

portal

PCが自動的に、

portal.company.example.com

として名前解決するためです。

VPN接続時だけ短い名前でアクセスできない原因

VPN接続時だけ短い名前で社内サーバーにアクセスできない場合、次のような原因が考えられます。

VPNアダプターにDNSサフィックスが設定されていない
VPN接続時のDNSサーバーが社内DNSになっていない
DNSサフィックス検索一覧に必要なドメインが入っていない
スプリットDNSの設定が不適切
VPNクライアント側のDNS設定が正しく反映されていない

このような場合でも、FQDNであればアクセスできることがあります。

たとえば、

fileserver

ではアクセスできないが、

fileserver.company.example.com

ならアクセスできる、というケースです。

この場合、DNSサフィックスの補完がうまく働いていない可能性があります。

DNSサフィックスを確認する方法

Windowsで確認する方法

Windowsでは、コマンドプロンプトで次のコマンドを実行すると、DNSサフィックスを確認できます。

ipconfig /all

表示結果には、次のような項目が出てきます。

プライマリ DNS サフィックス
DNS サフィックス検索一覧
接続固有の DNS サフィックス
DNS サーバー

例として、次のように表示されます。

Windows IP 構成

   ホスト名 . . . . . . . . . . . . . . .: PC001
   プライマリ DNS サフィックス . . . . .: ad.example.com
   DNS サフィックス検索一覧 . . . . . .: ad.example.com
                                            example.com

ネットワークアダプターごとの情報には、次のような表示があります。

イーサネット アダプター Ethernet:

   接続固有の DNS サフィックス . . . . .: office.example.com
   DNS サーバー . . . . . . . . . . . .: 192.168.1.10

VPN接続時のトラブルでは、VPNアダプターの「接続固有のDNSサフィックス」と「DNSサーバー」を確認することが重要です。

PowerShellで確認する方法

PowerShellでは、次のようなコマンドでDNS関連の設定を確認できます。

Get-DnsClient

また、DNSサーバーの設定を確認するには、次のコマンドも使えます。

Get-DnsClientServerAddress

名前解決の結果を確認するには、次のコマンドを使います。

Resolve-DnsName server01

FQDNで確認する場合は、次のように指定します。

Resolve-DnsName server01.example.com

DNSサフィックスが効いているか確認する方法

pingで確認する

実際に短い名前で接続できるか確認したい場合は、ping を使うことがあります。

ping server01

名前解決できれば、IPアドレスが表示されます。

ただし、ping が失敗しても、必ずしも名前解決に失敗しているとは限りません。

サーバー側でICMP応答を拒否している場合もあるためです。

そのため、ping の結果だけで判断せず、必要に応じて他のコマンドでも確認します。

nslookupで確認する

DNSサーバーが特定の名前を解決できるか確認するには、nslookup が使えます。

nslookup server01.example.com

短い名前で試す場合は、次のように実行します。

nslookup server01

ただし、nslookup はDNS問い合わせを確認するためのツールであり、Windowsが通常行う名前解決の流れと完全に同じではありません。

Windowsでは、DNS以外にもhostsファイル、DNSキャッシュ、LLMNR、NetBIOS名解決、mDNSなどが関係することがあります。

そのため、nslookup だけで「実際のアプリケーションでも同じように解決される」と断定しないほうが安全です。

Resolve-DnsNameで確認する

Windows PowerShellでは、Resolve-DnsName を使うとDNS解決の結果を確認できます。

Resolve-DnsName server01

FQDNで確認する場合は、次のようにします。

Resolve-DnsName server01.example.com

DNSサフィックスの影響を確認したい場合は、短い名前とFQDNの両方で試すと原因を切り分けやすくなります。

DNSサフィックスが原因で起きるトラブル

短い名前で社内サーバーにアクセスできない

よくあるトラブルのひとつが、FQDNではアクセスできるのに、短い名前ではアクセスできないケースです。

たとえば、

fileserver.example.com

ではアクセスできるのに、

fileserver

ではアクセスできない場合です。

この場合、DNSサフィックスが設定されていない、または検索一覧に必要なドメインが入っていない可能性があります。

確認すべきポイントは次の通りです。

接続固有のDNSサフィックスが設定されているか
DNSサフィックス検索一覧に必要なドメインがあるか
参照しているDNSサーバーが正しいか
VPN接続時にDNS設定が反映されているか

VPN接続中だけ名前解決できない

社内LANでは短い名前でアクセスできるのに、VPN接続中だけアクセスできない場合があります。

この場合、VPN接続時のDNS設定が原因になっていることが多いです。

たとえば、次のような状況です。

社内LANでは fileserver でアクセスできる
VPN接続中は fileserver でアクセスできない
ただし fileserver.company.example.com ならアクセスできる

この場合、VPNアダプターにDNSサフィックスが付与されていない、またはDNSサフィックス検索一覧に必要な値が入っていない可能性があります。

意図しないサーバーに接続される

DNSサフィックス検索一覧に複数のサフィックスが設定されている場合、短い名前が意図しないFQDNとして解決されることがあります。

たとえば、次の2つのサーバーがあるとします。

app01.tokyo.example.com
app01.osaka.example.com

検索一覧が次の順番になっている場合、

osaka.example.com
tokyo.example.com

ユーザーが、

app01

と入力すると、先に

app01.osaka.example.com

が解決される可能性があります。

本当は東京側のサーバーに接続したかったとしても、検索順によって大阪側のサーバーに接続されることがあります。

そのため、DNSサフィックス検索一覧の順番は重要です。

名前解決に時間がかかる

DNSサフィックス検索一覧が多いと、存在しない短い名前を入力したときに、複数の候補を順番に問い合わせます。

たとえば、検索一覧が次のようになっているとします。

tokyo.example.com
osaka.example.com
nagoya.example.com
example.com

存在しない名前、

unknownhost

を問い合わせた場合、PCは次のような候補を順番に試すことがあります。

unknownhost.tokyo.example.com
unknownhost.osaka.example.com
unknownhost.nagoya.example.com
unknownhost.example.com

すべて失敗するまで時間がかかるため、アプリケーションの起動や接続が遅く感じられる場合があります。

外部DNSへ不要な問い合わせが発生する

DNSサフィックスやDNSサーバーの設定によっては、本来社内だけで扱いたい名前が外部DNSへ問い合わせられる可能性があります。

たとえば、社内向けの短い名前を解決できない状態で、端末が外部DNSを参照していると、意図しないDNS問い合わせが発生することがあります。

これは情報漏えいやセキュリティ上の懸念につながる場合があります。

そのため、社内ネットワークやVPN環境では、DNSサーバーとDNSサフィックスの設計を適切に行うことが重要です。

DNSサフィックスと「.local」の注意点

.localは既存環境で使われていることがある

社内ネットワークでは、昔から次のような .local ドメインが使われていることがあります。

company.local
ad.company.local

特に、古いActive Directory環境では .local が使われているケースも珍しくありません。

既存環境ですでに .local が使われている場合、すぐに変更するのは簡単ではありません。

Active Directoryドメイン名の変更は影響範囲が大きいため、慎重な設計と検証が必要です。

新規設計では.localを避けるほうが無難

一方で、新しく社内DNSやActive Directoryドメインを設計する場合は、.local は避けるほうが無難です。

理由は、.local がmDNSやBonjourで使われる名前空間と重なるためです。

macOSやiOSなどのApple製デバイス、またmDNSを利用する機器がある環境では、.local を社内DNS名として使うことで名前解決の競合や混乱が起きる可能性があります。

新規設計では、自社が所有している公開ドメインのサブドメインを社内用に使う構成がよく選ばれます。

たとえば、会社が次のドメインを所有している場合、

example.com

社内用には次のようなサブドメインを使います。

ad.example.com
corp.example.com
internal.example.com

このように、実際に自社が管理しているドメインのサブドメインを使うことで、将来的な名前衝突や管理上の問題を避けやすくなります。

DNSサフィックスを設定すべき場面

社内サーバーを短い名前で利用したい場合

社内サーバーやプリンターを短い名前で利用したい場合、DNSサフィックスの設定が役立ちます。

たとえば、社内サーバーが次のFQDNで登録されている場合、

file01.office.example.com

DNSサフィックスとして、

office.example.com

を設定しておけば、

file01

だけでアクセスしやすくなります。

VPN利用者に社内システムへ簡単にアクセスさせたい場合

VPN利用者が社内システムへ短い名前でアクセスする場合も、DNSサフィックスが重要です。

たとえば、次のような社内システムがあるとします。

portal.company.example.com
intranet.company.example.com
fileserver.company.example.com

DNSサフィックスが適切に設定されていれば、ユーザーは次のような短い名前でアクセスできます。

portal
intranet
fileserver

VPNのユーザー体験を改善するうえでも、DNSサフィックスは重要な設定です。

複数拠点や複数ドメインを運用している場合

複数拠点や複数ドメインを運用している企業では、DNSサフィックス検索一覧が使われることがあります。

たとえば、次のような拠点別ドメインがある場合です。

tokyo.example.com
osaka.example.com
nagoya.example.com

検索一覧にこれらを設定しておけば、短いホスト名に対して複数の候補を順番に試せます。

ただし、検索一覧が多すぎると、名前解決の遅延や誤解決の原因になります。

必要なものだけを設定し、順番にも注意することが大切です。

DNSサフィックスをむやみに増やさないほうがよい理由

名前解決が遅くなる可能性がある

DNSサフィックス検索一覧を増やしすぎると、名前解決が遅くなることがあります。

短い名前を入力したとき、PCは検索一覧にあるサフィックスを順番に付けて問い合わせます。

検索一覧が長いほど、存在しない名前を問い合わせたときに失敗まで時間がかかる可能性があります。

意図しない名前に解決される可能性がある

複数のドメインに同じホスト名が存在する場合、検索一覧の順番によって接続先が変わることがあります。

たとえば、

db01.tokyo.example.com
db01.osaka.example.com

の両方が存在する場合、db01 とだけ入力すると、検索一覧で先に指定されているほうが使われる可能性があります。

そのため、DNSサフィックス検索一覧を設定する場合は、どの順番で検索されるかを慎重に設計する必要があります。

セキュリティ上のリスクにつながることがある

DNSサフィックスやDNSサーバーの設定が不適切だと、本来社内向けの名前が外部DNSへ問い合わせられる可能性があります。

また、短い名前が意図しないドメインで解決されると、利用者が想定していないサーバーに接続してしまう可能性もあります。

DNSサフィックスは便利な設定ですが、増やせば増やすほどよいものではありません。

必要な範囲に絞って、適切に管理することが重要です。

DNSサフィックスに関するよくある誤解

DNSサフィックスを設定すれば必ず名前解決できるわけではない

DNSサフィックスは、短い名前をFQDNに補完するための設定です。

しかし、補完後のFQDNがDNSサーバーに登録されていなければ、名前解決はできません。

たとえば、DNSサフィックスが、

example.com

に設定されていても、DNS上に、

server01.example.com

のレコードが存在しなければ、server01 は解決できません。

DNSサフィックスはあくまで補完ルールであり、DNSレコードそのものを作成するわけではありません。

DNSサフィックスとDNSサーバーは別の設定

DNSサフィックスとDNSサーバーは別の設定です。

DNSサフィックスは、短い名前に補うドメイン名です。

一方、DNSサーバーは、名前をIPアドレスに変換する問い合わせ先です。

たとえば、次のような違いがあります。

DNSサフィックス: example.com
DNSサーバー: 192.168.1.10

server01 という短い名前を問い合わせる場合、PCはDNSサフィックスを補って、

server01.example.com

を作り、その名前をDNSサーバー 192.168.1.10 に問い合わせます。

つまり、DNSサフィックスだけ正しくても、DNSサーバーが間違っていれば名前解決はできません。

逆に、DNSサーバーが正しくても、DNSサフィックスが不足していると、短い名前では解決できないことがあります。

短い名前でアクセスできる理由がDNSサフィックスとは限らない

fileserver のような短い名前でアクセスできる場合でも、その理由が必ずDNSサフィックスとは限りません。

Windows環境では、次のような名前解決方式が関係することがあります。

DNS
hostsファイル
DNSキャッシュ
LLMNR
NetBIOS名解決
mDNS

そのため、短い名前でアクセスできるからといって、DNSサフィックスが正しく設定されているとは限りません。

正確に確認するには、ipconfig /all や Resolve-DnsName などを使って、実際のDNS設定と名前解決結果を確認する必要があります。

DNSサフィックスを確認するときのチェックポイント

現在のDNSサフィックスを確認する

まず、PCにどのDNSサフィックスが設定されているか確認します。

Windowsでは、次のコマンドを実行します。

ipconfig /all

確認する項目は次の通りです。

プライマリDNSサフィックス
接続固有のDNSサフィックス
DNSサフィックス検索一覧

VPN接続中の場合は、VPNアダプターの項目も確認します。

DNSサーバーが正しいか確認する

DNSサフィックスが正しくても、参照しているDNSサーバーが間違っていると名前解決はできません。

社内ネットワークやActive Directory環境では、基本的に社内DNSサーバーを参照している必要があります。

確認する項目は次の通りです。

DNSサーバーのIPアドレス
VPN接続時のDNSサーバー
外部DNSを参照していないか

特にAD環境で、クライアントPCが外部DNSだけを参照している場合、ドメイン関連の名前解決に失敗する可能性があります。

FQDNと短い名前の両方で確認する

名前解決トラブルを調べるときは、短い名前とFQDNの両方で確認すると切り分けしやすくなります。

たとえば、次の両方を試します。

ping fileserver
ping fileserver.example.com

またはPowerShellで、

Resolve-DnsName fileserver
Resolve-DnsName fileserver.example.com

のように確認します。

FQDNでは解決できるのに短い名前では解決できない場合、DNSサフィックスや検索一覧の問題である可能性が高くなります。

検索一覧の順番を確認する

DNSサフィックス検索一覧がある場合は、順番も重要です。

たとえば、次のような検索一覧があるとします。

osaka.example.com
tokyo.example.com
example.com

この状態で server01 と入力すると、先に server01.osaka.example.com が試される可能性があります。

同じホスト名が複数のドメインに存在する場合、検索一覧の順番によって接続先が変わるため注意が必要です。

DNSサフィックスを一言でいうと

DNSサフィックスとは、短いホスト名の末尾に自動的に補われるドメイン名です。

たとえば、

server01

という短い名前を、

server01.example.com

として探すために使われる、

example.com

の部分がDNSサフィックスです。

まとめ

DNSサフィックスは、社内ネットワークやVPN、Active Directory環境などでよく使われる名前解決の補完設定です。

短いホスト名にドメイン名を自動的に補うことで、ユーザーは長いFQDNを毎回入力しなくても、社内サーバーや社内システムへアクセスしやすくなります。

たとえば、DNSサフィックスに、

example.com

が設定されていれば、

fileserver

という短い名前を、

fileserver.example.com

として名前解決できます。

ただし、DNSサフィックスは便利な一方で、設定を誤ると次のようなトラブルの原因になります。

短い名前でアクセスできない
VPN接続中だけ名前解決できない
意図しないサーバーに接続される
名前解決に時間がかかる
外部DNSへ不要な問い合わせが発生する

また、WindowsではDNSサフィックス検索一覧が明示的に設定されている場合、その一覧が優先されることがあります。

プライマリDNSサフィックス、接続固有DNSサフィックス、検索一覧の関係を正しく理解しておくことが大切です。

実務では、DNSサフィックスだけでなく、参照しているDNSサーバー、VPNアダプターの設定、Active Directoryドメイン名、検索一覧の順番などもあわせて確認する必要があります。

DNSサフィックスを理解すると、社内ネットワークやVPNで起こる名前解決トラブルを切り分けやすくなります。

特に「FQDNでは接続できるのに、短い名前では接続できない」という場合は、DNSサフィックスやDNSサフィックス検索一覧を確認すると原因を見つけやすくなります。

以上、DNSサフィックスとはなんなのかについてでした。

最後までお読みいただき、ありがとうございました。