DNS Summer Day 2017(発表⽤)

TTLの現状について，分析結果のご紹介

2017年6⽉28⽇
NTTコムエンジニアリング株式会社
NTTネットワーク基盤技術研究所

Copyright © NTT Communications Corporation. All rights reserved.

佐藤 正春
原⽥ 薫明

この発表について発表者

 佐藤 正春（NTTコムエンジ）
 OCN DNS の運⽤ 原⽥ 薫明（NTT研究所）

 通信トラヒック品質プロジェクトに所属
 トラヒック測定分析，仮想ネットワーク制御に関わる研究開発に従事

発表の⽬的 下記について情報共有します DNSのTTLの現状について
 DNSキャッシュサーバの負荷について

資料の構成

 DNSのTTL分析

 DNSレスポンスから⾒るTTLの経年変化①：キャッシュサーバ⇒ユーザへのレスポンス分析
 DNSレスポンスから⾒るTTLの経年変化②：権威サーバ⇒キャッシュサーバへのレスポンス分析

 DNSキャッシュサーバの負荷 CPUを引き上げる要因をグラフから探ってみた

Copyright © NTT Communications Corporation. All rights reserved.

DNSのTTL分析

DNSレスポンスから⾒るTTLの経年変化

Copyright © NTT Communications Corporation. All rights reserved.

2

DNS応答の傾向
 2013年，2015年，2017年のとある⽇におけるピーク時間帯（１時間）のレスポンスを分析．
 ユーザ数（ユーザ側IPアドレス数）はほぼ同⼀．
•2013年から2015年にかけてキャッシュサーバ応答のレスポンス数が増加しているが，スマートフォン等の普及に伴い宅内端末が増えた影響と推測．

 キャッシュサーバ，権威サーバ共にQNAME数は減少傾向．
 キャッシュサーバのレスポンス数は増加傾向であるのに対して，権威サーバでは微減．

①

②増加
不変減少

減少
減少

2013年を100％とした時の相対量
Copyright © NTT Communications Corporation. All rights reserved.

データ無2015年を100％とした時の相対量

【DNSレスポンスから⾒るTTLの経年変化①】

キャッシュサーバ⇒ユーザへのレスポンス分析
 MAX TTLが300秒以下のQNAME数，が秒以数レスポンス数ともに増加傾向．

 MAX TTL別のQNAME数分布は，300秒よりも短いQNAME数が増加傾向で，3600秒を超えるQNAME数が減少しつつある．
 MAX TTL=20秒のレスポンス数の割合は減少した
⼀⽅，MAX TTL=60秒の割合は増加傾向．
 レスポンスの⼤部分がMAX TTL=300秒以下であり，その割合も増加傾向にある．

割合累積値

割合

累積値

増加傾向
増加傾向
減少？

減少傾向
MAX TTLが推定できなかった（半端な数値となった）ものを除外して表⽰※全体的な傾向は変わらないことを確認済
Copyright © NTT Communications Corporation. All rights reserved.

【DNSレスポンスから⾒るTTLの経年変化②】

権威サーバ⇒キャッシュサーバへのレスポンス分析
 キャッシュサーバ⇒ユーザのレスポンスと同様に，ユーザのレスポンスと同様に，TTLが300秒以下のQNAME数，レスポンス数ともに増加傾向．
 TTL=60秒のQNAME数，レスポンス数の割合が増加．
 TTL=10秒以下のQNAME，レスポンスも数％存在．
割合

累積値

割合

累積値増加
謎増加

謎減少
MAX TTLが推定できなかった（半端な数値となった）ものを除外して表⽰※全体的な傾向は変わらないことを確認済
Copyright © NTT Communications Corporation. All rights reserved.

減少DNSキャッシュサーバの負荷
CPU Usageを引き上げる要因をグラフから探ってみた。

Copyright © NTT Communications Corporation. All rights reserved.

6

CPUを引き上げる要因をグラフから探ってみた。
6/2,4にCPU Usageがスパイクする状況が発⽣。
何が原因だったのかな？

Load Averageは問題なさそう

Query Countが連動しているように⾒える。
ただ、よく⾒ると、10-12⽇にQC的にはスパイクが発⽣しているが、CU的にはスパイクが発⽣していない。

Copyright © NTT Communications Corporation. All rights reserved.

7

CPUを引き上げる要因をグラフから探ってみた。

ID Spoofing Countも相関はなさそう。

*Defending against ID spoofing attacks
When Server is waiting for a legitimate response from an authoritative
server, andinstead gets a response with an incorrect ID value, it takes this as
possible evidence that an ID spoofing attack is underway. To protect itself,
Server repeats the query using TCP
instead of UDP, because TCP queries aren't vulnerable to the attack.

Rate-Limited-Requestsも相関はなさそう。

*rate-limited-requests
The number of DNS requests not sent by this resolver to other DNS
servers as a result of server-based rate-limiting.

Copyright © NTT Communications Corporation. All rights reserved.

8

CPUを引き上げる要因をグラフから探ってみた。

Recursion CountのRequests SentsとResponses Receivedの差分が⼤きい時により⼤きくCPU Usageが変化している。

ServFailであっても、権威サーバ側のレスポンスの違いによって、CPU Usageの挙動も異なる模様。

Copyright © NTT Communications Corporation. All rights reserved.

9

CPUを引き上げる要因をグラフから探ってみた。まとめ・RRのTTLとサーバの負荷(CPU Usage,LoadAverage)との関連性については、⾒出すことは出来なかった。
(TTLを考慮した、運⽤とか設計も意識したことは…..)
・権威サーバの挙動によって、キャッシュサーバでの状態が異なるもよう。
権威サーバが元気に返してくれれば、キャッシュサーバも安泰。
・キャッシュサーバ側でのRate Limitedも有効な感じ。たぶん、権威サーバに対してもやさしい。
・TTLが短いRRを運⽤している権威サーバのレスポンスが悪くなると、キャッシュサーバの負荷が⾼くなる可能性がありそうなので、権威サーバ側の運⽤をしっかりとしてほしい。WTとかの時にも。(キャッシュサーバの運⽤者側)

Copyright © NTT Communications Corporation. All rights reserved.

10

ご清聴ありがとうございました！

Copyright © NTT Communications Corporation. All rights reserved.

11