NSD4

2016年9月5日

9月になったので久々にLet’s Encryptによるサーバ証明書の自動更新具合をチェックしたところ、www.～の証明書なのにCNがmail.～になっている事に気づいた。

正確に言うと"今まで"気づいてなかった問題に"今になって"気づいたというのが正しく、最近おかしくなったわけではないと思うのだが、取り敢えず気づいたからには修正する方向でLet’s Encrypt の使い方を再確認。すると、「letsencrypt-auto/certbot-auto」においてドメイン名とサブドメイン名の両方を指定する必要があるような印象だったので、

sudo letsencrypt-auto certonly --webroot --webroot-path=/var/www/html \
        -d bravotouring.com -d www.bravotouring.com

としたものの、今度は**“bravotouring.comのアドレスが引けない”**と叱られた。

そら、bravotouring.comはドメインでホストじゃないから仕方ないじゃん…と思いつつ、ここで意地を張ってもしかたがないので、おとなしくDNSの設定を追加することに。

いつものとおり、/etc/nsd/zones/bravotouring.com.zoneのドメイン名の直下にCNAMEを

～～
       IN   CNAME  vps
vps    IN   A      49.212.151.67
vps    IN   AAAA   2403:3a00:202:1112:49:212:151:67
～～

…と追記して「えいや！」っとしたところ

yano@vps:~$ sudo nsdc rebuild
sudo: nsdc: **command not found**
yano@vps:~$

…な結果で、「nsdcどこ行ったの？？？？」という事にこれまた今頃気づいて大慌て。

色々と調べてみたら今年3月のアップデートでNSD 3からNSD 4に上がった形跡があり、その際にnsdc(8)やzonec(8)のコマンドも削除されたようだ。置き換えではなく「廃止」という事は、手順そのものが不要となったと考えるのが自然なのだが、DNSクエリを投げても返答は変わらず、/var/lib/nsd/nsd.dbも今年2月のタイムスタンプのままなので、NSDを再起動してsyslogを見たところ

nsd[6846]: bravotouring.com.zone:17: **CNAME and other data at the same name**
nsd[6846]: zone bravotouring.com file bravotouring.com.zone read with **1 errors**

なエラーが出ていた。

NSD4のプログラム — Unbound/NSD最新情報（OSC 2014 Tokyo/Spring）より

調べてみたところZone apexとCNAMEの制限にひっかかっているらしく、/etc/nsd/zones/bravotouring.com.zoneを

TTL 3600
@ IN SOA ns1.bravotouring.com. foo.bravotouring.com. (
            201609051429 ; serial
            10800  ; refresh
            3600   ; retry
            86400  ; expire
            43200  ; default_ttl
        )
       IN   NS     ns1.bravotouring.com.
       IN   NS     ns2.bravotouring.com.
       IN   MX 10  mail.bravotouring.com.
       IN   TXT    "v=spf1 mx a:foo.bravotouring.com ~all"
@      IN   A      49.212.151.67
@      IN   AAAA   2403:3a00:202:1112:49:212:151:67
vps    IN   CNAME  @
ns1    IN   CNAME  @
ns2    IN   CNAME  @
mail   IN   CNAME  @
www    IN   CNAME  @

…な感じで書き直して起動OK。なお、nsdc rebuild/reloadに代わるNSD 4でのzoneファイル更新は

yano@vps:~$ sudo nsd-control reload
ok
yano@vps:~$

となる模様。

その前に/etc/nsd/nsd.confに「control-enable: yes」を追記

#
# nsd.conf -- the NSD(8) configuration file, nsd.conf(5).
#
# Copyright (c) 2001-2006, NLnet Labs. All rights reserved.
#
# See LICENSE for the license.
#
# This is a comment.
# Sample configuration file
remote-control:
    control-enable: yes
～～

して、

yano@vps:~$ sudo nsd-control-setup
ok
yano@vps:~$

するのを忘れずに。

というわけで、

sudo letsencrypt-auto certonly --webroot --webroot-path=/var/www/html \
        -d bravotouring.com -d www.bravotouring.com

は通るようになったが、www.bravotouring.com代わりにbravotouring.comの証明書ができただけに終わり、結局

sudo letsencrypt-auto certonly --webroot --webroot-path=/var/www/html \
        -d www.bravotouring.com

で証明書を作りなおして、CNがwww.～になったので、問題は解決。

結局証明書のCNがmail.～になっていた原因はわからないままだが、改めてこれまでに作成した証明書のCNを洗ってみたところ、

cert1.pem    Subject: CN=www.bravotouring.com
 cert2.pem    Subject: CN=mail.bravotouring.com
 cert3.pem    Subject: CN=www.bravotouring.com
 cert4.pem    Subject: CN=www.bravotouring.com
 cert5.pem    Subject: CN=mail.bravotouring.com
 cert6.pem    Subject: CN=www.bravotouring.com
 cert7.pem    Subject: CN=mail.bravotouring.com
 cert8.pem    Subject: CN=mail.bravotouring.com
 cert9.pem    Subject: CN=mail.bravotouring.com
cert10.pem    Subject: CN=mail.bravotouring.com
cert11.pem    Subject: CN=mail.bravotouring.com
cert12.pem    Subject: CN=mail.bravotouring.com

と、wwwになったりmailになったり混在している傾向から、複数証明書を纏めて作成したケースにおけるletsencrypt-autoのバグのような気がする。

更新情報を保持している/etc/letsencrypt/renewal/www.bravotouring.com.confの

～～
domains = **mail.bravotouring.com, **www.bravotouring.com
[[webroot_map]]
**mail.bravotouring.com = /var/www/html**
www.bravotouring.com = /var/www/html

あたりが何だか怪しそうなので、ここだけ弄ってrenewalすれば良かったのかもしれないな。