カテゴリー別アーカイブ: Network

squid の名前解決

Squid を 3.0.9 から 3.5.19 にあげたらアクセスできなくなったのでメモ

NetBSD サーバの pkgsrc を 2016Q2 にし、squid を更新したところ 3.0.9 が 3.5.19 になった。

以前に特別な設定はしていなかったことを確認して、デフォルトの squid.conf を /usr/pkg/etc/squid/ にコピー。
squid を起動…したところつながらない。

ブラウザにはエラーが出ている。

ホスト名 “qiita.com” の IPアドレスがわかりません。

名前解決のエラーだ。

言うまでもないが、squid 以外の接続は正常で、ローカルの DNS は問題ない。

cache.log を見ると

2016/07/26 xx:xx:xx kid1| Adding nameserver 0.0.0.0 from /etc/resolv.conf
2016/07/26 xx:xx:xx kid1| WARNING: Squid does not accept 0.0.0.0 in DNS server specifications.
2016/07/26 xx:xx:xx kid1| Will be using [::1] instead, assuming you meant that DNS is running on the same machine

/etc/resolv.conf で指定した 0.0.0.0 が [::1] にフォールバックしている。
3.0.9 のときのログを見るとここは 127.0.0.1 だった。
というか 0.0.0.0 が許可されていないことに気づいてなかった。

ローカルの named はオプション -4 で運用しているのでつながらなかったわけだ。

どうしたものかちょっと考えた結果、squid.conf で明示的に 127.0.0.1 を指定することに。

dns_nameservers 127.0.0.1

今まで深くは考えていなかったけど、resolv.conf での 0.0.0.0 の指定ってどうなんだろう?

zoneedit と ddclient

zoneedit の dynamic DNS の更新に ddclient (pkgsrc/net/ddcleint) を利用していたのだが、エラーが出て更新できなくなってしまった。

zoneedit のアナウンスとかは見当たらなかったが、どうやら HTTPS でのみ更新が可能なように仕様が変更されたっぽい。

pkgsrc-2014Q1 の ddclient-3.6.6 は SSL が使用できないが、最新版では使用できるらしいとの話を聞きつけて、ddclient-3.8.2 を本家から持ってきて試してみたのだがエラーが出てうまくいかない。

syswrite() on closed filehandle GEN1 at ./ddclient line 1902.
Use of uninitialized value $result in numeric ne (!=) at ./ddclient line 1904.
WARNING:  cannot send to dynamic.zoneedit.com:443 (Bad file descriptor).

デバッグ出力を埋め込んで調べてみると、zoneedit の SSL 証明書の検証ができなくて失敗していることがわかった。

WARNING:  cannot connect to dynamic.zoneedit.com:443 socket: SSL connect attempt failed with unknown error error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed SSL connect attempt failed with unknown error error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

とはいえ、ブラウザはともかく、NetBSD で SSL ルート証明書の管理などしてない。どうしよう。

結局、検証は行わないように ddclient を修正して対処した。

@@ -1881,8 +1880,9 @@
             Proto => 'tcp',
             MultiHomed => 1,
             Timeout => opt('timeout'),
+            SSL_verify_mode => IO::Socket::SSL::SSL_VERIFY_NONE(),
         );
-           defined $sd or warning("cannot connect to $peer:$port socket: $@ " . IO::Socket::SSL::errstr());
+           fileno($sd) or warning("cannot connect to $peer:$port socket: $@ " . IO::Socket::SSL::errstr());
     } else {
            $sd = IO::Socket::INET->new(
             PeerAddr => $peer,

SSL_VERYFY_NONE は IO::Socket::SSL 内で定義されている定数だが、他所から明示的に参照したいときはサブルーチンのように記述すれば良いらしい。

あと、IPアドレス取得用の URL も https://dynamic.zoneedit.com/checkip.html のように HTTPS しか受け付けなくなってしまった。上記の修正だけでは HTTP で取得しようとしてしまうのだが、ddclient.conf の web の引数に https:// を付けて記述すればよい。

use=web, web=https://dynamic.zoneedit.com/checkip.html, web-skip='IP Address'

NetBSD-6.0 on Hyper-V

NetBSD-6.0 がリリースされたので、 Hyper-V のゲストとしてインストールしてみた。

boot 時のオプションで SMP と ACPI を無効にしないとネットワークドライバ tlp(4) が機能しないのは 5.x までの時と同じ。

でも、 ACPI を無効にするとリブートが途中で止まって再起動できない。ACPI が有効だと再起動できる。

5.x のときは ACPI 無効でも再起動できたんだが、これだとちょっと使えないなぁ。

BIND9 のエラー その他

まず、1件目。

...
Feb 22 12:44:27 hanon named[11934]: error (unexpected RCODE REFUSED) resolving 'ns.bta.net.cn/A/IN': 202.106.196.233#53
Feb 22 12:44:27 hanon named[11934]: error (unexpected RCODE REFUSED) resolving 'ns.bta.net.cn/A/IN': 202.106.196.234#53
...

RCODE とは DNS のレスポンスコードで “5:何らかの理由による拒否(Refused)” ということらしい。

このケースでは、たまたま、ということで無視して良いのかな?

2件目。

...
Feb 22 12:44:31 hanon named[11934]: lame server resolving '150.199.96.202.in-addr.arpa' (in '199.96.202.in-addr.arpa'?): 211.147.6.4#53
Feb 22 12:44:31 hanon named[11934]:   validating @0xb9201000: 96.202.in-addr.arpa SOA: got insecure response; parent indicates it should be secure
Feb 22 12:44:36 hanon named[11934]:   validating @0xb9201000: 96.202.in-addr.arpa SOA: got insecure response; parent indicates it should be secure
Feb 22 12:44:38 hanon named[11934]:   validating @0xb9201000: 96.202.in-addr.arpa SOA: got insecure response; parent indicates it should be secure
...

lame server resolving というのは、向こうのサーバがちゃんとしていない時に出るらしい。逆引きの時によく見られるようで、下のケースでも逆引きの時に発生している。

validation … got insecure response は DNSSEC の検証ができないということなのかな? 何か同じようなのが連続して大量に出力されているのはちょっと気になるところ。

上の2ケースは発生時間も近いし、同一のネームサーバ上のレコードに関連しているような感じなので、実は一連のエラーなのかもしれない。

とにかく、向こう側の問題のようなので、こちら側で対応する必要はなさそうだが、この類のエラーが頻発するようなら、ログを吐かないように調整する必要があるかも。

BIND9 のエラー (DNSSEC 関連?)

NetBSD を 5.1.2 にアップデートしたところ、システム標準の named.conf に DNSSEC の設定が追加され(cvs で確認すると 5.1.1 RELEASE からのようだ)、デフォルトで DNSSEC が有効になったようだ。

とりあえず、マージして運用してみたが、ログに下のようなエラーが出てくる。

...
named: error (host unreachable) resolving 'dns-a.iij.ad.jp/A/IN': 2001:2f8:0:100::153#53
...

メッセージのうち、ホスト名っぽいところはいろいろ、レコード種別っぽいところは ‘A’ 以外に ‘AAAA’, ‘PTR’, ‘DS’ , ‘DNSKEY’, ‘DLV’ などがある。最後のアドレスらしき箇所は IPv6 形式のみで IPv4 形式の物は見られない。

状況から察するに、IPv6 で接続できなくてエラーになっているのだろう。

このホストは IPv6 unreachable なところに置かれているので、接続できないのはしかたがない。BIND9 の方で IPv6 を使わないように設定するのが妥当だろう。

BIND9 のマニュアルを見たのだが、named.conf の IPv6 関連のオプションは複数あって、今回の問題にはどれが該当するのかがよくわからない。一括で無効にする指定ができるのかどうかもわからなかった。

一方、コマンドラインオプションで ‘-4’ を指定すれば一括で無効にするとかができるということなので、rc.conf に named_flags=”-4″ を追加することにした。

サーバの引越し(6) MX

前回のエントリの最後で、uconst.org の MX が記述できないことを書いた。誤解がないように、もう少し詳しく説明する。

まず、さくらのレンタルサーバでは、バーチャルドメインの指定をすることで、指定したドメインのメールを自分宛のメールとして受け取ることが出来るようになる。

つまり、バーチャルドメインとして example.org を指定すれば、example.org 宛のメールが受信可能となる。

しかし、バーチャルドメインとして www.example.org を指定するなら、受信可能なメールは www.example.com 宛であって、 example.com 宛ではない。

であるので、uconst.org 宛のメールを受信したければ、バーチャルドメインには uconst.org を指定して、ドメイン全体を管理すべきである。さくら的には。

ドメインには他のホストもあるので、ドメイン全体をさくらで管理するわけにはいかない。

メールを受け付けるドメインを、DNSの設定とは別に追加できるようになっているとよかったのだけれど。

やむを得ないので、MX はフリーのメール転送サービスに向けて、そちらから www.uconst.org に転送することにした。

サーバの引越し(5) DNS

このサイトの今のレジストラは お名前.com にしている。以前は海外のレジストラで登録していたのだけれども、お名前.com の方が料金が安いので、1年程前にレジストラ移管の手続きを行った。

切り替えたときは、自前のサーバを運用していたので、プライマリDNSも当然のように同じサーバで運用していた。そもそも切り替え以前のレジストラでは、DNSサーバを自前で用意するシステムだったので、他の選択肢はなかった。
このとき、セカンダリDNSはフリーのサービスを利用していた。

今回の引越しでは、公開サービスとしての自前のサーバはなくなってしまうので、プライマリDNSをどうするかを決めなくてはならない。

選択の際に重視したのは、コストと安定性。

まず、フリーのサービスをいくつか試してみたが、安定性に欠けるものや、登録内容が反映されないようなものしかなく、候補に残るものはなかった。原因が自分のオペレーションにあるかもしれないので、試して駄目だったサービスをここに記述することはやめておく。確認したのは当該サービスの質の良し悪しではなく、単に、オペレータである私との相性が悪かったというだけのことである。

お名前.com にもプライマリDNSのサービスがあり、レジストラをして利用しているので無料で利用出来る。操作は簡単だが、登録できる内容には制限があるようだ。

一番問題だったのは CNAME に異なるドメインのホストを指定できないことかな。何のための CNAME なんだか。

さくらのレンタルサーバで、バーチャルドメインの設定をすると、登録したバーチャルドメイン名の NS レコードと A レコード、そしてそのサブドメイン (www, mail など) の CNAME が登録される。

さくらのバーチャルドメイン名として www.uconst.org を設定して、お名前.com には www.uconst.org の NS に該当するさくらのネームサーバを指定すると、DNSで www.uconst.org の A レコードを検索することができる。

DNSレコードのイメージでいうと、以下のような感じ。

お名前.com
uconst.org.      IN  NS  01.dnsv.jp.     ; お名前.com のDNSサーバ
IN  NS  02.dnsv.jp.     ; お名前.com のDNSサーバ
www.uconst.org.  IN  NS  ns1.dns.ne.jp.  ; さくらのDNSサーバ
IN  NS  ns2.dns.ne.jp.  ; さくらのDNSサーバ
さくら
www.uconst.org.  IN  NS  ns1.dns.ne.jp.  ; さくらのDNSサーバ
IN  NS  ns2.dns.ne.jp.  ; さくらのDNSサーバ
IN  A   xxx.xxx.xxx.xxx ; レンタルサーバのIPアドレス
IN  MX  10 www.uconst.org.
www.www.uconst.org.   IN  CNAME  www.uconst.org.
mail.www.uconst.org.  IN  CNAME  www.uconst.org.

お名前.com でさくらのレンタルサーバを直接 CNAME 指定できないので、こんな構成になる。

何が問題かというと、www.www.uconst.org だの、 mail.www.uconst.org とかいうホスト名が生じてしまう (さくらの方のシステムで自動的に作成される) ことかな。まあ、気にしなければよいだけのことか。

書き忘れる所だった。これだと uconst.org の MX を記述してさくらのレンタルサーバで受けることができない。

この問題と、とった回避策は後ほど。

サーバの引越し(4) メールボックスの移動

移行先のメールサーバはさくらのメールボックスとした。
対外的なメールアドレスはさくらのアドレスとして、
さくらから uconst.org にメールの転送設定をしてある。

つまり、全てのメールがさくら経由で uconst.org に配送される状態である。

これを、さくらに配送されるように切り替える。

手順は以下のとおり。

  1. uconst.org の SMTP サーバ (Postfix) を停止する。
  2. メールボックスの中身をコピーする。
  3. さくらから uconst.org へのメール転送設定を解除
  4. uconst.org からさくらへのメール転送設定
  5. uconst.org の SMTP サーバ (Postfix) を起動する。

メールボックスのコピーは imapsync を使用した。

imapsync \
--host1 mail.uconst.org --ssl1 \
--user1 user_at_uconst_org --passfile1 pwfile_imap_uconst_org \
--host2 subdomain.sakura.ne.jp --ssl2 --authmech2 plain \
--user2 user_at_sakura@subdomain.sakura.ne.jp --passfile2 pwfile_imap_sakura

これで、外部にアナウンスしている subdomain.sakura.ne.jp 宛のメールは
直接 subdomain.sakura.ne.jp に入るようになった。

そして、uconst.org 宛のメールは、subdomain.sakura.ne.jp に転送される。

あとは、uconst.org の MX レコードをさくらに向ければ完了…のはずだったが。

続きは DNS の設定編で。

サーバの引越し(3) これまでのメールサーバの構成

メールサーバの移行の前に、現状の構成の整理

受信については、各プロバイダのメールを全て、独自ドメインのサーバに転送するよう設定している。
サーバのアプリケーションは Postfix。
SASL などを使用できるよう、NetBSD 付属のではなく、
pkgsrc で mk.conf に以下のオプションを指定して作成したものを使用している。

PKG_OPTIONS.postfix = sasl pcre

IMAPサーバは Dovecot で運用。
Postfix の main.conf に以下を記述し、
ローカル配送に Dovecot の配送プログラムを使用するようにしている。

/usr/pkg/etc/postfix/main.conf
mailbox_command = /usr/pkg/libexec/dovecot/delive

送信は、独自ドメインのサーバ(Postfix)で全てを一旦受け取る。
ここは、Postfix でいう smtpd の担当。

送信の場合のメールクライアントからの受付は submission port (587) で、
STARTTLS、認証必須。
認証は Dovecot の認証用のソケット(ここでは /var/run/dovecot/auth-client)を利用。
STARTTLS で使用するサーバ証明書は、openssl で第四種オレオレ証明書を作成。

/usr/pkg/etc/postfix/master.cf
submission inet n       -       n       -       -       smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
/usr/pkg/etc/postfix/main.cf
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
smtpd_tls_cert_file = /etc/openssl/certs/mailservercert.pem
smtpd_tls_key_file = /etc/openssl/private/serverkey.pem
smtpd_sasl_type = dovecot
smtpd_sasl_path = /var/run/dovecot/auth-client

Dovecot の認証用ソケットの設定(IMAP用も兼用)は以下。
認証は、UNIX のパスワード認証(passdb passwd)と
パスワードファイルによる認証 (passdb passwd-file)を使用可能とし、
パスワードファイルによる認証スキームとして CRAM-MD5 を指定している。

/usr/pkg/etc/dovecot.conf
auth default {
mechanisms = plain cram-md5
passdb passwd {
}
passdb passwd-file {
args = scheme=cram-md5 /usr/pkg/etc/cram-md5.pwd
}
userdb passwd {
}
user = root
socket listen {
client {
path = /var/run/dovecot/auth-client
mode = 0660
group = mail
}
}
}

Dovecot での CRAM-MD5 のパスワードは以下のようにして作成する。

$ dovecotpw -s CRAM-MD5
Enter new password: XXXXXX
Retype new password: XXXXXX
{CRAM-MD5}00747cf2ffaf11c5ea4a64979c3901fc1d20dee13f480bb598f7d8575b23e61b

“{CRAM-MD5}” より後の部分が CRAM-MD5 のパスワードのデータである。
これを切り取って、ユーザ名、”:”、パスワードデータ の形式で cram-md5.pwd に記述すればよい。
cram-md5.pwd は先の dovecot.conf 中で指定したファイルである。

/usr/pkg/etc/cram-md5.pwd
hoge:00747cf2ffaf11c5ea4a64979c3901fc1d20dee13f480bb598f7d8575b23e61b
fuga:4b05653a6b48eeeb7ef25800a514e2fe6d6ea31ff6d3a17bd2f4ac7cad390426

CRAM-MD5 だと MD5 の計算途中のデータを保存するので、
生のパスワードを保存するよりは安全らしい。

受け取ったメールは envelope sender の値に応じて、
送信する SMTP サーバを切り替える。
直接相手先には送らない。
独自ドメインを取得してはいるが、プロバイダのメールアドレスを使用して送るメールについては、
できるだけ一般のクライアントと同様となるように経路を選択するポリシーを適用する。

たとえば、 メールの envelope sender がプロバイダ A 所属のアドレスが記述されていれば
A の送信用サーバに、
プロバイダ B 所属のアドレスが記述されていれば
B の送信用サーバにメールを転送するといった具合である。

送信用サーバごとに切り替える情報は以下のとおり。

  • SMTPサーバのアドレスとポート (25 または 587)
  • 認証用IDとパスワードのセット

envelope sender で切り替えを行う設定は、以下のとおり。

/usr/pkg/etc/postfix/main.cf
sender_dependent_default_transport_maps =
hash:$config_directory/sender_transport
/usr/pkg/etc/postfix/sender_transport
@プロバイダAのドメイン     smtp:[Aの送信用サーバ]:587
@プロバイダBのドメイン     smtp:[Bの送信用サーバ]:587
@gmail.com                 smtp:[smtp.gmail.com]:587

プロバイダの送信用サーバは認証が必要(とくにそのプロバイダを接続業者としていない場合は)なので、
送信用サーバとその認証情報を関連付ける。

/usr/pkg/etc/postfix/main.cf
smtp_tls_security_level = may
smtp_sasl_auth_enable = yes
smtp_sasl_type = cyrus
smtp_sasl_password_maps = hash:$config_directory/sasl_passwd
smtp_sasl_tls_security_options = noanonymous
/usr/pkg/etc/postfix/sasl_passwd
[Aの送信用サーバ]:587   AのID:Aのパスワード
[Bの送信用サーバ]:587   BのID:Bのパスワード
[gmail.com]:587         gmailのID:gmailのパスワード

プロバイダへの送信時に使用する認証IDは、
メールを送信したユーザに関係なく共通になってしまうが、
ここは気にしないことにする。

あと、sender_transport や sasl_passwd は postmap を使って hashed database にしておく。

駆け足で、これまでの構成を記述したが、
あらためて読み返すとずいぶん複雑なものになってしまっている。
メールサーバを移行してしまった後は、これらは全て不要となるわけだが…。

サーバの引越し(2) メールサーバの選定

これまでは、固定IPを取得して外部に公開しているサーバで postfix を動かしてメールを受けていた。
このサーバは独自ドメインの名前をつけてある。
契約しているプロバイダのメールはこのサーバに転送し、まとめて参照するようにしていた。

送信するメールの発信元が独自ドメインだと、送り先によっては信用が足りないケースが懸念されるので、
公式には契約しているプロバイダのうち、最も古くから使用しているものを公式なメールアドレスとして使用していた。
具体的には IIJ4U であるが、これが長い間、メールアドレスを維持するためだけの契約となっていたのである。

ちなみに、IIJ4Uではメールアドレス付きの基本料金が840円/月、
アドレスを一つ追加するごとに+315円/月である。
いまどきの感覚だと、さすがにリーズナブルとはいいがたいのではなかろうか。

回線業者はこれまでに何度も切り替わっており、今後も切り替わる可能性が高いので、
回線業者の提供するメールアドレスとは独立している方が望ましい。
複数のアドレスを取得した場合に安価であることが必要だ。できれば追加料金はないほうがよい。

普段メールをチェックしないユーザも抱えているので、無料のサーバは使えない。
というのは、無料のサーバは一定期間利用しないと削除されてしまうからだ。
少なくとも調べた範囲ではそうなっていた。

また、複数の場所からメールを参照したいので、IMAPは必須である。

ということで、さくらインターネットのさくらメールボックスが候補に残った。

年間料金が1000円で、複数アドレスが作り放題なので、条件的としては申し分ない。
また、自由度も比較的高いようで、独自ドメインのメールを直接受けることもできる。

早速、さくらと契約した。

まずは、各所に登録しているアドレス(IIJ4U)をさくらに作成したアドレスに変更することだ。

大抵のところでは、ログインパスワードを忘れた場合、
パスワードを再登録するためのページを一時的作成して、そのアドレスを登録してあるメールアドレスに送ってくれる。

そのメールアドレスがなくなると、二度とログインできなくなってしまう。

新規登録しても問題ないようなものとか、
別経路(書類)で本人確認できるようなところ(銀行など)であればまだ何とかなるが、
mixy や flickr など、どうしようもないところもあるし、できるだけ面倒は避けたい。

思いつく限り、調べられる限りの所をリストアップして、メールアドレスの変更手続を行っていく。
アカウント情報を削除して構わないところは、この機会に削除手続きを行う。
あとは、不通になっても構わないところだけ。

もちろん自分だけではなく、メールを移行する他のユーザにもお願いして、
変更手続を行ってもらわなければならない。

面倒ではあるが、この作業を丁寧にやることがその後のトラブルを避ける最も近道であるはずだ。

普通の人はどうしているのだろう?