Internet DRAFT - draft-bill-dnsop-source-address-selection

draft-bill-dnsop-source-address-selection



 



INTERNET-DRAFT                                       Declan Ma, Ed.
Intended Status: Proposed Standard                        zDNS Ltd.
Expires: 2015-10-15                                      2015-05-22


         Multi-homed DNS Server Reply Source Address Selection
              draft-bill-dnsop-source-address-selection-00


Abstract

   RFC 2181 collected eight independent considerations and created a single
   docuement to address each of them in turn.  Over the following two decades
   it has become clear that each of these items should be considered and evovolve
   in its own right, as suggested in RFC 2181. This document extracts the exact 
   text from RFC 2181 and places it into its own track.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
 


Declan Ma, Ed.                 Expires 2015-10-15                  [Page 1]

INTERNET DRAFT       Reply Source Address Selection         2015-05-22


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3  UDP Source Address Selection  . . . . . . . . . . . . . . . . .  3
   4  Port Number Selection . . . . . . . . . . . . . . . . . . . . .  3
   5  Security Considerations . . . . . . . . . . . . . . . . . . . .  4
   6  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   7  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . .  4


































 


Declan Ma, Ed.                 Expires 2015-10-15                  [Page 2]

INTERNET DRAFT       Reply Source Address Selection         2015-05-22


1  Introduction

   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
   eliciting the reply was sent.  This is true for servers acting as
   clients for the purposes of recursive query resolution, as well as
   simple resolver clients.  The address, along with the identifier (ID)
   in the reply is used for disambiguating replies, and filtering
   spurious responses.  This may, or may not, have been intended when
   the DNS was designed, but is now a fact of life.

   Some multi-homed hosts running DNS servers generate a reply using a
   source address that is not the same as the destination address from
   the client's request packet.  Such replies will be discarded by the
   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.

   This document is intended to describe IP packet header address usage
   from multi-homed DNS servers. 

2  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


3  UDP Source Address Selection

   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
   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
   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
   be sent from any legal IP address allocated to the server.  That
   address should be chosen to maximise the possibility that the client
   will be able to use it for further queries.  Servers configured in
   such a way that not all their addresses are equally reachable from
   all potential clients need take particular care when responding to
   queries sent to anycast, multicast, or similar, addresses.


4  Port Number Selection

   Replies to all queries must be directed to the port from which they
   were sent.  When queries are received via TCP this is an inherent
 


Declan Ma, Ed.                 Expires 2015-10-15                  [Page 3]

INTERNET DRAFT       Reply Source Address Selection         2015-05-22


   part of the transport protocol.  For queries received by UDP the
   server must take note of the source port and use that as the
   destination port in the response.  Replies should always be sent from
   the port to which they were directed.  Except in extraordinary
   circumstances, this will be the well known port assigned for DNS
   queries [RFC1700].

5  Security Considerations

   It is not believed that anything in this document adds to any
   security issues that may exist with the DNS, nor does it do anything
   to that will necessarily lessen them.  Correct implementation of the
   clarifications in this document might play some small part in
   limiting the spread of non-malicious bad data in the DNS, but only
   DNSSEC can help with deliberate attempts to subvert DNS data.


6  References

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.



7  Authors' Addresses


        Declan Ma, Ed.

        ZDNS Ltd.
        4, South 4th Street, Zhongguancun, 
        Haidian, Beijing 100190,
        China















Declan Ma, Ed.                 Expires 2015-10-15                  [Page 4]