TTL digを使用してレコードをクエリする場合
この質問は このトピック から来ています。これを行うと、クエリされたネームサーバーでAレコードが期限切れになるまでの残りの秒数を取得します。
Dig stackexchange.com
ただし、これを行うと、信頼できるTTL値が得られます。
Dig any stackexchange.com
したがって、Dig any stackexchange.comを実行すると、実際に再帰クエリを実行したときに、信頼できる質問をしたかのようにすべてのTTL値が取得される理由がわかりません。
簡単に言うと、質問で言及した両方のクエリは、権限のないクエリです。
ドメインのDNSレコードは、キャッシングDNSサーバーまたは権限のあるDNSサーバーから照会できます。したがって、キャッシングDNSサーバーにクエリを実行する場合は、DNS IPアドレスを指定するか、指定されていない場合は、/etc/resolv.confで構成されているデフォルトのDNSサーバーが使用されます。
権限のないクエリ
$ Dig stackexchange.com
または
$ Dig stackexchange.com @8.8.8.8
上記の両方の場合、ISPのDNSまたはGoogleのパブリックDNS（8.8.8.8）はstackexchange.comドメインに対して権限がないため、クエリは権限のない応答を返します。権限のないネームサーバーにクエリを実行すると、クエリを実行するたびに提供されるTTL値は減少します。TTL値が期限切れになると、キャッシュネームサーバーは権限のあるDNSサーバーを再クエリします。
信頼できるクエリ
したがって、信頼できる応答を取得するには、信頼できるDNSサーバーからレコードをクエリする必要があります。これは、以下の方法で見つけることができます。
$ Dig ns stackexchange.com
...
;; ANSWER SECTION:
stackexchange.com. 84894 IN NS cf-dns02.stackexchange.com.
stackexchange.com. 84894 IN NS cf-dns01.stackexchange.com.
...
ANSWER SECTIONは、ドメインstackexchange.comの信頼できるネームサーバーを提供するため、信頼できる応答を取得する必要がある場合は、
$ Dig stackexchange.com @cf-dns01.stackexchange.com.
権限のあるDNSサーバーにクエリを実行している間、TTL値は変更されません。これは、これらのネームサーバーが情報の主要なソースであり、管理者が変更するまで有効期限が切れないためです。
レコードのしくみ
すべてのレコードはワイルドカードのようなものであり、DNSサーバーにキャッシュ/保存されているすべてのレコードを取得するために使用できます。たとえば、stackexchange.comに任意のレコードを照会したところ、デフォルトのDNSサーバーが次のように応答しました。
$ Dig any stackexchange.com
....
;; ANSWER SECTION:
stackexchange.com. 86350 IN SOA cf-dns01.stackexchange.com. dns.cloudflare.com. 2017456480 10000 2400 604800 3600
stackexchange.com. 176 IN A 198.252.206.140
stackexchange.com. 84338 IN NS cf-dns01.stackexchange.com.
stackexchange.com. 84338 IN NS cf-dns02.stackexchange.com.
....
ここでは、返信にSOA、A、およびNSレコードに関する情報のみが含まれていることがわかります。しかし、実際にはstackexchange.comのレコードがもっとありますが、クエリを実行していないため、デフォルトのDNSサーバーにキャッシュされていません。
現在、デフォルトのDNSサーバーにMXレコードを照会していますが、応答は次のようになります。
$ Dig MX stackexchange.com
....
;; ANSWER SECTION:
stackexchange.com. 300 IN MX 10 aspmx3.googlemail.com.
stackexchange.com. 300 IN MX 5 alt2.aspmx.l.google.com.
stackexchange.com. 300 IN MX 5 alt1.aspmx.l.google.com.
stackexchange.com. 300 IN MX 10 aspmx2.googlemail.com.
stackexchange.com. 300 IN MX 1 aspmx.l.google.com.
....
ここで、もう一度ANYレコードをクエリすると、ANYのクエリでもMXレコードが返されていることがわかります。したがって、ANYレコードは、デフォルトのネームサーバーにのみキャッシュされるレコードを提供するだけです。
$ Dig any stackexchange.com
....
;; ANSWER SECTION:
stackexchange.com. 298 IN MX 5 alt1.aspmx.l.google.com.
stackexchange.com. 298 IN MX 10 aspmx2.googlemail.com.
stackexchange.com. 86084 IN NS cf-dns01.stackexchange.com.
stackexchange.com. 298 IN MX 10 aspmx3.googlemail.com.
stackexchange.com. 298 IN MX 1 aspmx.l.google.com.
stackexchange.com. 298 IN MX 5 alt2.aspmx.l.google.com.
stackexchange.com. 86084 IN NS cf-dns02.stackexchange.com.
stackexchange.com. 243 IN A 198.252.206.140
stackexchange.com. 86343 IN SOA cf-dns01.stackexchange.com. dns.cloudflare.com. 2017456480 10000 2400 604800 3600
....
ご覧のとおり、権限のない返信の場合、TTLの値は変化しています。
DNSクエリのTTLフィールドを理解していません。TTLは、ネームサーバーを再クエリする前に結果をキャッシュする必要がある時間をクライアントに示す指標です。繰り返しますが、DNSサーバーをTTLの異なる値で更新しない限り、応答は常に同じになります。ホスト名をIPに解決する必要があるたびにネームサーバーに再クエリを実行することは非常に悪い習慣です。