INTERNET-DRAFT                                                Yuming Huang
Expires: January 1, 2010                                AT&T Labs
                                                                                June 2009



                DNS Encoding of Domain Reputation and IP# Classification
                                draft-huang-dnsext-reputation-00.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/ietf/1id-abstracts.txt.

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

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.


Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


Abstract

This document defines the format of a new Resource Record (RR) for
the Domain Naming System (DNS), (and reserves a corresponding DNS type
mnemonic: DRIC and numerical code - to be done)  This definition deals
with associating a reputation measure to a domain, a host name, or a url
before domain name resolution. It also deals with associating a classification
of the result ip# after domain name resolution. The data shown in this document
is fictitious and does not necessarily reflect the real Internet.

. Introduction

Online fraud, site spoofing, pharming and phishing are growing by leaps and bounds,and eroding consumer trust in online transaction security. User protection mechanism(Anti-phishing, etc.) is implemented by web browsers or browser plug-ins (toolbar etc).
Compared to the existing mechanisms, a more and maybe the most effective mechanism is to bind the domain reputation and IP# classification measures with the DNS lookup.
When a client (web browser or plug-in) wants a DNS server to resolve a domain name (host name, url) into ip#, the client received the ip# as well as the security info about the ip# and the domain name (host name, url).  Therefore, a Resource Record (RR), Domain Reputation and IP# Classification (DRIC), are recommended as an extension to the existing DNS protocol.



. RDATA Format

                                                  1  1  1  1  1  1
         0   1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |  Reputation             |  Classification       |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


   where:

   Reputation is a byte integer which encodes a reputation measure for a string (domain name, host name, or URL) sent by a DNS client to a DNS server to resolve. The DNS server acquires the reputation measure from various resources: the Resource Record (RR) of its DNS database, a further query to another DNS server to resolve the string whose answer may have the reputation measure, or a communication a clustered server which holds and looks up a blacklist against the string from the DNS client. The value of the byte is agreed upon by client and server. For example, 1 means the string is a hit on the blacklist, while 0 is not a hit. We define 2 as that the host name is a part of a URL which is a hit on the blacklist although the host name is not a hit. This is meaningful because many URLs (web pages) may share  a same host name and DNS server only holds reputation and classification as well as an ip# for a host name. If we know all the URLs are "good", we just tell DNS client "No-Hit" for all the URLs sharing the same host name. On the other hand, if some  URLs are "bad", the string from DNS client should be matched with the blacklist(which is done on a clustered security server).

   The reputation measure may come from a third party DNS server if the string from DNS client can not be resolved by this server. However, if an organization or an ISP want to protect its users based on most authentic and updated blacklist and other info, the org should have a clustered (with DNS server) server which handles blacklist and updates RR.

   Classification is a byte integer which encodes classification of ip#. For example, zombie ip#; dynamic ip# vs. static ip#; business ip# vs. home ip#. Similar to reputation,  a clustered security server handle ip# classification and updates RR. For those ip# not resolved on this DNS server, the clustered security server looks up ip# for its classification and informs DNS server the result. The DNS server sends back the classification byte as well as the reputation byte to its DNS client.


. The DRIC RR

   The Domain Reputation and IP# Classification is defined with the mnemonic DRIC and type code XX (to be determined).

   DRIC has the following format:
           <owner> <ttl> <class> DRIC <Reputation Byte> <Classification Byte>


. Master File Format

   Each host requires its own DRIC field (byte integer) in the corresponding DNS RR to explicitly specify its Domain Reputation and IP# Classification.  If the DRIC field is omitted, a DNS inquiry will return the value from the clustered security server lookup.

   Consider the following example:

; Authoritative data for lisle.labs.att.com.
;
@     IN    SOA   ns1.lisle.labs.att.com.
                (
                        94070503        ; Serial (yymmddnn)
                        10800           ; Refresh (3 hours)
                        3600            ; Retry (1 hour)
                        3600000         ; Expire (1000 hours)
                        86400           ; Minimum (24 hours)
                )

                IN      NS      ns1.lisle.labs.att.com.

ns1             IN      A       10.1.1.1
                IN      DRIC    0 0
machine1        IN      A       135.1.1.2
                IN      DRIC    2 0

machine2        IN      A       135.1.1.23
                IN      DRIC    1 1

machine3        IN      A       135.1.1.24

machine4        IN      A       135.7.1.99
                IN      DRIC    0 1



Note:
A generic form of URL is        protocol://userid:password@hostname(ip#):port/path?parameter#anchor

Reference:
http://tools.ietf.org/html/rfc1034
http://tools.ietf.org/html/rfc1035
http://tools.ietf.org/html/rfc1712
http://tools.ietf.org/html/rfc1876
http://tools.ietf.org/html/rfc3596
http://tools.ietf.org/html/rfc4398





Editor's Address

Yuming Huang
 Meadowridge Dr.
Aurora IL 60504, US
+1-630-810-7856
yuming@att.com