NETSUKUKU AND HOSTNAMES RESOLUTION:
                On Andna, dns and internet


1. INTRODUCTION

  The actual Domain Name System is a hierarchic structure. Protocols
  and architectures are builded with this consciousness.
  The inheritance is a strongly limited system, if compared with the 
  Ntk capabilities.
  It's easy to show some examples:
        - DNS is case insensitive
        - DNS hnames are limited to be a sequence of labels, separated
          with DOTs. Each label must be such that: strlen(label)<64.
        - CNAME, SOA, are a pain in the ass.
        - The DOT is elected to be a special char.
  
  So, it's a good idea to provide a new standard, bypassing actual
  limits. We will define a new way to query hnames.

  With the new standard, the hnames policies will be more flexible and
  free: sure, we have to forbid some char, like '/', which, for 
  example, could create trivial incompatibilities.
  But for hname policies, the principal work is to define a new 
  charset. And, sure, to choose a limit length for hnames. 
  That's all!
  
  From another point of view, the new standard has to be dns-compliant
  enough: the destiny of Ntk is strongly dependent on a beginning 
  internet coexistance.

  The goal of this document is to propose a standard of this kind.
  

2. DEFINITIONS
 
  - We define `old-style client', a hname resolver which formule its
  queries in the way of actual dns protocols.
  - We define `new-style client', a hname resolver which formule its
  queries in the new standard format.

2. ON INTERNET AND NTK COEXISTANCE

  At the begin, old-style clients should be able to formule queries and
  to obtain the desired resolution.
  Old-style clients, anyway, will be limited to query only hnames which
  respect actual dns-policies.
  This is not a created limit: also in the case Ntk decides to 
  respect these policies, old-style clients won't be more capable!
  This is simply a limit imposed on the actual hnames-structure: it's 
  not possible to overpass it.

  New-style clients could formule general queries. They will be able
  to look for the hname "....depou...sceve..." as the hname "frenzu.org".         

  If Ntk and internet will be integrated, each query could be 
  ntk-related or internet related: i.e., are we searching for a ntk-host
  or a internet-host?
  So, new-style clients, and old-style clients too, will be able to choose 
  the resolution domain.
  How?
  To resolve a ntk-host, say HNAME, we will ask for HNAME.NTK.
  To resolve the same host, but searching it in internet, we will
  ask for HNAME.INT.
  If both extension are absent, .NTK will be assumed.
  Note: in theory, this doesn't limit hname policies; the ntk-host:

  "cauchi.NTK"

  could be resolved searching for "cauchi.NTK.NTK", and so on.
  But it would be a good idea to forbid these possibilities.

  The compatibility of different kind of queries is guaranteed from
  dns_wrapper: if you are in Ntk, 
  
  # echo "nameserver 127.0.0.1" > /etc/resolv.conf

  the dns_wrapper will be listening on 127.0.0.1:53udp , and it will be
  able to interpret old-style and new-style queries, and to answer
  in both ways.
  If a query is INT-related, it will forward the request to some 
  dns-server.
  In the case of ntk-queries, it will intarface directly with ANDNA.


3. THE NEW RULES

3.1. ALLOWED QUERIES

  - The allowed queries in Ntk will be:
   1- hname ---> ip
   2- ip ---> hname
   3- hname ---> mx
   4- ip ---> mx ( 2 && 3)
  
3.2. HNAME LENGTH 

  For each ntk-hname HNAME:
   - strlen(HNAME)<256

3.3. NO MULTIPLE QUERIES

  In actual dns, a query can transport multiple questions or multiple
  answers. In Ntk:
   - Each query is a unique question or a unique answer.

  This is not a net-overload: nameserver=127.0.0.1!
 
4. THE BORN

4.1 THE HEADERS

  We have to preserve a little the actual dns protocols to obtain a 
  sufficient compatibility between Ntk and Internet.
  Actual dns-headers are:

                                   0  1  2  3  4  5
     0  1  2  3  4  5  6  7  8  9  1  1  1  1  1  1
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                      ID                       |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    QDCOUNT                    |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    ANCOUNT                    |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    NSCOUNT                    |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    ARCOUNT                    |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

  where the 3-bits field Z is unused, and always set to 0.
  This is a important field ;)

  We can discard the following fields:
   QDCOUNT,ANCOUNT,NSCOUNT,ARCOUNT
    - no multiple questions or answer are permitted (3.3).
    - Authority section is a pain on the ass
    - Additional info? No thanks, no CNAME, no SOA, no AUTH.

  Z becomes the NK field: if NK=1, the query is a new-style
  query.

  The new protocol will be:

                                   0  1  2  3  4  5
     0  1  2  3  4  5  6  7  8  9  1  1  1  1  1  1
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                      ID                       |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |QR|   QTYPE   |                 |NK|   RCODE   |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  
  where:

   ID is a query identifier.
   QR=:
    - 0 in the case of question
    - 1 in the case of answer
   
   Qtype is the query-type.
   QTYPE=:         
    - 0  querytype = hname-->ip
    - 1  querytype = ip-->hname
    - 2  querytype = hname-->mx
    - 3  querytype = ip-->mx

   NK is the query-style identifier.
   NK=:
    - 0 in the case of a old-style query (in this case NK=Z, 
         which is always 0)
    - 1 in the case of a new-style query.
   Note: in the case of NK=0, the query has to be formatted in the 
   old-style way, otherwise the dns_wrapper will refuse to read it.

   Rcode is the response code of an answer, it's dns-compliant.
   RCODE=:
    - 0 = No error
    - 1 = Format error: name server was unable to
          interpret the query
    - 2 = name server internal failure (problem)
    - 3 = domain does not exist
    - 4 = Not implemented
    - 5 = Refused
                                                        

  The empty fields in new protocol headers could be useful in future.
  New protocol header size is always 4, in bytes.
  Let's define:

  #define DN_ANDNA_HDR_SZ 4
  
  
4.1 THE CONTENTS

  The contents of new protocol-pkts could be as we prefere.
  This is, imho, a good and flexible proposition:

                                   0  1  2  3  4  5
     0  1  2  3  4  5  6  7  8  9  1  1  1  1  1  1
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                    RDLENGTH                   |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |                                               |
   /                     RDATA                     /
   /                                               /
   |                                               |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                 
  where rdlength is a u_int16_t, such that
   - RDLENGTH=sizeof(RDATA)
  
  and RDATA is the true pkt content.
  The RDLENGTH limits, and so the RDATA limit, will be defined in the
  future, when an ANDNA interface will be ready for the dns_wrapper.
  Now, this format guarantee a general way for every data transmission.
  The data type will be determined from headers fields.

  efphe, AlpT