親子の良好な関係を考える!

@Shtingrz 今井志有人

既存DNSの委譲に関する問題

上位は下位にゾーンを委譲できる

sub.example.com IN NS ns.sub.example.com

ns.sub.example.com IN A 192.0.2.1

→親は子についての情報を持つ

しかし子に確認しない

→Lame Delegationの原因

既存DNSの委譲に関する問題

委譲元であるかどうかは子のゾーンを見るだけでは確認することはできない

→子は親の状態を知らない

→権威DNSサーバ引越し時問題が発生することが

「引越し」時の問題点

引越し元は委譲されなくなった事実を知らない

→委譲されていないのにもかかわらず応答を返す

!

兼用サーバの場合古い情報を見させられる！

LDAPの仕様で見る解決策

LDAPとは

ディレクトリサービスを提供するプロトコル

有名な実装としてActive DirectoryやOpenLDAP

個人情報、認証情報を格納するのに便利な構造

RDBMSと違い「表」でなく「木」

LDAPのDNSエントリ

RFC1279

LDAPの前身であるX.500プロトコル上でのDNSレコードの取り扱いについて記述

bindもデータベースとしてLDAPを使用出来る(sbd+LDAP)

dn: dc=example,dc=com objectclass: top objectclass: dnsdomain objectclass: domainrelatedobject dc: example soarecord: ns.example.com admin@example.com 20130711 1800 3600 604800 84600 nsrecord: ns.example.com mxrecord: 10 mail.example.com associateddomain: example.com !dn: dc=mail,dc=example,dc=com objectClass: top objectClass: dnsDomain objectClass: dcObject dc: mail aRecord: 192.0.2.1 nsRecord: @

LDAPのDNSエントリ例

LDAPの{上位|下位}知識情報

上位知識情報(Superior Knowledge Information)

(実装)slap.confのreferralディレクティブに記述

下位知識情報(Subordinate Knowledge Information)

エントリにreferralオブジェクトクラスを記述

https://www.nic.ad.jp/ja/materials/iw/2003/proceedings/T18.pdf

root

com

example.com

example.com上位知識情報sub.example.com 委譲元情報

名前解決

referral

上位知識情報を見て委譲元を参照する実装を行う もし自分に委譲してなかったら自害するとか。

(ザナドゥ計画？)

LDAPの仕様で見る解決策

負荷分散

レプリケーション

DNS用途ではシングルマスタ方式か？

フェイルオーバー

Active/Standby方式

DNSはゾーン管理と応答がまぜまぜになっている感 →応答とゾーンの管理を別にわけて考えると従来の問題も解決できるかもしれないと思った。

応答も全てLDAPにすればセキュアになるとも感じた

全通信SSLはやっぱり遅い？

まとめ

参考文献

RFC1777(LDAPv2) RFC2551(LDAPv3)

RFC1279(DNS Record)

http://www.osstech.co.jp/_media/techinfo/seminar/lpic3ldap20090821.pdf

http://www.gentoo.org/doc/ja/ldapdns-guide.xml

https://www.nic.ad.jp/iw2005/t24.html

http://www.slideshare.net/OrangeMorishita/20111029-part1dnsdis

http://wiki.powerdns.com/trac/browser/trunk/pdns/modules/ldapbackend/dns.ldif