【DNS】Name Server 総合スレ Part2
■ このスレッドは過去ログ倉庫に格納されています
再起動すると正常動作(かつゾーン転送も済んだ状態)になるから
実際にはデータベース壊れてないと思うんだけど・・・ >>117
nsdc patch してみてください DNS1で名前解決できなかったらDNS2に問い合わせ
という仕組みを構築したいんですが、これって無理ですかね?
DNS1の電源が落ちているとか通信自体ができない場合はDNS2へ問い合わせに行くのですが、
DNS1の応答が「そんなレコードありません」という応答だった場合、
DNS2に見に行かないのです。
おそらく通常の仕様なのはわかっているのですが、何とかなりませんか?
社内向けDNSサーバーで解決できなかったら
クラウド上のDNSサーバーで解決させたいのですが・・・。
同じレコードを持てない理由がありまして・・。 「同じレコードを持てない」というのをもちっと詳しく書けませんか?
なんとなくzoneとかforwarderとか
そんな感じのことで調べてみるとなんとかなったりするかもしれません。 DNS2だけ見に行くようにして
DNS2をforwarderにするのがよさそう hoge.jpは他者管理
「www.hoge.jp」←インターネット上のhoge.jpの名前解決はDNS2
|
(インターネット)
|
「自社:jiya.jp」-(VPN)-「wwwsec.hoge.jp」←VPN上のhoge.jpの名前解決はDNS1
VPN上はセキュアなネットワークというポリシーらしく、
DNS1-DNS2間の通信はできない hoge.jpという同名のドメイン名が
VPN上とインターネット上 両方にあるのが問題かなーっと
でも他者なので口を挟めない。
自社にDNSサーバーにwww.sec.hoge.jpの問い合わせが来たら
DNS1へフォワードするってのが簡単に思いついた事だけど、
hoge.jpのサーバーが増えたりするたぶに手で修正すうのは面倒・・・。
DNS1レコードがなかったらDNS2へ追い合わせ汁!っていう形とれないかな? hoge はあれなんで example.jp で話すけど
example.jp は他者が管理していて、そのサブドメイン sec.example.jp を
自分のところの中でだけ存在させたい、ってことかな。
もし、そうなら自分のところDNS(DNS1なのか?)に勝手に sec.example.jp のドメインを持たせてしまえばいいんじゃないか?
example.jp のDNSで委譲してもらわなくても、クライアントがDNS1に問い合わせるようにしとけば
sec.example.jp については名前解決できる。
サブドメインじゃないよ、ホスト名だよって場合でも、ホスト毎にzoneを作ることは可能。 localhostのサブドメインでやればいいだよ好き放題作っていいんだから >>122
そういう名前解決をしてくれるDNS3を用意したいけどどのDNSサーバだと実現できるんだろうって話?
>>132
RFC2606で予約されてるのは、.test、.example、.invalid、.localhost、example.com、example.net、example.org
example.jpは予約されてませんよ、という野暮なツッコミ example.jpは実在するレジストリサービスが例示用だと言ってなかった? VPSで逆引きホスト名って1つ設定できるようになっているけど
xxx.jp か www.xxx.jp にするべきか 例示にはアスタリスクとか、あり得ない文字使えばええんちゃいますの?
www.***.jp とか。 perlのバージョン違いのテスト用に
p516.localhost
p518.localhost
p520.localhost
とか
vmに振るなら
deb.localhost debian
net.localhost netbsd
ubu.localhost ubuntu アスタリスクかぁ
使い方としたら、こんな感じ?
zone "localhost" { type master; file "localhost.db"; }
@ IN SOA localhost. mail.localhost. ( 1 2 3 4 5 )
IN NS localhost.
@ IN A 127.0.0.1
* IN A 127.0.0.1
かなり遊んだ設定だけど。 DNSの仕様上は、名前に*という文字が含まれていても問題ない。
アプリケーションがそういう文字を含む名前を扱えるかどうかはそれとは別問題。
むかし、*.cnというAレコードが実際に存在してたことがあるよ。
ワイルドカードを作るつもりで間違ってそうなっちゃったのか、
意図してそうしたのか、cnのやることだからわからん。 >>146
> DNSの仕様上は、名前に*という文字が含まれていても問題ない。
その根拠は。 横から失礼するけど、DNSの仕様ってどの範囲までを言うのかよーわからん
RRのフォーマットまでが仕様っぽいように見えるけど、そんなんネームサーバの
実装ごとに違っても別にいいじゃんって思うし。 仕様っていったら、当然 RFC に書かれた文章そのままだろうに…
古いホテルの様な拡張につぐ拡張で、わかりにくいけどな。
いいんだぜ。 hosts に記載された内容を応答する named を作っても。 >>149
*を使っていいってどのRFCに書いてんのよ。 >>147
きっと大元は RFC2181 なんだろうけど、ラベル名の定義が他の RFC で
アップデートされてるのかどうかが、よくわからん。これを読めば DNS の
仕様が一通り把握できる便利な RFC とか、ポータルなサイトとか無いのかな?
Information on RFC 2181
ttp://www.rfc-editor.org/info/rfc2181 ドメイン名の管理を代行する企業であってすら、
設定ミスを浸透と呼んで誤魔化すのが日常だし…
そんな便利なもんがあったらこんな状況にはならん気が 使えるのはアルファベットと数字とハイフンだけじゃなかったっけ。
ソースは RFC952 の 1.、RFC1035 の 2.3.1. あたり。ついでに RFC1123 の 2.1.も。
情報古いかな?
>>151
> きっと大元は RFC2181 なんだろうけど、
* 使っていいってどこに書いてある? *に関してはRFC1034の4.3.2., 4.3.3.かな? 例示にはドットを使えばいい。
www.....jp >>153
孫引きばかりで申し訳ないけど、以下のような解説を複数見かけました。
それで RFC 2181 が「DNSの仕様上は、名前に*という文字が含まれて
いても問題ない」の根拠なのかな、と。
# それにしてもあやふやだよな〜とは思う
> BIND 9 はドメイン名に使われる文字集合について制限しない。 RFC2181 の第11章にしたがい、
> 完全に 8 ビットクリーンである。DNS で広報されるホスト名は RFC952 の規則に従うことが強く
> 推奨されるが、 BIND 9 ではそれを強制しない。
(ttp://d.hatena.ne.jp/S_a_k_U/touch/20130612 より引用)
> RFC2181 #11 によると、DNS のラベルに使える文字に制限はない。バイナリ値でもかまわない
> (「日本語.jp」を punycode で符号化せずに Shift JIS で登録したって、DNS の仕様上は
> 違反ではない。JPRS が却下するけど)。ラベルの制限は長さだけ。
(ttp://ya.maya.st/d/200605c.html#s20060529_2 より引用)
> RFC1034 #3.5 や RFC1035 #3.1 にはアンスコがマズいと受けとれるような記述があるが、
> これは DNS でそういう文字を使うのが禁止という意味ではなく、アプリ側の都合でそういう
> 文字を使うことができないかもしれないから注意しろ、という意味である。
(同上) >>157
分散データベースとしての DNS システムは
使える文字に制限はない、ってことか。
なるほど。 3com.comが登場したとき
数字で始まるのはAUTOだろ、と
誰かがfjで議論してた記憶があるのだが
アスタリスクはもっとだめだろ
それはともかく例示のexample厨はタヒね DNSの仕様上使える文字=レコード定義に使っていい文字、ではないし、
BINDなどの各DNS実装で実際に定義できる文字=レコード定義に使っていい文字、でもない
ホスト名、ドメイン名、リソースレコード名、メールドメイン名などなど、
それぞれのRFCで使っていい文字、長さなどが規定されている
でも
hoge.example.com
これはホスト名?(サブ)ドメイン名?リソースレコード名?メールドメイン名?
適用されるべきRFCは何番?
そんなの区別つかんやろ? そもそも排他でもないし。
それをデフォルトで安全側に倒してチェックしていたのが BIND 8 まで、
自分で勉強して正しく定義しろや、となったのが BIND 9 最近は静かだと思ってたら、こんなんが来るのか。DNS は罪深いのう。
(緊急)複数のDNSソフトウェアにおける脆弱性(システム資源の過度な消費)について(2014年12月9日公開)
- BIND 9では権威DNSサーバーにも限定的に影響、バージョンアップを強く推奨 -
ttp://jprs.jp/tech/security/2014-12-09-multiple-impl-vuln-delegation-limit.html ▽対象となる実装/サービス・バージョン
現時点において判明している、本脆弱性が影響を及ぼすDNSソフトウェアは
以下の通りです。
・すべてのバージョンのBIND 9
・すべてのバージョンのUnbound
・すべてのバージョンのPowerDNS Recursor そういやBIND10はどうなったんだ?
開発諦めたの 10は鬼門だな。
Sendmail Xなんてのもあったね。 この案内を見てパッチ当てようと思ったら、まだyumで提供されていないんだが?
サポート料金は言い訳しか言わないテレクラ料金か?
と思っているけど恐くて口に出せませんです unbound.conf ですけど
forward-zone:
name: "."
forward-addr: 192.168.1.1
の行が無視されてしまってます。
192.168.1.1に問い合わせに行かず、rootへ聞いてるるみたいでして。
ちなみにこの3行を削除しても dig に成功してしまいます。
どうなってるんでしょうか。 >>174
まったく検証せずにテキトーなこと言ってみるけど、それは本当に root に
問い合わせがされているのか、どうやって確認しましたか?
root hint が関係している予感がします。 bindのforward only相当の設定が必要ってこと? >>174ancher-keyなんちゃらってのをコメントアウト
あとはunboundのDNSSECの無効化参照。 >>174
基本的には、それで 192.168.1.1にforwardされるはず。
Unboundのforward-zoneは、デフォルトで
BINDのforward-only yes相当だしなぁ。確認するポイント:
1. unbound-control list_forwards で、
Unboundが認識している設定として forward先が 192.168.1.1になってるか
確認。なってるなら「. IN forward: 192.168.1.1」という表示になるはず。
→ OS付属やパッケージのUnboundの場合、起動スクリプトやresolvconfが、
Unbound起動後に勝手にforward先を変えることがある
2. 対象のUnboundに digできてるか確認。dig @127.0.0.1 www.google.com
のようにIPを指定して digしているか? また重複をお許しくださいが来ましたね。いつもの通り BIND が対象ですが、今回は
DNSSEC 検証が有効になっていなければ影響を受けないそうで……
正直なところウチの会社は有効にしてないんだけど、有効にしていることろって
結構多いんですかね? 一般コンシューマ向けにサービスしているキャッシュサーバでは
有効になっているところの方が多いのかなあ。 なんでBINDのDNSSECはこんなに穴が出るんだろうな
根本的に作りがおかしいんじゃないのか? iscのソフトウェアは必要なら再発明するようにして全て排除すべきだよ >>180
権威サーバーがヘマこいてるのにこっちのリゾルバの障害だなんだとディスられるんじゃ割に合わんだろ。
NASAですらやらかすのに。
某ISPとか、キーマンらしき中の人抜けたけど無事に回せてるのかな。 国内のキャッシュサーバーは「有害サイト」をブロックするために勝手に虚偽の応答を返すし
気休めかもしれんがDNSSEC標準化にはちょっとだけ期待している >>181
BIND9ってNominumに委託して作り直したんじゃなかったっけ?
にしても痛いバグ大杉だね >>187
そんな話あったの?
Infobloxにお願いしたほうが早そうだよね。
Cricket LiuさんやJimmeiさんいるし。 >>188
「BIND9 Nominum」でググると出てくるよー。
Wikipediaにも書いてある。
http://en.wikipedia.org/wiki/BIND
>Version 9 was developed by Nominum, Inc. under an ISC outsourcing contract, nscdがttlを設定できるのでLinuxで使おうと思っていますが、
キャッシュできていないようです。
resolv.confがヒントかなと思って、127.0.0.1とルータのアドレスを書いて、networkもnscdも再起動しましたが、
nscd -gの結果は0になっています。
リゾルバがnscdを読みに行っていない気がするんですがご教示願いたく質問いたします。 すいません。キャッシュを読みに行った形跡がありましたが、また0になりました。
もう少し様子を見てみます。 nscd -gが何種類も出力してました。serviceの項しかみていませんでした。
失礼しました。nscdはうまく動いています。 Unboundで
forward-zone:
name "."
forward-addr: 192.168.1.1
※192.168.1.1はルーター(さらにISPのDNSに転送)
とやってます。
普段はいいのですが、ルーターを再起動するなどして上位への名前解決に失敗してる状態が数分間つづくと変になります。
1.試しにルーターOFF
2.dig www.yahoo.co.jp @127.0.0.1
最初のうちは
;; connection timed out; no servers could be reached
を返すんですが、数分(3〜5分)、ルーターを回復させないでおくと
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18870
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
になってしまいます。
ただし、unbound の中で local-data 書いたものに対しては、ちゃんと応答が帰ってきます。
(上位DNSを使って解決しないといけないものだけが SERVFAIL になる)
いったんこうなると、service unbound restart しないと回復しません。
なにか解決方法ないでしょうか。 ルーターのWAN側を引っこ抜いた状態にして
そのルーター相手に dig ると refused で戻されます。
上位DNSに問い合わせにいけないせいだと思うので正常なのですが
この状態で unbound 経由で dig ると、SERVFAIL になり、
ルーターの WAN側 が回復して、ルーター相手の dig が成功するようになっても
unbound のほうはサービス再起動するまで二度と回復してくれず、ずっと SERVFAIL のままです。 >>194それはyahoo以外に問い合わせてもservfailされる? PR-500KIだけど不定期にこんなログでるね。
BNE-OpS端末管理部 端末情報登録成功 >>193
unbound.conf (service.conf)に、
infra-host-ttl: 10 と書いてみるとどうかな?
フォワーダ先が1個しかない (かつ時々その1個に到達できないことがある)
環境だとデフォルトの900秒は長すぎるかもしれない 無くてもいいけどある方が便利
場合によっては無いとダメなこともあった気がする 正引きだとドメインごとにDNSサーバーを立てて管理するイメージだが
逆引きだと誰が管理するの?
例えば200.201.202.203の逆引きはどこのサーバーでやるの? >>200
逆順(203.202.201.200.in-addr.arpa)をドメインに見立てて設定するだけで正引きと同じですよ。 >>201
なるほど
で、サーバーはどこに作ると考えたら良いの? >>202
ど素人が横からですが教えてください
>IPアドレスを割り当てられた組織。
ってことは、1IPででも契約したらドメイン持って無くても逆引きサーバを立てる必要がでてくるの? >>204
グローバルIPアドレスの「割り振り」「割り当て」は専門用語だから、まあぐぐって。 >>203
サブドメインの委譲については知っているものとして書きます。
正引きの場合、ルートないし上位のドメイン(com、jp、など)はプロバイダなどなどが管理しているサーバーがあり、
自分のドメイン(例えばexample.com)を自分のサーバーで運用しようと思うなら、該当サブドメインを委譲してもらう。
レジストラなどが運用しているサーバーで運用する場合であっても同様。
逆引きの場合も基本的には同じ。CIDRを考えるとちょっと複雑になるので、ちょうど切りの良いところでIPを割り当てるケースで考える。
200.201.0.0/16をあるプロバイダXが持っているとする。それを /24ごとに、ユーザーに割り当てるとする。
200.201.1.0/24 を株式会社Aに、200.201.2.0/24をB大学に、というふうに。
逆引き用の in-addr.arpa ドメインは comやjpなどと同じようにプロバイダなどなどが管理しており、
そのサブドメインである 201.200.in-addr.arpa をプロバイダXが管理するサーバーに委譲する。
プロバイダXは、顧客の株式会社Aに 1.201.200.in-addr.arpa、B大学に 2.201.200.in-addr.arpaを委譲する。
株式会社AやB大学は、希望するなら自身のDNSサーバーで逆引き用のドメインを運用してもいいし、プロバイダXに任せてもいい。 ふと気になったのですが、
@i.softbank.jp なメールアドレスへのメール送信は、どこのサーバーへ行くのでしょうか
nslookup しても Non-existent domain と怒られてしまいます。
(A/SOA/TXT/MX すべて一緒) 普通に MX が存在してますよ? (それにしても TTL が短いな……)
どのように確認したのか教えていただかないと何とも言えませんが、
おそらく、あなたが参照しているキャッシュサーバの管理者様に
ご確認いただくのがよろしいかと。 失礼しました、i.softbank.ne.jp ってタイプしてしまってました ttp://pbs.twimg.com/media/CGF7njBVIAAkaFV.png 質問です。
とあるアプリケーションがSRVをサポートしており、SRVレコードを設定し使用しているのですが一部のユーザが接続できません。
はじめはそのユーザのPCの設定を疑ったのですが、複数人同じ問題を抱えるユーザが居たので余計原因がわからなくなりました。
SRVレコードに対応していないブロードバンドルータやDNSサーバというのは存在しているのでしょうか。
また、曖昧な情報で申し訳ありませんが原因はわかりますでしょうか。 >>211
その一部のユーザとやらの環境では「アプリに接続できない原因は名前解決が出来ない
という点である」ということは、ちゃんと裏付けが取れていますか?
あと、そこまで状況を分析できるのなら、DNS サーバ側 (キャッシュと権威の両方とも) の
クエリログを確認しようという発想が出てきても良いように思えます。それが出てこない
ということは、まだ何か特殊な事情があるのでは? という気もします。 >>212
レスありがとうございます。
ユーザにログを送信してもらい確認したのですが、ログを見る限りはSRVレコードでの解決を試して
その後失敗した(若しくはSRVレコードが登録されていない)ようならAレコードでの名前解決を試していました。
DNSサーバに関してですが、権威サーバはCloudFlareを使用しており、詳細なクエリログは確認できません…。
また、キャッシュサーバはユーザからISPを聞き出し、同じISPを使用している知人に、そのISPのDNSサーバでの名前解決を試みてもらいましたが
とくに問題もなく名前解決ができてしまいます。
これだけ書くと、ルータかPCが原因のような気もしますがどうなんでしょうか…。 >>213
ユーザの使っているブロードバンドルータがキャッシュサーバになっているケースもあり得ますね。
ユーザのPCのDNS設定はどうなっているか確かめるほうがいいかも。
古いブロードバンドルータだとSRVレコードを扱えないことがあるかもしれないですね。あくまで、かもしれないです。
ユーザのPCでSRVレコードの問い合わせが出来ているかどうか確かめるほうがいいかも。
そもそも、そのアプリはOSのリゾルバを使っているんでしょうか?
原因を切り分けるには、これらも考えてみてはどうですか。 >>214
レスありがとうございます。
ユーザとは主にメール等でしかやり取りできないので、知人や友人に似たような症状が出るか試してもらおうと思います。
該当のアプリがOSのリゾルバを使用しているのかも確認してみます。 接続できないユーザが使ってるIPアドレスに共通項があるようなら、アクセスブロックとか経路とか疑うかな。
同じISPでもIPv4の枯渇からこっち、様々な経路をもつIPアドレスをユーザに払い出したりしてるし。 >>211の問題に該当しているかはわからないけど、
古いファイアウォールやルータ(に内蔵されてるDNSフォワーダー)は、
SRVレコードのクエリをドロップするやつがいる。
特に、古いdnsmasqはSRVクエリをドロップする設定(filterwin2k)が
デフォルトになっていた時期があり、このdnsmasqをDNSフォワーダとして使っている
古い家庭用ブロードバンドルータがSRVレコードを落とすことがわかっている ■ このスレッドは過去ログ倉庫に格納されています