Differences between revisions 2 and 4 (spanning 2 versions)
Revision 2 as of 2006-02-05 15:26:29
Size: 8017
Editor: anonymous
Comment:
Revision 4 as of 2008-06-26 09:53:17
Size: 8015
Editor: anonymous
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
  and architectures are builded with this consciousness.   and architectures are built with this consciousness.

            NETSUKUKU AND HOSTNAMES RESOLUTION:
                On Andna, dns and internet


1. INTRODUCTION

  The actual Domain Name System is a hierarchic structure. Protocols
  and architectures are built 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,NSCOUNT,ARCOUNT
    - no multiple questions 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   |  ANCOUNT  |  |  NK |   RCODE   |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  
  where:

   ID is a query identifier.
   QR=:
    - 0 -> this is a question
    - 1 -> this is an 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 this is a old-style query, dns compliant. 
               Realm is specified with suffixes: 
                       .INT for internet
                       .NTK for Netsukuku
    - 1 this is a new-style query, in the netsukuku realm
    - 2 this is a new-style query, in the internet realm

   ANCOUNT=: the number of answers to the question. 
             In the case of QR=0 (this is a question) ANCOUNT must be 0.
                 
   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

Andna_and_dns (last edited 2008-06-26 09:53:17 by anonymous)