■掲示板に戻る■ 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 最新50



レス数が1000を超えています。残念ながら全部は表示しません。

BIND全般

1 :  :2001/07/12(木) 23:12
魔術師の溜まり場です

33 :質問 :01/10/11 20:57
以下のメッセージの対処方をおしえてください。

check_hints: root NS list in hints for class 1 does not match root NS list

34 :名無しさん@お腹いっぱい。 :01/10/11 21:03
>33
http://www.google.com/search?q=check_hints%3A+root+NS+list+in+hints+for+class+1+does+not+match+root+NS+list&filter=0

35 :名無しさん@お腹いっぱい。 :01/10/17 03:36
携帯電話のブラウザで有名なACCESSのDNSつついたんです。
そしたら、
C:\>nslookup -type=txt -class=chaos version.bind dns0.access.co.jp
Server: dns0.access.co.jp
Address: 157.78.0.252

VERSION.BIND text =

"8.2.2-P5"

C:\>nslookup -type=txt -class=chaos version.bind dns1.access.co.jp
Server: dns1.access.co.jp
Address: 157.78.0.251

VERSION.BIND text =

"8.2.2-P5"

これってどうよ?

36 :名無しさん@お腹いっぱい。 :01/10/17 04:37
>>35
オレッチのクラック済みリストに入ってるよ。自分の庭みたいにあそんでるよ。

37 :JAPU ◆JAPUTeX. :01/10/17 06:20
/FYI/

今月になっていろんなバージョンのBIND出ていますね。
http://www.isc.org/products/BIND/

----
安全なのは 8.2.3 以降と 9.x。
(8.2.3 も一部問題があったはず。)
4.x は論外。

http://www.isc.org/products/BIND/bind-security.html

38 :名無しさん@お腹いっぱい。 :01/10/17 06:25
>>37
> 安全なのは 8.2.3 以降と 9.x。
8系は 8.2.4 以降ですね。

> 4.x は論外。
そうでもないよ。とくに、ベンダー供給の Unix は未だに 4系だったりするし。
4 系は obsolete であるけれども、これを使わなければならない理由は
否定できない。そういう環境では 4.9.8 に age とけとしかアドバイスできない。

39 :JAPU ◆JAPUTeX. :01/10/17 06:51
えーと、
安全 == remote exploit 可能ではない という意味で使いましたけど、
8.2.3 って何か問題ありましたっけ?

40 :名無しさん@お腹いっぱい。 :01/10/20 21:40
ゾーン名が248aとかみたいにaがつくのはどうしてですか?

41 :名無しさん@お腹いっぱい。 :01/10/20 23:00
> 4.x は論外。
OpenBSDは、4.xが採用されてる。
そのうえ、IPv6対応済み

42 :名無しさん@お腹いっぱい。 :01/10/21 00:33
>>40
逆引きか?
RFC 2317 読んどけ。
http://www.google.com/search?lr=lang_ja&q=rfc+2317

43 :名無しさん@お腹いっぱい。 :01/10/24 14:10
>>39
8.2.3-beta までですね。スマソ
http://www.isc.org/products/BIND/bind-security.html

>>40
/25 以下の権限委譲については、該当するプロバイダ側で受け持ったのち
各ユーザー毎に分割して利用される。
http://www.fan.gr.jp/~kaz/rfc/rfc2317j.txt

>>41
OpenBSD のパッケージ場合はコードレベルで置きかえられているから、
version はあまり意味をなさない。
http://www.lac.co.jp/security/intelligence/CERT/CA-2001_02.html

44 :名無しさん :01/10/24 20:10
コピペしておこう。

ていうか、私が聞きたかっただけです。
Aレコードを複数定義してる人っていますか?
私は複数定義でBINDを動かしてるのですが
今のところ問題なく動いています。

やっぱ、CNAMEレコードで定義したの方が良いの?
そこら辺どうなんですかね?

45 :名無しさん@お腹いっぱい。 :01/10/24 21:13
甘やかしちゃいかんのだけどな……。

>>44
どちらかといえば、
逆に CNAME レコードを複数書く方が間違い。
たいていは問題ないだろうが。
読んどけ。
http://www.aso.ecei.tohoku.ac.jp/~dais/misc/rfc1912j.html

46 : :01/10/24 22:23
44のURLのどこをどう読むと「CNAMEを複数書く方が間違い」なの?
「間違った書き方をしてはいけません」みたいなことしか書いてないゾ。
オライリー本をちゃんと読んでくれ。

47 :   :01/10/24 22:35
現在のBINDでは、複数のCNAMEレコードの使用は推奨されてないですよ

48 :「45のURL」の :01/10/24 22:36
間違いだった。スマン。(46)

49 :名無しさん@お腹いっぱい。 :01/10/24 22:39
>>46
http://www.aso.ecei.tohoku.ac.jp/~dais/misc/rfc1912j.html#cname
MX、CNAME、 PTR、NS のような、 他の名前を指している資源レコードと 共同で CNAME を使わないでください。

50 :DNSスレの1 :01/10/24 23:05
>>44

コピペ有り難う御座います。

>>45

てこたぁ、やっぱ複数の名前を割り当てたいときは
CNAMEレコードじゃなくてAレコードを使うわけ?

今からそのURL読みます。
ていうか、質問する前によんどけって怒らないでください。

51 :45=49 :01/10/25 01:41
>>50
> てこたぁ、やっぱ複数の名前を割り当てたいときは
> CNAMEレコードじゃなくてAレコードを使うわけ?
ぐは、そっちか。
同じ名前で複数の CNAME RR を書くのかと思った。

どっちにしろ「CNAME を乱用しないでください。」だな。

52 :名無しさん@お腹いっぱい。 :01/11/01 14:35
8.xと9.xって何が違うの?

53 :名無しさん@お腹いっぱい。 :01/11/02 00:06
別スレでみて気になったんだけど named(bind-8.2.3)の
named[****]: Lame server on 〜 っていう message って何でしょうか?
うちにもたまに記録されるんだけど。
直訳したら 「不完全なサーバー」になるんだけど、、、

54 :名無しさん@お腹いっぱい。 :01/11/02 01:36
>>53
http://www.isc.org/products/BIND/docs/config/logging.html

55 :名無しさん@お腹いっぱい。 :01/11/02 11:05
バッタ本(三版)の7.6.1節ですな。

> 「艦長、本艦は座礁した模様であります!」インターネット海には
> 間違った委任という岩礁があちこちにあるようだ。

ってな、寒い表現。

56 :名無しさん@お腹いっぱい。 :01/11/02 12:14
>>53
http://www.google.com/search?lr=lang_ja&q=Lame+server

57 :  :01/11/03 02:10
Q1) ゾーン転送する機能を利用して悪いことをされたり
    しないのでしょうか?
Q2) BINDよりも安全で簡単なDNSがあるなら、どうして
    いつまでもBINDのようにいまだにバグが出ている
    ようなコードに依存するのですか?Linuxや
    FreeなBSDなら、BINDを捨ててもっと根本的に
    安全で簡潔なDNSシステムをデフォルト標準として
    採用するべきではないのでしょうか?

58 :名無しさん@お腹いっぱい。 :01/11/03 02:55
A1) 基本的に、ゾーン転送は slave server のみに許可するもの。
即クラックにつながるわけではないと思うが、不要な情報は公開しないのが原則。
A2) システム標準として使える安全で簡潔なDNSシステムってある?

59 :名無しさん@お腹いっぱい。 :01/11/03 04:48
A1) 通常のdnsクエリーよりゃ重いので、制限なしだとDoS攻撃される可能性も多少あり。
  今のBINDなら大丈夫だろうが。
  基本的には>>58の通り「余計な知識を攻撃者に与えない」ってのが重要。
A2) 「英語よりも平等で簡潔なエスペラントがあるのに、いまだに英語の様な非論理的で
  変動の激しい言語に依存しているのは何故?」というのと大して変わりませんな。
  あぁデファクトスタンダードって素敵。(藁

>>58
お約束だが djbdns はどうか?
OpenBSDのportsから見事に外されたが。

60 :名無しさん@お腹いっぱい。 :01/11/03 04:53
>>59
djbdns ってライセンスどうなってたっけ?
探したけど見つかんなかった。

61 :名無しさん@お腹いっぱい。 :01/11/03 04:59
>>60
djb toolsはライセンスがどこにあるのかわかりにくいよね。
source archiveとhttp://cr.yp.to/djbdns/ をざっと見たけど見当たらなかった。

qmailの例から想像すると、勝手に修正するなやゴルァなんじゃないかと。

62 :名無しさん@お腹いっぱい。 :01/11/04 07:06
>>61
確かそんなんだったはず。
今確認しようとしてcr.yp.toを見たら繋がらねぇでやんの。(藁

>>57
しかし実際問題、普通のマシンではBINDはキャッシュとして使われる他は
リゾルバ周りでライブラリが使われる程度なんだから、別にBINDが標準で
困ることはないと思う。

DNSサーバを建てるなら、当然その案件に即したDNS用ソフトウェアを導入
するだろうし。盲目的にBINDを使って墓穴を掘るのは、また別の問題だな。

63 :名無しさん@お腹いっぱい。 :01/11/04 19:14
>>62
おすすめは BIND + dnscache の併用って感じかな。

64 :名無しさん :01/11/08 04:31
サブドメインを使う場合のMX指定てこれでいいの。

IN MX 10 mx
aaa IN MX 10 mx
bbb IN MX 10 mx
mx IN A 192.168.1.1

なんか、こんな設定みたことないから不安。

65 :名無しさん@お腹いっぱい。 :01/11/08 05:51
今ふと思ったんだけど逆引きて偽造出来る?
例えば
123 IN PRT www.yahoo.co.jp.
とか出来ますよね。

これって、別に痛くも痒くもない?

66 :名無しさん@Emacs :01/11/08 09:02
>>65
その DNS server に誰が逆引きを検索に来るんですか?
それによって痛いかどうかは変わりますが。

67 :名無しさん@お腹いっぱい。 :01/11/08 09:13
>>65
そりゃできるだろうけど、逆引きゾーンの委任が
自分にされてなきゃ誰も聞いてこないと思うのだが。

68 :ゾイゾイ :01/11/08 09:37
こんなところで質問することではないかもしれませんが。。
あるくそソフト(名前は伏せさせていただきます。)が
起動時にftpでサーバーにアクセスして情報を取ってきているのですが
その時netstat -aするとその端末からftpコネクションを54個も
張ってくるのです。作った相手に聞いても dosから普通にftp
コマンド実行しているだけだと言い張っているのですが、
私が普通にftp実行しただけではそんなことは再現しないのです。
もしその様なことが起こったことがある、こんなオペレーションを
したら再現するよって情報あれば、よろしくお願いします。

69 :諸刃の出っ歯 :01/11/08 10:45
>>68
それってBINDに関係あるのか、もしくはBINDに疑いが濃厚なのか
問いたい
名前を伏せるということは有名もしくは一般入手可能なものか
問いつめたい
DOSのFTPなのに何故ウイソ板やム板でなくUNIX板なのか
小一時間問いつめたい

70 :名無しさん@お腹いっぱい。 :01/11/08 10:57
>>64
それで問題ないが、mxでのSMTPサーバの設定はちゃんとやっとかないとはまるよ。

>>65
そういうことができるから、gethostbyaddr()で得たホスト名は信頼できない。
普通は、gethostbyaddr() -> gethostbyname()でIPアドレスが一致するか調べる。

71 :名無しさん@お腹いっぱい。 :01/11/08 11:19
つーかさ、前からの疑問なんだけど、
MX 複数定義する、っつーことは定義されたホスト全てに同じユーザがいないとだめじゃないの?

72 :名無しさん@Emacs :01/11/08 11:33
>>71
MX で指定されたホストが最終配送先であるとは限りません。以上。

73 :71 :01/11/08 11:38
>>72
なるほど!まさに現実の郵便と同じですね!ありがとうございました

74 :名無しさん@Emacs :01/11/08 13:42
>>70

ひとつ勉強になった。多謝多謝。

75 :名無しさん@お腹いっぱい。 :01/11/08 14:36
便乗質問だが、
実のところ、MX複数定義ってどういうメリットがあるの?
中継ホストを多重化できるくらいの利点しか思いつかないのだが。
そもそも配送先メールサーバ落ちてても配送元が
時間をおいてリトライしてくれるわけで。

76 :名無しさん@お腹いっぱい。 :01/11/08 15:01
>>75
負荷分散ってことでいーんでねーの?

77 :名無しさん@お腹いっぱい。 :01/11/08 15:12
送信元のrootにmaillogみられたとき、だせーサイトだな
とか思われずにすみます > 複数MX

78 :名無しさん@お腹いっぱい。 :01/11/09 02:05
自分の管理するホストがセカンダリMXとなっていれば、プライマリMX復旧後に
再送をかけることでダウンタイムを最小限に出来るって意義もある。送信元の
リトライ頼みだと、仕事に使ってるメールアカウントでは結構困るしな。

...全然BINDの話じゃなくなってるのでsage(w

79 :名無しさん@お腹いっぱい。 :01/11/09 10:58
なんか、前の方にも書いてありますが

@ IN A 192.168.1.1
ns IN A 192.168.1.1
www IN A 192.168.1.1
mail IN A 192.168.1.1
ftp IN A 192.168.1.1

ていう風にやるデメリットてありますか?
デメリットというか、これってやっちゃいけないことなんでしょうか?

識者の方教えてください。

80 :名無しさん@お腹いっぱい。 :01/11/09 12:25
>>79
特におかしくないと思うが。
ちょっと質問の意図がわからない。

81 :名無しさん@お腹いっぱい。 :01/11/09 13:50
>>80
フツー CNAME 使うだろ、とかそーゆーこと ?

82 :名無しさん@お腹いっぱい。 :01/11/09 13:55
hostname <-> IP addr
の対称性がなくなってカコワルイとかかな?

83 :名無しさん@お腹いっぱい。 :01/11/10 02:00
>>81
今時CNAMEはないだろ。つーか、CNAMEを積極的に採用する必要ってあるのだろうか?

84 :79 :01/11/10 09:09
>>80

こういう風にかいてる例をみたことなかったんで気になってたんですよ。
ということで、一つのIPに複数のAレコードはみんなよくやるっていうことなんですか。

>>81

そうそう、そう言われると思ってかいたんですよ。

>>82

あんまり気にするところではないですよね。

>>83

そ、そうなの?

85 :名無しさん@お腹いっぱい。 :01/11/10 09:21
>>83
違うよ、CNAME はネストして使わなければいいだけの話であって、
単なるラベリングとしての CNAME なら問題ないよ。

86 :名無しさん@お腹いっぱい。 :01/11/10 12:04
>>85
ネストしなくてもマズい場合がある。
>>49 参照。

87 :名無しさん@お腹いっぱい。 :01/11/10 13:25
>>86
やばい。うちのサーバちゃんとしてない。逝ってくる

88 :名無しさん@お腹いっぱい。 :01/11/10 18:17
CNAMEはCクラス以下の逆引きを行うための必須アイテムです。

ftp://ftp.iij.ad.jp/pub/rfc/rfc2317.txt

89 :名無しさん@お腹いっぱい。 :01/11/10 18:59
Canonical Nameがどれだかわからなくて気持ち悪いな..
っつーのは気持ちの問題?

90 :名無しさん@お腹いっぱい。 :01/11/10 23:38
>>88
CNAME 使わなくても NS レコードで委譲できんじゃなかったっけ?
djbdns のドキュメントにあったような。

>>89
気持ちの問題。

91 :名無しさん@お腹いっぱい。 :01/11/10 23:59
CNAMEの便乗質問なんですけど

正引きさせるとき CNAME
xxxxx IN CNAME www.xxxxxx.xxx.
yyyyy IN CNAME www.xxxxxx.xxx.
と指定する場合と
xxxx IN A 192.168.117.4
yyyy IN A 192.168.117.4
と指定する場合どっちが信頼性とかレスポンスとかいいのでしょうか。
サーバのIPアドレスを変更したとき CNAMEだと www.xxxxxxx.xxxx.
のIPアドレスを変更すればいいだけですむので通常(?)はこっちで
しょうが、www.xxxxx.xxxx.が引けないとこのホストにCNAMEしてるホスト
は全滅だし www.xxxx.xxxx.を再度引かないといけないので問い合わせて
が増えるのではないかと。

92 :名無しさん@お腹いっぱい。 :01/11/11 00:04
>>91

私は後者を多用してる。
理由は特にないけどCNAMEだとMXにつかえないとかあるから。

信頼性とかレスポンスは分からん。申しわけ

93 :名無しさん@お腹いっぱい。 :01/11/11 12:35
>>91
委譲関係とか、ネームサーバのネットワーク環境など一概には言えないが、
CNAMEを使うと確実にDNSクエリーが多くなる。
ネームサーバやリゾルバにもよるが、初回アクセスのレスポンスを重視する
なら直接Aレコードを書いた方が良いだろうね。

・・・相変わらずBINDそのものとは関係ないな。

94 :名無しさん@お腹いっぱい。 :01/11/11 19:37
>>93
なるほど。やはりそうですか。

95 :名無しさん@お腹いっぱい。 :01/11/13 11:49
ていうか、実はCNAMEっていらない?

96 :名無しさん@お腹いっぱい。 :01/11/13 12:05
>>95
>>88で書いてあるように、クラスC以下での逆引きに必要。
とはいえ、>>90で
>CNAME 使わなくても NS レコードで委譲できんじゃなかったっけ?
>djbdns のドキュメントにあったような。
こう書いてるな。これってもしかしてIPアドレス一つごとにzoneを
わけるのだろうか。

97 :90 :01/11/13 12:27
>>96
そう。
要は /32 で権限を委譲しまくる。

……ってのがどっかに書いてあったと思うんだけど、見つからんな……。
理屈では可能でしょ?

98 :名無しさん@お腹いっぱい。 :01/11/13 12:49
>>97
可能だけど、zoneが増えすぎてマズーなのかな。
いろんな方法がある中で、RFC 2317がBest Current Practiceだったんでしょう。

99 :名無しさん@Emacs :01/11/13 14:03
なんだか CNAME いらんとか言ってる人がいるようだけど、
それでは自分の管理外のサイトにあるホストを CNAME で指したい時に
困るんじゃないだろうか? とか言ってみる。

100 :名無しさん@お腹いっぱい。 :01/11/13 14:05
>>99
A が使えないのってどんな状況?

101 :名無しさん@お腹いっぱい。 :01/11/13 14:51
A使えないことはないけど、IPアドレスが変わった時はCNAMEの
ほうが有利だね。

djbdns における classless delegation はこちら。>>97で正解。
http://djbdns.jp.qmail.org/djbdns/notes/delegation.html

102 :90 :01/11/13 15:13
ども。
djbdns だと、ゾーンがいくつあろうが
ぜんぶ root/data{,.cdb} に入るからラクだね。

103 :99 :01/11/13 15:24
>>100
101 さんが書いてるように IP アドレスが変わるような時とか。それ以外だと AAAA とか。(ワラ

もちろん A しかなかったら A でやるけど、もともと違うもんだから
CNAME の方が便利なケースもあるってことで。

classless の話だけど NS はりまくるのも CNAME でやるのもどっちもどっちなのに
そんなのを BIND 批判のネタにする DJB は大人げないってことでよろしい? (ワラ
# スレ違いなので sage

104 :名無しさん@お腹いっぱい。 :01/11/13 20:51
bind や djbdns 以外の DNS はどんなのがありますか?

105 :名無しさん@お腹いっぱい。 :01/11/14 01:20
DNSの部分的な機能を実装したやつなら沢山あると思うが、
一通りの機能を機能を備えたやつならこんなのがあるらしい:

Dents
http://sourceforge.net/projects/dents/

MaraDNS
http://www.maradns.org/

106 :名無しさん@お腹いっぱい。 :01/11/14 03:03
>>103
BINDの実装に束縛されたad hocな方法を嫌い、使用者にそんな手段を選ばせて
しまうBINDを非難することは間違ってはいないと思うぞ。本来だったらCIDRが
提唱された時点でBINDも何らかの対応を取るべきだったのではないか?

大体、CNAMEを介する方がメンドウなのは確かだしな。某プロバイダと逆引きの
設定でトラブった時、先方技術者に方法を教えることになってゲンナリしたよ。(w

107 :名無しさん@お腹いっぱい。 :01/11/14 09:30
>>105
Dents って今メンテナンスされてないんじゃなかったっけ?
MaraDNS って名前が(・∀・)イイ! 今度これ使ってみるよ!

108 :99 :01/11/14 09:37
>>106
そうかな? 束縛されてるのは BIND の実装じゃなくて DNS の設計だろ。
それを BIND の設定ファイルがどうとかいう矮小な問題として批判してるのが
変だという話だ。まあ、DJB だからしょうがないかって思うけどね。

本来の話をするんだったら CIDR が提唱されている時点で逆引きのメカニズムは
破綻している。BIND は延命策として ad hoc な解決法の一つを示しただけ。
それが RFC になったのは他にマトモな代案が出てこなかったからとちがうん?
何で BIND が非難されるん? 確かに BIND は DNS のデザインに責任があると
思うけど、DJB は非難の矛先を微妙に間違えていると思う。でもきっとわざとだ。藁

109 :釈、命 :01/11/14 09:41
自宅のLinux上でBINDの勉強をしています。

test.dom IN SOA test7.test.dom. root.test7.test.dom. (
1
3600
300
360000
86400
)

test.dom IN NS test7.test.dom.
test.dom IN NS test2.test.dom.

localhost IN A 127.0.0.1

test7 IN A 192.168.1.5
test2 IN A 192.168.1.1

上は、正引きゾーンマスタファイルです。この状態でnslookupを使用すると、test2のIPアドレスを出力することができます。

$ORIGIN test.dom

@ IN SOA test7.test.dom. root.test7.test.dom. (
1
3600
300
360000
86400
)

IN NS test7.test.dom.
IN NS test2.test.dom.

localhost IN A 127.0.0.1

test7 IN A 192.168.1.5
test2 IN A 192.168.1.1

上は、$ORIGINを使用して書き直したものです。この状態でnslookupを使用すると、test2のIPアドレスを出力することができません。どこか、文法が間違っているのでしょうか。

110 :名無しさん@お腹いっぱい。 :01/11/14 09:46
>>109
>> IN NS test7.test.dom.
>> IN NS test2.test.dom.
ここの行頭に空白か @ を入れる、かな?

111 :名無しさん@お腹いっぱい。 :01/11/14 13:44
ところで、
> test.dom IN SOA test7.test.dom. root.test7.test.dom. (
> 1
> 3600
> 300
> 360000
> 86400
> )
これや
> test.dom IN NS test7.test.dom.
> test.dom IN NS test2.test.dom.
これは、test.dom.$ORIGINを定義してるような気がするのは俺だけか?

112 :名無しさん@お腹いっぱい。 :01/11/14 14:53
http://pc.2ch.net/test/read.cgi/sec/1000359447/395
にも書いたんだけど、DION の dns server から変な
UDP port に大量の access が。

scandetd によると、
dns4.dion.ne.jp 210.172.64.112
I've counted 53 connections.
First connection was made to 3619 port at Tue Nov 13 15:05:43 2001
Last connection was made to 3619 port at Tue Nov 13 15:09:01 2001

I've counted 44 connections.
First connection was made to 3867 port at Tue Nov 13 17:17:23 2001
Last connection was made to 3867 port at Tue Nov 13 17:19:28 2001

I've counted 40 connections.
First connection was made to 4092 port at Tue Nov 13 17:58:06 2001
Last connection was made to 4094 port at Tue Nov 13 17:58:39 2001

I've counted 43 connections.
First connection was made to 2143 port at Wed Nov 14 14:33:54 2001
Last connection was made to 2149 port at Wed Nov 14 14:36:08 2001

dns1.dion.ne.jp 210.141.108.226
I've counted 46 connections.
First connection was made to 3619 port at Tue Nov 13 15:05:43 2001
Last connection was made to 3619 port at Tue Nov 13 15:09:01 2001
とのこと。


あ、named.conf で query-source address * port 53 しても、source
port が 53 に固定されるだけで、変な port には acccess してこないやん…。

113 :名無しさん@お腹いっぱい。 :01/11/14 15:40
>>112
それって BIND とか DNS と関係あるの?
dns*.dion.ne.jp からのアクセスだからといって DNS のアクセスとは限らんでしょ?

114 :名無しさん@お腹いっぱい。 :01/11/14 16:07
>>113
確かにそだね。

ただ、DION の DNS server からこんな request 来たこと
今までなかったし、DION の DNS server が crack
されたっていう話も聞かないし…。

どんな内容なのか log を取っておいていなかったのが
まずかったなぁ。

115 :名無しさん@お腹いっぱい。 :01/11/14 16:12
DNS queryがtimeoutした後で返事が返ってきてるってことはない?

116 :113 :01/11/14 16:14
>>114
でも port 53 にきたわけじゃないから log とっても DNS query かどうかも
わからないよね。いやそうでもないか。packet の中身調べたらわかるな。

じゃそういうことで頑張ってくれ。

117 :名無しさん@お腹いっぱい。 :01/11/14 16:22
>>115
う〜ん、port を変えて2分間に43connection
とか張らない思うよ。

>>116
そそ。scandetd だと packet の中身まで log を取る機能
はなかったと思うので、UDP 53 以外に dns*.dion.ne.jp
から来る packet を capture するように tcpdump を設定
しますか…。

118 :名無しさん@お腹いっぱい。 :01/11/14 18:37
CIDRの逆引きがみっともないってのは確かだが、破綻ってのは言い過ぎでは?
使い勝手からCNAMEの利用が広まったのはBINDの責任でしょ。

あとrfc2317は個人的に気にくわんので。(w
rfc2181は間違っちゃいないと思うが、それを言い訳にrfc1035を無視するのは
なんつーか。

119 :名無しさん@お腹いっぱい。 :01/11/14 18:38
ううむ。ヲレが管理していなかった mail server の log
を見たら、DION から SMTP の不正中継要求の嵐…。
ってことは、例の UDP request が IP address spoofing
か、実際に DION の DNS が crack されたかのどちらか
って可能性が高いなぁ。

http://www.dion.ne.jp/news/shougai.html を見ても
それらしいことは書いていないんだけど。

120 :名無しさん@お腹いっぱい。 :01/11/14 18:42
つーか逆引きってどうよ?

121 :名無しさん@お腹いっぱい。 :01/11/14 19:00
>>120

いらない。と個人的には思ってる。安直な考え?

122 :釈、命 :01/11/14 19:16
>>110
現状では、空白をいくつか入れてあります。また、「@」を入れる方法も試しましたが、ダメでした。test.domをいちいち書くのが面倒と言うことで$ORIGINを導入したかったのですが、うまくいかずこまったものです。

123 :名無しさん@お腹いっぱい。 :01/11/14 21:44
>>120
いらないでしょー。

124 :名無しさん@お腹いっぱい。 :01/11/14 22:35
うーむ。個人的には逆引き->正引きで元に戻らないIPアドレスにはお引き取り
願いたいなあ。

125 :名無しさん@お腹いっぱい。 :01/11/14 22:39
>>124
なんで?

126 :名無しさん@お腹いっぱい。 :01/11/14 22:52
>>125
なんとなく。あくまで気分なので「個人的には」ってことね。
逆にいらない理由も知りたいなあ。

127 :123 :01/11/14 22:57
>>126
必要性を感じないから、じゃだめ?

最近 BIND で walldns っぽい動きさせて遊んでる。
今のとこ問題なし。
>>124 みたいなのにも対応できる。

hoge.example.jp. IN A 192.168.12.34
34.12.168.192.in-addr.arpa. IN PTR 34.12.168.192.in-addr.arpa.
34.12.168.192.in-addr.arpa. IN A 34.12.168.192.in-addr.arpa.

本当は private address じゃないけど。

128 :名無しさん@お腹いっぱい。 :01/11/15 04:52
別に逆引き→正引きすることで特にセキュリティが
向上するわけでもないしねえ。
あ、DNS spoofing 防止効果が無いこともないか。

逆引きできないクライアントを本当に蹴る
ポリシでやってるとこを知ってるけどさ、
結局つなげなくなる場合を増やしているだけのような気がする。
連中に言わせると
「DNSの正引き逆引きが一致しないクライアントはマトモに
管理できてないところだ。そんなのは蹴ってよし。」
ということらしいが。
個人サイトならいいかもしれないけど、うちの大学のFTPサーバなんだよな…

129 :名無しさん@お腹いっぱい。 :01/11/15 06:12
host名で認証してるなら必要だけど、そうなると更に正引きして詐称の
チェックが必要だしなぁ。

本来なら自分の身元を明らかにする意味でマナーとして必要だったけど、
今じゃDHCPなサーバがいくらでも転がってるし、せいぜいプロバイダが
わかりやすくなる程度の恩恵しかないのかも。

130 :名無しさん@お腹いっぱい。 :01/11/15 07:03
>>129
プロバイダとドメイン名とは独立しているべきものだから、
whois を使えってことで終わっちゃわない?

131 :123 :01/11/15 07:41
逆引きを詐称されて困るのは、そんなもので認証するからだよな。
ハナから逆引きを信用しなければ問題なし。

>>128
「逆引きできない→マトモに管理できてない」は正しいか?
ポリシーで逆引き書かない、って可能性を想像できないのかな、その連中は。
「マトモに管理できてない→蹴ってよし」もどうかと。
「IE 4.0 以上をご使用ください」に似たにおいを感じる。

132 :99 :01/11/15 09:54
>>118
> 使い勝手からCNAMEの利用が広まったのはBINDの責任でしょ。
もちろんそうだね。これについて BIND の責任は決して軽くはないと思う。
ていうか、reference 実装としての BIND の責任はもっと重いと思っている。
だからこそ、CIDR が出た時に ad hoc な解決法ではなく、
真っ当な解決法を提案すべきだったと思うんだけどね。
DJB がやってるのは
「BIND よりもちょっとだけましな ad hoc な解決法を思いついたよ。偉いでしょ」
っていってるのに過ぎない。ad hoc だという点では同レベルだ。

ちなみに俺は site 単位での権限の委任ができてないという点で、
DJB の解決法は気に喰わない。概念を軽視して実装に偏りすぎだと思う。


次100 最新50 (10:00PM - 03:00AM の間一気に全部は読めません)

read.cgi ver5.26+ (01/10/21-)