Übersicht über das DNS Protokoll.
-
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 lessJede 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 records3.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 class3.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.)