| < draft-ietf-dnsind-clarify-07.txt | draft-ietf-dnsind-clarify-08.txt > | |||
|---|---|---|---|---|
| Network Working Group Robert Elz | Network Working Group Robert Elz | |||
| Internet Draft University of Melbourne | Internet Draft University of Melbourne | |||
| Expiration Date: September 1997 | Expiration Date: November 1997 | |||
| Randy Bush | Randy Bush | |||
| RGnet, Inc. | RGnet, Inc. | |||
| March 1997 | May 1997 | |||
| Clarifications to the DNS Specification | Clarifications to the DNS Specification | |||
| draft-ietf-dnsind-clarify-07.txt | draft-ietf-dnsind-clarify-08.txt | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft. Internet-Drafts are working | This document is an Internet-Draft. Internet-Drafts are working | |||
| documents of the Internet Engineering Task Force (IETF), its areas, | documents of the Internet Engineering Task Force (IETF), its areas, | |||
| and its working groups. Note that other groups may also distribute | and its working groups. Note that other groups may also distribute | |||
| working documents as Internet-Drafts. | working documents as Internet-Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| skipping to change at page 1, line 43 ¶ | skipping to change at page 1, line 43 ¶ | |||
| 1. Abstract | 1. Abstract | |||
| This draft considers some areas that have been identified as problems | This draft considers some areas that have been identified as problems | |||
| with the specification of the Domain Name System, and proposes | with the specification of the Domain Name System, and proposes | |||
| remedies for the defects identified. Eight separate issues are | remedies for the defects identified. Eight separate issues are | |||
| considered: | considered: | |||
| + IP packet header address usage from multi-homed servers, | + IP packet header address usage from multi-homed servers, | |||
| + TTLs in sets of records with the same name, class, and type, | + TTLs in sets of records with the same name, class, and type, | |||
| + correct handling of zone cuts, | + correct handling of zone cuts, | |||
| + two minor issues concerning SOA records and their use, | + three minor issues concerning SOA records and their use, | |||
| + the precise definition of the Time to Live (TTL) | + the precise definition of the Time to Live (TTL) | |||
| + Use of the TC (truncated) header bit | + Use of the TC (truncated) header bit | |||
| + the issue of what is an authoritative, or canonical, name, | + the issue of what is an authoritative, or canonical, name, | |||
| + and the issue of what makes a valid DNS label. | + and the issue of what makes a valid DNS label. | |||
| The first six of these are areas where the correct behaviour has been | The first six of these are areas where the correct behaviour has been | |||
| somewhat unclear, we seek to rectify that. The other two are already | somewhat unclear, we seek to rectify that. The other two are already | |||
| adequately specified, however the specifications seem to be sometimes | adequately specified, however the specifications seem to be sometimes | |||
| ignored. We seek to reinforce the existing specifications. | ignored. We seek to reinforce the existing specifications. | |||
| This versions ads two new minor clarifications, to the definition of | This versions adds one new minor clarification, to the definition and | |||
| a TTL, and to use of the TC bit. This paragraph will be deleted from | use of the SOA.mname field, and some editorial cleanups. This | |||
| the final version of this document. | paragraph will be deleted from the final version of this document. | |||
| Contents | Contents | |||
| 1 Abstract ................................................... 1 | 1 Abstract ................................................... 1 | |||
| 2 Introduction ............................................... 2 | 2 Introduction ............................................... 2 | |||
| 3 Terminology ................................................ 3 | 3 Terminology ................................................ 3 | |||
| 4 Server Reply Source Address Selection ...................... 3 | 4 Server Reply Source Address Selection ...................... 3 | |||
| 5 Resource Record Sets ....................................... 4 | 5 Resource Record Sets ....................................... 4 | |||
| 6 Zone Cuts .................................................. 8 | 6 Zone Cuts .................................................. 8 | |||
| 7 SOA RRs .................................................... 10 | 7 SOA RRs .................................................... 10 | |||
| 8 Time to Live (TTL) ......................................... 10 | 8 Time to Live (TTL) ......................................... 10 | |||
| 9 The TC (truncated) header bit .............................. 11 | 9 The TC (truncated) header bit .............................. 11 | |||
| 10 Naming issues .............................................. 11 | 10 Naming issues .............................................. 11 | |||
| 11 Name syntax ................................................ 13 | 11 Name syntax ................................................ 13 | |||
| 12 Security Considerations .................................... 14 | 12 Security Considerations .................................... 14 | |||
| 13 References ................................................. 14 | 13 References ................................................. 14 | |||
| 14 Acknowledgements ........................................... 14 | 14 Acknowledgements ........................................... 15 | |||
| 15 Authors' addresses ......................................... 15 | 15 Authors' addresses ......................................... 15 | |||
| 2. Introduction | 2. Introduction | |||
| Several problem areas in the Domain Name System specification | Several problem areas in the Domain Name System specification | |||
| [RFC1034, RFC1035] have been noted through the years [RFC1123]. This | [RFC1034, RFC1035] have been noted through the years [RFC1123]. This | |||
| draft addresses several additional problem areas. The issues here | draft addresses several additional problem areas. The issues here | |||
| are independent. Those issues are the question of which source | are independent. Those issues are the question of which source | |||
| address a multi-homed DNS server should use when replying to a query, | address a multi-homed DNS server should use when replying to a query, | |||
| the issue of differing TTLs for DNS records with the same label, | the issue of differing TTLs for DNS records with the same label, | |||
| skipping to change at page 3, line 28 ¶ | skipping to change at page 3, line 28 ¶ | |||
| Most, if not all, DNS clients, expect the address from which a reply | Most, if not all, DNS clients, expect the address from which a reply | |||
| is received to be the same address as that to which the query | is received to be the same address as that to which the query | |||
| eliciting the reply was sent. This is true for servers acting as | eliciting the reply was sent. This is true for servers acting as | |||
| clients for the purposes of recursive query resolution, as well as | clients for the purposes of recursive query resolution, as well as | |||
| simple resolver clients. The address, along with the identifier (ID) | simple resolver clients. The address, along with the identifier (ID) | |||
| in the reply is used for disambiguating replies, and filtering | in the reply is used for disambiguating replies, and filtering | |||
| spurious responses. This may, or may not, have been intended when | spurious responses. This may, or may not, have been intended when | |||
| the DNS was designed, but is now a fact of life. | the DNS was designed, but is now a fact of life. | |||
| Some multi-homed hosts running DNS servers fail to expect this usage. | Some multi-homed hosts running DNS servers generate a reply using a | |||
| Consequently they send replies from a source address other than the | source address that is not the same as the destination address from | |||
| destination address from the original query. This causes the reply | the client's request packet. Such replies will be discarded by the | |||
| to be discarded by the client. | client because the source address of the reply does not match that of | |||
| a host to which the client sent the original request. That is, it | ||||
| appears to be an unsolicited response. | ||||
| 4.1. UDP Source Address Selection | 4.1. UDP Source Address Selection | |||
| To avoid these problems, servers when responding to queries using UDP | To avoid these problems, servers when responding to queries using UDP | |||
| must cause the reply to be sent with the source address field in the | must cause the reply to be sent with the source address field in the | |||
| IP header set to the address that was in the destination address | IP header set to the address that was in the destination address | |||
| field of the IP header of the packet containing the query causing the | field of the IP header of the packet containing the query causing the | |||
| response. If this would cause the response to be sent from an IP | response. If this would cause the response to be sent from an IP | |||
| address that is not permitted for this purpose, then the response may | address that is not permitted for this purpose, then the response may | |||
| be sent from any legal IP address allocated to the server. That | be sent from any legal IP address allocated to the server. That | |||
| skipping to change at page 4, line 49 ¶ | skipping to change at page 4, line 49 ¶ | |||
| caching server, where the TTLs for some but not all the RRs in the | caching server, where the TTLs for some but not all the RRs in the | |||
| RRSet have expired. | RRSet have expired. | |||
| Consequently the use of differing TTLs in an RRSet is hereby | Consequently the use of differing TTLs in an RRSet is hereby | |||
| deprecated, the TTLs of all RRs in an RRSet must be the same. | 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 | Should a client receive a response containing RRs from an RRSet with | |||
| differing TTLs, it should treat this as an error. If the RRSet | differing TTLs, it should treat this as an error. If the RRSet | |||
| concerned is from a non-authoritative source for this data, the | concerned is from a non-authoritative source for this data, the | |||
| client should simply ignore the RRSet, and if the values were | client should simply ignore the RRSet, and if the values were | |||
| required, seek to acquire them from an authoritative source. Should | required, seek to acquire them from an authoritative source. Clients | |||
| an authoritative source send such a malformed RRSet, the client | that are configured to send all queries to one, or more, particular | |||
| should treat the RRs for all purposes as if all TTLs in the RRSet had | servers should treat those servers as authoritative for this purpose. | |||
| been set to the value of the lowest TTL in the RRSet. In no case may | Should an authoritative source send such a malformed RRSet, the | |||
| a server send an RRSet with TTLs not all equal. | 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. | ||||
| 5.3. DNSSEC Special Cases | 5.3. DNSSEC Special Cases | |||
| Two of the record types added by DNS Security (DNSSEC) [RFC2065] | Two of the record types added by DNS Security (DNSSEC) [RFC2065] | |||
| require special attention when considering the formation of Resource | require special attention when considering the formation of Resource | |||
| Record Sets. Those are the SIG and NXT records. It should be noted | Record Sets. Those are the SIG and NXT records. It should be noted | |||
| that DNS Security is still very new, and there is, as yet, little | that DNS Security is still very new, and there is, as yet, little | |||
| experience with it. Readers should be prepared for the information | experience with it. Readers should be prepared for the information | |||
| related to DNSSEC contained in this document to become outdated as | related to DNSSEC contained in this document to become outdated as | |||
| the DNS Security specification matures. | the DNS Security specification matures. | |||
| skipping to change at page 7, line 20 ¶ | skipping to change at page 7, line 20 ¶ | |||
| authoritative answer from a reply should replace cached data that had | authoritative answer from a reply should replace cached data that had | |||
| been obtained from additional information in an earlier reply. | been obtained from additional information in an earlier reply. | |||
| However additional information from a reply will be ignored if the | However additional information from a reply will be ignored if the | |||
| cache contains data from an authoritative answer or a zone file. | cache contains data from an authoritative answer or a zone file. | |||
| The accuracy of data available is assumed from its source. | The accuracy of data available is assumed from its source. | |||
| Trustworthiness shall be, in order from most to least: | Trustworthiness shall be, in order from most to least: | |||
| + Data from a primary zone file, other than glue data, | + Data from a primary zone file, other than glue data, | |||
| + Data from a zone transfer, other than glue, | + Data from a zone transfer, other than glue, | |||
| + Data from the answer section of an authoritative reply, | + The authoritative data included in the answer section of an | |||
| authoritative reply. | ||||
| + Data from the authority section of an authoritative answer, | + Data from the authority section of an authoritative answer, | |||
| + Glue from a primary zone, or glue from a zone transfer, | + Glue from a primary zone, or glue from a zone transfer, | |||
| + Data from the answer section of a non-authoritative answer, | + 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, | + Additional information from an authoritative answer, | |||
| Data from the authority section of a non-authoritative answer, | Data from the authority section of a non-authoritative answer, | |||
| Additional information from non-authoritative answers. | Additional information from non-authoritative answers. | |||
| Note that the answer section of an authoritative answer normally | ||||
| contains only authoritative data. However when the name sought is an | ||||
| alias (see section 10.1.1) only the record describing that alias is | ||||
| necessarily authoritative. Clients should assume that other records | ||||
| may have come from the server's cache. Where authoritative answers | ||||
| are required, the client should query again, using the canonical name | ||||
| associated with the alias. | ||||
| Unauthenticated RRs received and cached from the least trustworthy of | Unauthenticated RRs received and cached from the least trustworthy of | |||
| those groupings, that is data from the additional data section, and | those groupings, that is data from the additional data section, and | |||
| data from the authority section of a non-authoritative answer, should | 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 | 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 | answers to a received query. They may be returned as additional | |||
| information where appropriate. Ignoring this would allow the | information where appropriate. Ignoring this would allow the | |||
| trustworthiness of relatively untrustworthy data to be increased | trustworthiness of relatively untrustworthy data to be increased | |||
| without cause or excuse. | without cause or excuse. | |||
| When DNS security [RFC2065] is in use, and an authenticated reply has | When DNS security [RFC2065] is in use, and an authenticated reply has | |||
| skipping to change at page 10, line 7 ¶ | skipping to change at page 10, line 11 ¶ | |||
| subzone. Where a subzone is secure, the KEY and SIG records will be | subzone. Where a subzone is secure, the KEY and SIG records will be | |||
| present, and authoritative, in that zone, but should also always be | present, and authoritative, in that zone, but should also always be | |||
| present in the parent zone (if secure). | present in the parent zone (if secure). | |||
| Note that in none of these cases should a server for the parent zone, | Note that in none of these cases should a server for the parent zone, | |||
| not also being a server for the subzone, set the AA bit in any | not also being a server for the subzone, set the AA bit in any | |||
| response for a label at a zone cut. | response for a label at a zone cut. | |||
| 7. SOA RRs | 7. SOA RRs | |||
| Two minor issues concerning the Start of Zone of Authority (SOA) | Three minor issues concerning the Start of Zone of Authority (SOA) | |||
| Resource Record need some clarification. | Resource Record need some clarification. | |||
| 7.1. Placement of SOA RRs in authoritative answers | 7.1. Placement of SOA RRs in authoritative answers | |||
| RFC1034, in section 3.7, indicates that the authority section of an | RFC1034, in section 3.7, indicates that the authority section of an | |||
| authoritative answer may contain the SOA record for the zone from | authoritative answer may contain the SOA record for the zone from | |||
| which the answer was obtained. When discussing negative caching, | which the answer was obtained. When discussing negative caching, | |||
| RFC1034 section 4.3.4 refers to this technique but mentions the | RFC1034 section 4.3.4 refers to this technique but mentions the | |||
| additional section of the response. The former is correct, as is | additional section of the response. The former is correct, as is | |||
| implied by the example shown in section 6.2.5 of RFC1034. SOA | implied by the example shown in section 6.2.5 of RFC1034. SOA | |||
| skipping to change at page 10, line 30 ¶ | skipping to change at page 10, line 34 ¶ | |||
| 7.2. TTLs on SOA RRs | 7.2. TTLs on SOA RRs | |||
| It may be observed that in section 3.2.1 of RFC1035, which defines | It may be observed that in section 3.2.1 of RFC1035, which defines | |||
| the format of a Resource Record, that the definition of the TTL field | the format of a Resource Record, that the definition of the TTL field | |||
| contains a throw away line which states that the TTL of an SOA record | contains a throw away line which states that the TTL of an SOA record | |||
| should always be sent as zero to prevent caching. This is mentioned | should always be sent as zero to prevent caching. This is mentioned | |||
| nowhere else, and has not generally been implemented. | nowhere else, and has not generally been implemented. | |||
| Implementations should not assume that SOA records will have a TTL of | Implementations should not assume that SOA records will have a TTL of | |||
| zero, nor are they required to send SOA records with a TTL of zero. | zero, nor are they required to send SOA records with a TTL of zero. | |||
| 7.3. The SOA.MNAME field | ||||
| It is quite clear in the specifications, yet seems to have been | ||||
| widely ignored, that the MNAME field of the SOA record should contain | ||||
| the name of the primary (master) server for the zone identified by | ||||
| the SOA. It should not contain the name of the zone itself. That | ||||
| information would be useless, as to discover it, one needs to start | ||||
| with the domain name of the SOA record - that is the name of the | ||||
| zone. | ||||
| 8. Time to Live (TTL) | 8. Time to Live (TTL) | |||
| The definition of values appropriate to the TTL field in STD 13 is | The definition of values appropriate to the TTL field in STD 13 is | |||
| not as clear as it could be, with respect to how many significant | not as clear as it could be, with respect to how many significant | |||
| bits exist, and whether the value is signed or unsigned. It is | bits exist, and whether the value is signed or unsigned. It is | |||
| hereby specified that a TTL value is an unsigned number, with a | hereby specified that a TTL value is an unsigned number, with a | |||
| minimum value of 0, and a maximum value of 2147483647. That is, a | minimum value of 0, and a maximum value of 2147483647. That is, a | |||
| maximum of 2^31 - 1. When transmitted, this value shall be encoded | maximum of 2^31 - 1. When transmitted, this value shall be encoded | |||
| in the less significant 31 bits of the 32 bit TTL field, with the | in the less significant 31 bits of the 32 bit TTL field, with the | |||
| most significant, or sign, bit set to zero. | most significant, or sign, bit set to zero. | |||
| skipping to change at page 11, line 29 ¶ | skipping to change at page 11, line 38 ¶ | |||
| set, it should ignore that response, and query again, using a | set, it should ignore that response, and query again, using a | |||
| mechanism, such as a TCP connection, that will permit larger replies. | mechanism, such as a TCP connection, that will permit larger replies. | |||
| 10. Naming issues | 10. Naming issues | |||
| It has sometimes been inferred from some sections of the DNS | It has sometimes been inferred from some sections of the DNS | |||
| specification [RFC1034, RFC1035] that a host, or perhaps an interface | specification [RFC1034, RFC1035] that a host, or perhaps an interface | |||
| of a host, is permitted exactly one authoritative, or official, name, | of a host, is permitted exactly one authoritative, or official, name, | |||
| called the canonical name. There is no such requirement in the DNS. | called the canonical name. There is no such requirement in the DNS. | |||
| 10.1. CNAME records | 10.1. CNAME resource records | |||
| The DNS CNAME ("canonical name") record exists to provide the | The DNS CNAME ("canonical name") record exists to provide the | |||
| canonical name associated with an alias name. There may be only one | canonical name associated with an alias name. There may be only one | |||
| such canonical name for any one alias. That name should generally be | such canonical name for any one alias. That name should generally be | |||
| a name that exists elsewhere in the DNS, though some applications for | a name that exists elsewhere in the DNS, though there are some rare | |||
| aliases with no accompanying canonical name exist. An alias name | applications for aliases with the accompanying canonical name | |||
| (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, | undefined in the DNS. An alias name (label of a CNAME record) may, | |||
| and KEY RRs, but may have no other data. That is, for any label in | if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no | |||
| the DNS (any domain name) exactly one of the following is true: | other data. That is, for any label in the DNS (any domain name) | |||
| exactly one of the following is true: | ||||
| + one CNAME record exists, optionally accompanied by SIG, NXT, and | + one CNAME record exists, optionally accompanied by SIG, NXT, and | |||
| KEY RRs, | KEY RRs, | |||
| + one or more records exist, none being CNAME records, | + one or more records exist, none being CNAME records, | |||
| + the name exists, but has no associated RRs of any type, | + the name exists, but has no associated RRs of any type, | |||
| + the name does not exist at all. | + the name does not exist at all. | |||
| 10.1.1. CNAME terminology | 10.1.1. CNAME terminology | |||
| It has been traditional to refer to the label of a CNAME record as "a | It has been traditional to refer to the label of a CNAME record as "a | |||
| skipping to change at page 12, line 49 ¶ | skipping to change at page 13, line 15 ¶ | |||
| Searching for either NS or MX records causes "additional section | Searching for either NS or MX records causes "additional section | |||
| processing" in which address records associated with the value of the | processing" in which address records associated with the value of the | |||
| record sought are appended to the answer. This helps avoid needless | record sought are appended to the answer. This helps avoid needless | |||
| extra queries that are easily anticipated when the first was made. | extra queries that are easily anticipated when the first was made. | |||
| Additional section processing does not include CNAME records, let | Additional section processing does not include CNAME records, let | |||
| alone the address records that may be associated with the canonical | alone the address records that may be associated with the canonical | |||
| name derived from the alias. Thus, if an alias is used as the value | name derived from the alias. Thus, if an alias is used as the value | |||
| of an NS or MX record, no address will be returned with the NS or MX | of an NS or MX record, no address will be returned with the NS or MX | |||
| value. This can cause extra queries, and extra network burden, on | value. This can cause extra queries, and extra network burden, on | |||
| every query. It is trivial to avoid this by resolving the alias and | every query. It is trivial for the DNS administrator to avoid this | |||
| placing the canonical name directly in the affected record just once | by resolving the alias and placing the canonical name directly in the | |||
| when it is updated or installed. In some particular hard cases the | affected record just once when it is updated or installed. In some | |||
| lack of the additional section address records in the results of a NS | particular hard cases the lack of the additional section address | |||
| lookup can cause the request to fail. | records in the results of a NS lookup can cause the request to fail. | |||
| 11. Name syntax | 11. Name syntax | |||
| Occasionally it is assumed that the Domain Name System serves only | Occasionally it is assumed that the Domain Name System serves only | |||
| the purpose of mapping Internet host names to data, and mapping | the purpose of mapping Internet host names to data, and mapping | |||
| Internet addresses to host names. This is not correct, the DNS is a | Internet addresses to host names. This is not correct, the DNS is a | |||
| general (if somewhat limited) hierarchical database, and can store | general (if somewhat limited) hierarchical database, and can store | |||
| almost any kind of data, for almost any purpose. | almost any kind of data, for almost any purpose. | |||
| The DNS itself places only one restriction on the particular labels | The DNS itself places only one restriction on the particular labels | |||
| skipping to change at page 14, line 49 ¶ | skipping to change at page 15, line 14 ¶ | |||
| 14. Acknowledgements | 14. Acknowledgements | |||
| This memo arose from discussions in the DNSIND working group of the | This memo arose from discussions in the DNSIND working group of the | |||
| IETF in 1995 and 1996, the members of that working group are largely | IETF in 1995 and 1996, the members of that working group are largely | |||
| responsible for the ideas captured herein. Particular thanks to | responsible for the ideas captured herein. Particular thanks to | |||
| Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the | Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the | |||
| DNSSEC issues in this document, and to John Gilmore for pointing out | DNSSEC issues in this document, and to John Gilmore for pointing out | |||
| where the clarifications were not necessarily clarifying. Bob Halley | where the clarifications were not necessarily clarifying. Bob Halley | |||
| suggested clarifying the placement of SOA records in authoritative | suggested clarifying the placement of SOA records in authoritative | |||
| answers, and provided the references. Michael Patton, as usual, Mark | answers, and provided the references. Michael Patton, as usual, and | |||
| Andrews, and Alan Barrett provided much assistance with many details. | Mark Andrews, Alan Barrett and Stan Barber provided much assistance | |||
| with many details. Josh Littlefield helped make sure that the | ||||
| clarifications didn't cause problems in some irritating corner cases. | ||||
| 15. Authors' addresses | 15. Authors' addresses | |||
| Robert Elz | Robert Elz | |||
| Computer Science | Computer Science | |||
| University of Melbourne | University of Melbourne | |||
| Parkville, Victoria, 3052 | Parkville, Victoria, 3052 | |||
| Australia. | Australia. | |||
| EMail: kre@munnari.OZ.AU | EMail: kre@munnari.OZ.AU | |||
| Randy Bush | Randy Bush | |||
| RGnet, Inc. | RGnet, Inc. | |||
| 10361 NE Sasquatch Lane | 5147 Crystal Springs Drive NE | |||
| Bainbridge Island, Washington, 98110 | Bainbridge Island, Washington, 98110 | |||
| United States. | United States. | |||
| EMail: randy@psg.com | EMail: randy@psg.com | |||
| End of changes. 18 change blocks. | ||||
| 34 lines changed or deleted | 62 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||