## page was renamed from DNS/キャッシュサーバ調査/ISP比較 ## page was renamed from DNS/キャッシュサーバ/ISP比較 ## page was renamed from DNS/キャッシュサーバ比較 ## page was renamed from DNS/キャッシュサーバ/比較表 <> ---- [[../キャッシュサーバ]]　[[../キャッシュサーバ/関連ページ]] = キャッシュサーバの振る舞い = [[/動作確認]] 毒盛対策の視点からは「なにをキャッシュしているか」が問題です。 浸透問題の視点からはキャッシュされたレコードの[[/TTLの更新]]が行われるかなどが調査項目になります。 そして、TTL満了時の動作も問題になります。 == TTL についての調査 == http://www.e-ontap.com/dns/propagation/ttl.html ISPのキャッシュDNSサーバはTTLを越えてキャッシュを保持するか? [現在その証拠は見当たらない。] unbound, PowerDNS recursor などにはTTLの上限、下限を指定する機能があります。 　６０秒などの短いTLLは無視することも可能です。 長いTTLを許すキャッシュサーバにはGhost Domain Names脆弱性がありそうです。 == TCP サポート == DNSプロバイダでの[[DNS/TCP]]のサポート状況を調査しました。 　eaccess, plala を除いてサポートされています。 == yatz.qmail.jp を問い合わせたときの返答 == [[yatz.qmail.jp]] では委譲されたzone名がCNAMEである変則的設定になっている。<
> cn: CNAME; au(q): authority section に qmail.jpのSOA/NSを含めている。 　ns: NS; soa: SOA; （警告）以下は調査したときの返事をまとめたもので、いつも同じ返事になるとは限らない。 　キャッシュサーバの状態に依存する。 順番を入れ替え,NS,SOAは安定して返される項目だけに変更した。 -- ToshinoriMaeno <> ||server\query||A||NS||SOA||any||IP address|| ||[[../PowerDNS]]||cn,A||cn;au(soa)||soa,cn;au(ns)||cn,A|| ||[[../unbound]]||cn,A;au(NS)||cn;au(soa)||cn;au(soa)||cn;au(A)|| ||[[../dnscache]]||cn,A||cn||cn ||soa,ns,cn,A|| ||[[/OpenDNS/yatz]]||cn,A||cn||soa||soa,ns,cn,A||208.67.222.220,208.67.222.222|| ||[[/Google/yatz]]||cn,A||cn;au(soa)||cn;au(soa)||soa,ns,cn,A||8.8.8.8|| ||[[/plala.or.jp]]||cn,A||cn||cn||cn||220.220.248.1|| ||Norton||cn,A;au(ns)||ns,cname||soa,cn;auth|| ||198.153.192.1,8.153.194.1|| ||OpenNIC||cn,A;au(ns) ||ns ||soa;au(ns)|| ||69.164.208.50|| ||[[/Level3/yatz]]||cn,A||ns||soa||soa,ns,cn,A||209.244.0.3|| ||[[/sakura.ad.jp/yatz]]||cn,A||ns||soa||soa,ns,cn,A||210.188.224.10|| ||[[/sphere.ne.jp]]||cn,A;au(ns)||ns||soa;au(ns)||cn,ns;auth||203.138.63.115|| ||[[/asahi-net.jp/yatz]]||cn,A;au(ns)||ns||soa;au(ns)||soa,ns,cn,A;auth||202.224.32.1|| ||[[/kddi.ne.jp/yatz]]||cn,A;au(ns)||ns||soa;auth||soa,ns,cn,A;auth||211.134.181.105|| ||[[/so-net.ne.jp/yatz]]||cn,A;au(ns)||ns||soa;auth||soa,ns,cn,A;auth||202.238.95.24,202.238.95.26|| ||[[/iij4u.or.jp]]||cn,A;au(ns)||ns||soa;au(ns)||soa,ns,cn,A;auth||210.130.0.1|| ||[[/nifty.com]] ||cn,A;au(ns)||ns||soa;auth|| ||202.248.37.74,202.248.20.133|| ||[[/point.ne.jp]] ||cn,A;au(ns)||ns||soa;au(ns)|| || ||ocn.ne.jp||cn,A;au(ns)||ns||soa;au(jp)|| ||202.234.232.6, 221.113.139.250|| ||vectant.ne.jp||cn,A;au(q)|| cn;au(soa)||cn;au(soa)|||| * GTEIDNS 4.2.2.1, 4.2.2.2 * DNSAdvantage 156.154.70.1, 156.154.71.1 * auone 210.196.3.183, 210.141.112.163 * BIGLOBE 202.225.94.247, 210.147.240.193 * odn 143.90.130.165,143.90.130.39 eo光ネット ･ 優先DNSサーバー　：【 60.56.0.135 】　　TTL refresh ・ 代替DNSサーバー　：【 218.251.89.134 】 ----- OpenDNSがdnscacheと類似の返答をしています。 日本のプロバイダのサーバはBINDが多いようです。 -- ToshinoriMaeno <> authority section にあるSOAやNSは返事としては余計だと考えますので、無視してみます。 == ひとつの分類 == (NS, SOA）を問い合わせたときに、(NS, SOA)を答えるものと、CNAMEだけを答えるものに分けられます。 　Aの問い合わせにはCNAMEとその先のAを答えるものだけでした。 NSなどにCNAMEを答えるものはanyに対しての返答で分類できます。 SOAが含まれているか、いないかです。 zone apex に対するCNAMEをどう扱うかの違いでしょう。 　RFCではまだ正式には認められていないのですが、エラーとするキャッシュサーバ（リゾルバー）は見当たりません。 === CNAME がキャッシュされると === いったんCNAMEがキャッシュに入ると、SOAを問い合わせても、CNAMEを答えてくるようです。　-- ToshinoriMaeno <> 調査に間違いがありました。再調査中です。 == yata.qmail.jp の扱い == [[yata.qmail.jp/設定]]　zone が CNAME だけから構成されている。 == 今後調べたいこと == 毒盛対策の視点からは「なにをキャッシュしているか」が問題です。