home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / ip / dns / doc.2.0 / RFC.XXXX < prev    next >
Encoding:
Text File  |  1990-08-22  |  20.2 KB  |  513 lines
  1. /*
  2. ** Distributed with 'doc' Version 2.0 from University of Southern
  3. ** California Information Sciences Institute (USC-ISI). 8/22/90
  4. */
  5.  
  6. Network Working Group                                 Steve Hotz
  7. Request for Comments: XXXX                            Paul Mockapetris
  8.                                                       XX/YY/ZZ
  9.  
  10.          PRELIMINARY DRAFT & NOTES: NOT YET RELEASED/REVIEWED
  11.  
  12.                        Automated Domain Testing
  13.  
  14.  
  15. 1. Status:
  16.  
  17. This RFC suggests ideas for the automated testing of DNS domains for
  18. correct configuration.  The purpose of this RFC is to elicit further
  19. discussion regarding system requirements and issues of design and
  20. implementation.
  21.  
  22. Distribution of this memo is unlimited.
  23.  
  24.  
  25. 2. Introduction:
  26.  
  27. The Domain Name System, currently used by a majority of the Internet's
  28. component networks, is a large and complex, autonomously administrated,
  29. distributed database which provides a network wide name service.  It's
  30. size, and the autonomously administered nature of the system, make it
  31. an ideal breeding ground for problems caused by misconfigured domains.
  32.  
  33. An automated tool for checking that domains are consistent with the
  34. procedures as specified in the official RFCs would prove useful in
  35. a couple ways.
  36.  
  37. It would be most useful as a means for domain administrators to verify
  38. (to a certain degree) that their domains are configured correctly.
  39. This would allow new domains to become operational fairly quickly,
  40. while ensuring that the domain is not causing far-reaching problems
  41. during the period when the administrator is still gaining hands-on
  42. experience.
  43.  
  44. The development of such a tool would also codify the interpretation
  45. of what is considered correct or incorrect, and serve as a yardstick
  46. against which strangely behaving domains may be measured.
  47.  
  48. Additionally, by examining misconfiguration trends of the Internet
  49. as a whole, one might identify areas in which the DNS, or various
  50. implementations, may need to evolve in future versions (i.e. perhaps
  51. administrators often configure their domains in a certain "incorrect"
  52. manner to gain some particular behavior or characteristic not
  53. achievable with standard "correct" configuration).
  54.  
  55.  
  56.  
  57. 3.1.  On what scope should a question be asked?
  58.  
  59. There are a few variants on the question that one would like such a
  60. tool to answer.  The simplest query would be whether or not a specific
  61. domain is correctly configured.  In light of the primary intended use
  62. this tool, this question is probably sufficient.
  63.  
  64. However, one might like to ask about the configuration of the entire
  65. domain tree.  A generalization of this would be to ask about a
  66. specified subtree (which could be a leaf domain).  However, pursuing
  67. this question requires walking the domain tree by searching through
  68. all zone information for zone delegations.  This would cause a
  69. considerable amount of network traffic, and you may be thwarted by
  70. servers unwilling to give up entire zone information.
  71.  
  72. Although the latter may more convenient when checking a group of
  73. domains, and possibly more efficient with respect to network and
  74. nameserver utilization (by not repeating queries to common parent
  75. domain servers), we will assume the former model throughout this RFC.
  76.  
  77.  
  78. 3.2.  What should be tested?  General Discussion.
  79.  
  80. The most interesting task in designing such a tool is determining what
  81. constitutes a misconfigured domain, which problems we should look for,
  82. and finally, which misconfigurations are possible/reasonable to detect
  83. with an automated procedure.
  84.  
  85. Because the point at which a zone delegation is made is prone to
  86. errors, and the "delegation" and "acceptance" of authority spans two
  87. distinct domains, a test of a single domain should probably look at
  88. information from multiple domains.
  89.  
  90. One could, in addition to looking at the particular domain in
  91. question, attempt to look at children (delegated) domains. However,
  92. this again raises the issue of determining which domains (if any) are
  93. below a given domain.  On the other hand, one can test the parent
  94. (delegating) domain to verify that it's configuration is consistent
  95. with respect to the domain under scrutiny.
  96.  
  97. We will assume the latter approach for now.  Again, whether one
  98. approach or the other is more useful, is a topic for discussion.
  99. I believe that a tool based on either model could be used to discover
  100. the same set of problems in any arbitrary subtree, by choosing the
  101. appropriate set of domains to examine.
  102.  
  103.  
  104. 3.4. What claims should be made?
  105.  
  106. Once we have decided on a set of conditions we wish to test, we need
  107. to specify what one should say about anomalies that are detected.
  108. Should there be an attempt to classify them in some manner?  If so, a
  109. classification might be similar to the following:
  110.  
  111.  
  112. ERRORS:   Something is definitely wrong, and should be fixed.
  113.           Example: Authoritative nameservers for a domain disagree
  114.           on information about the domain.
  115.  
  116. WARNINGS: Used for less serious problems or strong indicators of
  117.           problems not decidably testable.  Example: Parent domain
  118.           servers have differing SOA records.  A sign of a change
  119.           to domain information which hasn't propagated yet.
  120.           May explain some of the other errors.
  121.  
  122. NOTE:     One may be able to determine some potential problems by
  123.           looking at information returned as a matter of course in
  124.           investigating some separate problem.  If such potential
  125.           problems don't occur as often as the indicator, you may
  126.           choose to note it rather than incur additional overhead
  127.           investigating a likely dead-end.  Example: Glue records
  128.           were not returned with NS query to non-authoritative
  129.           server.  May not be an error since returning them in
  130.           "ADDITIONAL" section is optional.
  131.  
  132.  
  133. 3.5. Procedure Variants
  134.  
  135. When subsequent queries are based on the results of a query, there
  136. are often several possible ways to proceed.
  137.  
  138. Example:  Assume that we are querying the parent domain servers to
  139. determine a set of authoritative servers for the domain.  The response
  140. to these queries will be used to form a list of the appropriate
  141. servers to which another query will be posed.  In some instances,
  142. among the set of servers for the parent domain, some may claim to also
  143. be authoritative for the domain being tested.  Should you treat these
  144. replies differently than replies from parent servers that are not
  145. authoritative for the domain?  A few alternatives might be: (1) Ignore
  146. the non-authoritative replies, only if authoritative responses were
  147. received.  (2) Classify nameservers for the domain based on whether
  148. parent nameserver holding an NS record for them were authoritative or
  149. not, and further, look at results from nameservers of different
  150. classes differently.  (3) Most simply, you might consider any
  151. nameserver for the domain specified in an NS record from any parent
  152. domain server to be equivalent.
  153.  
  154. Similar issues will exist for other parts of the procedure.
  155.  
  156.  
  157. 3.6.  What should be tested?  Specific examples.
  158.  
  159. The following is a partial set of anomalies to consider for automated
  160. domain testing.
  161.  
  162.  
  163. 3.6.1.  Queries to parent domain servers about domain.
  164.  
  165. a. Server claims to be non-authoritative for parent domain.
  166.    An initial query will probably be made to discover the nameservers
  167.    for the parent domain.  If one of these nameservers is not
  168.    authoritative, it probably should not have been listed among the
  169.    NS referrals.
  170.  
  171. b. Server has no SOA record for parent domain.
  172.    As above (a), this server should not have been listed as a
  173.    nameserver.
  174.  
  175. c. Server returns multiple SOAs for parent domain.
  176.  
  177. d. SOA records from different servers have different serial numbers.
  178.    All servers should, except during short transition interval between
  179.    updates, have consistent data.
  180.  
  181. e. SOA records from different servers are different (same serial no).
  182.    Changes to important information is being changed, but version is
  183.    not being updated; possibly preventing distribution of changes.
  184.  
  185.  
  186.  
  187. 3.6.2.  Queries to parent domain servers about domain.
  188.  
  189. f. NS records from single server have different TTLs.
  190.    Server has information, possibly inconsistent, from incorrect
  191.    sources or out-of-date versions.
  192.  
  193. g. Glue records present (or not present).
  194.    Parent server should have addresses of authoritative servers;
  195.    particularly important if non-authoritative.
  196.  
  197. h. List of NS records for domain differ among servers.
  198.    Parent servers should have consistent delegation information
  199.    for the domain.
  200.  
  201. i. Server claims to also be authoritative for domain.
  202.    This is certainly not infrequent, however we might want to test
  203.    whether other authoritative domain servers concur.   Also, often
  204.    the NS records from domain servers and from parent domain servers
  205.    disagree, even if both authoritative.  May want to note whether
  206.    inconsistent NS lists are of this special case.
  207.  
  208.  
  209. 3.6.3.  Queries to domain servers about domain.
  210.  
  211. j. Server has no SOA record for domain.
  212.    Parent servers have incorrect data and are referring queries to
  213.    about the domain to an unsuspecting server.
  214.  
  215. k. Server claims to be non-authoritative.
  216.    As above (j), parent server believes server to be authoritative and
  217.    is referring others to this server.
  218.  
  219. l. Server returns multiple SOAs for domain.
  220.    See above (c).
  221.  
  222. m. SOA records from different servers have different serial numbers.
  223.    See above (d).
  224.  
  225. n. SOA records from different servers are different (but same serial).
  226.    See above (e).
  227.  
  228. o. NS records from single server have different TTLs.
  229.    See above (f).
  230.  
  231. p. List of NS records for domain differ among servers.
  232.    All authoritative servers for a domain should agree on information
  233.    about domain, particularly important delegation records.
  234.  
  235. q. NS list from parent servers does not match list from authoritative
  236.    servers.
  237.    Correctly operating domains will have identical NS records at all
  238.    domains servers and parents domain servers.
  239.  
  240. r. Server claims to be authoritative, however no NS record
  241.    from authoritative servers.
  242.    Strangely enough, this happens often when a server claims to be
  243.    authoritative, answers questions about the domain, but does not
  244.    have an NS record for itself.
  245.  
  246. s. Reverse mapping (in-addr.arpa.) for server address not found.
  247.    A frequent error in newly established domains.
  248.  
  249.  
  250. 4. Implementation:
  251.  
  252. An initial implementation attempt is available via anonymous
  253. ftp from venera.isi.edu, file: pub/doc.tar.Z
  254.  
  255. Doc requires the latest release of 'dig' (version 2.0) to perform
  256. nameserver queries;  dig is also available: pub/dig.2.0.tar.Z.
  257. This software is intended to run on Berkeley UNIX (and variants)
  258. machines.
  259.  
  260.  
  261. 4.1. Current procedure (Doc-V.1.0):
  262.  
  263.   A: Abort test -- can't continue.
  264.   E: Incorrect behavior is considered an error.
  265.   W: Incorrect behavior in this respect causes warning to be issued.
  266.   N: Note occurrence/information.
  267.   o: Side effects ... additional "computation".
  268.  
  269. Start test:
  270.  
  271. (1) Query default nameserver for NS records of parent domain.
  272.  
  273. (2) Query servers for parent domain for SOA record for parent domain.
  274.  
  275.     W: Check each response to see that it was authoritative.
  276.     W: Check each response to see that SOA records were returned.
  277.     W: Check that only one SOA was returned.
  278.  
  279.     W: Check that SOA serial numbers are same from all servers.
  280.        Only servers not issued warning above are tested here.
  281.  
  282.     A: No server returned an SOA record.
  283.  
  284.     o  Generate list of parent servers that are authoritative and
  285.        returned correct SOA information.  This is the list of servers
  286.        that are asked next query.
  287.   
  288.   At this point, might want to add check to compare entire SOA.
  289.   Such a check for parent SOAs probably not relative enough for
  290.   test of child domain.  Similar reasoning why above are warnings
  291.   and not errors.
  292.  
  293.  
  294. (3) Query all authoritative servers of parent zone for
  295.     NS records of domain being tested.
  296.  
  297.     N: Note the number of NS records and A records corresponding
  298.        to nameserver (glue) were returned in response.
  299.  
  300.     E: Check that TTLs of NS records are the same.
  301.  
  302.     o: Determine if response is happens to be authoritative for
  303.        testee domain.  Information is kept separate depending if
  304.        came from authoritative server.
  305.        This gets sort of messy, and may not be necessary (partially
  306.        leftover from earlier versions).  However, many domains have
  307.        different information at non-authoritative and authoritative.
  308.        This allows one to be a bit more specific in issuing errors
  309.        about what set of servers had inconsistent data.
  310.  
  311.     E: Check that NS records from different servers agree.
  312.         (Test is done separately for the AUTH and non-AUTH
  313.         server's lists.  If both are consistent, then check
  314.         if the two lists also agree.)
  315.  
  316.     o: Generate list of servers for testee domain.
  317.         Include any with corresponding NS record from any
  318.         parent server (regardless to authority of server).
  319.         Other lists are also maintained:
  320.           - servers known by authoritative parent servers
  321.           - servers known by non-authoritative parent servers
  322.           - servers only known by non-authoritative parent servers
  323.         Might also want to look at those only known by authoritative.
  324.  
  325.     W: Look at each parent server that also claimed authority for
  326.        domain -- check that an NS record is held for it (by any
  327.        of the servers).
  328.  
  329. (4) Query set of nameservers for testee domain for SOA records for
  330.     domain.  Currently, set is generated above and includes any
  331.     nameserver for which an NS record was returned in the above
  332.     series (3) of queries.  Different criteria for set inclusion
  333.     may also be interesting.
  334.  
  335.     E: Check each response to see that it was authoritative.
  336.     E: Check each response to see that SOA records were returned.
  337.     W: Check that only one SOA was returned.
  338.  
  339.     E: Check that SOA serial numbers are same from all servers.
  340.        Only servers not issued warning above are tested here.
  341.  
  342.     E: Check that entire SOA record matches among servers.
  343.        (Checked only if serial numbers agree).
  344.  
  345.     o: Generate list of nameservers that are authoritative
  346.        and have at least one SOA record.
  347.  
  348.  
  349. (5) Query set of testee domain nameservers for NS records of domain.
  350.     Currently, this set includes all nameservers which in previous
  351.     series of queries, returned authoritative response containing
  352.     exactly one SOA.
  353.  
  354.     E: Check that TTLs of NS records are the same.
  355.  
  356.     E: Check that NS records from servers are the same.
  357.  
  358.     E: Check that NS records from testee serves agree with
  359.        NS records from parent domain servers (make comparison with
  360.        any list consistent among some set of the parent servers --
  361.        i.e. remember that AUTH/non-AUTH mess !!)
  362.        This is only checked if child servers agree among themselves.
  363.      check for agreement between parent and child servers.
  364.  
  365.     E: Check that all servers that claim to be authoritative
  366.        have NS record at held by one of the AUTH servers.
  367.  
  368. Generate a list of addresses of nameservers for domain the domain.
  369. Choose addresses of servers that are in the domain in question
  370. (i.e. don't care about some other domain's server which is acting
  371. as a secondary).  Currently, we only look at one address on per any
  372. single network (i.e. only of 128.9.0.32 and 128.9.0.33 would be
  373. followed up).
  374.  
  375.  
  376. (6) Query for in-addr.arpa. PTR records for list of addresses
  377.     on networks of the domain.
  378.  
  379.     E:  Check that response is returned to reverse mapping query.
  380.  
  381.  
  382. 4.2. Example test runs:
  383.  
  384. Note: The domains have been changed to protect the miscreants.
  385.       Output has been changed to fit the RFC.
  386.  
  387.  
  388. 4.2.1.  Test for mystery domain #1:
  389.  
  390. Doc-1.0: Starting test of mystery.dom.   parent is edu.
  391. Doc-1.0: Test date - Fri Apr 27 14:57:05 PDT 1990
  392. soa @a.isi.edu. for edu. has serial: 900423
  393. DIGERR (TIME_OUT): dig @aos.brl.mil. for SOA of parent failed
  394. soa @c.nyser.net. for edu. has serial: 900423
  395. soa @gunter-adam.af.mil. for edu. has serial: 900423
  396. soa @ns.nasa.gov. for edu. has serial: 900423
  397. DIGERR (TIME_OUT): dig @ns.nic.ddn.mil. for SOA of parent failed
  398. soa @terp.umd.edu. for edu. has serial: 900426
  399. WARNING: Found 2 unique SOA serial #'s for edu.
  400. Found 3 NS and 3 glue records for mystery.dom. @a.isi.edu. 
  401. Found 3 NS and 3 glue records for mystery.dom. @c.nyser.net. 
  402. Found 3 NS and 3 glue records for mystery.dom. @gunter-adam.af.mil.
  403. Found 3 NS and 3 glue records for mystery.dom. @ns.nasa.gov.
  404. Found 3 NS and 3 glue records for mystery.dom. @terp.umd.edu.
  405. DNServers for edu.
  406.    === 0 were also authoritatve for mystery.dom.
  407.    === 5 were non-authoritative for mystery.dom.
  408. Servers for edu. (not also authoritative for mystery.dom.)
  409.    === agree on NS records for mystery.dom.
  410. NS list summary for mystery.dom. from parent (edu.) servers
  411.   == mystery.dom. cs.mystery.dom. pendragon.cs.purdue.edu.
  412. soa @mystery.dom. for mystery.dom. serial: 900425
  413. soa @cs.mystery.dom. for mystery.dom. serial: 900425
  414. soa @pendragon.cs.purdue.edu. for mystery.dom. serial: 900425
  415. SOA serial #'s agree for mystery.dom.
  416. Authoritative domain (mystery.dom.) servers agree on NS for mystery.dom.
  417. ERROR: NS list from mystery.dom. servers do not match parent
  418.   === (edu.) NS list
  419. NS list summary for mystery.dom. from authoritative servers
  420.   == telcom.mystery.dom.
  421. ERROR: mystery.dom. claims to be AUTH no NS record from AUTH servers
  422. ERROR: cs.mystery.dom. claims to be AUTH no NS record
  423. ===   from AUTH servers
  424. ERROR: pendragon.cs.purdue.edu. claims to be AUTH no NS record
  425. ===   from AUTH servers
  426. Checking 2 potential addresses for hosts at mystery.dom.
  427.   == 128.196.128.233 192.12.69.1
  428. in-addr PTR record found for 128.196.128.233
  429. in-addr PTR record found for 192.12.69.1
  430. Summary:
  431.    ERRORS found for mystery.dom. (count: 4)
  432.    WARNINGS issued for mystery.dom. (count: 1)
  433. Done test of mystery.dom.  Fri Apr 27 14:59:07 PDT 1990
  434.  
  435.  
  436. 4.2.2 Test for mystery domain #2:
  437.  
  438. Doc-1.0: Starting test of mystery.dom.   parent is edu.
  439. Doc-1.0: Test date - Fri Apr 27 16:14:02 PDT 1990
  440. soa @a.isi.edu. for edu. has serial: 900423
  441. soa @aos.brl.mil. for edu. has serial: 900426
  442. soa @c.nyser.net. for edu. has serial: 900423
  443. soa @gunter-adam.af.mil. for edu. has serial: 900423
  444. soa @ns.nasa.gov. for edu. has serial: 900423
  445. soa @ns.nic.ddn.mil. for edu. has serial: 900426
  446. soa @terp.umd.edu. for edu. has serial: 900426
  447. WARNING: Found 2 unique SOA serial #'s for edu.
  448. Found 3 NS and 3 glue records for mystery.dom. @a.isi.edu.
  449. Found 3 NS and 3 glue records for mystery.dom. @aos.brl.mil.
  450. Found 3 NS and 3 glue records for mystery.dom. @c.nyser.net.
  451. Found 3 NS and 3 glue records for mystery.dom. @gunter-adam.af.mil.
  452. Found 3 NS and 3 glue records for mystery.dom. @ns.nasa.gov.
  453. Found 3 NS and 3 glue records for mystery.dom. @ns.nic.ddn.mil.
  454. Found 3 NS and 3 glue records for mystery.dom. @terp.umd.edu.
  455. DNServers for edu.
  456.    === 0 were also authoritatve for mystery.dom.
  457.    === 7 were non-authoritative for mystery.dom.
  458. Servers for edu. (not also authoritative for mystery.dom.)
  459.    === agree on NS records for mystery.dom.
  460. NS list summary for mystery.dom. from parent (edu.) servers
  461.   == eos.cair.mystery.dom. nike.cair.mystery.dom. ns.utah.edu.
  462. DIGERR (TIME_OUT): dig @eos.cair.mystery.dom. for SOA of mystery.dom.
  463. soa @nike.cair.mystery.dom. for mystery.dom. serial: 60001
  464. soa @ns.utah.edu. for mystery.dom. serial: 60001
  465. SOA serial #'s agree for mystery.dom.
  466. Authoritative domain (mystery.dom.) servers agree on NS for mystery.dom.
  467. ERROR: NS list from mystery.dom. servers do not match parent
  468.   === (edu.) NS list
  469. NS list summary for mystery.dom. from authoritative servers
  470.   == nike.cair.mystery.dom. orion.cair.mystery.dom.
  471. ERROR: ns.utah.edu. claims to be AUTH no NS record from AUTH servers
  472. Checking 1 potential addresses for hosts at mystery.dom.
  473.   == 130.253.1.5
  474. ERROR: no in-addr PTR recorder found for 130.253.1.5
  475. Summary:
  476.    ERRORS found for mystery.dom. (count: 3)
  477.    WARNINGS issued for mystery.dom. (count: 1)
  478.    Incomplete test for mystery.dom. (1)
  479. Done test of mystery.dom.  Fri Apr 27 16:16:08 PDT 1990
  480.  
  481.  
  482. References/Readings:
  483.  
  484. [RFC-1034]      P. Mockapetris, "Domain Names - Concepts and
  485.                 Facilities", RFC-1034, USC/Information Sciences
  486.                 Institute, November 1987.
  487.  
  488. [RFC-1035]      P. Mockapetris, "Domain Names - Implementation and
  489.                 Specification", RFC-1035, USC/Information Sciences
  490.                 Institute, November 1987.
  491.  
  492.  
  493. Authors' Addresses:
  494.  
  495. Steve Hotz
  496. USC - Information Sciences Institute
  497. 4676 Admiralty Way
  498. Marina del Rey, Ca. 90293
  499.  
  500. Phone: (213) 822-1511
  501.  
  502. Email: hotz@isi.edu
  503.  
  504.  
  505. Paul Mockapetris
  506. USC - Information Sciences Institute
  507. 4676 Admiralty Way
  508. Marina del Rey, Ca. 90293
  509.  
  510. Phone: (213) 822-1511
  511.  
  512. Email: pvm@isi.edu
  513.