1/* 2** Distributed with 'doc' Version 2.0 from University of Southern 3** California Information Sciences Institute (USC-ISI). 8/22/90 4*/ 5 6Network Working Group Steve Hotz 7Request 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 151. Status: 16 17This RFC suggests ideas for the automated testing of DNS domains for 18correct configuration. The purpose of this RFC is to elicit further 19discussion regarding system requirements and issues of design and 20implementation. 21 22Distribution of this memo is unlimited. 23 24 252. Introduction: 26 27The Domain Name System, currently used by a majority of the Internet's 28component networks, is a large and complex, autonomously administrated, 29distributed database which provides a network wide name service. It's 30size, and the autonomously administered nature of the system, make it 31an ideal breeding ground for problems caused by misconfigured domains. 32 33An automated tool for checking that domains are consistent with the 34procedures as specified in the official RFCs would prove useful in 35a couple ways. 36 37It would be most useful as a means for domain administrators to verify 38(to a certain degree) that their domains are configured correctly. 39This would allow new domains to become operational fairly quickly, 40while ensuring that the domain is not causing far-reaching problems 41during the period when the administrator is still gaining hands-on 42experience. 43 44The development of such a tool would also codify the interpretation 45of what is considered correct or incorrect, and serve as a yardstick 46against which strangely behaving domains may be measured. 47 48Additionally, by examining misconfiguration trends of the Internet 49as a whole, one might identify areas in which the DNS, or various 50implementations, may need to evolve in future versions (i.e. perhaps 51administrators often configure their domains in a certain "incorrect" 52manner to gain some particular behavior or characteristic not 53achievable with standard "correct" configuration). 54 55 56 573.1. On what scope should a question be asked? 58 59There are a few variants on the question that one would like such a 60tool to answer. The simplest query would be whether or not a specific 61domain is correctly configured. In light of the primary intended use 62this tool, this question is probably sufficient. 63 64However, one might like to ask about the configuration of the entire 65domain tree. A generalization of this would be to ask about a 66specified subtree (which could be a leaf domain). However, pursuing 67this question requires walking the domain tree by searching through 68all zone information for zone delegations. This would cause a 69considerable amount of network traffic, and you may be thwarted by 70servers unwilling to give up entire zone information. 71 72Although the latter may more convenient when checking a group of 73domains, and possibly more efficient with respect to network and 74nameserver utilization (by not repeating queries to common parent 75domain servers), we will assume the former model throughout this RFC. 76 77 783.2. What should be tested? General Discussion. 79 80The most interesting task in designing such a tool is determining what 81constitutes a misconfigured domain, which problems we should look for, 82and finally, which misconfigurations are possible/reasonable to detect 83with an automated procedure. 84 85Because the point at which a zone delegation is made is prone to 86errors, and the "delegation" and "acceptance" of authority spans two 87distinct domains, a test of a single domain should probably look at 88information from multiple domains. 89 90One could, in addition to looking at the particular domain in 91question, attempt to look at children (delegated) domains. However, 92this again raises the issue of determining which domains (if any) are 93below a given domain. On the other hand, one can test the parent 94(delegating) domain to verify that it's configuration is consistent 95with respect to the domain under scrutiny. 96 97We will assume the latter approach for now. Again, whether one 98approach or the other is more useful, is a topic for discussion. 99I believe that a tool based on either model could be used to discover 100the same set of problems in any arbitrary subtree, by choosing the 101appropriate set of domains to examine. 102 103 1043.4. What claims should be made? 105 106Once we have decided on a set of conditions we wish to test, we need 107to specify what one should say about anomalies that are detected. 108Should there be an attempt to classify them in some manner? If so, a 109classification might be similar to the following: 110 111 112ERRORS: Something is definitely wrong, and should be fixed. 113 Example: Authoritative nameservers for a domain disagree 114 on information about the domain. 115 116WARNINGS: 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 122NOTE: 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 1333.5. Procedure Variants 134 135When subsequent queries are based on the results of a query, there 136are often several possible ways to proceed. 137 138Example: Assume that we are querying the parent domain servers to 139determine a set of authoritative servers for the domain. The response 140to these queries will be used to form a list of the appropriate 141servers to which another query will be posed. In some instances, 142among the set of servers for the parent domain, some may claim to also 143be authoritative for the domain being tested. Should you treat these 144replies differently than replies from parent servers that are not 145authoritative for the domain? A few alternatives might be: (1) Ignore 146the non-authoritative replies, only if authoritative responses were 147received. (2) Classify nameservers for the domain based on whether 148parent nameserver holding an NS record for them were authoritative or 149not, and further, look at results from nameservers of different 150classes differently. (3) Most simply, you might consider any 151nameserver for the domain specified in an NS record from any parent 152domain server to be equivalent. 153 154Similar issues will exist for other parts of the procedure. 155 156 1573.6. What should be tested? Specific examples. 158 159The following is a partial set of anomalies to consider for automated 160domain testing. 161 162 1633.6.1. Queries to parent domain servers about domain. 164 165a. 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 171b. Server has no SOA record for parent domain. 172 As above (a), this server should not have been listed as a 173 nameserver. 174 175c. Server returns multiple SOAs for parent domain. 176 177d. 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 181e. 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 1873.6.2. Queries to parent domain servers about domain. 188 189f. NS records from single server have different TTLs. 190 Server has information, possibly inconsistent, from incorrect 191 sources or out-of-date versions. 192 193g. Glue records present (or not present). 194 Parent server should have addresses of authoritative servers; 195 particularly important if non-authoritative. 196 197h. List of NS records for domain differ among servers. 198 Parent servers should have consistent delegation information 199 for the domain. 200 201i. 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 2093.6.3. Queries to domain servers about domain. 210 211j. 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 215k. 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 219l. Server returns multiple SOAs for domain. 220 See above (c). 221 222m. SOA records from different servers have different serial numbers. 223 See above (d). 224 225n. SOA records from different servers are different (but same serial). 226 See above (e). 227 228o. NS records from single server have different TTLs. 229 See above (f). 230 231p. 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 235q. 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 240r. 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 246s. Reverse mapping (in-addr.arpa.) for server address not found. 247 A frequent error in newly established domains. 248 249 2504. Implementation: 251 252An initial implementation attempt is available via anonymous 253ftp from venera.isi.edu, file: pub/doc.tar.Z 254 255Doc requires the latest release of 'dig' (version 2.0) to perform 256nameserver queries; dig is also available: pub/dig.2.0.tar.Z. 257This software is intended to run on Berkeley UNIX (and variants) 258machines. 259 260 2614.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 269Start 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 368Generate a list of addresses of nameservers for domain the domain. 369Choose 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 371as a secondary). Currently, we only look at one address on per any 372single network (i.e. only of 128.9.0.32 and 128.9.0.33 would be 373followed 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 3824.2. Example test runs: 383 384Note: The domains have been changed to protect the miscreants. 385 Output has been changed to fit the RFC. 386 387 3884.2.1. Test for mystery domain #1: 389 390Doc-1.0: Starting test of mystery.dom. parent is edu. 391Doc-1.0: Test date - Fri Apr 27 14:57:05 PDT 1990 392soa @a.isi.edu. for edu. has serial: 900423 393DIGERR (TIME_OUT): dig @aos.brl.mil. for SOA of parent failed 394soa @c.nyser.net. for edu. has serial: 900423 395soa @gunter-adam.af.mil. for edu. has serial: 900423 396soa @ns.nasa.gov. for edu. has serial: 900423 397DIGERR (TIME_OUT): dig @ns.nic.ddn.mil. for SOA of parent failed 398soa @terp.umd.edu. for edu. has serial: 900426 399WARNING: Found 2 unique SOA serial #'s for edu. 400Found 3 NS and 3 glue records for mystery.dom. @a.isi.edu. 401Found 3 NS and 3 glue records for mystery.dom. @c.nyser.net. 402Found 3 NS and 3 glue records for mystery.dom. @gunter-adam.af.mil. 403Found 3 NS and 3 glue records for mystery.dom. @ns.nasa.gov. 404Found 3 NS and 3 glue records for mystery.dom. @terp.umd.edu. 405DNServers for edu. 406 === 0 were also authoritatve for mystery.dom. 407 === 5 were non-authoritative for mystery.dom. 408Servers for edu. (not also authoritative for mystery.dom.) 409 === agree on NS records for mystery.dom. 410NS list summary for mystery.dom. from parent (edu.) servers 411 == mystery.dom. cs.mystery.dom. pendragon.cs.purdue.edu. 412soa @mystery.dom. for mystery.dom. serial: 900425 413soa @cs.mystery.dom. for mystery.dom. serial: 900425 414soa @pendragon.cs.purdue.edu. for mystery.dom. serial: 900425 415SOA serial #'s agree for mystery.dom. 416Authoritative domain (mystery.dom.) servers agree on NS for mystery.dom. 417ERROR: NS list from mystery.dom. servers do not match parent 418 === (edu.) NS list 419NS list summary for mystery.dom. from authoritative servers 420 == telcom.mystery.dom. 421ERROR: mystery.dom. claims to be AUTH no NS record from AUTH servers 422ERROR: cs.mystery.dom. claims to be AUTH no NS record 423=== from AUTH servers 424ERROR: pendragon.cs.purdue.edu. claims to be AUTH no NS record 425=== from AUTH servers 426Checking 2 potential addresses for hosts at mystery.dom. 427 == 128.196.128.233 192.12.69.1 428in-addr PTR record found for 128.196.128.233 429in-addr PTR record found for 192.12.69.1 430Summary: 431 ERRORS found for mystery.dom. (count: 4) 432 WARNINGS issued for mystery.dom. (count: 1) 433Done test of mystery.dom. Fri Apr 27 14:59:07 PDT 1990 434 435 4364.2.2 Test for mystery domain #2: 437 438Doc-1.0: Starting test of mystery.dom. parent is edu. 439Doc-1.0: Test date - Fri Apr 27 16:14:02 PDT 1990 440soa @a.isi.edu. for edu. has serial: 900423 441soa @aos.brl.mil. for edu. has serial: 900426 442soa @c.nyser.net. for edu. has serial: 900423 443soa @gunter-adam.af.mil. for edu. has serial: 900423 444soa @ns.nasa.gov. for edu. has serial: 900423 445soa @ns.nic.ddn.mil. for edu. has serial: 900426 446soa @terp.umd.edu. for edu. has serial: 900426 447WARNING: Found 2 unique SOA serial #'s for edu. 448Found 3 NS and 3 glue records for mystery.dom. @a.isi.edu. 449Found 3 NS and 3 glue records for mystery.dom. @aos.brl.mil. 450Found 3 NS and 3 glue records for mystery.dom. @c.nyser.net. 451Found 3 NS and 3 glue records for mystery.dom. @gunter-adam.af.mil. 452Found 3 NS and 3 glue records for mystery.dom. @ns.nasa.gov. 453Found 3 NS and 3 glue records for mystery.dom. @ns.nic.ddn.mil. 454Found 3 NS and 3 glue records for mystery.dom. @terp.umd.edu. 455DNServers for edu. 456 === 0 were also authoritatve for mystery.dom. 457 === 7 were non-authoritative for mystery.dom. 458Servers for edu. (not also authoritative for mystery.dom.) 459 === agree on NS records for mystery.dom. 460NS list summary for mystery.dom. from parent (edu.) servers 461 == eos.cair.mystery.dom. nike.cair.mystery.dom. ns.utah.edu. 462DIGERR (TIME_OUT): dig @eos.cair.mystery.dom. for SOA of mystery.dom. 463soa @nike.cair.mystery.dom. for mystery.dom. serial: 60001 464soa @ns.utah.edu. for mystery.dom. serial: 60001 465SOA serial #'s agree for mystery.dom. 466Authoritative domain (mystery.dom.) servers agree on NS for mystery.dom. 467ERROR: NS list from mystery.dom. servers do not match parent 468 === (edu.) NS list 469NS list summary for mystery.dom. from authoritative servers 470 == nike.cair.mystery.dom. orion.cair.mystery.dom. 471ERROR: ns.utah.edu. claims to be AUTH no NS record from AUTH servers 472Checking 1 potential addresses for hosts at mystery.dom. 473 == 130.253.1.5 474ERROR: no in-addr PTR recorder found for 130.253.1.5 475Summary: 476 ERRORS found for mystery.dom. (count: 3) 477 WARNINGS issued for mystery.dom. (count: 1) 478 Incomplete test for mystery.dom. (1) 479Done test of mystery.dom. Fri Apr 27 16:16:08 PDT 1990 480 481 482References/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 493Authors' Addresses: 494 495Steve Hotz 496USC - Information Sciences Institute 4974676 Admiralty Way 498Marina del Rey, Ca. 90293 499 500Phone: (213) 822-1511 501 502Email: hotz@isi.edu 503 504 505Paul Mockapetris 506USC - Information Sciences Institute 5074676 Admiralty Way 508Marina del Rey, Ca. 90293 509 510Phone: (213) 822-1511 511 512Email: pvm@isi.edu 513