アカウント名:
パスワード:
VoIPとか、プッシュ型のサービスを考えた場合、固定されたFQDNからIPが引けるというのはメリットがあると思います。
>・レコードのTTLを短くするだけで対応できないのか?
DNSという仕組みは一つのある程度成功した仕組みではあると思いますが、それが唯一絶対の(他に代替できない)ものではありません。 TTLを短くする事で、それなりに対応する事は可能かもしれませんが、その場合TTLを短くする事の対価として、多数のDNSクエリを発生させてしまう事になります。 頻繁にIPアドレスが変更されてしまう場合であれば、たとえば現在のDNSの仕組みである、クライアントからDNSサーバへLookupするという形をやめ、クライアントからDNSサーバへ特定のFQDNの参照を登録し、端末のIPアドレスが変更になった場合はDNSサーバ側からクライアントへプッシュ型で変更を通知するという形も有用かもしれません。
また、現在のDNSの仕組みでは「IPアドレスが何か?」という事はわかりますが、「そのIPアドレスは(そのFQDNでは)使われなくなった」という事がわかりません。まぁexpireすればわかりますが、明示的に通知する仕組みはありません。 この辺の仕組みは、端末のIPアドレスの変動よりも、DNSサーバの存在/確実性の方が低いという歴史的事情により「わからなければそこにいた事にしよう」という方向で各種のキャッシュなどが最適化されているためであり、IPアドレスが頻繁に変わる可能性のあるモバイル向けに適した設定にはなっていないと思います。
これらの「相手側端末の性格の違い」を、クライアント側に知らせる一つの方法としてTLDで識別するというのもアリかもしれません。 私的にはTLDで識別するより、DNSに新たなレコードを設けて(たとえばIPv6でAAAAレコードが増えたように)、端末側の特徴を知らせる仕組みを作って、それに対応できるクライアント/DNSサーバ間では別の方法で名前解決を行うという方がスマートな解決法だとは思いますが。
それによると、申請があった sTLD は、「.asia」「.cat」「.jobs」「.mail」「.mobi」「.post」「.travel」「.xxx」および2社から競合申請された「.tel」
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
.mobiの必要性 (スコア:2, 興味深い)
・モバイル端末のIPアドレスは頻繁に変わる
・現在のドメインはアップデートに最大48時間もかかる
という理由で.mobiドメインが必要らしいがそうすると
・モバイル機器をサーバにでもする気なのか?
・レコードのTTLを短くするだけで対応できないのか?
という疑問が。
Re:.mobiの必要性 (スコア:3, 参考になる)
VoIPとか、プッシュ型のサービスを考えた場合、固定されたFQDNからIPが引けるというのはメリットがあると思います。
>・レコードのTTLを短くするだけで対応できないのか?
DNSという仕組みは一つのある程度成功した仕組みではあると思いますが、それが唯一絶対の(他に代替できない)ものではありません。
TTLを短くする事で、それなりに対応する事は可能かもしれませんが、その場合TTLを短くする事の対価として、多数のDNSクエリを発生させてしまう事になります。
頻繁にIPアドレスが変更されてしまう場合であれば、たとえば現在のDNSの仕組みである、クライアントからDNSサーバへLookupするという形をやめ、クライアントからDNSサーバへ特定のFQDNの参照を登録し、端末のIPアドレスが変更になった場合はDNSサーバ側からクライアントへプッシュ型で変更を通知するという形も有用かもしれません。
また、現在のDNSの仕組みでは「IPアドレスが何か?」という事はわかりますが、「そのIPアドレスは(そのFQDNでは)使われなくなった」という事がわかりません。まぁexpireすればわかりますが、明示的に通知する仕組みはありません。
この辺の仕組みは、端末のIPアドレスの変動よりも、DNSサーバの存在/確実性の方が低いという歴史的事情により「わからなければそこにいた事にしよう」という方向で各種のキャッシュなどが最適化されているためであり、IPアドレスが頻繁に変わる可能性のあるモバイル向けに適した設定にはなっていないと思います。
これらの「相手側端末の性格の違い」を、クライアント側に知らせる一つの方法としてTLDで識別するというのもアリかもしれません。
私的にはTLDで識別するより、DNSに新たなレコードを設けて(たとえばIPv6でAAAAレコードが増えたように)、端末側の特徴を知らせる仕組みを作って、それに対応できるクライアント/DNSサーバ間では別の方法で名前解決を行うという方がスマートな解決法だとは思いますが。
Re:.mobiの必要性 (スコア:0)
同時に頻繁に切り替わるのでないなら、変わったノードが
変わって無い方のノードへ新しいIPアドレスを通知すれば
大抵の通信はできてしまうと思います。
セッション鍵なりを作れば移動しても同一ノードだ
Re:.mobiの必要性 (スコア:1)
これまでに出てきているものだけではなく、新しい仕組みも含めて。
ただ、「これまでの仕組みでもTTL短くすれば対応できる」という考え方へのアンチテーゼとして、新しい(元々想定されていなかった)用途には新しい仕組みを作った方が良いのではないか。
そのための提案として「TLDを別ける」というのを「スマートなやり方ではないからダメ」と言うならまだ良いでしょうが「これまでの仕組みでも何とかできるから不要」というのは論拠としてあまり良くないかな?と思ったまでです。
おふとぴ(was: .mobiの必要性) (スコア:2, おもしろおかしい)
Steve.JobsとかIn.telとかfree.mailとかxxx.xxx.xxx.xxxとか
出てくるんだろうなぁ。
Re:おふとぴ(was: .mobiの必要性) (スコア:2, おもしろおかしい)
time.travel
東京三菱の中の人のあなたに。
sugu.mobi
古い国産スポーツカーを愛するあなたに。
cerica.xxx
中島みゆき大好きなあなたに。
east.asia
モモちゃんなあなたに。
pet.post
Re:おふとぴ(was: .mobiの必要性) (スコア:0)
[tohato.jp]
Re:おふとぴ(was: .mobiの必要性) (スコア:0)
first.post
Re:おふとぴ(was: .mobiの必要性) (スコア:1)
ドメイン名を偽装したウイルスの発生をしばらく
予防できるかな.
# command.com [command.com]を見ると以前と違うような...
Re:おふとぴ(was: .mobiの必要性) (スコア:1)
いや、最近問題になった [srad.jp] .mp3 ドメインのがいいかも:-)
そんなことを言いだしたら、.html ドメインを作りたくなってしまうじゃないか!!
http://index.html/index.html なんてサイトがあったらおちゃめ:-)
Re:おふとぴ(was: .mobiの必要性) (スコア:0)
Re:おふとぴ(was: .mobiの必要性) (スコア:0)
#既出を変換するのにがいしゅつと入力してから間違いに気付いたのでAC
Re:.mobiの必要性 (スコア:1)