DNSサーバについて

ネスぺ平成29年の午後2の問1でSDNとDNSについての問題が出題されました。DNSについてはリソースレコードの記述方法やセキュリティ対策など弱いところがあることが分かったので、自分の備忘録としてDNSについて整理しました。
自分の試験前の見直し用ですので、間違いがあったらご指摘ください。

 

目次

 


DNSの問合せ方法

DNSの問い合わせ方法は以下のように「再帰問い合わせ」と「反復問い合わせ」の2種類の問い合わせを介して実行される。

引用元: https://www.infraexpert.com/study/tcpip15.html
  • 再帰問い合わせ」はPC(DNSリゾルバ)が最初に問い合わせを行うDNSサーバに対して行う。このDNSサーバは問い合わせを受けたドメインに対して名前を解決するために、ルートDNSから順次「反復問い合わせ」を実施していく。
    最終的に指定されたドメインのIPアドレスが入手出来たら、DNSリゾルバに対して、IPアドレスを応答する。
  • 反復問い合わせ」を受け取るDNSサーバを権威DNSサーバ(コンテンツサーバ)と呼び、多段階に分散された構成を持つ。
  • 再帰問い合わせ」を受け取るDNSサーバは、キャッシュ機能をもったDNSキャッシュサーバやISPが提供しているDNSキャッシュサーバへ問い合わせを転送するだけのスレーブサーバ(フォワーダとしてISPのDNSキャッシュサーバを指定)が採用される。
  • 上記図にはないが、各階層のDNSサーバは冗長化構成をしている。
    メインのDNSサーバをプライマリDNSサーバと呼び、冗長化構成されたサーバをセカンダリDNSサーバと呼ばれる。

 

DNSで使用されるパケットとしては用途に合わせてTCPパケットとUDPパケットが使用される。

引用元: https://www.infraexpert.com/study/tcpip15.html
  • DNSリゾルバからDNSサーバへの問い合わせは宛先ポート53のUDPパケットが使用される。
  • プライマリサーバからセカンダリサーバへのゾーンファイルの転送(ゾーン転送)は宛先ポート53のTCPパケットが使用される。
  • ゾーンファイルの記述内容については次の章を参照。

 

 

 

DNSのゾーンファイル

DNSサーバは冗長構成をとっており、プライマリサーバからセカンダリサーバ。。。などの冗長化したサーバに対してゾーン転送を行っており。
ゾーン転送ではゾーンファイルと呼ばれるデータをやり取りしている。

ゾーンファイルについては以下のサイトが分かりやすいので詳細はそちらで確認する。

参考:

 

ここでは備忘録として気を付けることだけを記述する。

  • ゾーンファイルは複数のリソースレコードで構成されている。
  • リソースレコードは省略した形式とそのままかく形式がある。
    ※ネスぺ平成29年の午後2の問1では省略形式が出題された。
  • 各リソースレコードの概要は下記。
    ネスぺ平成29年の午後2の問1では、ISP上にあるDNSサーバから他のDNSサーバに切り替えを行うときに、CNAMEで指定する問題が出た。
リソースレコード説明
SOAレコード
(Start of Authority)
プライマリサーバのドメイン名、管理者のメールアドレス、ゾーン情報を記述する。
NSレコード
(Name Server)
下位のドメインサーバのドメインを記述する。
記述したドメインのIPアドレスはAレコードで記述する。
Aレコード
(host Address)
ホスト名とIPアドレスの紐づけを記述する。
MX レコード
(Mail eXchange)
ドメイン名とメールサーバの紐づけを記述する。
そのドメインあてに送信されたメールは指定されたメールサーバに転送される。
CNAME レコード
(Canonical Name)
エイリアス(別名)と正式のドメイン名の紐づけを記述する。
PTR レコード
(PoinTeR)
IPアドレスとホスト名の紐づけを記述する。
TXTレコード
(TeXT strings)
ホスト名にテキスト情報を付加する。
ドメイン所有者であることを証明するために、認証コードをTXTレコードに記述して認証することができる。(こちらを参考)

 

 

 

DNSのセキュリティ対策

以下ではDNSに関するセキュリティ対策をまとめる。

 

コンテンツサーバとキャッシュサーバを分ける

DMZのような外部からアクセスできるところにはコンテンツサーバのみを設置し、キャッシュサーバは外部から直接アクセスできないところに設置する。
キャッシュサーバへの攻撃にDNSキャッシュポイズニングがあるが、キャッシュを内部に設置することで直接アクセスの改ざんから守ることができる。
コンテンツサーバへのセキュリティ対策はDNSSECを使う。

 

外部DNS(コンテンツサーバ)には再帰問合せを禁止する

コンテンツサーバは反復問い合わせの応答をできれば良いので、再帰問い合わせは禁止する。

引用元: https://www.infraexpert.com/study/tcpip24.html

 

DNSSECを導入する

DNSSECとはDNSサーバの応答が改ざんされていないか検証したり、不正なDNSサーバでないかを認証するための仕組みである。
方法としては、DNSサーバの応答にDNSサーバの秘密鍵で電子署名をつけることで、応答に改ざんがないかの検証を行う。
また、DNSSECでは、この公開鍵の正当性を「信頼の連鎖(chain of trust)」と呼ばれる仕組みによって担保できるようになっており、これによりDNSサーバの認証をすることができる。
詳細については以下を参照。

参考:
DNSSEC | JPNIC

 

DKIMやSPFを導入する

DKIMやSPFはメールアドレスのDNS問い合わせに対して、セキュリティを上げる仕組み。
SPFは送信元メールサーバのIPアドレスをDNSサーバのSPFレコードに事前に登録しておくことで認証を行う。
DKIMは送信元メールサーバの公開鍵をDNSサーバに登録しておき、メールに付与された送信元メールサーバの電子署名をその公開鍵で検証することで認証を行う。
詳細については以下を参照。

参照:
SPF, DKIMの特徴と違い | SendGrid

 

 

 

関連情報

 

 

参考

以下の書籍やサイトをよく参考にしました。

 

以上!

Share

  • Add this entry to Hatena Bookmark

Follow Me