web-dev-qa-db-ja.com

DNSゾーンのリソースレコードの有効性を確認する

私はPerlを使用していくつかのDNS操作タスクを実行しています。

DNSサーバーとして [〜#〜] nsd [〜#〜] を使用しています。

DNSゾーンファイル内のすべてのリソースレコードの名前が有効かどうかを確認するのが最善の方法を理解したいと思います。

チェックを行うには、(私が考えることができる)いくつかの可能性があるようです。

  1. nsd-checkzone
  2. すでに作成されたPerlモジュール https://metacpan.org/pod/Data::Validate::Domain
  3. 有効な名前とそうでない名前を記述しているすべてのRFCを知って、Perlで手動でチェックを行います。

私の意見では、主な問題は、リソースレコードの特別な名前が問題になるときに発生します。

例:オンラインで、リソースレコードの名前として*を使用する可能性があることを確認しました。

*                IN A      192.168.150.144

これはおそらく、他のレコードが一致しない場合にこのレコードを返すことを意味します。

this RFCのように、リソースレコードの「特別な」名前(逆引きDNSゾーン)もいくつか見ました。

   192/26          NS      ns.C.domain.
   192/26          NS      some.other.third.name.server.
   0/25            NS      ns.A.domain.
   0/25            NS      some.other.name.server.

追加の質問もあります:

  • フォワードDNSゾーンとリバースDNSゾーンで許可されているリソースレコードのこれらすべての特別な名前とその意味はどこで確認できますか? (私はそれらすべてを知りたいので:))
2
Subzero123

IMHOゾーンファイルは、テキストファイルとして操作するためのPITAです。

手始めに:

各RRは次のようになりますname ttl record_class record_type record_dataしかし:

  • nameは省略でき、レコードは前のレコードからフィールドを継承します。
  • ttlは省略でき、$TTLの値になります
  • record_classも、デフォルトのIN以外のものを使用する人はほとんどいないため、省略されることがよくあります。

そして、それはあなたの問題の始まりにすぎません。


特に、ゾーンが手作業で維持されている場合、速記とタイプミスや非常に巧妙な取引のトリックを区別するのが難しい場合があります。これにより、エントリ(さらに)がコンテキストに依存する可能性があります。たとえば$ディレクティブが機能すると、解析の難しさがさらに悪化する可能性があります。

そしてもちろん、nsd-checkzoneまたはnamed-checkzoneで確認された有効な構文のゾーンファイルとの間にも違いがあります。意味的に有効で意図したとおりに機能するリソースレコード。

かなり典型的な例は、example.comゾーンのCNAMEレコードです。

www IN CNAME www.example.net

これは有効ですが、www.example.netに末尾のドットがないため、FQDNおよびゾーンファイルの省略形ではありません。 $ Originの値が追加され、デフォルトでは次のようになります。

www IN CNAME www.example.net.example.com.

ただし、常にではありません。
$ Originの暗黙的な値を使用したり、規則に従って$ Originをゾーンの名前に明示的に設定したりするのではなく、明示的に $ Originを.ドットのみに定義

ここでも、example.comゾーンのCNAMEレコードの例

$Origin .

www IN CNAME www.example.net

次に、$ Originの値が追加されると、次のようになります。

www IN CNAME www.example.net.

このQ&A は、MXレコードの場所が有効な構文であるが、電子メールが壊れている例です。

私のこの答え は悪い考えの例ですが、リソースレコードのコンテキストがゾーンファイル内の正確な位置に依存し、繰り返し使用することで速記の効果が変わる有効な構文です/ $ Origin $ディレクティブの乱用。

1
HBruijn