株式会社 協栄情報 Tech Career

DNSレコードは「暗記科目」ではありません。 A、AAAA、CNAME、MX、TXT、NS、HTTPS――。 一見すると暗号のようですが、すべて「DNSに何を質問するか」の違いです。 ・A 「この名前のIPv4アドレスは？」 ・AAAA 「この名前のIPv6アドレスは？」 ・CNAME 「この別名が示す正規名は？」 ・MX 「このドメイン宛てのメールを、どのサーバーへ配送する？」 複数ある場合は、原則として数値の小さいものが優先されます。 ・NS 「このゾーンの情報に責任を持つ権威DNSサーバーは？」 ・TXT 「この名前に、どんなテキスト情報が公開されている？」 SPFなどの送信ポリシー、DKIM公開鍵、ドメイン制御確認用の値などに使われます。 ・HTTPS／SVCB 「このサービスへ、どの接続先・ポート・プロトコルで接続できる？」 2023年にRFC 9460として標準化され、HTTP/3などの利用候補を接続前に伝えることもできます。 ここからが、現場で重要なポイントです。 ① 複数のAレコード≠本格的なロードバランサー 複数のアドレスを返す、いわゆるDNSラウンドロビンは可能です。しかし、複数のAレコードを並べるだけでは、均等な振り分けや死活監視、即時フェイルオーバーは保証されません。 ② CNAMEはほかのレコードと同居できない DNSSEC関連を除き、CNAMEを設定した名前には、原則としてほかのデータを置けません。 ゾーン頂点にはSOAやNSが必要なため、通常のCNAMEは設定できません。Amazon Route 53のAliasは、この制約を回避できるAWS独自の拡張機能であり、CNAMEそのものではありません。 ③ 公開DNSのTXTレコードは秘密の保管場所ではない ドメイン制御の確認コードや公開鍵は置けますが、APIキーやパスワードを入れてはいけません。 ④ NSレコードは通信の転送設定ではない NSレコードが委任するのは、Webリクエストではなく「そのゾーンのDNS情報を管理・回答する責任」です。 DNS障害を切り分けるときは、値だけを見るのではなく、 ・何のレコードタイプを問い合わせたか ・どのDNSサーバーへ問い合わせたか ・キャッシュやTTLの影響を受けていないか を分けて考えることが重要です。 レコードの名前を暗記するより、「DNSに何を質問し、誰が答えているのか」を理解する。 それだけで、DNSは謎の呪文から、筋道の見える仕組みに変わります。 協栄情報では(というか私が関わるプロジェクトでは)、こうした基礎技術を現場の切り分けにつながる形で理解し、チームで共有することを心がけており、こうした姿勢・取り組みを積極的に評価しています。

「DNSを変更したのに、まだ切り替わらない…」 一般に「DNSの反映待ち」と呼ばれる現象では、変更前の応答がキャッシュDNSに残っていることが主な原因の一つです。 DNSレコードは利用者側へ一斉配布されるものではありません。キャッシュDNSは通常、取得した応答をTTLの有効期間中保持し、期限後に必要に応じて権威DNSへ再問い合わせします。 トラブル時は、 ・各権威DNSが新しい値を返すか ・利用しているキャッシュDNSが何を返すか ・digで確認したTTLが何秒か を切り分けます。応答の比較には、digやnslookupが役立ちます。 DNSは敬遠されがちですが、名前解決とキャッシュの流れを理解すれば、Web・クラウド・メールなど幅広い分野で長く役立つ基礎技術です。 私たち協栄情報は、こうした「地味だけれど重要な技術」を仕組みから理解し、チームで共有することを大切にしています。