{{{ 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 }}}