トップ «前の日記(2014-08-27) 最新 次の日記(2014-09-24)» 編集

インターノット崩壊論者の独り言


EPIC2014
Google Public DNS (8.8.8.8, 8.8.4.4) 経由では本サイトにアクセスできないよう措置させて頂いております。

2014-08-28 伝播、反映いうな

「BIGLOBEクラウドホスティング」において、コントロールパネルから、DNS設定が可能に

題記のニュースを見て、どんなサービスだろうと http://cloud.bioglobe.ne.jp/hosting/spec/#anc15 を見てみましたがあまりに記述が意味不明です。

いくつか質問してみたところ以下の回答が返ってきました。

共用 DNS サービスの脆弱性には不十分ながら(*)それなりの対策は考えられているようです。

それ以外の質問への回答は残念なものですね。「インターネット上の全てのDNSサーバへ反映される」とか。伝播、反映いうな。

Date: Mon, 25 Aug 2014 11:29:54 +0900
 
この度は「BIGLOBEクラウドホスティング」サービスをご検討いただきまして、
誠にありがとうございます。
BIGLOBE法人コンタクトセンター **と申します。
 
先日ご質問いただいた内容につきまして、以下インラインにて回答いたします。
 
> ここの説明が意味不明すぎます。
> http://cloud.biglobe.ne.jp/hosting/spec/#anc15
> いくつか質問させてください。
> 1.「既に設定されているレコードのTTL値を変更した場合、すぐに設定
> されたTTL値で反映されません。」とはどういうことですか?
 
掲載内容が分かりづらく、申し訳ございません。
 
コントロールパネルの設定画面で入力したTTL値は、クラウドホスティングで
提供しているDNSサーバでは(ほぼ)即時反映されます。
「すぐに設定されたTTL値で反映されません。」とは、お客様(エンドユーザ等)
自身が登録した内容を参照しようとした際、参照しているDNSサーバには
設定が反映されてないこと(つまりは伝播しきれない)を述べております。
 
> 2.「同じホスト名で同じIPアドレスを設定することはできません。」どういうことでしょう。
 
【同じホスト名】とはレコードタイプでA またはCNAME を選択した場合、同じ
名前で同じIPアドレスを設定できない(同じ組み合わせにできない)ことを
述べております。
 
> 3.「お申し込みされたDNS設定情報が世界中のDNSサーバへ伝播するには、
> 数時間〜1日程度かかります。」伝播とはどういう現象ですか?
 
1.でもご案内しておりますが、設定したレコード(ゾーン情報)がインター
ネット上の全てのDNSサーバへ反映されることです。
 
> 4.以下の脆弱性があるのではないかと思いますが、どういう対策を
> 行っていますか?
> http://jprs.jp/tech/security/2012*06*22*shared*authoritative*dns*server.html
 
ご提示いただいたURLの対策に記載のあります通り、
クラウドホスティングののDNSサーバに設定済のゾーンのサブドメイン及び上位
ドメインは作成できないように制限しております。
 
また、別のハイジャック対策として、クラウドホスティングのDNSサーバに登録
しようとしているドメインの委任(NS)が、既にこのDNSサーバを指して
いる場合には、登録を不可としています。
 
 ※前利用者がレジストリにクラウドホスティングのDNSサーバへの委任(NS)を
  残存してしまっており、その後このDNSサーバに別利用者が同じ
  ドメインでのゾーンを作成した場合、不正利用されてしまうからです。
 
 ※レジストリの委任(NS)情報は、クラウドホスティングDNSのご契約後
  (ゾーン作成後)に変更していただく仕様としています。
  委任情報を変更できる=正当な所有者である、という見方です。
 
> 5.なぜこのフォ*ムはURLまでいわゆる全角で入力しないといけないのですか?
> 「お問い合わせ内容に環境に依存する文字「*******」が含まれています。」と
> 出たのでハイフンを*に置換しました。
 
お手数をおかけし、誠に申し訳ございません。
本件、入力フォームの改善事項として認識しておりますので、今後改修等検討
させていただきます。
恐れ入りますが、ご了承くださいますようお願いいたします。
 
以上、何卒よろしくお願い申し上げます。
 
BIGLOBEクラウドホスティングに関するご不明点・ご相談などは、下記窓口まで
お気軽にお問い合わせください。

* 例えば待ち伏せ対策になっていません。待ち伏せを防ぐには恒常的な所有確認が必要になります。
また登録時に所有確認がないということは実際の所有者に対する登録妨害が可能となります。

本日のツッコミ(全6件) [ツッコミを入れる]
tm (2014-08-29 10:13)

共用ゾーンサービスの危険性をしっかり認識していないかぎり、対策は無理ですね。<br><br>認識していれば、安易に共用ゾーンサービスを始めるはずもないでしょう。<br>(利用客が多数いるとも思えないw)

tss (2014-08-29 10:56)

DNS の仕組みからして理解されていないようなのでどうしようもありませんね。

tm (2014-08-30 21:17)

「待ち伏せ」とはどういうものですか。

tss (2014-08-31 10:42)

NSが向くのを待つ受動的攻撃をさしています。 (サーバを設定していないのに委譲元を変更するのは間違いですがみかけますね)

tm (2014-08-31 14:40)

そういう意味であれば、ゾーンサービスの提供は「待ち伏せ」の道具として使われる、あるいは「待ち伏せ」を援助しているということで犯罪ですね。w<br><br>「待ち伏せ対策」どころの話ではない。

tm (2014-10-16 19:27)

どの程度の調査をするんでしょうね。 ー>「クラウドホスティングのDNSサーバに登録<br>しようとしているドメインの委任(NS)が、既にこのDNSサーバを指して<br>いる場合には、登録を不可としています。」


最近の日記

2008|04|05|06|07|08|10|11|
2009|02|03|04|06|07|09|10|11|
2010|01|03|06|09|10|11|12|
2011|01|02|03|05|06|07|10|11|
2012|03|06|07|10|11|12|
2013|02|03|04|05|06|08|09|10|11|
2014|01|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|07|08|09|10|11|12|
2016|01|06|08|12|
2017|03|07|08|09|12|
2018|04|08|10|11|
2019|01|02|07|11|12|
2020|01|02|03|05|06|07|08|
2021|02|03|09|12|
2022|02|03|05|06|
2024|02|

リンク

Copyright by T.Suzuki