O uso de pesquisa de domínios substituídos no dhclient + resolvconf parece ser anexado?

0

Na minha máquina Ubuntu 16.04, estou usando o DHCP para obter um endereço IP do roteador do meu provedor. Ele responde com os servidores DNS e os domínios de pesquisa DNS que desejo substituir.

/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";

Aqui eu configurei o cliente DHCP para:

  • não solicita servidores de nomes de domínio e / ou domínio de pesquisa
  • substitua os itens domain-name-servers e domain-search , se fornecidos de qualquer maneira.

No entanto, o que acontece com o resolvconf agora:

/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

Observe a entrada home lá? Isso é o que meu roteador de baixa qualidade ISP está me enviando apesar de eu não estar solicitando isso (confirmado com o tcpdump veja abaixo). Portanto, aparentemente, o dhclient está anexando em vez de substituir, como se eu tivesse usado append em vez de supersede .

O que estou fazendo errado? Eu quero que o dhclient ignore o falso domínio de pesquisa DNS não configurável.

Eu consideraria isso um problema de segurança, já que não quero que ele pesquise em um domínio assustador para cada consulta DNS que eu faço no meu host. Além disso, por que o dhclient está se incomodando em analisar as opções de resposta que ele não pediu?

Informação sobre a versão do software (todo o stock Ubuntu 16.04):

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
    
por gertvdijk 08.07.2017 / 00:57

1 resposta

0

Eu estava substituindo a opção dhcp errada.

Em vez da opção domain-name-search , meu roteador do ISP respondeu com uma opção domain-name . Este último é a opção para substituir.

Parece que a combinação dhclient-resolvconf mescla as informações do nome de domínio primário ( home here) com os domínios de pesquisa.

Ainda aberto: por que o dhclient se preocupa em analisar e processar a opção domain-name ? Eu não pedi isso. Aparentemente, eu preciso substituir todas as respostas que eu não pedi para este dispositivo não confiável está me enviando? Soa como um bom vetor de ataque aqui ...

    
por 08.07.2017 / 01:42