C
Das DNS Protokoll
Nachdem ich außerhalb des RFC 1035 weder auf deutsch noch auf englisch eine vernünftige Beschreibung des DNS-Protokolls finden konnte, werde ich hier versuchen, anderen das Vergnügen dieses RFC quasi ohne Überblick lesen zu müssen zu ersparen.
Dieses Tutorial wird sich auf das Protokoll selbst beschränken, allgemeine Informationen können z.B. bei Wikipedia oder anderen Seiten eingeholt werden.
DNS läuft über Port 53 und unterstützt sowohl TCP als auch UDP. Laut dem RFC sollen für kleine Anfragen UDP genutzt werden. (Weniger Overhead.)
Interessant dazu auch:
2.3.4. Size limits
Various objects and parameters in the DNS have size limits. They are
listed below. Some could be easily changed, others are more
fundamental.
labels 63 octets or less
names 255 octets or less
TTL positive values of a signed 32 bit number.
UDP messages 512 octets or less
Jede Nachricht innerhalb des DNS-Protokolls ist folgendermaßen aufgebaut:
4.1. Format
[...]
+---------------------+
| Header |
+---------------------+
| Question | the question for the name server
+---------------------+
| Answer | RRs answering the question
+---------------------+
| Authority | RRs pointing toward an authority
+---------------------+
| Additional | RRs holding additional information
+---------------------+
Bis auf den Header der Nachricht ist kein Teil zwingend vorhanden, welche vorhanden sind, wird im Header angegeben.
Der Header ist dabei folgendermaßen aufgebaut: (Die exakte Beschreibung wird an dieser Stelle übersprungen und ist weiter unten nachzulesen.)
4.1.1. Header section format
The header contains the following fields:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID | // Wird in die Antwort kopiert, um mehrere separate Anfragen unterscheiden zu können.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE | // Flags, siehe weiter unten in der genauen Beschreibung.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT | // Anzahl der Anfragen
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT | // Anzahl der Antworten.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT | // ...
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT | // ...
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Die "Question section" so: (Genaue Beschreibung wieder unten.)
4.1.2. Question section format
The question section is used to carry the "question" in most queries,
i.e., the parameters that define what is being asked. The section
contains QDCOUNT (usually 1) entries, each of the following format:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | // Hier steht die URL, deren IP wir wissen wollen.
/ QNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE | // Siehe unten
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS | // Siehe unten
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Und die drei restlichen Teile so: (Genaue Beschreibung wieder unten.)
4.1.3. Resource record format
The answer, authority, and additional sections all share the same
format: a variable number of resource records, where the number of
records is specified in the corresponding count field in the header.
Each resource record has the following format:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | // Hier steht, auf welche Anfrage sich die Antwort bezieht.
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE | // Siehe unten
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS | // Siehe unten
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL | // Siehe unten
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH | // Länge des RDATA Feldes.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA / // Was hier steht, hängt mit "Type" oben zusammen. Die wichtigsten Types sind dabei A (IPv4 Adresse)
/ / // und CNAME ("Normalform" für angefragten Namen, z.B. www.l.google.com ).
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Besonders interessant ist dabei der Aufbau der Namenssektionen. (Originalbeschreibung siehe unten.)
Der Name wird in "Label" unterteilt, konkret sind das einfach die Punkte der URL. Vor ein solches Label wird seine Größe geschrieben. (1 Byte)
Aus "www.henkessoft.de" wird so: "\x03www\x0Ahenkessoft\0x02de". (Man beachte das wichtige, nur bei C automatisch hinzugefügte letzte Nullbyte. Mit diesem wird ein Name abgeschlossen.)
Doch das war nicht alles. Um die Nachrichten klein zu halten, werden noch Pointer genutzt. Da ein Label nicht mehr als 63 Elemente umfassen kann, sind die ersten zwei Bit des "Längen"-Byte immer 0. Sind beide 1, liegt ein Pointer vor. Die anderen sechs Bit zusammen mit den 8 Bit des nächsten Byte bilden dabei einen Pointer auf ein anderes Label. (Es wird immer solange weiter gelesen, bis ein Nullbyte gefunden wurde.)
("Pointer" heißt hier, dass der Wert auf den Nachrichtenursprung addiert und von da an weiter gelesen wird.)
Es folgen die Originalbeschreibungen (RFC 1035) für die Teile des Protokolls, die für eine Simple Anfrage nötig sind. Danach folgt eine "von Hand" ausgerechnete Beispielanfrage und Antwort.
4.1.1. Header section format
The header contains the following fields:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ID A 16 bit identifier assigned by the program that
generates any kind of query. This identifier is copied
the corresponding reply and can be used by the requester
to match up replies to outstanding queries.
QR A one bit field that specifies whether this message is a
query (0), or a response (1).
OPCODE A four bit field that specifies kind of query in this
message. This value is set by the originator of a query
and copied into the response. The values are:
0 a standard query (QUERY)
1 an inverse query (IQUERY)
2 a server status request (STATUS)
3-15 reserved for future use
AA Authoritative Answer - this bit is valid in responses,
and specifies that the responding name server is an
authority for the domain name in question section.
Note that the contents of the answer section may have
multiple owner names because of aliases. The AA bit
corresponds to the name which matches the query name, or
the first owner name in the answer section.
TC TrunCation - specifies that this message was truncated
due to length greater than that permitted on the
transmission channel.
RD Recursion Desired - this bit may be set in a query and
is copied into the response. If RD is set, it directs
the name server to pursue the query recursively.
Recursive query support is optional.
RA Recursion Available - this be is set or cleared in a
response, and denotes whether recursive query support is
available in the name server.
Z Reserved for future use. Must be zero in all queries
and responses.
RCODE Response code - this 4 bit field is set as part of
responses. The values have the following
interpretation:
0 No error condition
1 Format error - The name server was
unable to interpret the query.
2 Server failure - The name server was
unable to process this query due to a
problem with the name server.
3 Name Error - Meaningful only for
responses from an authoritative name
server, this code signifies that the
domain name referenced in the query does
not exist.
4 Not Implemented - The name server does
not support the requested kind of query.
5 Refused - The name server refuses to
perform the specified operation for
policy reasons. For example, a name
server may not wish to provide the
information to the particular requester,
or a name server may not wish to perform
a particular operation (e.g., zone
transfer) for particular data.
6-15 Reserved for future use.
QDCOUNT an unsigned 16 bit integer specifying the number of
entries in the question section.
ANCOUNT an unsigned 16 bit integer specifying the number of
resource records in the answer section.
NSCOUNT an unsigned 16 bit integer specifying the number of name
server resource records in the authority records
section.
ARCOUNT an unsigned 16 bit integer specifying the number of
resource records in the additional records section.
4.1.2. Question section format
The question section is used to carry the "question" in most queries,
i.e., the parameters that define what is being asked. The section
contains QDCOUNT (usually 1) entries, each of the following format:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ QNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QTYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QCLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
QNAME a domain name represented as a sequence of labels, where
each label consists of a length octet followed by that
number of octets. The domain name terminates with the
zero length octet for the null label of the root. Note
that this field may be an odd number of octets; no
padding is used.
QTYPE a two octet code which specifies the type of the query.
The values for this field include all codes valid for a
TYPE field, together with some more general codes which
can match more than one type of RR.
QCLASS a two octet code that specifies the class of the query.
For example, the QCLASS field is IN for the Internet.
4.1.3. Resource record format
The answer, authority, and additional sections all share the same
format: a variable number of resource records, where the number of
records is specified in the corresponding count field in the header.
Each resource record has the following format:
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| |
/ /
/ NAME /
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| CLASS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| TTL |
| |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| RDLENGTH |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/ RDATA /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NAME a domain name to which this resource record pertains.
TYPE two octets containing one of the RR type codes. This
field specifies the meaning of the data in the RDATA
field.
CLASS two octets which specify the class of the data in the
RDATA field.
TTL a 32 bit unsigned integer that specifies the time
interval (in seconds) that the resource record may be
cached before it should be discarded. Zero values are
interpreted to mean that the RR can only be used for the
transaction in progress, and should not be cached.
RDLENGTH an unsigned 16 bit integer that specifies the length in
octets of the RDATA field.
RDATA a variable length string of octets that describes the
resource. The format of this information varies
according to the TYPE and CLASS of the resource record.
For example, the if the TYPE is A and the CLASS is IN,
the RDATA field is a 4 octet ARPA Internet address.
3.2.2. TYPE values
TYPE fields are used in resource records. Note that these types are a
subset of QTYPEs.
TYPE value and meaning
A 1 a host address
NS 2 an authoritative name server
MD 3 a mail destination (Obsolete - use MX)
MF 4 a mail forwarder (Obsolete - use MX)
CNAME 5 the canonical name for an alias
SOA 6 marks the start of a zone of authority
MB 7 a mailbox domain name (EXPERIMENTAL)
MG 8 a mail group member (EXPERIMENTAL)
MR 9 a mail rename domain name (EXPERIMENTAL)
NULL 10 a null RR (EXPERIMENTAL)
WKS 11 a well known service description
PTR 12 a domain name pointer
HINFO 13 host information
MINFO 14 mailbox or mail list information
MX 15 mail exchange
TXT 16 text strings
3.2.3. QTYPE values
QTYPE fields appear in the question part of a query. QTYPES are a
superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the
following QTYPEs are defined:
AXFR 252 A request for a transfer of an entire zone
MAILB 253 A request for mailbox-related records (MB, MG or MR)
MAILA 254 A request for mail agent RRs (Obsolete - see MX)
* 255 A request for all records
3.2.4. CLASS values
CLASS fields appear in resource records. The following CLASS mnemonics
and values are defined:
IN 1 the Internet
CS 2 the CSNET class (Obsolete - used only for examples in
some obsolete RFCs)
CH 3 the CHAOS class
HS 4 Hesiod [Dyer 87]
3.2.5. QCLASS values
QCLASS fields appear in the question section of a query. QCLASS values
are a superset of CLASS values; every CLASS is a valid QCLASS. In
addition to CLASS values, the following QCLASSes are defined:
* 255 any class
3.3. Standard RRs
The following RR definitions are expected to occur, at least
potentially, in all classes. In particular, NS, SOA, CNAME, and PTR
will be used in all classes, and have the same format in all classes.
Because their RDATA format is known, all domain names in the RDATA
section of these RRs may be compressed.
<domain-name> is a domain name represented as a series of labels, and
terminated by a label with zero length. <character-string> is a single
length octet followed by that number of characters. <character-string>
is treated as binary information, and can be up to 256 characters in
length (including the length octet).
3.3.1. CNAME RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ CNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
CNAME A <domain-name> which specifies the canonical or primary
name for the owner. The owner name is an alias.
CNAME RRs cause no additional section processing, but name servers may
choose to restart the query at the canonical name in certain cases. See
the description of name server logic in [RFC-1034] for details.
[...]
3.4. Internet specific RRs
3.4.1. A RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS A 32 bit Internet address.
Hosts that have multiple Internet addresses will have multiple A
records.
3.1. Name space definitions
Domain names in messages are expressed in terms of a sequence of labels.
Each label is represented as a one octet length field followed by that
number of octets. Since every domain name ends with the null label of
the root, a domain name is terminated by a length byte of zero. The
high order two bits of every length octet must be zero, and the
remaining six bits of the length field limit the label to 63 octets or
less.
To simplify implementations, the total length of a domain name (i.e.,
label octets and label length octets) is restricted to 255 octets or
less.
Although labels can contain any 8 bit values in octets that make up a
label, it is strongly recommended that labels follow the preferred
syntax described elsewhere in this memo, which is compatible with
existing host naming conventions. Name servers and resolvers must
compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
with zero parity. Non-alphabetic codes must match exactly.
4.1.4. Message compression
In order to reduce the size of messages, the domain system utilizes a
compression scheme which eliminates the repetition of domain names in a
message. In this scheme, an entire domain name or a list of labels at
the end of a domain name is replaced with a pointer to a prior occurance
of the same name.
The pointer takes the form of a two octet sequence:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| 1 1| OFFSET |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The first two bits are ones. This allows a pointer to be distinguished
from a label, since the label must begin with two zero bits because
labels are restricted to 63 octets or less. (The 10 and 01 combinations
are reserved for future use.) The OFFSET field specifies an offset from
the start of the message (i.e., the first octet of the ID field in the
domain header). A zero offset specifies the first byte of the ID field,
etc.
The compression scheme allows a domain name in a message to be
represented as either:
- a sequence of labels ending in a zero octet
- a pointer
- a sequence of labels ending with a pointer
Pointers can only be used for occurances of a domain name where the
format is not class specific. If this were not the case, a name server
or resolver would be required to know the format of all RRs it handled.
As yet, there are no such cases, but they may occur in future RDATA
formats.
If a domain name is contained in a part of the message subject to a
length field (such as the RDATA section of an RR), and compression is
used, the length of the compressed name is used in the length
calculation, rather than the length of the expanded name.
Programs are free to avoid using pointers in messages they generate,
although this will reduce datagram capacity, and may cause truncation.
However all programs are required to understand arriving messages that
contain pointers.
For example, a datagram might need to use the domain names F.ISI.ARPA,
FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the
message, these domain names might be represented as:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | 1 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 | 3 | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 | S | I |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 | 4 | A |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28 | R | P |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
30 | A | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40 | 3 | F |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42 | O | O |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44 | 1 1| 20 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
64 | 1 1| 26 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
92 | 0 | |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The domain name for F.ISI.ARPA is shown at offset 20. The domain name
FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
concatenate a label for FOO to the previously defined F.ISI.ARPA. The
domain name ARPA is defined at offset 64 using a pointer to the ARPA
component of the name F.ISI.ARPA at 20; note that this pointer relies on
ARPA being the last label in the string at 20. The root domain name is
defined by a single octet of zeros at 92; the root domain name has no
labels.
Anmerkung: Bei dem Versenden von Nachrichten auf die "Host-Byteorder" achten, soll heißen, alle Zahlen werden im Big-Endian Format gesendet. Die IP-Adresse ist hier nicht als Zahl zu sehen und muss deshalb auch nicht umgewandelt werden.
+ Eine sehr einfache Implementierung des Protokolls kann im PrettyOS Sourcecode gefunden werden: "Source/user/user-tools/dns.c | dns.h | dns_help.c | dns_help.h"
Beispiel-Anfrage auf www.google.com
Erster Schritt: Nachrichten-Header erstellen
- ID: Die ID ist hier eigentlich egal, wir nehmen als Beispiel 1911. Die binäre Darstellung der beiden Bytes wäre dann: 0000-0111 0111-0111. (Hier schon Big-Endian).
- Flags:
QR: Da wir eine Anfrage schicken, ist dieses Bit 0.
OPCODE: Da wir eine normale Anfrage schicken, 0000.
AA: Nur für Antworten wichtig, daher 0.
TC: Wir senden eine kleine Nachricht, daher 0. (Nicht truncated.)
RD: Wir möchten, dass der DNS-Server für uns rekursive Aufrufe macht, daher 1.
RA: Nur für Antworten wichtig, daher 0.
Z: Reserviert, daher 000.
RCODE: Nur für Antworten wichtig, daher 0000.
Zusammen ergibt das (Big-Endian): 0-0000-0-0-1-0-000-0000, dec: 256.
- QDCOUNT:
Da wir eine Anfrage haben, 1. (0000-0000 0000-0001)
- ANCOUNT:
- NSCOUNT:
- ARCOUNT:
Alle 0. (0000-0000 0000-0000)
Zusammenfassung Header:
ID: 0000-0111 0111-0111 (1911)
FLAGS: 0000-0001 0000-0000 (256)
QDCOUNT: 0000-0000 0000-0001 (1)
ANCOUNT: 0000-0000 0000-0000 (0)
NSCOUNT: 0000-0000 0000-0000 (0)
ARCOUNT: 0000-0000 0000-0000 (0)
Zweiter Schritt: Anfrage erstellen
- QNAME
Zuerst muss der Name in die richtige Form gebracht werden. "www.google.com" Wird also zu: "\x03www\x06google\x03com". In hex:
03 77 77 77 06 67 6F 6F 67 6C 65 03 63 6F 6D 00
- QTYPE: Wir möchten eine IPv4 Adresse, also Type A. (1)
- QCLASS: Im Internet, also Class IN. (1).
Zusammenfassung Anfrage:
QNAME: 0000-0011 (3) 0111-0111 (119)
0111-0111 (119) 0111-0111 (119)
0000-0110 (6) 0110-0111 (103)
0110-1111 (111) 0110-1111 (111)
0110-0111 (103) 0110-1100 (108)
0110-0101 (101) 0000-0011 (3)
0110-0011 (99) 0110-1111 (111)
0110-1101 (109) 0000-0000 (0) // Nullbyte nicht vergessen.
QTYPE: 0000-0000 (0) 0000-0001 (1)
QCLASS: 0000-0000 (0) 0000-0001 (1)
So, das muss jetzt nur noch in einen Puffer gepackt und verschickt werden, schon gibt's eine Anwort.
Beispiel-Antwort für www.google.com
Erster Schritt: Nachrichten-Header parsen
Header:
ID: 0000-0111 0111-0111 (1911)
FLAGS: 1000-0001 1000-0000 (33152)
QDCOUNT: 0000-0000 0000-0001 (1)
ANCOUNT: 0000-0000 0000-0111 (2) // Sind normalerweile 7 bis 9. :)
NSCOUNT: 0000-0000 0000-0000 (0)
ARCOUNT: 0000-0000 0000-0000 (0)
ID: Stimmt mit der Anfrage überein.
FLAGS:
QR: 1, daher eine Antwort.
OPCODE: 0000, normale Anfrage.
AA: 0, unwichtig. (Nachlesen :))
TC: 0, Nachricht passt in die UDP Anwort.
RD: 1, wir haben uns rekursive Aufrufe vom Server gewünscht.
RA: 1, der Server unterstützt rekursive Aufrufe.
Z: Reserviert, daher 000.
RCODE: 0000, kein Fehler.
QDCOUNT: 1, unsere Anfrage wurde mit zurückgeschickt.
ANCOUNT: 2 Anworten erhalten.
(Die selbst geschickte Frage wird hier übersprungen.)
Zweiter Schritt: Anworten parsen
- Erste Antwort:
NAME: 0000-0011 (3) 0111-0111 (119)
0111-0111 (119) 0111-0111 (119)
0000-0110 (6) 0110-0111 (103)
0110-1111 (111) 0110-1111 (111)
0110-0111 (103) 0110-1100 (108)
0110-0101 (101) 0000-0011 (3)
0110-0011 (99) 0110-1111 (111)
0110-1101 (109) 0000-0000 (0)
TYPE: 0000-0000 0000-0101 (5)
CLASS: 0000-0000 0000-0001 (1)
TTL: 0000-0000 0101-1100
0011-0001 0010-1011 (6043691)
RDLENGTH: 0000-0000 0000-1000 (8)
RDATA: 0000-0011 (3) 0111-0111 (119)
0111-0111 (119) 0111-0111 (119)
0000-0001 (1) 0110-1100 (108)
1100-0000 (192) 0010-0010 (36)
NAME: "\x03www\x06google\x03com" (Wie üblich kodiert.)
TYPE: CNAME (5) (Typ von RDATA)
CLASS: IN (1)
TTL: 6043691
RDLENGTH: 8
RDATA: Hier schickt der Server jetzt einen Pointer. Der Anfang sieht noch normal aus ("\x03www\x01l"), aber dann kommt ein Pointer. In diesem Fall zeigt er 36 Einheiten hinter das erste Byte, auf "\x06google\x03com". Zusammen wird daraus also: "\x03www\x01l\x06google\x03com" -> www.l.google.com .
- Zweite Antwort:
NAME: 1100-0000 (192) 0011-1010 (58)
TYPE: 0000-0000 0000-0001 (1)
CLASS: 0000-0000 0000-0001 (1)
TTL: 0000-0000 0000-0000
0000-1011 1011-1001 (3001)
RDLENGTH: 0000-0000 0000-0100 (4)
RDATA: 0100-1010 (74) 0111-1101 (125)
0010-0111 (39) 1001-0011 (147)
NAME: Besteht nur aus einem Pointer auf www.l.google.com , man sieht hier auch, dass Pointer durchaus verschachtelt sein können.
TYPE: A (1) (Typ von RDATA, IPv4-Adresse)
CLASS: IN (1)
TTL: 3001
RDLENGTH: 4
RDATA: Die erwartete IPv4-Adresse (74.125.39.147). Wie gesagt, das sind einzelne Bytes, deren Reihenfolge nicht geändert werden muss.
Ich hoffe das Ganze hier hat einen kleinen Überblick über das Protokoll gegeben.
(Rechtschreibe-/sonstige Fehler gerne anmerken, ich werde sie dann nachbessern. Der Text wurde halt an einem Stück geschrieben.)