2006年 08月 25日
センター側の回線工事(後編)
さて,ようやっと後編にたどり着きました。でも,まだ終わりにはたどり着いていません(;_;)

プロバイダの切り替えでやり取りが大変でした。

■1■セカンダリサーバのFQDN問題
今回プロバイダを切り替えるドメイン名は,すでにプロバイダ切り替えを経験済みでした。
ですから,プロバイダ側から手続きについての指示書が来る3週間前に,TTL値を1日から1時間に,10日前には10分に,4日前(金曜日が切り替えなので,月曜日)には5分にと順次減らしておきました。

さて,問題は切り替えの10日前に起こりました。セカンダリサーバはプロバイダのDNSサーバを借りることにしていました。プライマリサーバはこちらなので,ドメイン名維持管理会社移転に伴う,ドメイン登録申請や,逆引き権限委譲で,セカンダリサーバの正引きFQDN名を,こちらのドメイン名にして提出しました。
プライマリサーバのFQDN: xxx.▲▲▲.ed.jp
IPアドレス      : XXX.XXX.XXX.2(こちらに新規に割り当てられるネットワーク)
セカンダリサーバのFQDN: ns2.▲▲▲.ed.jp
IPアドレス      :プロバイダ指定のセカンダリサーバのIPアドレス
というわけです。
 すると,プロバイダから,セカンダリサーバのFQDNは,プロバイダのドメイン名で登録すると連絡がきました。このような申請は見たことがないというのです。
 プライマリサーバはこちらで持ち,トランスファーするので,正引きの場合のセカンダリサーバのFQDNはこちらのドメイン名でないと.jpのDNSサーバに負担をかけるし,BINDのバージョンによってはグルー情報が得られなくて引けない場合もありうるのではないかと,申し出たわけです。
 具体的に言うとJPRSのWOISサービスでドメインを検索したときに
p. [Name Server] xxx.▲▲▲.ed.jp
p. [Name Server] ns2.▲▲▲.ed.jp

と表示して欲しかったわけです。でもそれが理解されないみたいでした。「営業担当を通じての伝言ゲームになっているのかな?」という感じでした。そこで,こちらの意図の理由の参考資料として,  http://jprs.jp/tech/material/IW2004-DNS-DAY-internal-hostname-in-nameserver-minda.pdf
をプロバイダの営業担当者に連絡しました。

ところが,返ってきた返事は,
 1)当社のDNSサーバはきちんとグルー情報を返すので,古いネームサーバを利用している相手にも検索できる
 2)ドメイン空間が異なるネームサーバが登録されていても,.ed.jpと.ne.jpのネームサーバが検索され,貴社のネームサーバの情報を応答するから大丈夫
というものでした。

 そのドメイン空間が違う
  →別のドメイン空間の検索をしなければならない
  →その検索の負荷を.jpのDNSサーバにかけてしまう
  →この負荷が無駄な負荷であろう
  →これが不可避ではなく,設定だけで回避できるという話のつもりなんだけど?
といったんですが,通じない(-_-;)
 ま,最終的には話が通じたようで,現在JPRSのWHOISで検索すると
p. [Name Server] xxx.▲▲▲.ed.jp
p. [Name Server] ns2.▲▲▲.ed.jp

のようになってます。
 でも,ここまでくるのに2週間かかりました。

■2■プロバイダ切り替え時のネームサーバ二重登録
実は,こっちのほうが問題でした。
 プロバイダ切り替えの時に,新旧プロバイダで同じFQDNのネームサーバが違うIPアドレスで登録されないようにするため
p. [Name Server] new-xxx.▲▲▲.ed.jp
p. [Name Server] old-xxx.▲▲▲.ed.jp
という存在しないFQDNのネームサーバがJPRSに登録されていました。

 そういう手続きをするという話はきいていませんでした。
 プロバイダからは,
標記につきまして、変更完了いたしましたので、ご連絡させていただきます。

<指定事業者変更完了のご連絡>

以下の指定事業者変更が完了し、ドメイン名は貴社の管理下に移りました。

# BEGIN_DATA_BLOCK
[申請種別] 指定事業者変更
[ドメイン名] ▲▲▲.ED.JP
[組織名] ▲▲▲市立小中学校間ネットワーク
[変更元指定事業者略称] PNJ-C
[変更元指定事業者名] KDDI株式会社
[変更先指定事業者略称] xxxxxx
[変更先指定事業者名] 株式会社xxxxxxx
# END_DATA_BLOCK

=======
<指定事業者変更完了のご連絡>

以下の指定事業者変更が完了し、ドメイン名は貴社の管理下に移りました。

# BEGIN_DATA_BLOCK
[申請種別] 指定事業者変更
[ドメイン名] ▲▲▲-BE.●●●.■■■.JP
[組織名] ▲▲▲市教育委員会
[変更元指定事業者略称] PNJ-C
[変更元指定事業者名] KDDI株式会社
[変更先指定事業者略称] xxxxxxx
[変更先指定事業者名] 株式会社xxxxxxx
# END_DATA_BLOCK


新旧の仮プライマリDNSへの二重登録申請は、本日させていただきますので、
8/18の設定変更につきましては、予定通りおこなっていただけるかと思います。
弊社セカンダリDNSへの転送は、8/18切替結果を8/21に確認させていただき
実施させていただきたいと考えております。

尚、不要なトラブルを避けるためKDDI様にセカンダリDNS情報の削除を、8/18にして
いただくようご連絡をお願いいたします。

以上、よろしくお願いいたします。

だけで,どのような登録になったのかの連絡はありませんでした。地域イーサネット網の切り替えでトラぶっていた(光インターフェースが必要だとわかって,入手にてんやわんやの真っ最中)だったので,そこまで気が回らなかったのです。
 でも,K氏はすぐに気がついて,「これおかしくないですか?」と連絡してくれたのです。

 さっそくプロバイダに連絡したところ,
  ・プロバイダ移管のときは,このような方法を使う
  ・存在しないFQDNを使ってもIPアドレスが存在するから大丈夫
と,私たちには理解不能な返事。実際にK氏のほうからは正引きできなくなったとのこと。

 なんど問い合わせても「大丈夫」の一点張り。
 そこで,日曜日にCECのOSPプロジェクトでもお世話になっている,日本のインターネットの世界では知られているA大学のO先生に相談したら「なんですか、これ???」という返事。
 「でも,JPRSがなんかの指導をしているかも知れないので,教え子のU氏@JPRSに聞いてみれば?」ということなので,連絡はしたけど,返事は来なかった。忙しいからしかたないよね!(^^)!

 K氏は「やっぱり引けないから,ゾーン情報に『new-xxx.▲▲▲.ed.jp』を登録しよう」といって,存在するFQDNにして引けるようにしました。

 ※※※どなたか,こういう風にするものだという情報をお持ちですか?

月曜日になって,「移行期間を終わらせたいのですが」とプロバイダから連絡がきたので,「頼むから存在しない,かつこちらから申請もしていないFQDNの登録を速やかに削除して」といいました。


■3■sun.comが引けない
日本サン・マイクロシステムズのホームページが見えません。というか,sun.com以下のDNSが引けなくなっちゃいました。

$dig jp.sun.com +trace

; <<>> DiG 9.3.1 <<>> jp.sun.com +trace
;; global options: printcmd
. 216911 IN NS g.root-servers.net.
. 216911 IN NS h.root-servers.net.
. 216911 IN NS i.root-servers.net.
. 216911 IN NS j.root-servers.net.
. 216911 IN NS k.root-servers.net.
. 216911 IN NS l.root-servers.net.
. 216911 IN NS m.root-servers.net.
. 216911 IN NS a.root-servers.net.
. 216911 IN NS b.root-servers.net.
. 216911 IN NS c.root-servers.net.
. 216911 IN NS d.root-servers.net.
. 216911 IN NS e.root-servers.net.
. 216911 IN NS f.root-servers.net.

;; Received 420 bytes from 127.0.0.1#53(127.0.0.1) in 8 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 488 bytes from 128.63.2.53#53(h.root-servers.net) in 205 ms

sun.com. 172800 IN NS ns1.sun.com.
sun.com. 172800 IN NS ns2.sun.com.
sun.com. 172800 IN NS ns7.sun.com.
sun.com. 172800 IN NS ns8.sun.com.
;; Received 164 bytes from 192.5.6.30#53(a.gtld-servers.net) in 214 ms

;; connection timed out; no servers could be reached

という状態。プロバイダと接続しているルータの設定が原因かも知れないので,
 プロバイダとナンバードで接続しているWAN側の設定にあわせてWindowsXPのIPアドレスを設定
 このとき,ネームサーバもプロバイダのネームサーバを登録
プロバイダの光コンバータからルータのWAN側に刺しているLANケーブルを上記の設定にしたWindowsXPでJP.SUN.COMを引いてみると引ける。

C:\>nslookup jp.sun.com
Server: ns2.xxxxx.ne.jp
Address: xx.xxx.xxx.xxx

Non-authoritative answer:
Name: jp.sun.com
Address: 72.5.124.18

つぎに,プロバイダの光コンバータからのLANケーブルをゲートウェイルータ差し戻して,
 ・WindowsXPのIPを当方のグローバルアドレス
 ・デフォルトゲートウェイはルータ
にした上で
 1)DNSサーバをプロバイダのモノに設定 → 上と同じく引ける
 2)DNSサーバをこちらのモノに設定   → sun.comで引けなくなる

まだ調べることがいっぱいありそう。
にほんブログ村 IT技術ブログへ
[PR]

by ji3faf | 2006-08-25 17:53 | システム管理


<< また雷雨      明日から高校PTA全国大会 >>


にほんブログ村 教育ブログへ




Map