DNS温泉2015 (DNS温泉2)

Sep 12-13, 2015 @伊豆山研修センター




13:00 始業式

13:40 1時間目 哲学

    DNS の基礎を疑い再考する
        (テキスト: RFC1034, RFC1035)

15:10 休み時間

15:20 2時間目 図工

    DNS を触ってみる
        TLD を作る
        (教材: ノートパソコン, VirtualBox, VITOCHA)

16:50 放課 (お風呂など)

18:00 夕食

19:30 3時間目 学級会

    LT大会 & 懇親会
        「nslookup しか知らなかった人がDNS温泉に参加するまで」
        「毎日 dig ったら分かったこと 〜某 registry 編〜」

22:00 就寝


7:00 朝食

8:30 1時間目 理科

        (テキスト: RFC2181 / 教材: ノートパソコン, VirtualBox, VITOCHA)

10:00 休み時間

10:30 2時間目 社会

    DNS の脆弱性を知る

12:00 解散

1時間目 哲学

DNS の基礎を疑い再考する




   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").
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".  


2.4. Elements of the DNS

The DNS has three major components:


  - 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)
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.


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.


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.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.


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.



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.

再帰 (続き)

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.

鈴木の解釈: recursive は iterative あるいはローカルな情報を持つサーバに辿り着くまで多段となりうるから recursive

4.3.2. Algorithm 
      5. Using the local resolver or a copy of its algorithm (see
      resolver section of this memo) to answer the query.
(resolver については5章参照)


RFC 1035


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                    |


ID              A 16 bit identifier assigned by the program  (snip)
QR              (snip) query (0), or a response (1).
OPCODE          (snip)   0   a standard query (QUERY)
AA              Authoritative Answer (snip)
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

                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.

5種類の DNS 返答

Notes on the Domain Name System (D.J.Bernstein) - The five types of DNS responses (前野訳)

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.

NXDOMAIN responses can be categorised into four types ...

3時間目 理科



5.3.2. Resources 
SNAME           the domain name we are searching for.

STYPE           the QTYPE of the search request.

SCLASS          the QCLASS of the search request.

SLIST           a structure which describes the name servers and the
                zone which the resolver is currently trying to query.
                   (snip)                                         The
                zone name equivalent is a match count of the number of
                labels from the root down which SNAME has in common with
                the zone being queried; this is used as a measure of how
                "close" the resolver is to SNAME.

SBELT           a "safety belt" structure of the same form as SLIST,
                which is initialized from a configuration file, (snip)

CACHE           A structure which stores the results from previous
                responses.  Since resolvers are responsible for
                discarding old RRs whose TTL has expired, most
                implementations convert the interval specified in
                arriving RRs to some sort of absolute time when the RR
                is stored in the cache.  Instead of counting the TTLs
                down individually, the resolver just ignores or discards
                old RRs when it runs across them in the course of a
                search, or discards them during periodic sweeps to
                reclaim the memory consumed by old RRs.


5.3.3. Algorithm

The top level algorithm has four steps:

   1. See if the answer is in local information, and if so return
      it to the client.

   2. Find the best servers to ask.

   3. Send them queries until one returns a response.

   4. Analyze the response, either:

         a. if the response answers the question or contains a name
            error, cache the data as well as returning it back to
            the client.

         b. if the response contains a better delegation to other
            servers, cache the delegation information, and go to
            step 2.

         c. if the response shows a CNAME and that is not the
            answer itself, cache the CNAME, change the SNAME to the
            canonical name in the CNAME RR and go to step 1.

         d. if the response shows a servers failure or other
            bizarre contents, delete the server from the SLIST and
            go back to step 3.


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)

受信した RRSet の取り扱い

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.


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
     + Additional information from an authoritative answer,
       Data from the authority section of a non-authoritative answer,
       Additional information from non-authoritative answers.


5.4.1. Ranking data
   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:/home/guest # jexec 9 tcsh
root@server_unbound147:/ # 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
authority: wine.nom 239 NS ns.wine.nom
authority: wine.nom 239 NS ns2.wine.nom
additional: ns.wine.nom 239 A
additional: ns2.wine.nom 239 A
root@server_unbound147:/ # 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
authority: wine.nom 300 NS ns.wine.nom
authority: wine.nom 300 NS ns2.wine.nom
additional: ns.wine.nom 300 A
additional: ns2.wine.nom 300 A


VITOCHA については http://sim.internot.jp/vitocha/を参照してください。


  1. パソコンに VirtualBox をインストール
  2. http://sim.internot.jp/vitocha/DNSSPA2_20150908.ovaをダウンロード
    (9/12 追記:http://sim.internot.jp/vitocha/DNSSPA2_20150911.ovaなら後述の tar の展開の必要なし)
  3. 「仮想アプライアンスのインポート」でダウンロードした OVA ファイルをインポート
  4. DNSSPA2 を選択し「設定」-「システム」でメモリやプロセッサ数を自分の環境に合わせて調整。ネットワークインターフェイスの調整も必要かも。ホストオンリーアダプタを足すと便利。
    (「ポート」-「USB」で USBインターフェイスを無効にしたほうが良い場合もあり)
  5. DNSSPA2 をダブルクリックで起動
  6. guest でログイン (パスワードも guest)
  7. パスワードなしで root に su
  8. /jails/bin/dnsspa2.rb で演習環境起動
  9. jls で jail (それぞれが仮想サーバ) を確認
    # jls
       JID  IP Address      Hostname                      Path
         1  -               bridge0                       /jails/bridge0
         2  -               server_nom1                   /jails/server_nom1
         3  -               server_orz1                   /jails/server_orz1
         4  -               server_sld_nom1               /jails/server_sld_nom1
         5  -               server_sld_orz1               /jails/server_sld_orz1
         6  -               server_bind1                  /jails/server_bind1
         7  -               server_unbound1               /jails/server_unbound1
         8  -               server_bind981                /jails/server_bind981
         9  -               server_unbound147             /jails/server_unbound147
  10. 追加の設定ファイルをダウンロードし展開
    # cd / 
    # fetch http://sim.internot.jp/vitocha/etc_nsd_2015090902.tar.gz
    # tar xfz etc_nsd_2015090902.tar.gz


vitocha(host)  : root 
server_nom1    : : .nom 
server_nom2    : : .orz 
server_sld_nom1: wine.nom etc. 
server_sld_orz1: nic.orz etc. 
server_bind1   : bind99 cache server
server_unbound1: unbound cache server
server_bind981 : bind9.8.1-P1
server_unbound147 : unbound1.4.7

/jails/bin/web.rb & とするとホスト側から http://:3333/ でネットワーク図を見ることができます。(dnsspa2.rb が自動生成した図です)



I. zone cut / 委譲 確認実験

 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. 浸透遅い実験


   dnsqr a www.wine.nom

 (www.wine.nom の TTL を短くしたほうが良いかも)

(改訂: この実験は BIND 9.2.2 以前で行う必要あり)

IV. 幽霊実験

 1. server_bind981 
     dnsqr a www.wine.nom

 2. server_sld_nom1
     sed 's/ns2/ns3/' /etc/namedb/wine.nom.zone 
     sed 's/20150910../2015091201/' /etc/namedb/wine.nom.zone 
     nsd-control reload

 3. server_bind981 
     dnsqr a www.wine.nom

V. 親子同居実験

    dnsq a www.beer.nom a.root-servers.nom
    dnsq a www.beer.nom a.nic.nom

VI. 共用サーバ実験

    dnsq a www.awamori.nom a.nic.nom
    dnsq a www.awamori.nom ns.awamori.nom

    dnsqr a www.awamori.nom

VII. 毒入れ脆弱性実験 (親子同居実験2)

   dnsq a 123.nic.nom a.nic.nom
   dnsq a 123.nic.orz a.nic.orz