reports/rfc/draft-ietf-dnsind-clarify-01.txt

   1
   2
   3 Network Working Group                                         Robert Elz
   4 Internet Draft                                   University of Melbourne
   5 Expiration Date: November 1996
   6                                                               Randy Bush
   7                                                              RGnet, Inc.
   8
   9                                                                 May 1996
  10
  11
  12                 Clarifications to the DNS Specification
  13
  14
  15                     draft-ietf-dnsind-clarify-01.txt
  16
  17 Status of this Memo
  18
  19    This document is an Internet-Draft.  Internet-Drafts are working
  20    documents of the Internet Engineering Task Force (IETF), its areas,
  21    and its working groups.  Note that other groups may also distribute
  22    working documents as Internet-Drafts.
  23
  24    Internet-Drafts are draft documents valid for a maximum of six months
  25    and may be updated, replaced, or obsoleted by other documents at any
  26    time.  It is inappropriate to use Internet-Drafts as reference
  27    material or to cite them other than as "work in progress."
  28
  29    To learn the current status of any Internet-Draft, please check the
  30    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  31    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  32    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  33    ftp.isi.edu (US West Coast).
  34
  35 1. Abstract
  36
  37    This draft considers some areas that have been identified as problems
  38    with the specification of the Domain Name System, and proposes
  39    remedies for the defects identified.  Two separate issues are
  40    considered, IP packet header address usage from multi-homed servers,
  41    and TTLs in sets of records with the same name, class, and type.
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54 kre/randy                                                       [Page 1]
  55 \f
  56 Internet Draft      draft-ietf-dnsind-clarify-01.txt            May 1996
  57
  58
  59 2. Introduction
  60
  61    Several problem areas in the Domain Name System specification
  62    [RFC1034, RFC1035] have been noted through the years [RFC1123].  This
  63    draft addresses two additional problem areas.  The two issues here
  64    are independent.  Those issues are the question of which source
  65    address a multi-homed DNS server should use when replying to a query,
  66    and the issue of differing TTLs for DNS records with the same label,
  67    class and type.
  68
  69    Suggestions for clarifications to the DNS specification to avoid
  70    these problems are made in this memo.  The solutions proposed herein
  71    are intended to stimulate discussion.  It is possible that the sense
  72    of either may be reversed before the next iteration of this draft,
  73    but less likely now than it was before the previous version.
  74
  75 3. Server Reply Source Address Selection
  76
  77    Most, if not all, DNS clients, whether servers acting as clients for
  78    the purposes of recursive query resolution, or resolvers, expect the
  79    address from which a reply is received to be the same address as that
  80    to which the query eliciting the reply was sent.  This, along with
  81    the identifier (ID) in the reply is used for disambiguating replies,
  82    and filtering spurious responses.  This may, or may not, have been
  83    intended when the DNS was designed, but is now a fact of life.
  84
  85    Some multi-homed hosts running DNS servers fail to anticipate this
  86    usage, and consequently send replies from the "wrong" source address,
  87    causing the reply to be discarded by the client.
  88
  89 3.1. UDP Source Address Selection
  90
  91    To avoid these problems, servers when responding to queries using UDP
  92    must cause the reply to be sent with the source address field in the
  93    IP header set to the address that was in the destination address
  94    field of the IP header of the packet containing the query causing the
  95    response.  If this would cause the response to be sent from an IP
  96    address which is not permitted for this purpose, then the response
  97    may be sent from any legal IP address allocated to the server.  That
  98    address should be chosen to maximise the possibility that the client
  99    will be able to use it for further queries.  Servers configured in
 100    such a way that not all their addresses are equally reachable from
 101    all potential clients need take particular care when responding to
 102    queries sent to anycast, multicast, or similar, addresses.
 103
 104
 105
 106
 107
 108
 109
 110 kre/randy                                                       [Page 2]
 111 \f
 112 Internet Draft      draft-ietf-dnsind-clarify-01.txt            May 1996
 113
 114
 115 3.2. Port Number Selection
 116
 117    Replies to all queries must be directed to the port from which they
 118    were sent.  With queries received via TCP this is an inherent part of
 119    the transport protocol, for queries received by UDP the server must
 120    take note of the source port and use that as the destination port in
 121    the response.  Replies should always be sent from the port to which
 122    they were directed.  Except in extraordinary circumstances, this will
 123    be the well known port assigned for DNS queries [RFC1700].
 124
 125 4. Resource Record Sets
 126
 127    Each DNS Resource Record (RR) each has a label, class, type, and
 128    data.  While it is meaningless for two records to ever have label,
 129    class, type and data all equal (servers should suppress such
 130    duplicates if encountered), it is possible for many record types to
 131    exist with the same label class and type, but with different data.
 132    Such a group of records is hereby defined to be a Resource Record Set
 133    (RRSet).
 134
 135 4.1. Sending RRs from an RRSet
 136
 137    A query for a specific (or non-specific) label, class, and type, will
 138    always return all records in the associated RRSet - whether that be
 139    one or more RRs, or the response shall be marked as "truncated" if
 140    the entire RRSet will not fit in the response.
 141
 142 4.2. TTLs of RRs in an RRSet
 143
 144    Resource Records also have a time to live (TTL).  It is possible for
 145    the RRs in an RRSet to have different TTLs, however no uses for this
 146    have been found which cannot be better accomplished in other ways.
 147    This can, however, cause partial replies (not marked "truncated")
 148    from a caching server, where the TTLs for some but not all of the RRs
 149    in the RRSet have expired.
 150
 151    Consequently the use of differing TTLs in an RRSet is hereby
 152    deprecated, the TTLs of all RRs in an RRSet must be the same.
 153
 154    Should a client receive a response containing RRs from an RRSet with
 155    differing TTLs, it should treat the RRs for all purposes as if all
 156    TTLs in the RRSet had been set to the value of the lowest TTL in the
 157    RRSet.
 158
 159
 160
 161
 162
 163
 164
 165
 166 kre/randy                                                       [Page 3]
 167 \f
 168 Internet Draft      draft-ietf-dnsind-clarify-01.txt            May 1996
 169
 170
 171 4.3. Receiving RRSets
 172
 173    Servers never merge RRs from a response with RRs in their cache to
 174    form an RRSet.  If a response contains data which would form an RRSet
 175    with data in a server's cache the server must either ignore the RRs
 176    in the response, or use those to replace the existing RRSet in the
 177    cache, as appropriate.  Consequently the issue of TTLs varying
 178    between the cache and a response does not cause concern, one will be
 179    ignored.
 180
 181 4.3.1. Ranking data
 182
 183    When considering whether to accept an RRSet in a reply, or retain an
 184    RRSet already in its cache instead, a server should consider the
 185    relative likely trustworthiness of the various data.  That is, an
 186    authoritative answer from a reply should replace cached data that had
 187    been obtained from additional information in an earlier reply, but
 188    additional information from a reply will be ignored if the cache
 189    contains data from an authoritative answer or a zone file.
 190
 191    The accuracy of data available is assumed from its source.
 192    Trustworthiness shall be, in order from most to least:
 193
 194     + Data from a primary zone file, other than glue data,
 195     + Data from a zone transfer, other than glue,
 196     + That from the answer section of an authoritative reply,
 197     + Glue from a primary zone, or glue from a zone transfer,
 198     + Data from the authority section of an authoritative answer,
 199     + Data from the answer section of a non-authoritative answer,
 200     + Additional information from an authoritative answer,
 201     + Data from the authority section of a non-authoritative answer,
 202     + Additional information from non-authoritative answers.
 203
 204    Where authenticated data has been received it shall be considered
 205    more trustworthy than unauthenticated data of the same type.
 206
 207    "Glue" above includes any record in a zone file that is not properly
 208    part of that zone, including nameserver records of delegated sub-
 209    zones (NS records), address records that accompany those NS records
 210    (A, AAAA, etc), and any other stray data that might appear.
 211
 212 4.4. Sending RRSets (reprise)
 213
 214    A Resource Record Set should only be included once in any DNS reply.
 215    It may occur in any of the Answer, Authority, or Additional
 216    Information sections, as required, however should not be repeated in
 217    the same, or any other, section, except where explicitly required by
 218    a specification.  For example, an AXFR response requires the SOA
 219
 220
 221
 222 kre/randy                                                       [Page 4]
 223 \f
 224 Internet Draft      draft-ietf-dnsind-clarify-01.txt            May 1996
 225
 226
 227    record (always an RRSet containing a single RR) be both the first and
 228    last record of the reply.  Where duplicates are required this way,
 229    the TTL transmitted in each case must be the same.
 230
 231 5. Security Considerations
 232
 233    This document does not consider security.
 234
 235    In particular, nothing in section 3 is any way related to, or useful
 236    for, any security related purposes.
 237
 238    Section 4.3.1 is also not related to security.  Security of DNS data
 239    will be obtained by the Secure DNS [DNSSEC], which is orthogonal to
 240    this memo.
 241
 242    It is not believed that anything in this document adds to any
 243    security issues that may exist with the DNS, nor does it do anything
 244    to lessen them.
 245
 246 6. References
 247
 248    [RFC1034]   Domain Names - Concepts and Facilities,  (STD 13)
 249                P. Mockapetris, ISI, November 1987.
 250
 251    [RFC1035]   Domain Names - Implementation and Specification  (STD 13)
 252                P. Mockapetris, ISI, November 1987
 253
 254    [RFC1123]   Requirements for Internet hosts - application and support,
 255                (STD 3) R. Braden, January 1989
 256
 257    [RFC1700]   Assigned Numbers (STD 2)
 258                J. Reynolds, J. Postel, October 1994.
 259
 260    [DNSSEC]    Domain Name System Security Extensions,
 261                D. E. Eastlake, 3rd, C. W. Kaufman,
 262                Work in Progress (Internet Draft), January 1996.
 263
 264 7. Acknowledgements
 265
 266    This memo arose from discussions in the DNSIND working group of the
 267    IETF in 1995 and 1996, the members of that working group are largely
 268    responsible for the ideas captured herein.
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278 kre/randy                                                       [Page 5]
 279 \f
 280 Internet Draft      draft-ietf-dnsind-clarify-01.txt            May 1996
 281
 282
 283 8. Authors' addresses
 284
 285    Robert Elz
 286    Computer Science
 287    University of Melbourne
 288    Parkville, Victoria, 3052
 289    Australia.
 290
 291    EMail: kre@munnari.OZ.AU
 292
 293
 294    Randy Bush
 295    RGnet, Inc.
 296    9501 SW Westhaven
 297    Portland, Oregon, 97225
 298    United States.
 299
 300    EMail: randy@psg.com
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334 kre/randy                                                       [Page 6]