IP addressとinterface nameはそんなに簡単に結び付かないのでは? 自宅では(*BSDばっかりなので)gifに見かけ上world-reachableなaddressを与えていますが、overheadを避けるためにospfでgif側のcostを上げる工夫をしています(したがってgifに流れているのはospfだけ)。このため、どのinterfaceからどんなdestinationを持ったpacketが来るかわかりません(これはあくまで最適なroutingに応じて決めるべきであり、applicationが勝手な仮定をおくべきではない)。
djbdnsに (スコア:1)
また,DNSの仕組みをきちんと理解できるいいソフトだと思う。
ただ,DJBシンパはどうかと思うが…
# 私は――qmailも使ってるけど――シンパではありません。
Re:djbdnsに (スコア:1)
自宅でdjbdnsを考えてましたが、viewの概念がないためにあきらめました。viewがないとprivate addressをrecordに入れ、かつzoneを外へtransferする(世界中からreachableなもののみ)ことがまずできません。
世界中からreachableなものをいきなり外のzoneに書くことも考えましたが、結局は自宅からいじることが多い(まだ動かしていないが、updateを使い出すともうそれしかできない)ので見送りました。
Re:djbdnsに (スコア:1)
そういう時,djbdns 的には IP Alias するなどして,tinydns を外向けと内向けに2個立てます。
実際にうち(ADSL)で採っている方法は:
dnscacheはlocalhostで立てることが推奨されていますが,Windowsから参照したかったのでLAN向けに立っています。
また,セカンダリは cron + afxr-get + shell script で。
Re:djbdnsに (スコア:1)
IP addressとinterface nameはそんなに簡単に結び付かないのでは? 自宅では(*BSDばっかりなので)gifに見かけ上world-reachableなaddressを与えていますが、overheadを避けるためにospfでgif側のcostを上げる工夫をしています(したがってgifに流れているのはospfだけ)。このため、どのinterfaceからどんなdestinationを持ったpacketが来るかわかりません(これはあくまで最適なroutingに応じて決めるべきであり、applicationが勝手な仮定をおくべきではない)。
そうなると、結局はsource addressで確認がとれないと使いものにならないわけです。
Re:djbdnsに (スコア:1)
うーん?
というか eth0(LAN) と ppp0(ADSL=eth1) で分けているだけなので,問題ないと思うのですが?(当然NICは2枚)
というか,61.~ を持つ ppp0 に,destination が 192.~ なパケットが来ることはないですし,192.~ を使う LAN マシンが 61.~ に宛ててもそこは IP masquerade が良きに計らってくれますし。
だからbindするアドレスだけで見分けられませんかね?
それともまだ何か勘違いとかしてますでしょうか。
Re:djbdnsに (スコア:1)
そうか、tietewさんの場合はdjbdnsを走らせている計算機を迂回してeth0側のlinkとeth1側のlinkを結ぶ経路が全く存在しないからそれでいけるわけですね。
私の場合は、bindを走らせている計算機が複数のinterfaceを持っているだけでなく、そのどれを通っても自宅、ないしは世界中からたどり着くことができます。この場合、通るべきinterfaceはsourceやdestinationには依りません。Routing tableに反映されたpolicyによってのみ決まります。
Routing policyはEthernet優先なので、前述の通りgif側のospf costを高くしています。このため、bindが走っている計算機へのtraffic(ospf以外)は(sourceやdestinationはお構いなしに)すべてEthernetを通ります。かくして、interfaceにsocketを張り付けるだけでは不十分なわけです。
Re:djbdnsに (スコア:1)
まだ見てる事を願いつつ。
クエリを投げてきたクライアントアドレスによって 応答を変えることは出来ます。
例えば
%in:192.168
%ex
+jupiter.heaven.af.mil:192.168.1.2:::in
+jupiter.heaven.af.mil:1.2.3.4:::ex
こんな感じで書いておくと、192.168.0.0/16 から検索があった 時だけ、プライベート IP を返すことが出来ます。
詳しくは tinydns-dataの説明 [qmail.org]のデータ形式のところを見てみてください。Tatsuki Sugiura
Re:djbdnsに (スコア:1)
record単位では応答を変えられるのはわかりましたが、実は外のname serverへzoneをtrasferしている手前、zone単位で応答を変えられる方が(私の問題の場合は)すっきりするんですよね。特にNSやMXなどはzone単位でまとめてみることができないとinconsistentなzone(あるviewについてMXの右辺に対応するA/AAAA/A6が存在しないなど)を作ってしまう恐れすらあります。
そうなると、record単位で応答を変えなければならないのはかえって設定ミスの原因になりそうで。
Re:djbdnsに (スコア:1)
ごめんなさい。情報少なすぎたか。
record 単位ではなくて、tinydns のデータファイルの 行単位になります。NS や MX の定義は一緒に A も生成 する事が出来、そういう風に使っていればミスは減ります。
bind 風のデータファイルだと確かにミスを起こしそうですが、 この書き方は tinydns の書式にはマッチしています。
# 個人的にはこの A と PTR を一行で定義できることと、
# 自動シリアルは非常に役に立っています。
# 絶対に(自分も含めて)誰かが PTR 定義し忘れるとか、シリアル
# あげ忘れるとかをしてしまうので。
あとは、bind の様に zone 単位でファイルを作るわけではなく、 (最終的にcatでくっつければよいだけだから)好きなように分割出来るので、その分け方でもミスは減らせると思います。
Tatsuki Sugiura