サーチリストを使った名前解決はやめよう

DNS を運用していると名前衝突問題に気を付ける必要がある．名前衝突問題とは，組織が内部的に使う Top Level Domain（TLD）とインターネットで利用できる TLD が重複してしまうことによりDNSの動作が期待するものとは違った動作になることを指す．名前衝突問題で具体的に問題となるのは，例えばインターネット上のドメイン名を検索するつもりが，ローカルネットワークで独自に付けたTLDに対して名前解決を行ってしまうことや，またその反対に，ローカルネットワークのドメイン名を検索するつもりがインターネット上の TLD に対して名前解決してしまうことである．JPNIC のページが詳しいのでリンクを置いておく．

www.nic.ad.jp

今回は後者の問題である「ローカルネットワークのドメイン名を検索するつもりがインターネット上の TLD に対して名前解決してしまう」という事象を再現してみようと思う．上記の記事で紹介されているサーチリストを使ったケースを想定する．

概要

環境として使うのは AWS とし，AWS の各サービスの説明は本質的な部分とは異なるので今回は割愛する．

dig コマンドで名前解決の確認を行うために OS を Ubuntu18.04 とした EC2 を立てておく．EC2 から利用する内部的に使うドメインは Route53 で管理し， example.com という名前でプライベートホストゾーンを作成する．プライベートホストゾーンにインターネット上に存在するサブドメインを登録し，サーチリストを設定した EC2 から名前解決を行うと「ローカルネットワークのドメイン名を検索するつもりがインターネット上の TLD に対して名前解決してしまう」が再現することを確認する．

Route53 の設定

Route53 では example.com というプライベートホストゾーンを作成し，適当なプライベート IP アドレス（172.30.20.86）を指定した 2 つの A レコードを登録しておく．

後に設定するサーチリストの挙動を確かめる用途で使う instance-dst というサブドメイン
インターネットに存在するドメインと重複させるための dns1.nic.aws というサブドメイン

aws という TLD は AWS が取得しているドメインであり， dns1.nic.aws を名前解決すると既に A レコードを正引きすることができる．

Route53 の設定を以下の図に示す．

f:id:a-mochan:20211031174115p:plain — Route53の設定

サーチリストの設定

EC2 でサーチリストを設定する．

サーチリストは、DNS検索サフィックス、 DNS suffix search listなどとも呼ばれる、ユーザーがドメイン名を入力する手間を減らせるようにするためのリストです。具体的にはDNSにおいて、名前解決の際にドメイン名を最後まで入力しなくても、サーバやクライアントで補完がされるように、補完候補となる文字列を順番に並べたものです。 www.nic.ad.jp

Ubuntu18.04 の場合 EC2 上で /etc/netplan/99-manual.yaml というファイル名を以下の内容で作成し再起動すればよい．

network:
    ethernets:
        eth0:
            nameservers:
                search:
                  - example.com
    version: 2

再起動した EC2 にログインし，サーチリストを使うようにオプションをつけた dig を実行すると example.com が補完され instance-dst.example.com を名前解決できていることが確認できる．

root@ip-172-30-20-203:/etc# dig instance-dst +search

; <<>> DiG 9.11.3-1ubuntu1.16-Ubuntu <<>> instance-dst +search
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41197
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;instance-dst.example.com.  IN  A

;; ANSWER SECTION:
instance-dst.example.com. 300   IN  A   172.30.20.86

;; Query time: 2 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Oct 31 08:55:09 UTC 2021
;; MSG SIZE  rcvd: 69

では，プライベートホストゾーンに登録してあるもう 1 つのサブドメインの dns1.nic.aws を名前解決してみる．

root@ip-172-30-20-203:/etc# dig dns1.nic.aws +search

; <<>> DiG 9.11.3-1ubuntu1.16-Ubuntu <<>> dns1.nic.aws +search
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8193
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;dns1.nic.aws.          IN  A

;; ANSWER SECTION:
dns1.nic.aws.       300 IN  A   213.248.218.53

;; Query time: 2 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Oct 31 08:58:35 UTC 2021
;; MSG SIZE  rcvd: 57

名前解決の結果 172.30.20.86 ではなく 213.248.218.53 が返ってきている．これより，プライベートホストゾーンではなくインターネットで公開されているドメインが正引きされていることが分かる．これは，サーチリストの補完が行われる前にまずは dig コマンドで指定されたドメインが名前解決されるため， dns1.nic.aws の正引き結果が返ってきてしまっている状態である．この事象は，プライベートホストゾーンのサブドメインを運用中にそのサブドメインとインターネットに存在するドメインが重複した場合，サーチリストを設定したサーバからの名前解決が失敗する可能性があることを示している．