【DNS】Name Server 総合スレ Part2
■ このスレッドは過去ログ倉庫に格納されています
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レコードを落とすことがわかっている >>217
ブロードバンドルータの DNS キャッシュサーバでは SRV を扱えない製品が存在するかも。
→これは納得できないけど理解できる
ブロードバンドルータの DNS フォワーダでは SRV をドロップする製品が存在する。
→え、マジ!? ブロードバンドルータ怖い…… (さすがに最近の製品には無いと思うけど) >>217
ルータやPCを交換したら接続できなくなったユーザも居ました…。
古いdnsmasqがSRVクエリをドロップするというのはとても興味深い情報です。
調べてみようと思います。 海外に居た時に使ってたBelkinのルータがSRVクエリをドロップしてた。
検索したらNetgearにもそういうのがあるみたい。そんなに古い話ではないようだ
http://www.willglynn.com/2013/11/01/comcast-netgear-routers-eat-srv-records/
国産のはよくわからない。今日本で使ってるAtermは大丈夫っぽいが…… 質問です。
unboundのforward-addrにISPなどの複数のDNSサーバを列記した場合、全てにクエリを送って早く返ってきたものを採用するようですが、
一つ試して返答がなければ次のサーバというように設定できないでしょうか。
よろしくお願いいたします。 上記の方とは別の質問です。教えて偉い人!
とある権威サーバに dig で問い合わせたら、ADDITIONAL SECTION に同一ラベル名の
A レコードが複数返ってきました。これって合法なんでしょうか?
↓
$ dig @dns0.heteml.jp example.co.jp ns +norec
; <<>> DiG 9.9.7 <<>> @dns0.heteml.jp example.co.jp ns +norec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 227
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;example.co.jp. IN NS
;; ANSWER SECTION:
example.co.jp. 259200 IN NS dns0.heteml.jp.
example.co.jp. 259200 IN NS dns1.heteml.jp.
;; ADDITIONAL SECTION:
dns0.heteml.jp. 86400 IN A 210.188.214.228
dns1.heteml.jp. 86400 IN A 210.188.214.229
dns1.heteml.jp. 259200 IN A 210.188.214.229
;; Query time: 19 msec
;; SERVER: 210.188.214.228#53(210.188.214.228)
;; WHEN: 水 6月 17 09:22:03 JST 2015
;; MSG SIZE rcvd: 129 ん? ネタじゃなくて本当にそういう応答が返ってくるね。
だけど偉い人じゃないんで合法かどうかは分からん。すまん。
どういう設定をするとこうなるのか、という点には興味あるな。 少なくとも言えるのは、いくつかの特徴から
dns0.heteml.jp はBIND9でもNSDでもNominumでも
無いってことですな。権威サーバは実装が簡単な分、
種類が多くて間違った実装が多いから、
こういう怪しい動きをするサーバがいてもあまり驚くことではない
重複する{owner,class,type,rdata}の組は
DNSプロトコルとしては違法だが、これを
拒否するリゾルバはたぶん無いんじゃないかな >>222
> 複数のDNSサーバを列記した場合、全てにクエリを送って
> 早く返ってきたものを採用するようですが
全てにクエリを送るではなく、
「基本はランダムに送信するが、ある一定のRTTより
長いやつや応答しないやつは避ける」
といったほうが正しい
> 一つ試して返答がなければ次のサーバ
Unboundの設定だけでは出来ないんだけど、
なぜそうしたいんだろう
基本的にはISPのDNSサーバ使いたいが、
ISPのDNSが障害になったら8.8.8.8に
切替えたいとかそういうことかな >>227 dnsmasqだとstrict-orderという設定で一つがだめならもう一つを試すってやりかたで、
パケット量を減らせるんですよね。
unboundがいいのは、min-ttlを設定できるところです。
ランダムで送るのならこのまま使います。
パケット量を減らしたかったのでした。
ありがとうございました。 >>226
偉い人ステキ!
それはともかく、権威サーバってそんなにいろいろあるんですか。
拒否するリゾルバが存在したら、こういう権威サーバが修正される助けになるのに……
無駄に厳密な解釈をするリゾルバが存在していたら、チェック用途としても面白いかもですね。 >>230
GSLBとかへんてこなFWで設定ミスったり仕様が腐ってたりして
おかしなことが起こることもあるよ。 ■ このスレッドは過去ログ倉庫に格納されています