Differences between revisions 3 and 15 (spanning 12 versions)
Revision 3 as of 2005-12-01 13:28:38
Size: 8232
Editor: alpt
Comment: small example added
Revision 15 as of 2006-05-09 16:13:24
Size: 10406
Editor: anonymous
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
     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, in fact, the
  dns_wrapper deletes the .NTK/.INT suffix, therefore if we have an hname

  "cauchi.NTK"

  we can resolve it searching for "cauchi.NTK.NTK", and so on.
  Moreover the hname resolution is case sensitive, so there are no
  changes for the hname of this type: "xxxxx.ntk".

  For example "cauchi.ntk" is a complete hname and it will be resolved
  as a ntk-host.
  
  It is adviced to don't choose hnames ending in .NTK or .INT since it can
  create some confusion for the users.

  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 |
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  



                        ANDNS PROTOCOL

0. - INTRODUCTION -

   This document describes the protocol used to communicate with ANDNA.
   This protocol is used also to make query in internet realm.
   So, we can query for `google.it` in internet, or for `depausceve`
   in the netsukuku net.

   In the case of internet queries, the dns_wrapper will contact the
   dns-servers specified in /etc/resolv.conf when ntkd is loaded.

1. - NOTATIONS -

   In the next section, we represent a byte with this graphic:

         1 2 3 4 5 6 7 8
        +--+--+--+--+--+--+--+--+
        | |
        +--+--+--+--+--+--+--+--+

   The numbers represent the bits
   Let's show two bytes:

         1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        | | |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

2. - HEADERS -

  Headers are 4-byte long, and the format is:

        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        | ID |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |QR| P| QTYPE | ANCOUNT |I | NK| RCODE |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Line 166: Line 46:
   ID is a query identifier.
   QR=:
    - 0 in the case of question
    - 1 in the case of answer
        ID = It's a 2-byte value which identifies the query.
                   ID is choosed in a random way and the future
                   answers must have the same ID.

        QR = 0 implies that this packet contains a question
                   1 if the packets contains answers

        P = If the query is h2ip and ntk-related, P specifies
                   the protocol service:
                   0 for TCP
                   1 for UDP
                   P has to be zero otherwise.

        QTYPE = Query Type. See below.
                  Note: answers must leave this field unchanged.

        ANCOUNT = Answer Count. This field is set only if QR=1,
                  ie if this packet contains answers.
                  ANCOUNT is the number of answers which belongs
                  to this packet.

        I = Ip-version bit. Specifies the ip version for the
                  packet contents. All addresses contained in the
                  packet are:
                  if I==0 IPv4 addresses (4-bytes)
                  if I==1 Ipv6 addresses (16-bytes)
                  This bit is useful only for questions. The server
                  will reply "NO SUCH DOMAIN" if his node is running
                  with a different ip-version.
                  Otherwise, only IPs of the same family will be
                  returned.
                  
        NK = Netsukuku bit. With this field, you can specify
                  the query realm.
                  If NK=1, the realm is netsukuku.
                  If NK=2, the realm is internet.
                  If NK=0, the packet is not encoded with this
                  protocol, but with standard DNS protocol.
                  To specify realms with DNS protocol, see below.
                  Note: answers must leave this field unchanged.

        RCODE = This is the result of a query.
                  RCODE has to be 0 if this packet contains a
                  question.
                  In the case of errors, ANCOUNT has to be 0.

3. - QUERY TYPE -

  There are different kind of questions:

  QTYPE = 0
        This is the classic resolution `hostname -> ip`.
        A gethostbyname.
        Note: this type of query is used also for SNSD
        resolution (see `NTK_RFC 0009`).
        You can specify a service.
        So, the general way to represent this query is:

                hostname:service -> ip

        If you don't specify a service, the 0-service
        will be used.

        Example: if you want to discover which address is
        hosting the http service of hostname `depausceve`,
        you have to formule this query:

                depausceve:80

        See below how to formule queries.

  QTYPE = 1
        This is a reverse resolution: `ip -> host`.

4. - QUERY REALMS -

  A query can be formulated to find some object in the
  netsukuku net or in internet.
  Maybe you want to know the ip of `google.it`, but you
  have to specify where: internet or netsukuku?

  If you use ANDNS protocol, you specify this with NK
  bit (See the HEADERS SECTION).

  If you use DNS protocol, you have to formule the query
  with some suffix: if you ask for `google.it.int` (or
  google.it.INT), the question is made in internet.
  If you ask for `google.it.ntk` (or `google.it.NTK)
  the question is made in netsukuku.
  If you don't specify any suffix, the default realm
  is ****************************

  The dns_wrapper first search for a suffix, understanding
  the correct realm.
  If the question does not have any suffix, the query
  will be made in the default realm.
  Otherwise, dns_wrapper removes this suffix and
  resolves the query without it.

5. - RCODE -

  This is the answer report.
  It's always 0 if the packet carries a question.
  Possible values, in the case of an answer, are:

   RCODE = 0 No Error.
        This answer contains answers.
        The number of ANSWERS is ANCOUNT (see
        HEADERS SECTION).

   RCODE = 1 Interpretation Error.
        The server did not understand your query.
        In other words, your question is malformed.

   RCODE = 2 Server Fail.
        The server did encounter some error processing
        your question. Your question is good.

   RCODE = 3 No Such Domain
        The object of your question does not exist.

   RCODE = 4 Not Implemented
        This type of query is not implemented yet
        in this server.

   RCODE = 5 Refused
        The server refuse to talk with you.

  Note: this expression is always true:

                (RCODE XOR ANCOUNT)

  ie, if RCODE contains some error (RCODE!=0), there is
  not answer in this packet. If RCODE is 0 (no error),
  the packet contains some answer.

6. - QUESTIONS -

  There are three types of questions.
  We have to switch the value QTYPE against realm.

  - Case QTYPE = 0 (h2ip) AND Realm=NTK
    The format of the question is:

        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        | SERVICE |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        | |
        | |
        | |
        | HOSTNAME |
        | HASH |
        | (HH) |
        | |
        | |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

    where:

     SERVICE is a 2-byte field and represents the SNSD service
     value (see `NTK_RFC 0009`).

     HH is the 16-bytes hostname hash.

  - Case QTYPE = 0 (h2ip) AND Realm=INET
    The format of the question is:

        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        | SERVICE |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        | RDLENGTH |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        | |
        \ \
        \ RDATA \
        | |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

    where:

     SERVICE is a 2-byte field and represents the SNSD service
     value (see `NTK_RFC 0009`). At this moment, for INET
     resolutions, the service is limited to value 25
     - TCP is assumed - or 0.

     RDLENGTH is the RDATA len

     RDATA is a hostname string, such that:
                 strlen(RDATA)=RDLENGTH

  - Case QTYPE = 1 (ip2h).
    The format of the question is:

        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        | |
        / RDATA /
        / /
        | |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

    where:

     RDATA is an IP in the binary format.
     The length of the field - ie the family address (4 or 6) -
     depends on the bit `I' in the headers section.
Line 171: Line 252:
   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

7. - ANSWERS -

  The format of answers is:

  CASE QTYPE=0 (h2ip)

        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        | M| WG | PRIO |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        | |
        / RDATA /
        / /
        | |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where:
    
   M is set for the main IP of the resoliton (See `NTK_RFC 0009`)
     
   WG is the weigth of an answer (see `NTK_RFC 0009`)

   PRIO the priority (see `NTK_RFC 0009`)

   RDATA is a binary ip address, His family (and his length) is specified
         in the headers bit `I'.

  CASE QTYPE=1 (ip2h)

        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        | RDLENGTH |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        | |
        / RDATA /
        / /
        | |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where:

   RDLENGTH is the strlen of RDATA (RDATA is a hostname).

   RDATA the hostname resolution.

                        ANDNS PROTOCOL

0. - INTRODUCTION -

   This document describes the protocol used to communicate with ANDNA.
   This protocol is used also to make query in internet realm.
   So, we can query for `google.it` in internet, or for `depausceve`
   in the netsukuku net.

   In the case of internet queries, the dns_wrapper will contact the
   dns-servers specified in /etc/resolv.conf when ntkd is loaded.

1. - NOTATIONS -

   In the next section, we represent a byte with this graphic:

         1  2  3  4  5  6  7  8
        +--+--+--+--+--+--+--+--+
        |                       |
        +--+--+--+--+--+--+--+--+

   The numbers represent the bits
   Let's show two bytes:

         1  2  3  4  5  6  7  8  1  2  3  4  5  6  7  8
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |                       |                       |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

2. - HEADERS -

  Headers are 4-byte long, and the format is:

        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |                      ID                       |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |QR| P|  QTYPE |  ANCOUNT  |I |   NK|   RCODE   |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

  where:

        ID      =  It's a 2-byte value which identifies the query.
                   ID is choosed in a random way and the future
                   answers must have the same ID.

        QR      =  0 implies that this packet contains a question
                   1 if the packets contains answers

        P       =  If the query is h2ip and ntk-related, P specifies
                   the protocol service:
                   0 for TCP
                   1 for UDP
                   P has to be zero otherwise.

        QTYPE   = Query Type. See below.
                  Note: answers must leave this field unchanged.

        ANCOUNT = Answer Count. This field is set only if QR=1,
                  ie if this packet contains answers.
                  ANCOUNT is the number of answers which belongs
                  to this packet.

        I       = Ip-version bit. Specifies the ip version for the
                  packet contents. All addresses contained in the 
                  packet are:
                  if I==0    IPv4 addresses (4-bytes)
                  if I==1    Ipv6 addresses (16-bytes)
                  This bit is useful only for questions. The server 
                  will reply "NO SUCH DOMAIN" if his node is running
                  with a different ip-version.
                  Otherwise, only IPs of the same family will be 
                  returned.
                  
        NK      = Netsukuku bit. With this field, you can specify
                  the query realm.
                  If NK=1, the realm is netsukuku.
                  If NK=2, the realm is internet.
                  If NK=0, the packet is not encoded with this
                  protocol, but with standard DNS protocol.
                  To specify realms with DNS protocol, see below.
                  Note: answers must leave this field unchanged.

        RCODE   = This is the result of a query.
                  RCODE has to be 0 if this packet contains a
                  question.
                  In the case of errors, ANCOUNT has to be 0.

3. - QUERY TYPE -

  There are different kind of questions:

  QTYPE = 0
        This is the classic resolution `hostname -> ip`.
        A gethostbyname.
        Note: this type of query is used also for SNSD
        resolution (see `NTK_RFC 0009`).
        You can specify a service.
        So, the general way to represent this query is:

                hostname:service -> ip

        If you don't specify a service, the 0-service
        will be used.

        Example: if you want to discover which address is
        hosting the http service of hostname `depausceve`,
        you have to formule this query:

                depausceve:80

        See below how to formule queries.

  QTYPE = 1
        This is a reverse resolution: `ip -> host`.

4. - QUERY REALMS -

  A query can be formulated to find some object in the
  netsukuku net or in internet.
  Maybe you want to know the ip of `google.it`, but you
  have to specify where: internet or netsukuku?

  If you use ANDNS protocol, you specify this with NK
  bit (See the HEADERS SECTION).

  If you use DNS protocol, you have to formule the query
  with some suffix: if you ask for `google.it.int` (or
  google.it.INT), the question is made in internet.
  If you ask for `google.it.ntk` (or `google.it.NTK)
  the question is made in netsukuku.
  If you don't specify any suffix, the default realm
  is ****************************

  The dns_wrapper first search for a suffix, understanding
  the correct realm.
  If the question does not have any suffix, the query
  will be made in the default realm.
  Otherwise, dns_wrapper removes this suffix and
  resolves the query without it.

5. - RCODE -

  This is the answer report.
  It's always 0 if the packet carries a question.
  Possible values, in the case of an answer, are:

   RCODE = 0 No Error.
        This answer contains answers.
        The number of ANSWERS is ANCOUNT (see
        HEADERS SECTION).

   RCODE = 1 Interpretation Error.
        The server did not understand your query.
        In other words, your question is malformed.

   RCODE = 2 Server Fail.
        The server did encounter some error processing
        your question. Your question is good.

   RCODE = 3 No Such Domain
        The object of your question does not exist.

   RCODE = 4 Not Implemented
        This type of query is not implemented yet
        in this server.

   RCODE = 5 Refused
        The server refuse to talk with you.

  Note: this expression is always true:

                (RCODE XOR ANCOUNT)

  ie, if RCODE contains some error (RCODE!=0), there is
  not answer in this packet. If RCODE is 0 (no error),
  the packet contains some answer.

6. - QUESTIONS -

  There are three types of questions.
  We have to switch the value QTYPE against realm.

  - Case QTYPE = 0 (h2ip) AND Realm=NTK
    The format of the question is:

        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |                    SERVICE                    |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |                                               |       
        |                                               |       
        |                                               |
        |                   HOSTNAME                    |
        |                     HASH                      |
        |                     (HH)                      |
        |                                               |
        |                                               |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

    where:

     SERVICE is a 2-byte field and represents the SNSD service
     value (see `NTK_RFC 0009`).

     HH is the 16-bytes hostname hash.

  - Case QTYPE = 0 (h2ip) AND Realm=INET
    The format of the question is:

        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |                   SERVICE                     |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |                   RDLENGTH                    |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |                                               |
        \                                               \
        \                    RDATA                      \
        |                                               |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

    where:

     SERVICE is a 2-byte field and represents the SNSD service
     value (see `NTK_RFC 0009`). At this moment, for INET 
     resolutions, the service is limited to value 25 
     - TCP is assumed - or 0.

     RDLENGTH is the RDATA len

     RDATA is a hostname string, such that:
                 strlen(RDATA)=RDLENGTH

  - Case QTYPE = 1 (ip2h).
    The format of the question is:

        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |                                               |
        /                     RDATA                     /
        /                                               /
        |                                               |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

    where:

     RDATA is an IP in the binary format.
     The length of the field - ie the family address (4 or 6) -
     depends on the bit `I' in the headers section. 
   

7. - ANSWERS -

  The format of answers is:

  CASE QTYPE=0    (h2ip)   

        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        | M|        WG          |       PRIO            |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |                                               |
        /                     RDATA                     /
        /                                               /
        |                                               |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where:
    
   M is set for the main IP of the resoliton (See `NTK_RFC 0009`)
     
   WG is the weigth of an answer (see `NTK_RFC 0009`)

   PRIO the priority (see `NTK_RFC 0009`)

   RDATA is a binary ip address, His family (and his length) is specified
         in the headers bit `I'.

  CASE QTYPE=1   (ip2h)

        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |                    RDLENGTH                   |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        |                                               |
        /                     RDATA                     /
        /                                               /
        |                                               |
        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   where:

   RDLENGTH is the strlen of RDATA (RDATA is a hostname).

   RDATA the hostname resolution.

Ntk_andna_and_dns (last edited 2008-06-26 09:50:34 by anonymous)