ゾーンの図
Sep 9-10, 2023 @下呂温泉 木曽屋
鈴木常彦 @E-ONTAP.COM
一日目
13:00 - 始業式
オリエンテーション
自己紹介
13:30 - 1 時間目
DNS 基礎講座 (テキスト: RFC1034, RFC1035)
DNS の学び方
名前空間, リソースレコードとは何か
DNS を構成するサーバたちの関係
ゾーンとは何か, 権威とは何か, グルーとは何か, 再帰とは何か
フォーマット, 5種類の DNS 返答 他
15:00 - 休み時間 (チェックイン)
15:20 2 時間目: DNS学習用DNS Full Revolverの実装について ... Kawakami_Kento さん
16:20 3 時間目: 仮想ネットワークシミュレータ VITOCHA の紹介 ... 鈴木 (tss)
17:00 休憩、温泉等
18:00 食事、休憩、温泉等
20:00 参加者発表, LT, フリーディスカッション (with drink)
・DNS フルリゾルバの開発について ... khibino さん
・レジストラとDNSプロバイダの世界 ... garnet_yn さん
・メールとOSINT ... xplntr さん
・Python 版 vitocha : vitothon ... FikaStudio さん
・DNS水責め絨毯爆撃と隠れオープンリゾルバ調査の裏側 ... 鈴木 (tss)
・その他自由に LT 等
23:00 随時就寝
二日目 8:00 朝食 (荷物は会場へ) 9:00 4 時間目: DNS セキュリティ - これまでの脆弱性の振り返り - 10:00 休憩 (チェックアウト) 10:20 5 時間目: インターネットシミュレータによる実習 (ネームサーバ移転実験など) 12:00 解散 (夕刻より名古屋にて有志で懇親会を予定)
RFC1912 Common DNS Operational and Configuration Errors もかな
|
|
+---------------------+------------------+
| | |
MIL EDU ARPA
| | |
| | |
+-----+-----+ | +------+-----+-----+
| | | | | | |
BRL NOSC DARPA | IN-ADDR SRI-NIC ACC
|
+--------+------------------+---------------+--------+
| | | | |
UCI MIT | UDEL YALE
| ISI
| |
+---+---+ |
| | |
LCS ACHILLES +--+-----+-----+--------+
| | | | | |
XX A C VAXA VENERA Mockapetris
RFC1033 ZONES A zone defines the contents of a contiguous section of the domain space, usually bounded by administrative boundaries. There will typically be a separate data file for each zone. The data contained in a zone file is composed of entries called Resource Records (RRs). You may only put data in your domain server that you are authoritative for. You must not add entries for domains other than your own (except for the special case of "glue records").
RFC2181 6. Zone Cuts The DNS tree is divided into "zones", which are collections of domains that are treated as a unit for certain management purposes. Zones are delimited by "zone cuts".
RFC1034 2.4. Elements of the DNS The DNS has three major components: - The DOMAIN NAME SPACE and RESOURCE RECORDS (snip) - NAME SERVERS are server programs which hold information about the domain tree's structure and set information. A name server may cache structure or set information about any part of the domain tree, but in general a particular name server has complete information about a subset of the domain space, and pointers to other name servers that can be used to lead to information from any part of the domain tree. Name servers know the parts of the domain tree for which they have complete information; a name server is said to be an AUTHORITY for these parts of the name space. Authoritative information is organized into units called ZONEs, and these zones can be automatically distributed to the name servers which provide redundant service for the data in a zone. - RESOLVERS (snip)
RFC2181 6.1. Zone authority The authoritative servers for a zone are enumerated in the NS records for the origin of the zone, which, along with a Start of Authority (SOA) record are the mandatory records in every zone.
RFC1034 4. NAME SERVERS 4.2. How the database is divided into zones The domain database is partitioned in two ways: by class, and by "cuts" made in the name space between nodes. The class partition is simple. ...(snip) Within a class, "cuts" in the name space can be made between any two adjacent nodes. After all cuts are made, each group of connected name space is a separate zone. The zone is said to be authoritative for all names in the connected region. (snip) These rules mean that every zone has at least one node, and hence domain name, for which it is authoritative, and all of the nodes in a particular zone are connected. Given, the tree structure, every zone has a highest node which is closer to the root than any other node in the zone. The name of this node is often used to identify the zone. It would be possible, though not particularly useful, to partition the name space so that each domain name was in a separate zone or so that all nodes were in a single zone. Instead, the database is partitioned at points where a particular organization wants to take over control of a subtree. Once an organization controls its own zone it can unilaterally change the data in the zone, grow new tree sections connected to the zone, delete existing nodes, or delegate new subzones under its zone.
RFC1034 4.2.1. Technical considerations The data that describes a zone has four major parts: - Authoritative data for all nodes within the zone. - Data that defines the top node of the zone (can be thought of as part of the authoritative data). - Data that describes delegated subzones, i.e., cuts around the bottom of the zone. - Data that allows access to name servers for subzones (sometimes called "glue" data).ゾーンの主たる4つの構成物
RFC1034 4.2.1. Technical considerations Though logically part of the authoritative data, the RRs that describe the top node of the zone are especially important to the zone's management. These RRs are of two types: name server RRs that list, one per RR, all of the servers for the zone, and a single SOA RR that describes zone management parameters. The RRs that describe cuts around the bottom of the zone are NS RRs that name the servers for the subzones. Since the cuts are between nodes, these RRs are NOT part of the authoritative data of the zone, and should be exactly the same as the corresponding RRs in the top node of the subzone. Since name servers are always associated with zone boundaries, NS RRs are only found at nodes which are the top node of some zone. In the data that makes up a zone, NS RRs are found at the top node of the zone (and are authoritative) and at cuts around the bottom of the zone (where they are not authoritative), but never in between.
RFC1034 4.2.1. Technical considerations One of the goals of the zone structure is that any zone have all the data required to set up communications with the name servers for any subzones. That is, parent zones have all the information needed to access servers for their children zones. The NS RRs that name the servers for subzones are often not enough for this task since they name the servers, but do not give their addresses. In particular, if the name of the name server is itself in the subzone, we could be faced with the situation where the NS RRs tell us that in order to learn a name server's address, we should contact the server using the address we wish to learn. To fix this problem, a zone contains "glue" RRs which are not part of the authoritative data, and are address RRs for the servers. These RRs are only necessary if the name server's name is "below" the cut, and are only used as part of a referral response.
RFC1034 2.3. Assumptions about usage - In any system that has a distributed database, a particular name server may be presented with a query that can only be answered by some other server. The two general approaches to dealing with this problem are "recursive", in which the first server pursues the query for the client at another server, and "iterative", in which the server refers the client to another server and lets the client pursue the query. Both approaches have advantages and disadvantages, but the iterative approach is preferred for the datagram style of access. The domain system requires implementation of the iterative approach, but allows the recursive approach as an option.
RFC1034 4.3.1. Queries and responses The way that the name server answers the query depends upon whether it is operating in recursive mode or not: - The simplest mode for the server is non-recursive, since it can answer queries using only local information: the response contains an error, the answer, or a referral to some other server "closer" to the answer. All name servers must implement non-recursive queries. - The simplest mode for the client is recursive, since in this mode the name server acts in the role of a resolver and returns either an error or the answer, but never referrals. This service is optional in a name server, and the name server may also choose to restrict the clients which can use recursive mode.
以上 RFC1034 より抜粋
(この RFC が書かれた時代にはキャッシュとコンテンツの分離がちゃんとなされていなかったことを考慮して理解する必要がある)
鈴木の解釈: recursive は iterative あるいはローカルな情報を持つサーバに辿り着くまで多段となりうるから recursive
RFC 1035 4. MESSAGES 4.1. Format +---------------------+ | Header | +---------------------+ | Question | the question for the name server +---------------------+ | Answer | RRs answering the question +---------------------+ | Authority | RRs pointing toward an authority +---------------------+ | Additional | RRs holding additional information +---------------------+
RFC 1035 4.1.1. Header section format 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ID | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ |QR| Opcode |AA|TC|RD|RA| Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ANCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: ID A 16 bit identifier assigned by the program QR query (0), or a response (1). OPCODE 0 Query, 1 IQuery (Inverse Query), 2 Status (3 available for assignment, 4 Notify [RFC 1996], 5 Update [RFC 2136], 6-15 available for assignment) AA Authoritative Answer TC TrunCation - specifies that this message was truncated due to length greater than that permitted on the transmission channel. RD Recursion Desired - this bit may be set in a query and is copied into the response. If RD is set, it directs the name server to pursue the query recursively. Recursive query support is optional. RA Recursion Available - this be is set or cleared in a response, and denotes whether recursive query support is available in the name server. Z Reserved for future use. Must be zero in all queries and responses.
RCODE Response code - this 4 bit field is set as part of
responses. The values have the following
interpretation:
0 No error condition
1 Format error - The name server was
unable to interpret the query.
2 Server failure - The name server was
unable to process this query due to a
problem with the name server.
3 Name Error - Meaningful only for
responses from an authoritative name
server, this code signifies that the
domain name referenced in the query does
not exist.
4 Not Implemented - The name server does
not support the requested kind of query.
5 Refused - The name server refuses to
perform the specified operation for
policy reasons. For example, a name
server may not wish to provide the
information to the particular requester,
or a name server may not wish to perform
a particular operation (e.g., zone
transfer) for particular data.
6-15 Reserved for future use.
RFC 8499 DNS Terminology / JPRS 訳より
NXDOMAIN: このRCODEは、"名前エラー [...] このコードは、問い合わせで参照されたドメイン名が存在しないことを意味する"という記述で[RFC1035]のセクション4.1.1の中に初出している。[RFC2308]は、Name Error(名前エラー)の同義語としてNXDOMAINを規定した。
NODATA: "指定されたクラスの名前としては正当だが、指定されたタイプのレコードが存在しないことを示す疑似RCODE。NODATA応答は、回答からの推論を必要とする"([RFC2308]のセクション1から引用)。"NODATAは、RCODEがNOERRORに設定されており、かつ回答部に関連する情報を何も持たないことで提示される。権威部はSOAレコードを含む。SOAレコードが無ければNSレコードは存在しない"([RFC2308]のセクション2.2から引用)。
RFC2308 1 - Terminology "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as described in [RFC1035 Section 4.1.1] and the two terms are used interchangeably in this document. "NODATA" - a pseudo RCODE which indicates that the name is valid, for the given class, but are no records of the given type. A NODATA response has to be inferred from the answer.
RFC 8499 DNS Terminology / JPRS 訳より
NXDOMAIN: このRCODEは、"名前エラー [...] このコードは、問い合わせで参照されたドメイン名が存在しないことを意味する"という記述で[RFC1035]のセクション4.1.1の中に初出している。[RFC2308]は、Name Error(名前エラー)の同義語としてNXDOMAINを規定した。
~% drill -o rd wwww.e-ontap.com @ns.e-ontap.com ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 49053 ;; flags: qr aa ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;; wwww.e-ontap.com. IN A ;; ANSWER SECTION: ;; AUTHORITY SECTION: e-ontap.com. 2560 IN SOA ns.e-ontap.com. hostmaster.e-ontap.com. 1607761683 16384 2048 1048576 2560 ;; ADDITIONAL SECTION:
RFC 8499 DNS Terminology / JPRS 訳より
NODATA: "指定されたクラスの名前としては正当だが、指定されたタイプのレコードが存在しないことを示す疑似RCODE。NODATA応答は、回答からの推論を必要とする"([RFC2308]のセクション1から引用)。"NODATAは、RCODEがNOERRORに設定されており、かつ回答部に関連する情報を何も持たないことで提示される。権威部はSOAレコードを含む。SOAレコードが無ければNSレコードは存在しない"([RFC2308]のセクション2.2から引用)。
~% drill -o rd aaaa www.e-ontap.com @ns.e-ontap.com ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 45117 ;; flags: qr aa ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;; www.e-ontap.com. IN AAAA ;; ANSWER SECTION: ;; AUTHORITY SECTION: e-ontap.com. 2560 IN SOA ns.e-ontap.com. hostmaster.e-ontap.com. 1607761683 16384 2048 1048576 2560 ;; ADDITIONAL SECTION:
RFC 8499 DNS Terminology / JPRS 訳より
NODATA: ... SOA レコードが権威部に存在すること、または NS レコードが権威部に存在しないこと等を手がかりに、NODATA 応答と参照応答を区別することは可能である。
> drill -o rd a www.e-ontap.com @a.gtld-servers.net ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 3504 ;; flags: qr ; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;; www.e-ontap.com. IN A ;; ANSWER SECTION: ;; AUTHORITY SECTION: e-ontap.com. 172800 IN NS ns.e-ontap.com. e-ontap.com. 172800 IN NS ns2.e-ontap.com. ;; ADDITIONAL SECTION: ns.e-ontap.com. 172800 IN A 14.192.44.1 ns2.e-ontap.com.172800 IN A 49.212.106.253
NXDOMAINに関する警告: NXDOMAIN は 照会ドメインにサブドメインが存在しないことを保証することは RFC 1034 と RFC 1035 から明らかである。
例えば、ns.heaven.af.milに対して NXDOMAIN があったら、 a.ns.heaven.af.mil と b.ns.heaven.af.mil とが存在しないと結論できる。 あるサーバがa.ns.heaven.af.mil と b.ns.heaven.af.mil に対するレコードを持ち、 ns.heaven.af.mil に対するレコードを持たないなら、 NXDOMAINではなく、zero-records (#5) 返答を送る。
『にもかかわらず』、RFC 2308 ではドメインが存在しているときでさえ、 照会名に対してはいかなるタイプのレコードも存在しないことを意味することに NXDOMAIN を返事することを認めた。 そこで、相互運用上の破滅を引き起こさぬために、 キャッシュとしては上の推論をしないようにすることが必須である。
下には全く何もない
Abstract This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist. This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them.
(JPRS訳) この文書は、DNSリゾルバーがドメイン名不在のレスポンスコードを持つ応答を受信した場合、ないと否定されたドメイン名とその下にあるすべての名前は存在しないということを明確に述べている。
解説: ドメイン名はラベルの木構造なのだから、あるノードが存在しない ("Name Error" or "NXDOMAIN") というなら、そのノードを根とする枝(サブツリー)全体が存在しないってこと。
Warning: if there is a chain of CNAME (or DNAME), the name that does not exist is the last of the chain ([RFC6604]) and not the QNAME. The NXDOMAIN stored in the cache is for the denied name, not always for the QNAME.
警告: CNAME (や DNAME) の連鎖がある場合、存在しないのは連鎖の最後の名前であって QNAME ではない。キャッシュに登録される NXDOMAIN は "denied name" であって、いつも QNAME というわけではない。
こいつは何だ?
~% drill -o rd a cname.small-is-beautiful.jp @ns.small-is-beautiful.jp ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 53591 ;; flags: qr aa ; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;; cname.small-is-beautiful.jp. IN A ;; ANSWER SECTION: cname.small-is-beautiful.jp. 60 IN CNAME www-elb-ext-1997305994.ap-northeast-1.elb.amazonaws.com. ;; AUTHORITY SECTION: amazonaws.com. 600 IN SOA ns.amazonaws.com. tss.e-ontap.com. 2019080501 3600 600 86400 600
権威サーバが否定回答を作成するとき TTL を指定しなければいけない。
Authority Section に SOA レコードをいれる。その TTL は SOA の minimum フィールドと SOA レコードの TTL の小さい方が選ばれる。キャッシュの TTL は減算されて 0 になったら回答に使用してはいけない。
SOA レコードのない否定応答はキャッシュされるべきではない。
キャッシュ時間には制限を設けるべきだ。1 - 3 時間をデフォルトとするのが賢明だ。1日を越えると問題が多いことがわかっている。
(Unbound のデフォルトは cache-max-negative-ttl: 3600)
VITOCHA については http://sim.internot.jp/vitocha/を参照してください。
演習環境は以下のように用意しましょう。
# jls
JID IP Address Hostname Path
(snip)
15 server_nom1 /jails/server_nom1
16 server_sld_nom1 /jails/server_sld_nom1
17 server_orz1 /jails/server_orz1
18 server_sld_orz1 /jails/server_sld_orz1
19 server_bind1 /jails/server_bind1
20 server_unbound1 /jails/server_unbound1
21 server_bind981 /jails/server_bind981
22 server_unbound_old /jails/server_unbound_old
23 server_bind922 /jails/server_bind922
サーバの構成は以下です。
vitocha(host) :192.168.100.1: root server_nom1 :172.18.1.1 : .nom .example server_sld_nom1 :172.18.1.2 : wine.nom a.example etc. server_orz1 :172.18.5.1 : .orz server_sld_orz1 :172.18.5.2 : nic.orz etc. server_bind1 :172.18.9.1 : BIND 9.10.4-P2 cache server server_unbound1 :172.18.9.2 : Unbound 1.10.1 cache server (DNSSEC) server_bind981 :172.18.9.3 : BIND 9.8.1-P1 cache server server_unbound_old:172.18.9.4 : Unbound 1.4.7 cache server server_bind922 :172.18.9.5 : BIND 9.2.2-P3 cache server
1. dnsq a www.scotch.nom a.root-servers.nom
dnsq a www.scotch.nom a.nic.nom
2. dnsq a www.wine.nom a.root-servers.nom
dnsq a www.wine.nom a.nic.nom
dnsq a www.wine.nom ns.wine.nom
問い: 違いは何か?
II. Glue 確認実験
Additional Section の違いを観察
1. dnsq a www.wine.nom a.nic.nom 2. dnsq a www.bourbon.nom a.nic.nom 3. dnsq a www.juice.nom a.nic.nom 4. dnsq a www.water.nom a.nic.nom
問い: 違いとその理由を考えよ
III. 共用サーバ実験
server_nom1
dnsq a www.awamori.nom a.nic.nom
dnsq a www.awamori.nom ns.awamori.nom
server_unbound1
dnsqr a www.awamori.nom
IV. 親子同居実験
dnsq a www.beer.nom a.root-servers.nom
dnsq a www.beer.nom a.nic.nom
(www.wine.nom とどう違うか)
V. 親子同居実験2 (上級編:毒入れ脆弱性の違い)
以下を比較
dnsq a 123.nic.nom a.nic.nom dnsq a 123.nic.orz a.nic.orz
問い: 何が違うのか?
RFC2181 5.2. TTLs of RRs in an RRSet Resource Records also have a time to live (TTL). It is possible for the RRs in an RRSet to have different TTLs. No uses for this have been found that cannot be better accomplished in other ways. This can, however, cause partial replies (not marked "truncated") from a caching server, where the TTLs for some but not all the RRs in the RRSet have expired. Consequently the use of differing TTLs in an RRSet is hereby deprecated, the TTLs of all RRs in an RRSet must be the same. Should a client receive a response containing RRs from an RRSet with differing TTLs, it should treat this as an error. If the RRSet concerned is from a non-authoritative source for this data, the client should simply ignore the RRSet, and if the values were required, seek to acquire them from an authoritative source. Clients that are configured to send all queries to one, or more, particular servers should treat those servers as authoritative for this purpose. Should an authoritative source send such a malformed RRSet, the client should treat the RRs for all purposes as if all TTLs in the RRSet had been set to the value of the lowest TTL in the RRSet. In no case may a server send an RRSet with TTLs not all equal.
RRset の RRs の TTL 値は一致していなくてはならない (MUST)
RFC2181 5.4. Receiving RRSets Servers must never merge RRs from a response with RRs in their cache to form an RRSet. If a response contains data that would form an RRSet with data in a server's cache the server must either ignore the RRs in the response, or discard the entire RRSet currently in the cache, as appropriate. Consequently the issue of TTLs varying between the cache and a response does not cause concern, one will be ignored. That is, one of the data sets is always incorrect if the data from an answer differs from the data in the cache. The challenge for the server is to determine which of the data sets is correct, if one is, and retain that, while ignoring the other. Note that if a server receives an answer containing an RRSet that is identical to that in its cache, with the possible exception of the TTL value, it may, optionally, update the TTL in its cache with the TTL of the received answer. It should do this if the received answer would be considered more authoritative (as discussed in the next section) than the previously cached answer.
RFC2181 5.4.1. Ranking data Trustworthiness shall be, in order from most to least: + Data from a primary zone file, other than glue data, + Data from a zone transfer, other than glue, + The authoritative data included in the answer section of an authoritative reply. + Data from the authority section of an authoritative answer, + Glue from a primary zone, or glue from a zone transfer, + Data from the answer section of a non-authoritative answer, and non-authoritative data from the answer section of authoritative answers, + Additional information from an authoritative answer, Data from the authority section of a non-authoritative answer, Additional information from non-authoritative answers.
RFC2181 5.4.1. Ranking data (snip) Unauthenticated RRs received and cached from the least trustworthy of those groupings, that is data from the additional data section, and data from the authority section of a non-authoritative answer, should not be cached in such a way that they would ever be returned as answers to a received query. They may be returned as additional information where appropriate. Ignoring this would allow the trustworthiness of relatively untrustworthy data to be increased without cause or excuse.
2008 年の BlackHat での Kaminsky の説明が間違っていた所以がここに...
root@vitocha:/jails/bin# jexec server_unbound_old root@server_unbound_old:/ # dnsqr a www.wine.nom 1 www.wine.nom: 113 bytes, 1+1+2+2 records, response, noerror query: 1 www.wine.nom answer: www.wine.nom 1 A 192.168.11.11 authority: wine.nom 239 NS ns.wine.nom authority: wine.nom 239 NS ns2.wine.nom additional: ns.wine.nom 239 A 192.168.11.11 additional: ns2.wine.nom 239 A 192.168.11.12 root@server_unbound_old:/ # dnsqr a www.wine.nom 1 www.wine.nom: 113 bytes, 1+1+2+2 records, response, noerror query: 1 www.wine.nom answer: www.wine.nom 30 A 192.168.11.11 authority: wine.nom 300 NS ns.wine.nom authority: wine.nom 300 NS ns2.wine.nom additional: ns.wine.nom 300 A 192.168.11.11 additional: ns2.wine.nom 300 A 192.168.11.12
1. 以下の初期状態を用意する
server_nom1: nom zonehoppy.nom. 86400 IN NS ns.hoppy.nom. ns.hoppy.nom. 86400 IN A 172.18.1.2server_sld_nom1: hoppy.nom zone
hoppy.nom. 3600 IN NS ns.hoppy.nom. ns.hoppy.nom. 3600 IN A 172.18.1.2 www.hoppy.nom. 30 IN A 172.18.1.2
2. 移転先を用意する
server_sld_orz1: hoppy.nom zonehoppy.nom. 3600 IN NS ns2.hoppy.nom. ns2.hoppy.nom. 3600 IN A 172.18.5.2 www.hoppy.nom. 60 IN A 172.18.5.2
3. 移転前のキャッシュサーバ
server_unbound1: Unbound 1.5.10;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2 ;; AUTHORITY SECTION: hoppy.nom. 3600 IN NS ns.hoppy.nom. ;; ADDITIONAL SECTION: ns.hoppy.nom. 3600 IN A 172.18.1.2server_bind1: BIND 9.10.4-P2
;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2 ;; AUTHORITY SECTION: hoppy.nom. 3600 IN NS ns.hoppy.nom. ;; ADDITIONAL SECTION: ns.hoppy.nom. 86400 IN A 172.18.1.2server_bind922: BIND 9.2.2-P3
;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2 ;; AUTHORITY SECTION: hoppy.nom. 3600 IN NS ns.hoppy.nom.
4. 委譲を切り替える
server_nom1: nom zonehoppy.nom. 86400 IN NS ns2.hoppy.nom. ;ns.hoppy.nom. 86400 IN A 172.18.1.2 ns2.hoppy.nom. 86400 IN A 172.18.5.2
5. 委譲切替後に www.hoppy.nom を問い合わせたキャッシュサーバの応答
server_unbound1: Unbound 1.5.10;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2 ;; AUTHORITY SECTION: hoppy.nom. 3515 IN NS ns.hoppy.nom. ;; ADDITIONAL SECTION: ns.hoppy.nom. 3515 IN A 172.18.1.2server_unbound_old: Unbound 1.4.7 (幽霊ドメイン名脆弱性あり)
;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2 ;; AUTHORITY SECTION: hoppy.nom. 3600 IN NS ns.hoppy.nom. ;; ADDITIONAL SECTION: ns.hoppy.nom. 3600 IN A 172.18.1.2server_bind1: BIND 9.10.4-P2
;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2 ;; AUTHORITY SECTION: hoppy.nom. 3515 IN NS ns.hoppy.nom. ;; ADDITIONAL SECTION: ns.hoppy.nom. 86315 IN A 172.18.1.2server_bind922: BIND 9.2.2-P3 (幽霊ドメイン名脆弱性あり)
;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2 ;; AUTHORITY SECTION: hoppy.nom. 3600 IN NS ns.hoppy.nom.問い: それぞれの応答の意味を考えよう
1. 新 NS のゾーンを用意するとともに、旧 NS のゾーンデータも書き換える
server_sld_nom1: 旧 hoppy.nom zonehoppy.nom. 3600 IN NS ns2.hoppy.nom. ns2.hoppy.nom. 3600 IN A 172.18.5.2 www.hoppy.nom. 30 IN A 172.18.1.2注: 説明の都合上 www はそのままにしてありますが、これも必要 (タイミング) に応じて新しい方に向けると良いでしょう。
2. 委譲を切り替える
server_nom1: nom zonehoppy.nom. 86400 IN NS ns2.hoppy.nom. ;ns.hoppy.nom. 86400 IN A 172.18.1.2 ns2.hoppy.nom. 86400 IN A 172.18.5.2
3. 委譲切替後に www.hoppy.nom を問い合わせたキャッシュサーバの応答
server_unbound1: Unbound 1.5.10;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2 ;; AUTHORITY SECTION: hoppy.nom. 3600 IN NS ns2.hoppy.nom. ;; ADDITIONAL SECTION: ns2.hoppy.nom. 3600 IN A 172.18.5.2server_unbound_old: Unbound 1.4.7
;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2 ;; AUTHORITY SECTION: hoppy.nom. 3600 IN NS ns2.hoppy.nom. ;; ADDITIONAL SECTION: ns2.hoppy.nom. 3600 IN A 172.18.5.2server_bind1: BIND 9.10.4-P2
;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2 ;; AUTHORITY SECTION: hoppy.nom. 3526 IN NS ns2.hoppy.nom. ;; ADDITIONAL SECTION: ns2.hoppy.nom. 3600 IN A 172.18.5.2server_bind922: BIND 9.2.2-P3
;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2 ;; AUTHORITY SECTION: hoppy.nom. 3600 IN NS ns2.hoppy.nom. ;; ADDITIONAL SECTION: ns2.hoppy.nom. 3600 IN A 172.18.5.2問い: それぞれの応答の意味を考えよう
1. 新 NS のゾーンを用意して、委譲の変更をした後、旧 NS のゾーンを消す
server_sld_orz1: 新 hoppy.nom zonehoppy.nom. 3600 IN NS ns2.hoppy.nom. ns2.hoppy.nom. 3600 IN A 172.18.5.2 www.hoppy.nom. 30 IN A 172.18.5.2server_nom1: nom zone
hoppy.nom. 86400 IN NS ns2.hoppy.nom. ns2.hoppy.nom. 86400 IN A 172.18.5.2server_sld_nom1: 旧 nom zone (nsd.conf)
#zone: # name: "hoppy.nom" # zonefile: "hoppy.nom.zone"
3. 旧ゾーン削除後に www.hoppy.nom を問い合わせたキャッシュサーバの応答
server_unbound1 : Unbound 1.5.10;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 60 IN A 172.18.5.2 ;; AUTHORITY SECTION: hoppy.nom. 3600 IN NS ns2.hoppy.nom. ;; ADDITIONAL SECTION: ns2.hoppy.nom. 3600 IN A 172.18.5.2server_bind1: BIND 9.10.4-P2 1回目
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 40538server_bind1: BIND 9.10.4-P2 2回目
;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 60 IN A 172.18.5.2 ;; AUTHORITY SECTION: hoppy.nom. 3600 IN NS ns2.hoppy.nom. ;; ADDITIONAL SECTION: ns2.hoppy.nom. 86389 IN A 172.18.5.2server_bind922: BIND 9.2.2-P3 1回目
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9388server_bind922: BIND 9.2.2-P3 2回目
;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 60 IN A 172.18.5.2 ;; AUTHORITY SECTION: hoppy.nom. 3600 IN NS ns2.hoppy.nom.問い: それぞれの応答の意味を考えよう
キャッシュサーバ初期状態
server_unbound1 : Unbound 1.5.10;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2server_bind1: BIND 9.10.4-P2
;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2 ;; AUTHORITY SECTION: hoppy.nom. 86400 IN NS ns.hoppy.nom. ;; ADDITIONAL SECTION: ns.hoppy.nom. 86400 IN A 172.18.1.2
問い: NS + A はどこから得た応答をキャッシュしているでしょう
委譲元 (server_nom1), 権威サーバ(server_sld_nom1) ともに
hoppy.nom. IN NS ns2.hoppy.nom. に切り替えたのちキャッシュサーバに問い合わせてみる (数分後)
;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2server_bind1: BIND 9.10.4-P2
;; ANSWER SECTION: www.hoppy.nom. 30 IN A 172.18.1.2 ;; AUTHORITY SECTION: hoppy.nom. 86291 IN NS ns.hoppy.nom. ;; ADDITIONAL SECTION: ns.hoppy.nom. 86291 IN A 172.18.1.2問い: これはどういう状況でしょう
hoppy.nom. の NS がたまたま問い合わせれれば、、、
server_unbound1 : Unbound 1.5.10;; QUESTION SECTION: ;hoppy.nom.INNS ;; ANSWER SECTION: hoppy.nom. 3600 IN NS ns2.hoppy.nom. ;; ADDITIONAL SECTION: ns2.hoppy.nom. 3600 IN A 172.18.5.2server_bind1: BIND 9.10.4-P2
;; QUESTION SECTION: ;hoppy.nom. IN NS ;; ANSWER SECTION: hoppy.nom. 3600 IN NS ns2.hoppy.nom. ;; ADDITIONAL SECTION: ns2.hoppy.nom. 3600 IN A 172.18.5.2問い: これは何が起きているのか?
その後、再度キャッシュサーバに問い合わせてみると
server_unbound1 : Unbound 1.5.10;; QUESTION SECTION: ;www.hoppy.nom. IN A ;; ANSWER SECTION: www.hoppy.nom. 60 IN A 172.18.5.2server_bind1: BIND 9.10.4-P2
;; ANSWER SECTION: www.hoppy.nom. 60 IN A 172.18.5.2 ;; AUTHORITY SECTION: hoppy.nom. 3586 IN NS ns2.hoppy.nom. ;; ADDITIONAL SECTION: ns2.hoppy.nom. 3586 IN A 172.18.1.2問い: それぞれの応答の意味を考えよう
その他、DNS温泉番外編 (2016) の資料も参照のこと
時間が残っていれば DNSSEC を学びたい人のために用意した RFC 5155 Appendix A. Example Zone の模擬環境を使ってざっと説明したいと思います。資料はありません。
教養として知っておく程度でいいかと思います。詳しく勉強する必要はないでしょう。(DNSSEC はなぜダメなのか)
