Die Verwendung einer übergeordneten Domain-Suche in dhclient + resolvconf scheint anzuhängen?

1158
gertvdijk

Auf meinem Ubuntu 16.04-Computer verwende ich DHCP, um eine IP-Adresse vom Router meines ISPs zu erhalten. Es antwortet mit DNS-Servern und DNS-Suchdomänen, die ich überschreiben möchte.

/etc/dhcp/dhclient.conf:

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;  send host-name = "my.hostname";  request subnet-mask, broadcast-address, routers, interface-mtu;  supersede domain-name-servers 10.1.2.3; supersede domain-search "mydomain.tld";

Hier habe ich den DHCP-Client folgendermaßen konfiguriert:

  • Domänennamen-Server und / oder Suchdomäne nicht anfordern
  • überschreiben Sie beide domain-name-serversund, domain-searchfalls vorhanden,

Was passiert jetzt mit resolvconf:

/etc/resolv.conf:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 10.1.2.3 search home mydomain.tld

Beachten Sie den homeEintrag dort? Das ist es, was mir mein beschissener ISP-Router sendet, obwohl ich ihn nicht frage (bestätigt mit tcpdump siehe unten). Anscheinend hängt dhclient an, anstatt zu überschreiben, als hätte ich appendstatt verwendet supersede.

Was mache ich falsch? Ich möchte, dass dhclient die gefälschte, nicht konfigurierbare DNS-Suchdomäne ignoriert.

Ich würde dies als Sicherheitsproblem betrachten, da ich nicht möchte, dass eine gespenstische Domäne für jede DNS-Abfrage durchsucht wird, die ich auf meinem Host durchführe. Warum macht sich Dhclient auch die Mühe, Antwortoptionen zu analysieren, nach denen er nicht gefragt hat?

Informationen zur Softwareversion (alle Ubuntu 16.04 auf Lager):

ii isc-dhcp-client 4.3.3-5ubuntu12.7 ii resolvconf 1.78ubuntu4

tcpdump:

01:09:35.629136 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 52:54:00:23:86:a8, length 300, xid 0x9e3d912a, Flags [none] (0x0000) Client-Ethernet-Address 52:54:00:23:86:a8 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Request Requested-IP Option 50, length 4: 192.168.999.24 Hostname Option 12, length 27: "my.hostname" Parameter-Request Option 55, length 4:  Subnet-Mask, BR, Default-Gateway, MTU 01:09:35.642166 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576) 192.168.999.1.67 > 192.168.999.24.68: [udp sum ok] BOOTP/DHCP, Reply, length 548, xid 0x9e3d912a, Flags [none] (0x0000) Your-IP 192.168.999.24 Server-IP 192.168.999.1 Client-Ethernet-Address 52:54:00:23:86:a8 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: ACK Server-ID Option 54, length 4: 192.168.999.1 Lease-Time Option 51, length 4: 3600 Hostname Option 12, length 27: "my.hostname" Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.999.1 Domain-Name-Server Option 6, length 8: 1.2.3.4,4.5.6.7 Domain-Name Option 15, length 4: "home" TTL Option 23, length 1: 64
0

1 Antwort auf die Frage

0
gertvdijk

Ich habe die falsche Dhcp-Option abgelöst.

Anstelle einer domain-name-searchOption antwortete mein ISP-Router mit einer domain-nameOption. Letzteres ist die Option zum Ersetzen.

Es scheint, dass die dhclient-resolvconf-Kombination die Informationen aus dem primären Domänennamen ( homehier) mit den Suchdomänen zusammenführt .

Immer noch zum Nachdenken offen: Warum macht sich Dhclient die Mühe, die Option zu analysieren und zu verarbeiten domain-name? Ich habe es nicht verlangt. Anscheinend muss ich alle Antworten ersetzen, die ich nicht nach diesem nicht vertrauenswürdigen Gerät gefragt habe, das mich sendet. Klingt nach einem netten Angriffsvektor hier ...

Verwandte Probleme