Category: 192.jp

  • Fedora 35に更新

    リリースされたので更新しました。

  • DNS構築

    192.jpゾーンを立てました。 VPS内にプライマリDNSサーバとしてNSDを立て、ゾーンの編集など管理を行う さくらインターネットのネームサーバをセカンダリサーバにし、一般に公開する DNSの設定 VPS内に構築するDNSは外部から見えないため、よく使われるBINDでも良いのですが、ものは試しでNSDを使うことにしました。 NSDはFedoraリポジトリに置かれているため、DNFで入れました。 その上で、ゾーンファイルとゾーン設定ファイルを作成します。ここではゾーン設定ファイルを示すのみで、ゾーンファイルは省略します。 ゾーン更新時の通知先を指定するnotify、および許可するゾーン転送サーバを指定するprivide-xfrで指定しているIPアドレスはドキュメントに書かれているものになります。 ※ プライマリネームサーバにて弊社ネームサーバ(210.188.224.9 / 210.224.172.13)からの問い合わせを許可するように設定してください。 ネームサーバ利用申請 – さくらのサポート情報 セカンダリDNSサーバのみ公開 続いてVPS内のDNSサーバを一般に公開せず、セカンダリDNSサーバのみアクセス可能にします。Fedora 32での標準的なパケットフィルタであるFirewalldを使って対応しました。 まずIPアドレスベースで通信の許可を設定します。Firewalldではzoneを分けることで設定しますので、dns-secondaryというゾーンを作成し、送信元IPアドレスを設定しました。これによりセカンダリDNSサーバからの問い合わせ通信はdns-secondaryで処理されます。そしてこのゾーンにdnsサービスの許可を指定します。具体的には次のコマンドを実行しています。 ここまでの変更は直ちに反映されますので、この状態で次の確認を行いました。 セカンダリDNSサーバからのDNS問い合わせへ応答していること(tcpdumpを使って確認) ほかのホストからDNS応答がないこと(手元から確認) 接続の確認が終わったら設定ファイルへ書き出し、サーバの再起動以降も通信許可設定が適用される設定とします。 以上で設定を終えました。

  • サーバ構築中

    ふたたびゼロからサーバ構築を始めました。 なぜサーバを構築するのか? AWSやAzureといったパブリッククラウド基盤が一般的になり、基盤の面倒を見なくて良い世界になりつつあります。アプリケーション開発においてもDockerコンテナを使うことで、基盤部分とアプリケーション部分の分離が進んでいます。 一方でクラウドサービスもコンテナ技術も、一般的なサーバ上に構築されています。数年経つことで新しい技術・実装もあるので、復習を兼ねて新しくサーバを構築することにしました。 ホスト先をどこにするか? 今は様々なパブリッククラウドを使う機会に恵まれているため、いままで利用していたさくらインターネットのVPSを選択しました。 OSは何にするか? 今回はFedoraにしました。現時点で最新の32にしています。 今まではRHEL互換のCentOSを使うことが多かったですが、CentOS 7から8へ公式のバージョンアップがサポートされていませんでした。Fedoraは半年に1回のバージョンアップを行う必要はあるもののバージョンアップの対応は可能なので、長期的にみてメリットが大きいと考えました。

  • サーバの引っ越し中

    重い腰を上げてサーバの引っ越し中です。 見えるようになったり、見えなくなったりしています。

  • KSKの更新

    2013年10月から192.jpにDNSSECを実施していますが、KSKやZSKの見直しと更新をしました。ここでは、KSKの更新手順についてまとめたいと思います。