Unbound DNS Server, Python-Modul: inspizieren Antwortnachricht Elemente

Question

Tor

Ich mag würde Unbound Python-Modul nutzen, um die Reaktion zu untersuchen, kurz bevor es an den Kunden versandt wird. Hauptsächlich interessiert mich die ;; ANSWER SECTION:, d. H. Zu welcher IP-Adresse die Abfrage aufgelöst wurde.

Problem

Was aussieht hatte mich wie eine triviale Änderung der logDnsMsg Funktion aus Surfen reply_info, rrset_ref und ub_packed_rrset_key Strukturen auf der Suche nach dem gewünschten ;; ANSWER SECTION: Bytes eine dounting Aufgabe.

Der Grund ist die logDnsMsg Funktion funktioniert nicht wie erwartet für A;; ANSWER SECTION: abfragt, während es überraschend wie für ;; AUTHORITY SECTION: auf AAAA Abfragen erwartet arbeitet.

Lemme demonstrieren einen Vergleich zwischen der Python implementiert logDnsMsg Funktion und eine native log_dns_msg Funktion; wobei ersteres ein Kauderwelsch zeigt und letzteres genau wie erwartet funktioniert. Beide Funktionen werden aus dem Python-Modul Kontext wie folgt aufgerufen:

+++ 
def operate(id, event, qstate, qdata): 
    log_info("pythonmod: operate called, id: %d, event:%s" % (id, strmodulevent(event))) 
    if (qstate.return_msg): 
     logDnsMsg(qstate) 
     log_dns_msg("blackpie KARMMMMMM XXXXXXX", qstate.return_msg.qinfo, qstate.return_msg.rep) 
+++ 

Bitte beachte, dass ich das Original logDnsMsg so verändert, wie es verwendet die Logging-Framework für print. Die Ausgabe war die gleiche für print aber für die verstreut über das Logfile im Ermessen des Puffers.

Ausgang:

karm@localhost:~$ dig seznam.cz @127.0.0.1 -p53535 
; <<>> DiG 9.9.4-P2-RedHat-9.9.4-18.P2.fc20 <<>> seznam.cz @127.0.0.1 -p53535 
;; global options: +cmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38630 
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 
;; OPT PSEUDOSECTION: 
; EDNS: version: 0, flags:; udp: 4096 
;; QUESTION SECTION: 
;seznam.cz.  IN A 
;; ANSWER SECTION: 
seznam.cz. 300 IN A 77.75.76.3 
;; Query time: 656 msec 
;; SERVER: 127.0.0.1#53535(127.0.0.1) 
;; WHEN: Sat Apr 25 16:04:32 CEST 2015 
;; MSG SIZE rcvd: 54 

Ausgang für AAAA Abfrage sieht ;; AUTHORITY SECTION: anständig genug von beiden logDnsMsg und log_dns_msg:

[1429970672] unbound[14053:0] info: pythonmod: operate called, id: 1, event:module_event_moddone 
[1429970672] unbound[14053:0] info: ------------------------------------------------------------------------------------------ 
[1429970672] unbound[14053:0] info: Query: e.root-servers.net., type: AAAA (28), class: IN (1) 
[1429970672] unbound[14053:0] info: ------------------------------------------------------------------------------------------ 
[1429970672] unbound[14053:0] info: Return reply :: flags: 8080, QDcount: 1, Security:0, TTL=86400 
[1429970672] unbound[14053:0] info:   qinfo :: qname: ['e', 'root-servers', 'net', ''] e.root-servers.net., qtype: AAAA, qclass: IN 
[1429970672] unbound[14053:0] info: Reply: 
[1429970672] unbound[14053:0] info: 0:['root-servers', 'net', ''] root-servers.net. flags: 0004 
[1429970672] unbound[14053:0] info: type:SOA (6) class:IN (1) 
[1429970672] unbound[14053:0] info: 0:TTL=3600000 
[1429970672] unbound[14053:0] info: 
[1429970672] unbound[14053:0] info:  0x00 | 00 40 01 61 0C 72 6F 6F 74 2D 73 65 72 76 65 72 73 | . @ . a . r o o t - s e r v e r s 
     0x10 | 73 03 6E 65 74 00 05 6E 73 74 6C 64 0C 76 65 72 69 | s . n e t . . n s t l d . v e r i 
     0x20 | 69 73 69 67 6E 2D 67 72 73 03 63 6F 6D 00 78 0C E3 | i s i g n - g r s . c o m . x . . 
     0x30 | E3 24 00 00 38 40 00 00 1C 20 00 12 75 00 00 36 EE | . $ . . 8 @ . . . . . u . . 6 . 
     0x40 | EE 80            | . . 
[1429970672] unbound[14053:0] info: ------------------------------------------------------------------------------------------ 
[1429970672] unbound[14053:0] info: blackpie KARMMMMMM XXXXXXX ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0 
;; flags: qr ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 
;; QUESTION SECTION: 
e.root-servers.net. IN AAAA 
;; ANSWER SECTION: 
;; AUTHORITY SECTION: 
root-servers.net. 3600000 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014110500 14400 7200 1209600 3600000 
;; ADDITIONAL SECTION: 
;; MSG SIZE rcvd: 96 
[1429970672] unbound[14053:0] debug: mesh_run: python module exit state is module_finished 

Im Gegenteil, für A Abfrage ist ;; ANSWER SECTION: vollständig bis nutzlos als logDnsMsg geht:

[1429970672] unbound[14053:0] info: pythonmod: operate called, id: 1, event:module_event_moddone 
[1429970672] unbound[14053:0] info: ------------------------------------------------------------------------------------------ 
[1429970672] unbound[14053:0] info: Query: seznam.cz., type: A (1), class: IN (1) 
[1429970672] unbound[14053:0] info: ------------------------------------------------------------------------------------------ 
[1429970672] unbound[14053:0] info: Return reply :: flags: 8080, QDcount: 1, Security:0, TTL=300 
[1429970672] unbound[14053:0] info:   qinfo :: qname: ['seznam', 'cz', ''] seznam.cz., qtype: A, qclass: IN 
[1429970672] unbound[14053:0] info: Reply: 
[1429970672] unbound[14053:0] info: 0:['seznam', 'cz', ''] seznam.cz. flags: 0000 
[1429970672] unbound[14053:0] info: type:A (1) class:IN (1) 
[1429970672] unbound[14053:0] info: 0:TTL=300 
[1429970672] unbound[14053:0] info: 
[1429970672] unbound[14053:0] info:  0x00 | 00 04 4D 4B 4C 03         | . . M K L . 
[1429970672] unbound[14053:0] info: ------------------------------------------------------------------------------------------ 
[1429970672] unbound[14053:0] info: blackpie KARMMMMMM XXXXXXX ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0 
;; flags: qr ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION: 
seznam.cz. IN A 
;; ANSWER SECTION: 
seznam.cz. 300 IN A 77.75.76.3 
;; AUTHORITY SECTION: 
;; ADDITIONAL SECTION: 
;; MSG SIZE rcvd: 43 
[1429970672] unbound[14053:0] debug: mesh_run: python module exit state is module_finished 

Beachten Sie die 00 04 4D 4B 4C 03 Bytes, die fälschlicherweise als ASCII interpretiert werden.

Frage

Wo in der struct ub_packed_rrset_key** rrsets; man die gewünschten ;; ANSWER SECTION: Daten findet? (Wenn es in der Tat der richtige Ort ist, um nachzusehen.)

Ich habe schon eine ganze Weile ohne Glück damit herumhantiert. Ich untersuchte die sldns_wire2str_pkt_scan Funktion, die intern zum Entpacken der wire Binärdaten verwendet wird, aber ich bin keiner der Klügere.

Answer 1

logDnsMsg() protokolliert einen hex dump des Inhalts jedes DNS-Ressourceneintrags. Er gibt die Bytes neben ihrer ASCII-Interpretation aus (mit . s für nicht druckbare Bytes). Dies bedeutet, dass wenn die Daten ASCII-Strings enthalten, diese in der Ausgabe sichtbar sind, während andere Datentypen (wie IP-Adressen) nicht in sinnvollen Text übersetzt werden.

Die ersten zwei Bytes der Daten sind das Feld RDLENGTH, das die Länge der Datensatzdaten angibt. Die verbleibenden Bytes sind das richtige Feld RDATA. Die Interpretation dieser Bytes hängt vom Datensatztyp ab. A Datensätze bestehen aus einer einzelnen 32-Bit-IP-Adresse, sodass sie leicht zu analysieren sind.

Der folgende Beispielcode druckt den Inhalt eines A Rekord:

def print_a_record(data): 
    rdlength, rdata = data[:2], data[2:] 
    assert rdlength == '\x00\x04' 
    assert len(rdata) == 4 
    addr_bytes = [ord(c) for c in rdata] 
    print('{}.{}.{}.{}'.format(*addr_bytes)) 

Weitere Informationen:

• Domain Name System, Wikipedia
• RFC 1035 - Domain Names - Implementation and Specification, IETF