目次 >> DNS
ここでは、DNSサーバとしてBIND9を取り上げて、その設定方法を解説する。
仮想のexample.comおよびexample.orgというドメインネームの設定を行うことを考える。ここの説明では、10.0.0.1~10.0.0.5をグローバルIPアドレスとして、192.168.1.xをプライベートIPアドレスとして考える。
設定を確認するにはUNIXではdigを使う。(nslookupより良い。Windowsなどではnslookup)
$ dig 情報を得たいサーバ名
なお、CentOSではデフォルトではdigはインストールされていない。bind-utilsに含まれているので、
# yum install bind-utils
と打って、インストールする。
(例)
$ dig www.ckme.co.jp
で、現在利用しているDNSサーバから情報を取得する。問い合わせるDNSサーバを変更するには、@をつけて指定する。なお、@前にスペースを入れるのをお忘れ無く。
$ dig 情報を得たいサーバ名 @問い合わせサーバ名
(例)
$ dig www.ckme.co.jp @dns.example.com
MX情報を取得するには
$ dig www.ckme.co.jp mx
(例)
$ dig www.ckme.co.jp mx
SOA情報を取得するには
$ dig 情報を得たいサーバ名 soa
(例)
$ dig www.ckme.co.jp soa
https://www.dnscolos.com/ や https://dnscheck.jp/ 等を使う。
起動
#/etc/init.d/named start
停止
#/etc/init.d/named stop
再起動
#/etc/init.d/named restart
サーバ起動時にBINDを自動起動するようにするには、chkconfigを使う。
# chkconfig named on
念のため確認
# chkconfig named --list
named 0:off 1:off 2:off 3:on 4:off 5:on 6:off
CentOS7では、通常のnamedを使っている場合は
# systemctl start named
named-chrootを使っている場合は
# systemctl start named-chroot
で起動する。
自動起動するためには通常のnamedを使っている場合はsystemctl enable namedコマンドで行う。
# systemctl enable named
Created symlink from /etc/systemd/system/multi-user.target.wants/named.service to /usr/lib/systemd/system/named.service.
named-chrootを使っている場合は
# systemctl enable named-chroot
Created symlink from /etc/systemd/system/multi-user.target.wants/named-chroot.service to /usr/lib/systemd/system/named-chroot.service.
自動起動が設定されているかどうかは systemctl is-enabled named、もしくはsystemctl is-enabled named-chrootで確認できる。
# systemctl is-enabled named
enabled
# systemctl is-enabled named-chroot
enabled
sudo brew services start bind
で起動、
sudo brew services stop bind
で停止、
sudo brew services restart bind
で再起動。
sudo serveradmin start dns
で起動、
sudo serveradmin stop dns
で停止する。
sudo serveradmin fullstatus dns
で、下記のような情報を得ることができる。
# sudo serveradmin fullstatus dns
dns:primaryZones = 2
dns:readWriteSettingsVersion = 1
dns:servicePortsRestrictionInfo = _empty_array
dns:secondaryZones = 2
dns:startedTime = "2014-10-03 01:17:56 +0000"
dns:version = "BIND 9.9.2-P2"
dns:logPaths:_default_log = "/Library/Logs/named.log"
dns:servicePortsAreRestricted = "NO"
dns:state = "RUNNING"
dns:setStateVersion = 1
OpenSUSE 11.2で、bindを立ち上げようとすると、たとえデフォルトの設定でもbindがsegfault(/var/log/messagesでわかる)でクラッシュしてします。この場合、yastからAppArmorでUpdate Profile Wizardを実行してやると解消する。
Fedora、およびCentOSの場合、chrootがデフォルトでインストールされている。chrootを導入している場合(セキュリティ上導入するのが望ましい)、
/var/named/chroot
がルートとなる。その下ディレクトリに各種設定ファイルを置く。BIND自体の設定は
/var/named/chroot/etc/named.conf
ゾーンファイルは下記のディレクトリ内に置く。
/var/named/chroot/var/named
openSUSEではデフォルトではchrootが導入されていないので、
/etc/named.conf
macOSの設定ファイルの場所は/usr/local/etc/named.conf
named.caファイルはなかったので、ネットからnamed.rootをダウンロードして改名して、/usr/local/var/namedにおいた。
ログファイルの場所は/usr/local/var/log/named
OS X Server設定ファイルの場所は/Library/Server/named/以下にあり、下記のファイル群で設定する。
/Library/Server/named/ (zone files) /Library/Server/named/named.conf
ここでは、外部向けに、example.comのゾーンに対してのみ応答するコンテンツサーバとして、LAN内向けには反復問い合わせを行うフルサービスリゾルバとして設定している。
options { directory "/var/named";#chrootを使っていても、chrootのルートから書く allow-transfer { #セカンダリサーバの場所を記述する 10.0.0.3; }; }; # 内向けの view # 必ず、内向けから書く。 # 内向け、外向けを分ける必要がない場合は、 # view "internal" {}、および # view "internal" {}は不要 view "internal" { # この view は次のネットワークからの要求に対してのみ使用される match-clients {#ここに一致するクライアントからの接続に対し、このviewを使用する。 ::1/32; # localhost 127.0.0.0/8; # localhost 192.168.1.0/24; # 内側のネットワーク192.168.1.xxx }; # 以下ゾーンの設定 # 最初の 3 つは基本設定での内容と同じ zone "." { type hint; file "named.ca"; }; zone "0.0.127.in-addr.arpa" { type master; file "localhost.zone"; }; zone "example.com" { type master; file "example.com.zone-priv"; }; zone "example.org" { type master; file "example.org.zone-priv"; }; zone "0.168.192.in-addr.arpa" { type master; file "0.168.192.in-addr.arpa.zone"; }; }; # 外向けの view view "external" { # view "internal" の match-clients にマッチしない場合は、 # この view が使われる。 match-clients { any; }; recursion no; # 外から勝手にDNSサーバとして使われては困るので再帰検索はしないに設定 # (つまり自分の担当のドメインのみ答えるということ) zone "." { type hint; file "named.ca"; }; zone "0.0.127.in-addr.arpa" { type master; file "named.local"; }; zone "example.com" { type master; file "example.com.zone"; }; zone "example.org" { type master; file "example.org.zone"; }; zone "0.0.10.in-addr.arpa" { type master; file "0.0.10.in-addr.arpa.zone"; }; }; include "/etc/rndc.key";
ゾーンファイルを置く場所は、デフォルトでは、FC4、FC5、FC6の場合/var/named/chroot/var/namedです。ゾーンファイルを作成した場合、bindがアクセスできるかアクセス権を必ず確認してください。
$TTL 86400 @ IN SOA ns1.example.com. admin.example.com. ( 2006021000 ; serial 3600 ; refresh 1hr 900 ; retry 15min 604800 ; expire 1w 86400 ; min 24hr ) IN NS ns1.example.com. IN NS ns2.example.com. @ IN A 10.0.0.1 ns1 IN A 10.0.0.2 ns2 IN A 10.0.0.3 www IN A 10.0.0.4 mail IN A 10.0.0.5 mail2 IN A 10.0.0.6 example.com. IN MX 10 mail.example.com. example.com. IN MX 20 mail2.example.com.
まず、最初の行でデフォルトのTTLを指定しています。単位は秒です。86400は1日に相当します。BINDはゾーンファイル内でTTLが指定されていない項目に出会った場合はもっとも直前に書かれたデフォルトTTLの値を使います。
SOAでは、セカンダリサーバに対する指示が主です。
serialはゾーンファイルを更新した際には、必ず以前の値よりも大きな値にします。通常は日付+数値を使うことが多いようです。
その次の行はセカンダリサーバのrefresh間隔を指定指定していて、この間隔でセカンダリサーバはデータが更新されていないかをチェックします。
retry行は、セカンダリサーバがチェックした際に、失敗したときに再度試みる間隔です。retryを何度も行っても取得できずに、expireの時間が過ぎると、セカンダリサーバはデータをすべて破棄します。
INはインターネットを表します。現在ではこれ以外のものが使われることは非常にまれです。
NSはネームサーバを表します。ネームサーバは必ず2つ以上必要です。
Aレコードで、名前とIPアドレスの対応を書いていきます。
ns1 IN A 10.0.0.2
と書いた場合は、ns1.example.comのIPアドレスを指定していることになります。
@は特別で、ゾーンの起点を示します。例えば下記のように書くと、
@ IN A 10.0.0.1
example.comのIPアドレスを指定していることになります。
MXレコードを使ってメールの配送が行われる。
例えばfoo@example.com宛のメールはMXレコードで指定したmail.example.comに配送される。
もしここでMXレコードが指定されていない場合は、たいていの場合、Aレコードを使ってexample.comに配送される。
ただし、MXレコードが無い場合はたいていの場合Aレコードを使って送るサーバが多いが、MXレコードしか見ないで、Aレコードを使用しないサーバもあるので、メールサーバを使用する際は必ずMXレコードも設定すること。
MXレコードを複数設定すると、数値の小さいものに優先的に配送される。数値の大きいサーバは数値の小さいサーバがダウンしていて配送できない場合に、利用される。この場合、ダウンしていたサーバが回復した際にそこに自動的に転送するようにメールサーバを設定しておく必要がある。
なお、MXが同じ値のものを複数書くと、ラウンドロビンとして機能するようになる。
セカンダリサーバとして使いには下記のように設定する。(もちろん、一つのサーバで、あるドメインについてはプライマリ、別のドメインについてはセカンダリというように、一つのサーバでプライマリとセカンダリを共存させることもできる。)
options { directory "/var/named";#chrootを使っていても、chrootのルートから書く allow-transfer { #セカンダリサーバの場合は、自分自身のみかnoneを指定すること 127.0.0.1; }; }; recursion no; # 外から勝手にDNSサーバとして使われては困るので再帰検索はしないに設定 # (つまり自分の担当のドメインのみ答えるということ) zone "." { type hint; file "named.ca"; }; zone "0.0.127.in-addr.arpa" { type master; file "named.local"; }; zone "example.com" { type slave;#ここでtypeをslaveに指定する。 masters { 10.0.0.2; };#プライマリサーバの場所を指定する file "slaves/example.com.zone";#プライマリサーバから得られた情報はこのファイルに書き込まれる }; include "/etc/rndc.key";
ここでは、ダイナミックDNS(Dynamic DNS、DDNS)の設定方法を記述する。
(現在、作成中)
SPF(Sender Policy Framework)は、送信されたメールが、正当な送信サーバから送信されたのかをチェックすることを可能にする技術です。SPFは、DNSサーバに、どのメールサーバからメール送信を許可するかを記述します。メールを受け取る側は、DNSサーバに問い合わせて、送信元がそれに一致するかを確認することにより、スパムかどうかをチェックすることができます。この技術は、送信側、受信側が共に対応して初めて効果を発揮するもので、対応サーバが少ないうちは、あまり効果がありませんが、将来対応していないメールサーバからの受け取りを拒否する用になる可能性もあるので早めに対応しておきましょう。
(現在、作成中)
最終更新日