X
【DNS】Name Server 総合スレ Part2
0102名無しさん＠お腹いっぱい。
垢版 |
2014/07/08(火) 03:46:30.63
ISCのBIND祭と言えば、六尺褌一丁のDNS担当者たちが、
namedをアップデートし合う、勇壮な祭りとして、
この地方に知られている。
0110名無しさん＠お腹いっぱい。
垢版 |
2014/08/14(木) 20:31:59.50
DNS名前衝突ブロックリストな件
ttp://internet.watch.impress.co.jp/docs/news/newgtld/20140812_661957.html

これ、DNSプリフェッチ機能で問い合わせされたドメインは、除外されてるの？
どうしても登録させたくないドメインを毎日機械的に問い合わせてれば、禁止にできるの？

中の人、あ意外とほっぽい。
0112名無しさん＠お腹いっぱい。
垢版 |
2014/08/14(木) 21:33:41.85
あれ、この記事、申請拒否されたドメインがプレミアム予約リストに該当してるんなら、
やっぱりレジストラが腹黒ってことになるじゃね？
0114名無しさん＠お腹いっぱい。
垢版 |
2014/09/06(土) 18:21:32.33
>>113
そのページだと軽く流して、直ぐに名前衝突に話が進んでいるが、
付加価値がつく名前はレジストラが先に予約しているって書いてある

.network .dot .inspire .trust
.nt .do .nex .aegis .terra
とかプレミアついて人気レジストラになれそうじゃん

こういうのはレジストラがキープしてねずみ講の親になるから、パンピーにはやらんってことだよ
0115名無しさん＠お腹いっぱい。
垢版 |
2014/09/06(土) 18:27:23.80
今に手数料の上納ルールが作られるだろうしね
仕組み上必ずルートに検索かける通り、上の方は負荷がかかるから保守費払え、インフラただ乗りすんなーってね
0117名無しさん＠お腹いっぱい。
垢版 |
2014/09/09(火) 09:24:15.22
nsdでセカンダリ建ててます。
プライマリのレコードが（SOAも）変更されたとき
セカンダリに転送かかるべきところ、そのタイミングでセカンダリ側のnsdが落ちます。
(プロセスにも残らない)

Sep 9 08:00:48 ubuntu14 nsd[14255]: database corrupted, cannot update
Sep 9 08:00:41 ubuntu14 nsd[1149]: message repeated 54 times: [ wait failed: No child processes]
Sep 9 08:00:48 ubuntu14 nsd[1149]: handle_reload_cmd: reload closed cmd channel
Sep 9 08:00:48 ubuntu14 nsd[1149]: Reload process 14255 failed with status 256, continuing with old database
Sep 9 08:00:48 ubuntu14 nsd[1149]: wait failed: No child processes

※ubuntu14 はホスト名

shutdown -r now で再起動かけると
ちゃんと起動直後にゾーン転送が行われ正常終了します。

プライマリのSOAが変わらないうちは好調に動作しますが、
またゾーン転送がかかると落ちます。

なにか原因として考えられることありますでしょうか。
0119名無しさん＠お腹いっぱい。
垢版 |
2014/09/09(火) 14:35:11.95
再起動すると正常動作（かつゾーン転送も済んだ状態）になるから
実際にはデータベース壊れてないと思うんだけど・・・
0121名無しさん＠お腹いっぱい。
垢版 |
2014/09/12(金) 02:00:49.66
>>117
nsdc patch してみてください
0122名無しさん＠お腹いっぱい。
垢版 |
2014/09/12(金) 11:01:55.05
DNS1で名前解決できなかったらDNS2に問い合わせ
という仕組みを構築したいんですが、これって無理ですかね？

DNS1の電源が落ちているとか通信自体ができない場合はDNS2へ問い合わせに行くのですが、
DNS1の応答が「そんなレコードありません」という応答だった場合、
DNS2に見に行かないのです。

おそらく通常の仕様なのはわかっているのですが、何とかなりませんか？

社内向けDNSサーバーで解決できなかったら
クラウド上のDNSサーバーで解決させたいのですが・・・。
同じレコードを持てない理由がありまして・・。
0123名無しさん＠お腹いっぱい。
垢版 |
2014/09/12(金) 11:18:32.48
「同じレコードを持てない」というのをもちっと詳しく書けませんか？

なんとなくzoneとかforwarderとか
そんな感じのことで調べてみるとなんとかなったりするかもしれません。
0125名無しさん＠お腹いっぱい。
垢版 |
2014/09/12(金) 12:54:40.00
hoge.jpは他者管理



「www.hoge.jp」←インターネット上のhoge.jpの名前解決はDNS2
　　　　|
(インターネット)
｜
「自社：jiya.jp」-(VPN)-「wwwsec.hoge.jp」←VPN上のhoge.jpの名前解決はDNS1


VPN上はセキュアなネットワークというポリシーらしく、
DNS1-DNS2間の通信はできない
0126122・125
垢版 |
2014/09/12(金) 12:58:58.60
hoge.jpという同名のドメイン名が
VPN上とインターネット上　両方にあるのが問題かなーっと
でも他者なので口を挟めない。

自社にDNSサーバーにwww.sec.hoge.jpの問い合わせが来たら
DNS1へフォワードするってのが簡単に思いついた事だけど、
hoge.jpのサーバーが増えたりするたぶに手で修正すうのは面倒・・・。
DNS1レコードがなかったらDNS2へ追い合わせ汁！っていう形とれないかな？
0132名無しさん＠お腹いっぱい。
垢版 |
2014/09/12(金) 14:31:42.18
hoge はあれなんで example.jp で話すけど
example.jp は他者が管理していて、そのサブドメイン sec.example.jp を
自分のところの中でだけ存在させたい、ってことかな。

もし、そうなら自分のところDNS(DNS1なのか？)に勝手に sec.example.jp のドメインを持たせてしまえばいいんじゃないか？
example.jp のDNSで委譲してもらわなくても、クライアントがDNS1に問い合わせるようにしとけば
sec.example.jp については名前解決できる。

サブドメインじゃないよ、ホスト名だよって場合でも、ホスト毎にzoneを作ることは可能。
0133名無しさん＠お腹いっぱい。
垢版 |
2014/09/13(土) 01:14:12.33
localhostのサブドメインでやればいいだよ好き放題作っていいんだから
0134名無しさん＠お腹いっぱい。
垢版 |
2014/09/13(土) 05:28:05.27
>>122
そういう名前解決をしてくれるDNS3を用意したいけどどのDNSサーバだと実現できるんだろうって話？
>>132
RFC2606で予約されてるのは、.test、.example、.invalid、.localhost、example.com、example.net、example.org
example.jpは予約されてませんよ、という野暮なツッコミ
0143名無しさん＠お腹いっぱい。
垢版 |
2014/09/16(火) 13:56:35.37
perlのバージョン違いのテスト用に
p516.localhost
p518.localhost
p520.localhost
とか
vmに振るなら
deb.localhost debian
net.localhost netbsd
ubu.localhost ubuntu
0145名無しさん＠お腹いっぱい。
垢版 |
2014/09/17(水) 01:30:20.52
アスタリスクかぁ
使い方としたら、こんな感じ？
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

かなり遊んだ設定だけど。
0146名無しさん＠お腹いっぱい。
垢版 |
2014/09/17(水) 19:11:45.77
DNSの仕様上は、名前に*という文字が含まれていても問題ない。
アプリケーションがそういう文字を含む名前を扱えるかどうかはそれとは別問題。

むかし、*.cnというAレコードが実際に存在してたことがあるよ。
ワイルドカードを作るつもりで間違ってそうなっちゃったのか、
意図してそうしたのか、cnのやることだからわからん。
0148名無しさん＠お腹いっぱい。
垢版 |
2014/09/17(水) 23:41:09.29
横から失礼するけど、DNSの仕様ってどの範囲までを言うのかよーわからん
RRのフォーマットまでが仕様っぽいように見えるけど、そんなんネームサーバの
実装ごとに違っても別にいいじゃんって思うし。
0149名無しさん＠お腹いっぱい。
垢版 |
2014/09/18(木) 00:49:43.98
仕様っていったら、当然 RFC に書かれた文章そのままだろうに…
古いホテルの様な拡張につぐ拡張で、わかりにくいけどな。

いいんだぜ。 hosts に記載された内容を応答する named を作っても。
0151名無しさん＠お腹いっぱい。
垢版 |
2014/09/18(木) 01:19:54.77
>>147
きっと大元は RFC2181 なんだろうけど、ラベル名の定義が他の RFC で
アップデートされてるのかどうかが、よくわからん。これを読めば DNS の
仕様が一通り把握できる便利な RFC とか、ポータルなサイトとか無いのかな？

Information on RFC 2181
ttp://www.rfc-editor.org/info/rfc2181
0152名無しさん＠お腹いっぱい。
垢版 |
2014/09/18(木) 03:06:52.51
ドメイン名の管理を代行する企業であってすら、
設定ミスを浸透と呼んで誤魔化すのが日常だし…
そんな便利なもんがあったらこんな状況にはならん気が
0153名無しさん＠お腹いっぱい。
垢版 |
2014/09/18(木) 10:53:54.77
使えるのはアルファベットと数字とハイフンだけじゃなかったっけ。
ソースは RFC952 の 1.、RFC1035 の 2.3.1. あたり。ついでに RFC1123 の 2.1.も。
情報古いかな?

>>151
> きっと大元は RFC2181 なんだろうけど、
* 使っていいってどこに書いてある?
0157名無しさん＠お腹いっぱい。
垢版 |
2014/09/18(木) 12:15:23.61
>>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 でそういう文字を使うのが禁止という意味ではなく、アプリ側の都合でそういう
> 文字を使うことができないかもしれないから注意しろ、という意味である。
(同上)
0159名無しさん＠お腹いっぱい。
垢版 |
2014/09/26(金) 22:14:16.05
3com.comが登場したとき
数字で始まるのはAUTOだろ、と
誰かがfjで議論してた記憶があるのだが

アスタリスクはもっとだめだろ

それはともかく例示のexample厨はタヒね
0160名無しさん＠お腹いっぱい。
垢版 |
2014/10/08(水) 04:21:38.92
DNSの仕様上使える文字＝レコード定義に使っていい文字、ではないし、
BINDなどの各DNS実装で実際に定義できる文字＝レコード定義に使っていい文字、でもない

ホスト名、ドメイン名、リソースレコード名、メールドメイン名などなど、
それぞれのRFCで使っていい文字、長さなどが規定されている

でも

hoge.example.com

これはホスト名？（サブ）ドメイン名？リソースレコード名？メールドメイン名？
適用されるべきRFCは何番？
そんなの区別つかんやろ？ そもそも排他でもないし。

それをデフォルトで安全側に倒してチェックしていたのが BIND 8 まで、
自分で勉強して正しく定義しろや、となったのが BIND 9
0161名無しさん＠お腹いっぱい。
垢版 |
2014/12/09(火) 13:05:35.63
最近は静かだと思ってたら、こんなんが来るのか。DNS は罪深いのう。

（緊急）複数のDNSソフトウェアにおける脆弱性（システム資源の過度な消費）について（2014年12月9日公開）
- BIND 9では権威DNSサーバーにも限定的に影響、バージョンアップを強く推奨 -
ttp://jprs.jp/tech/security/2014-12-09-multiple-impl-vuln-delegation-limit.html
0164名無しさん＠お腹いっぱい。
垢版 |
2014/12/09(火) 20:24:54.59
▽対象となる実装／サービス・バージョン

現時点において判明している、本脆弱性が影響を及ぼすDNSソフトウェアは
以下の通りです。

・すべてのバージョンのBIND 9

・すべてのバージョンのUnbound

・すべてのバージョンのPowerDNS Recursor
0172名無しさん＠お腹いっぱい。
垢版 |
2014/12/11(木) 08:45:48.07
この案内を見てパッチ当てようと思ったら、まだyumで提供されていないんだが？
サポート料金は言い訳しか言わないテレクラ料金か？
と思っているけど恐くて口に出せませんです
0174名無しさん＠お腹いっぱい。
垢版 |
2014/12/12(金) 16:18:12.96
unbound.conf ですけど

　forward-zone:
　　name: "."
　　forward-addr: 192.168.1.1

の行が無視されてしまってます。
192.168.1.1に問い合わせに行かず、rootへ聞いてるるみたいでして。
ちなみにこの3行を削除しても dig に成功してしまいます。

どうなってるんでしょうか。
0176名無しさん＠お腹いっぱい。
垢版 |
2014/12/12(金) 19:22:54.51
>>174
まったく検証せずにテキトーなこと言ってみるけど、それは本当に root に
問い合わせがされているのか、どうやって確認しましたか？

root hint が関係している予感がします。
0178名無しさん＠そうだ選挙に行こう
垢版 |
2014/12/13(土) 19:34:55.84
>>174ancher-keyなんちゃらってのをコメントアウト
あとはunboundのDNSSECの無効化参照。
0179名無しさん＠そうだ選挙に行こう
垢版 |
2014/12/13(土) 21:33:16.94
>>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しているか?
0180名無しさん＠お腹いっぱい。
垢版 |
2015/02/19(木) 14:09:15.18
また重複をお許しくださいが来ましたね。いつもの通り BIND が対象ですが、今回は
DNSSEC 検証が有効になっていなければ影響を受けないそうで……

正直なところウチの会社は有効にしてないんだけど、有効にしていることろって
結構多いんですかね？ 一般コンシューマ向けにサービスしているキャッシュサーバでは
有効になっているところの方が多いのかなあ。
0182名無しさん＠お腹いっぱい。
垢版 |
2015/02/19(木) 18:41:10.66
iscのソフトウェアは必要なら再発明するようにして全て排除すべきだよ
0184名無しさん＠お腹いっぱい。
垢版 |
2015/02/19(木) 19:46:18.32
>>180
権威サーバーがヘマこいてるのにこっちのリゾルバの障害だなんだとディスられるんじゃ割に合わんだろ。
NASAですらやらかすのに。

某ISPとか、キーマンらしき中の人抜けたけど無事に回せてるのかな。
0186名無しさん＠お腹いっぱい。
垢版 |
2015/02/21(土) 22:43:52.73
国内のキャッシュサーバーは「有害サイト」をブロックするために勝手に虚偽の応答を返すし

気休めかもしれんがDNSSEC標準化にはちょっとだけ期待している
0190名無しさん＠お腹いっぱい。
垢版 |
2015/03/31(火) 12:59:42.21
nscdがttlを設定できるのでLinuxで使おうと思っていますが、
キャッシュできていないようです。

resolv.confがヒントかなと思って、127.0.0.1とルータのアドレスを書いて、networkもnscdも再起動しましたが、
nscd -gの結果は0になっています。

リゾルバがnscdを読みに行っていない気がするんですがご教示願いたく質問いたします。
0191名無しさん＠お腹いっぱい。
垢版 |
2015/03/31(火) 13:14:50.87
すいません。キャッシュを読みに行った形跡がありましたが、また0になりました。
もう少し様子を見てみます。
0192名無しさん＠お腹いっぱい。
垢版 |
2015/03/31(火) 13:28:10.12
nscd -gが何種類も出力してました。serviceの項しかみていませんでした。
失礼しました。nscdはうまく動いています。
0193名無しさん＠お腹いっぱい。
垢版 |
2015/04/01(水) 10:42:02.29
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 しないと回復しません。
なにか解決方法ないでしょうか。
0194193
垢版 |
2015/04/01(水) 12:32:54.32
ルーターのWAN側を引っこ抜いた状態にして
そのルーター相手に dig ると refused で戻されます。

上位DNSに問い合わせにいけないせいだと思うので正常なのですが
この状態で unbound 経由で dig ると、SERVFAIL になり、
ルーターの WAN側 が回復して、ルーター相手の dig が成功するようになっても
unbound のほうはサービス再起動するまで二度と回復してくれず、ずっと SERVFAIL のままです。
0195名無しさん＠お腹いっぱい。
垢版 |
2015/04/02(木) 19:31:32.31
>>194それはyahoo以外に問い合わせてもservfailされる？
0197sage
垢版 |
2015/04/07(火) 03:04:22.46
>>193
unbound.conf (service.conf)に、
infra-host-ttl: 10 と書いてみるとどうかな？
フォワーダ先が1個しかない (かつ時々その1個に到達できないことがある）
環境だとデフォルトの900秒は長すぎるかもしれない
0200名無しさん＠お腹いっぱい。
垢版 |
2015/04/22(水) 19:38:02.34
正引きだとドメインごとにDNSサーバーを立てて管理するイメージだが
逆引きだと誰が管理するの？
例えば200.201.202.203の逆引きはどこのサーバーでやるの？
新着レスの表示
レスを投稿する

ニューススポーツなんでも実況