ゾーンの図
Aug 22-23, 2025 @琵琶湖グランドホテル
鈴木常彦 @E-ONTAP.COM
一日目
12:30 送迎バス（おごと温泉駅)
13:30 始業式 (会議室は東館 1F 「志賀」)
オリエンテーション
自己紹介
14:00 1 時間目 DNS 基礎講座 (with dig の使い方) ... tss
15:50 休み時間
16:10 2 時間目 「DNS浸透と言ってはいけない理由」 ... debiru_R
17:00 休憩、温泉等 (部屋は西館2F の 201,202,203,231,232)
風呂: 男性 京近江1F 伊吹の湯、女性 京近江2F 三上の湯
庭園風呂: 男性 東館1F しゃくなげの湯、女性 西館1F 比叡の湯 ... 16:30-17:50 学生団体貸切
18:00 食事、休憩、温泉等
19:30 3 時間目 「浸透しなさい RFC 5322&7208」 ... 野々垣
20:10 休憩
20:20 4 時間目 「DNS をパケットキャプチャで調査」 ... 大塚
21:00 LT, フリーディスカッション (with drink)
・未定 ... kakira
・go.jp を保護した話 ... tss
・オープンリゾルバのログ ... tss
・反復クエリ数の上限について ... tss
23:00 随時就寝
二日目
8:00 朝食 (バイキング形式 6:30～9:00, 荷物は「滋賀」へ)
9:00 5 時間目: 仮想ネットワーク構築ライブラリ VITOCHA の紹介 ... tss
10:00 休憩 (チェックアウト)
10:20 6 時間目: インターネットシミュレータによる実習
(DNSSEC の機能と問題点を体験) ... tss
12:00 解散 〜 送迎バス
|
|
+---------------------+------------------+
| | |
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.
% dnsq ns _acme-challenge.office.ipsj-tokai.jp ns1.gslb9.sakura.ne.jp 2 _acme-challenge.office.ipsj-tokai.jp: 99 bytes, 1+0+1+1 records, response, noerror query: 2 _acme-challenge.office.ipsj-tokai.jp authority: _acme-challenge.office.ipsj-tokai.jp 600 NS acme-challenge.office.ipsj-tokai.jp additional: acme-challenge.office.ipsj-tokai.jp 600 A 49.212.139.40
Delegation |Parent|Name Server Name | Type -----------+------+------------------+----------------------------- com | . |a.gtld-servers.net|in-bailiwick / sibling domain net | . |a.gtld-servers.net|in-bailiwick / in-domain example.org| org |ns.example.org |in-bailiwick / in-domain example.org| org |ns.ietf.org |in-bailiwick / sibling domain example.org| org |ns.example.com |out-of-bailiwick example.jp | jp |ns.example.jp |in-bailiwick / in-domain example.jp | jp |ns.example.ne.jp |in-bailiwick / sibling domain example.jp | jp |ns.example.com |out-of-bailiwick
in-bailiwick ではあるが in-domain ではないし glue でもない
(spam18.net の古い glue の残骸 / com, net はゴミ掃除がされない / jp ではこのようなゴミは出ない)
% dnsq ns tkix.net a.gtld-servers.net 2 tkix.net: 137 bytes, 1+0+3+3 records, response, noerror query: 2 tkix.net authority: tkix.net 172800 NS ns.tkix.net authority: tkix.net 172800 NS fake.spam18.net authority: tkix.net 172800 NS fake2.spam18.net additional: ns.tkix.net 172800 A 150.42.6.4 additional: fake.spam18.net 172800 A 14.192.44.1 additional: fake2.spam18.net 172800 A 14.192.44.1
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
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: a.root-servers.nom (NSD 4.12) vitocha(host) :192.168.100.2: 192.168.100.1 を root とするリゾルバ (Unbound 1.23) 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.18.29 (ESV) cache server server_unbound1 :172.18.9.2 : Unbound 1.21.0 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
