Skip to main content

Method to pre-fetch Domain Names at HTTP Proxy Servers
draft-pchowdaiah-prefetch-dns-over-http-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Parikshith Chowdaiah
Last updated 2017-03-28
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-pchowdaiah-prefetch-dns-over-http-00
INTERNET-DRAFT                                               P.Chowdaiah
Intended Status: Experimental                          (ariksh software)
Expires: September 29, 2017                               March 28, 2017

        Method to pre-fetch Domain Names at HTTP Proxy Servers 
               draft-pchowdaiah-prefetch-dns-over-http-00

Abstract

   This specification offers an approach for augmenting domain name
   resolution times by intercepting HTTP responses at HTTP Proxy servers
   and triggering DNS queries to the servers in lieu of user requests
   and returning responses without an explicit requests from clients.
   This functionality can be achieved by multiple approaches at HTTP and
   Domain Name System [DNS] Protocols, this document specifies approach
   that shall be employed at HTTP protocol [RFC 2616].
   Methods/approaches pertaining to DNS shall be documented in [draft-
   pchowdaiah-dns-without-explicit-query.txt].

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) 2017 IETF Trust and the persons identified as the
   document authors. All rights reserved.
 

P.Chowdaiah            Expires September 29, 2017               [Page 1]
INTERNET DRAFT    Pre-fetch Domain Names at HTTP Proxy        March 2017

   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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Functionality Overview . . . . . . . . . . . . . . . . . . . .  3
   3. Detailed Specification  . . . . . . . . . . . . . . . . . . . .  5
     3.1. HTTP Header Fields  . . . . . . . . . . . . . . . . . . . .  6
     3.2. HTTP Request Header Fields  . . . . . . . . . . . . . . . .  6
       3.2.1. Dns-prefetch-over-http  . . . . . . . . . . . . . . . .  7
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
     5.1. Dns-prefetch-over-http  . . . . . . . . . . . . . . . . . .  7
   6.  Implementation Source Code . . . . . . . . . . . . . . . . . .  8
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  8
     7.3.  Notice . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9

 

P.Chowdaiah            Expires September 29, 2017               [Page 2]
INTERNET DRAFT    Pre-fetch Domain Names at HTTP Proxy        March 2017

1.  Introduction

   HTTP proxy servers have information that can be utilized to augment
   the resolution times of Domain names which could increase the speed
   of loading web pages on account of domain name resolution being pre
   resolved by the proxy servers and responses being sent before
   explicit requests from domain name clients. This document specifies a
   method to send DNS responses by pre-negotiating a time bound
   transport layer [TCP and UDP] connection and sending responses on
   this connection when HTTP Proxy server parses HTTP responses received
   for an earlier HTTP request. 

1.1.  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].

2.  Functionality Overview

   [Figure 1] shows high-level generic behavior in HTTP proxies, which
   is summarized here: A web Browser Client sends HTTP Protocol
   requests, (transport layer connections are not covered here), the
   request is received at Proxy, proxy interprets and parses requests
   into its internal data structures, forwards request to the
   destination server, on receiving responses from server, proxy updates
   internal data structures, might cache responses and forwards response
   back to Browser client.

 

P.Chowdaiah            Expires September 29, 2017               [Page 3]
INTERNET DRAFT    Pre-fetch Domain Names at HTTP Proxy        March 2017

    Client          HTTPProxy        DNSServer            HTTPServer      
    ---+---         ----+----        ---+-----            ----+-----
       |     ...        |               |                     |
       |                |               |                     |
       |--HTTPReq------>|               |                     |
       |                |[InternalData  |                     |
       |                | creation]     |                     | 
       |                |               |                     |
       |                |--Forward Request------------------->|
       |                |               |                     |
       |                |<--------------------------Response--|
       |                |[updateInternal|                     |
       |                |data]          |                     | 
       |                |               |                     |
       |<------FwdResp--|               |                     |
       |                |               |                     |
       |--DNSQuery (if any)------------>|                     | 
       |<------------------DNSResponse--|                     |
       |                |               |                     |
       |--HTTPReq------>|               |                     |
       |     ...        |               |                     |
       |                |               |                     |

                             [Figure 1]

   [Figure 2] shows overview of proposed approach: A web browser client
   sends HTTP Protocol requests, request is received at proxy, proxy
   parses the requests and does bookkeeping into its internal data
   structures, forwards request to destination server, on receiving
   responses from server, proxy parses responses and updates internal
   data structures and looks for domain name [RFC 1034] queries inside
   the responses and forwards it to proxy DNS resolver co-located with
   HTTP proxy implementations, then forwards the received HTTP responses
   to browsing client. On receiving the DNS query responses, DNS module
   co-located in the HTTP proxy module constructs agreed implementation
   specific responses towards the client on the transport layer
   connection known as 'DNS Pre-fetch Connection' henceforth with pre-
   negotiated port and protocol specified in the HTTP requests received
   from the browser client which could be configured or dynamically
   generated. The browser client then constructs the HTTP requests as
   per received DNS resolution and proceeds with its activities, thereby
   avoiding explicit DNS requests. Detailed procedure is documented in
   section "Detailed Specification"

 

P.Chowdaiah            Expires September 29, 2017               [Page 4]
INTERNET DRAFT    Pre-fetch Domain Names at HTTP Proxy        March 2017

    Client          HTTPProxy        DNSServer            HTTPServer      
    ---+---         ----+----        ---+-----            ----+-----
       |     ...        |               |                     |
       |                |               |                     |
       |    HTTPReq     |               |                     |
       |--WithHeaders-->|               |                     |
       |                |               |                     |
       |                |[InternalData  |                     |
       |                |creation,setup |                     | 
       |                |DNS Pre-fetch  |                     |
       |                |connection etc]|                     |
       |                |               |                     |
       |                |--Forward Request------------------->|
       |                |               |                     |
       |                |<--------------------------Response--|
       |                |               |                     |
       |                |[updateInternal|                     |
       |                |data, parse for|                     | 
       |                |DomainName     |                     |
       |                |send DNSQuery] |                     |
       |                |               |                     |
       |<------FwdResp--|--DNSQuery---->|                     |
       |                |<-DNSResponse--|                     |
       |                |               |                     | 
       |  SendDNSResp   |               |                     |
       |  onDNSPrefetch |               |                     |
       |<--Connection-- |               |                     |
       |                |               |                     |
       |--HTTPReq------>|               |                     |
       |     ...        |               |                     |
       |                |               |                     |

                              [Figure 2]

3. Detailed Specification

   Today most of the HTTP proxy designs either transparent or non-
   transparent probably are proprietary implementations that are based
   on the knowledge gained through experience and deployments. The
   approach presented here is also an outcome of this knowledge. Some of
   the HTTP proxy implementations have full knowledge of the HTTP
   request and responses as they snoop into the messages that are
   exchanged between the client and server. This document's approach is
   to use this information available at the proxies to augment the
   domain name resolution times by pre-requesting the DNS queries for
   domain names in the HTTP responses being exchanged, the proxy might
   cache responses if domain names are found to spill over-to next
 

P.Chowdaiah            Expires September 29, 2017               [Page 5]
INTERNET DRAFT    Pre-fetch Domain Names at HTTP Proxy        March 2017

   response packets. If the responses are encrypted then pre-requesting
   domain names shall be ignored and the responses are just forwarded.
   Here are the detailed steps that are involved:

   a. This functionality shall be controlled at the client side with
   configuration options which needs to be set to have this
   functionality communicated to the proxies through HTTP message header
   field. This new HTTP message header field are detailed in section
   [3.2]. New message headers contain magic security cookie, transport
   and network layer information on protocol, port, Internet protocol
   address, timeout for connection keep-alive  that client would listen
   on. The client would setup transport connections ('DNS Pre-fetch
   Connection') that it shall be listening on with parameters that it
   shall advertise. Network Address Translation (NAT)-Application Layer
   gateways (ALG) implementations shall need to be updated for the new
   functionality.

   b. Received HTTP request at the proxy is parsed, internal bookkeeping
   carried out, an optional implementation ACK can be sent back on the
   connection that client has advertised in item [a]. Received request
   is forwarded to destination server sans the header specific to this
   documented functionality. If destination server receives a request
   having the new HTTP message headers, it needs to do a no-operation on
   it as per [RFC 2616].

   c. On receiving HTTP response from the server, session identified by
   comparing the book kept data structures. Domain names are retrieved
   from the parsed responses, limited responses are cached if domain
   names span across multiple packets, domain names resolution is
   triggered to co-located DNS server. The HTTP responses is forwarded
   to the client.

   d. Domain query responses received from co-located DNS server is
   forwarded on the connection to the client. Agreement on format of the
   message that is exchanged would be implementation specific.
   Implementations shall define formats of message types and information
   that it needs to be exchanged over DNS-prefetch-connection.
   Approaches shall include either limited exchanging of specific
   information from query response or approaches described in [draft-
   pchowdaiah-dns-without-explicit-query.txt]

   e. Client with response received on the connection setup for this
   functionality shall use the domain name resolution information and
   send out new HTTP requests.

3.1. HTTP Header Fields

3.2. HTTP Request Header Fields
 

P.Chowdaiah            Expires September 29, 2017               [Page 6]
INTERNET DRAFT    Pre-fetch Domain Names at HTTP Proxy        March 2017

3.2.1. Dns-prefetch-over-http

   The Dns-prefetch-over-http request header field communicates
   connection parameters.

   Dns-prefetch-over-http  = "Dns-prefetch-over-http" ":"
                             1#( prefetch-params )

   prefetch-params = "magic-cookie" ";" "hostIpAddress" ";" "protocol"
                     ";" "port" ";"  "connection timeout"
                     ";"  "response timeout"

   where:

     magic-cookie       : dynamically generated session security 
                          authenticator
     hostIpAddress      : Internet protocol address of client
     protocol           : transport layer protocol TCP and UDP
     port               : the port socket listening on
     connection timeout : keep-alive timeout in seconds
     response timeout   : time client waits for pre-fetch DNS responses
                          before initiating standard DNS query

   Example of its usage:

    Dns-prefetch-over-http : MAGICCOOKIE;192.168.1.1;UDP;25001:60;500\r\n

4.  Security Considerations

   Any cookie related authentication mechanisms employed shall create
   security pitfalls. This proposed method shall not have any unknown
   security issues other than issues similarly identified for the HTTP
   standard cookie related HTTP header field though both are unrelated.

5.  IANA Considerations

   This specification being experimental shall not request any updates
   to any standard or registry. However upon review if this
   specification acquires standard status, this specification proposes
   and requests the following HTTP fields to be included in HTTP message
   header field registry [see RFC3864]:

5.1. Dns-prefetch-over-http

          Header field name: Dns-prefetch-over-http

          Applicable protocol: http
 

P.Chowdaiah            Expires September 29, 2017               [Page 7]
INTERNET DRAFT    Pre-fetch Domain Names at HTTP Proxy        March 2017

          Status: provisional

          Author/Change controller: this specification

          Specification document: this specification (Section 3.2.1)

6.  Implementation Source Code

   Proof-of-concept source code shall be available on github at this web
   link <TODO: add link after resolving open source, copyright license
   issues>

7.  References

7.1.  Normative References

      [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
                    RFC 793, September 1981.

      [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
                    "Uniform Resource Identifier (URI): Generic Syntax",
                    STD 66, RFC 3986, January 2005.

      [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
                    Transfer Protocol (HTTP/1.1): Semantics and Content",
                    RFC 7231, June 2014.

      [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                    Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
                    RFC 7234, June 2014.

      [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
                    Transfer Protocol (HTTP/1.1): Authentication",
                    RFC 7235, June 2014.

7.2.  Informative References

      [RFC1919]     Chatel, M., "Classical versus Transparent IP Proxies",
                    RFC 1919, March 1996.

      [RFC1945]     Berners-Lee, T., Fielding, R., and H. Nielsen,
                    "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
                    May 1996.

      [RFC2068]     Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
 

P.Chowdaiah            Expires September 29, 2017               [Page 8]
INTERNET DRAFT    Pre-fetch Domain Names at HTTP Proxy        March 2017

                    T. Berners-Lee, "Hypertext Transfer Protocol --
                    HTTP/1.1", RFC 2068, January 1997.

      [RFC2145]     Mogul, J., Fielding, R., Gettys, J., and H. Nielsen,
                    "Use and Interpretation of HTTP Version Numbers",
                    RFC 2145, May 1997.

      [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                    Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
                    Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

7.3.  Notice

   Please forward any comments and feedback to parikpub@gmail.com

Authors' Addresses

   Parikshith Chowdaiah
   ariksh software technologies
   1578/A, BSK II Stage
   Bangalore 560070
   India

   Email: parikpub@gmail.com

P.Chowdaiah            Expires September 29, 2017               [Page 9]