Làm thế nào để tránh xung đột giữa dnsmasq và systemd được giải quyết?


57

Gần đây tôi đã cài đặt dnsmasq để hoạt động như Máy chủ DNS cho mạng cục bộ của mình. dnsmasq lắng nghe trên cổng 53 đã được sử dụng bởi trình nghe DNS gốc cục bộ từ hệ thống được phân giải .

Chỉ cần dừng giải quyết systemd và sau đó khởi động lại nó sau khi dnsmasq đang chạy giải quyết vấn đề này. Nhưng nó trả về sau khi khởi động lại: systemd-phân giải được bắt đầu với ưu tiên và dnsmasq sẽ không bắt đầu vì cổng 53 đã được sử dụng.

Câu hỏi rõ ràng đầu tiên, tôi đoán, là làm thế nào để tôi giải quyết tốt nhất hệ thống hiểu rằng nó không nên khởi động trình nghe sơ khai DNS cục bộ và do đó giữ cổng 53 để dnsmasq sử dụng?

Tuy nhiên, một câu hỏi thú vị hơn là làm thế nào hai dịch vụ thường hoạt động cùng nhau. Chúng thậm chí có nghĩa là để làm việc cạnh nhau hoặc được giải quyết theo hệ thống theo cách nếu một người sử dụng dnsmasq?


4
Bạn đã thử chỉ vô hiệu hóa thông qua sudo systemctl disable systemd-resolved? dnsmasq nếu được cấu hình đúng sẽ xử lý độ phân giải tên miền tôi nghĩ.
pbhj

1
Bạn cũng phải phát hành sudo systemctl stop systemd-resolvednếu nó đang chạy. Sử dụng sudo systemctl status systemd-resolvedđể kiểm tra
Bruce Barnett

Câu trả lời:


42

Kể từ systemd 232 (phát hành năm 2017), bạn có thể chỉnh sửa /etc/systemd/resolved.confvà thêm dòng này:

DNSStubListener=no

Điều này sẽ tắt ràng buộc với cổng 53.

Tùy chọn này được mô tả chi tiết hơn trong trang man .

Bạn có thể tìm thấy phiên bản systemd mà hệ thống của bạn đang chạy với:

systemctl --version

2
Thực hiện lần lượt kết nối internet này
Ravinder

2
@Ravinder: Nó sẽ vô hiệu hóa máy chủ DNS systemd, vâng. Nếu hệ thống của bạn được cấu hình để sử dụng máy chủ này thì có vẻ như kết nối Internet sẽ ngừng hoạt động (vì bạn đã tắt nó). Bạn sẽ cần phải định cấu hình hệ thống của mình để sử dụng máy chủ DNS khác thay thế. Thông thường mọi người tắt liên kết trên cổng 53 vì họ muốn chạy máy chủ DNS của riêng họ ở đó, vì vậy đó không phải là vấn đề.
Malvineous

18

Bạn có thể vô hiệu hóa systemd-resolvedtải khi khởi động bằng cách sử dụng sudo systemctl disable systemd-resolved.

Nếu bạn muốn chạy cả hai cùng nhau, bạn có thể chuyển hướng systemd-resolvedđể sử dụng localhost làm máy chủ tên chính. Điều này sẽ đảm bảo rằng tất cả các truy vấn được chuyển đến dnsmasq để giải quyết trước khi nhấn máy chủ DNS bên ngoài. Điều này có thể được thực hiện bằng cách thêm dòng nameserver 127.0.0.1ở đầu /etc/resolv.conftệp của bạn . Điều này cũng sẽ vô hiệu hóa bộ nhớ đệm cục bộ của systemd.

Bạn có thể đọc thêm trên wiki Arch Linux . Tôi đã sao chép nó từ đó và nó bao gồm nó khá tốt.

Tuy nhiên, điều này không đáng tin cậy để tránh lỗi khi khởi động, tức là dnsmasq vẫn sẽ thất bại nếu hệ thống được giải quyết xảy ra để bắt đầu trước. Nếu phiên bản của bạn systemdđủ mới, hãy sử dụng câu trả lời của Malvineous . Nếu phiên bản của bạn systemdquá cũ, bạn có thể khắc phục sự cố này bằng cách sửa đổi đơn vị dnsmasq: trong [Unit]phần, thêm Before=systemd-resolved.

Sau này, nếu bạn thích, bạn có thể tạo một /etc/dnsmasq-resolv.conftệp riêng cho máy chủ tên ngược dòng và chuyển nó bằng cách sử dụng -rhoặc --resolv-filetùy chọn hoặc thêm máy chủ tên ngược dòng vào tệp cấu hình dnsmasq và sử dụng tùy chọn -Rhoặc --no-resolv. Bằng cách này, bạn chỉ có localhost trong /etc/resolv.confvà mọi thứ đều đi qua dnsmasq.


2
Tôi đã phải xóa bình luận trước đây vì tôi không còn có thể xác nhận rằng điều này đã giải quyết được vấn đề. Tôi đã đọc wiki trước khi hỏi ở đây và tôi đã có một tệp giải quyếtvvv với máy chủ tên localhost ở trên cùng. Điều này đã không giúp đỡ. Sau đó tôi làm theo hướng dẫn của bạn để chuyển các máy chủ tên bên ngoài sang tệp thứ hai cho dnsmasq. Sau lần khởi động lại đầu tiên, dnsmasq đã tải trước để vấn đề không xảy ra. Ở lần khởi động lại thứ hai, giải quyết được tải trước tiên để dnsmasq thoát với lỗi được mô tả. Tôi xa như trước đây.
vic

6
Trong đơn vị dnsmasq, đặt một Before=systemd-resolvedtrong các [Unit]phần. Bằng cách đó, dnsmasq sẽ luôn bắt đầu trước.
Munir

7

Đánh giá từ các trang web hệ thống, nó không có ý định vô hiệu hóa máy chủ DNS còn sơ khai. Thật thú vị, tôi chỉ nhận thấy vấn đề được mô tả sau khi nâng cấp systemd từ 230 lên 231.

Vô hiệu hóa giải quyết systemd không phải là tùy chọn đối với tôi vì tôi cần nó để xử lý các máy chủ DNS ngược dòng thông qua DHCP.

Giải pháp của tôi là làm cho dnsmasq dừng giải quyết systemd trước khi bắt đầu và bắt đầu lại sau đó.

Tôi đã tạo một cấu hình thả trong /etc/systemd/system/dnsmasq.service.d/resolved-fix.conf:

[Unit]
After=systemd-resolved.service

[Service]
ExecStartPre=/usr/bin/systemctl stop systemd-resolved.service
ExecStartPost=/usr/bin/systemctl start systemd-resolved.service

Điều này dường như là một giải pháp khá hackish nhưng nó hoạt động.


2
Hey thực sự giải pháp này là khá trơn tru. Nó vẫn tồn tại ngay cả sau khi cập nhật gói vì nó giữ tệp đơn vị gốc. Hoàn thành tốt Phần sau đây được nêu DNSStubListenertrong hướng dẫn đã được giải quyết: "Lưu ý rằng trình nghe sơ khai DNS bị tắt hoàn toàn khi địa chỉ nghe và cổng của nó đã được sử dụng." Đó là lý do tại sao phương pháp này hoạt động tốt tôi nghĩ.
Jonathan Komar

Một giải pháp ++ !!!
sjas

Tôi đã phải đổi / usr / bin / systemctl thành / bin / systemctl
Bruce Barnett

5

Tôi chỉ kích hoạt tùy chọn "liên kết giao diện" bằng cách xóa '#' ở đầu dòng trong /etc/dnsmasq.conf.

Tôi đã có thể bắt đầu lại dnsmasq:

  • dnsmasq liên kết cổng DNS trên tất cả các giao diện (bao gồm cả 127.0.0.1) cổng 53,
  • systemd-decv tiếp tục nghe trên 127.0.0. 53 : 53

Tôi đã được chỉ ra giải pháp này bởi cuộc thảo luận này đã được giải quyết: thêm một tùy chọn để vô hiệu hóa trình giải quyết sơ khai


Đây là câu trả lời tốt nhất cho một đám cháy rác là gì. Không có lý do gì systemd nên chiếm cổng đó, ngay cả trên loopback.
Jonathan S. Fisher


2

Nếu bạn đang sử dụng thiết lập Ubuntu 18.04 mặc định, điều này thể do xung đột giữa systemd-resolved(máy chủ DNS mặc định) và dnsmasq. Nếu bạn dnsmasqtự cài đặt một cách có chủ ý vì bạn rõ ràng muốn nó, thì một trong những câu trả lời khác cho câu hỏi này, giải thích cách vô hiệu hóa systemd-resolved, có lẽ sẽ tốt cho bạn. Nếu bạn không cài đặt rõ ràng dnsmasq, thì có khả năng là do bạn đang sử dụng lxd. Điều này có thể là do bạn thực sự sử dụng lxdđể quản lý các container, nhưng rất có thể là do snaps sử dụng lxdđể bảo vệ bạn khi các ứng dụng được cài đặt. Từ góc nhìn của tôi, tôi muốn giữ dnsmasq(vì lxdmuốn nó) nhưng tôi cũng muốn giữsystemd-resolved với tư cách là máy chủ DNS (vì đó là những gì nhóm Ubuntu đã chọn và tôi tin tưởng họ hơn bản thân mình).

Vì vậy, đây dường như là một lxdvấn đề trong tim. Nếu vậy, cách tôi sửa nó, theo bài đăng danh sách gửi thư của người dùng lxd , là:

$ lxc network edit lxdbr0

Điều này sẽ chỉnh sửa cấu hình của bạn trong một trình soạn thảo thiết bị đầu cuối. Nó sẽ trông giống như thế này:

config:
  ipv4.address: 10.216.134.1/24
  ipv4.nat: "true"
  ipv6.address: none
  ipv6.nat: "true"
name: lxdbr0
type: bridge

Thêm ba dòng cho nó:

config:
  ipv4.address: 10.216.134.1/24
  ipv4.nat: "true"
  ipv6.address: none
  ipv6.nat: "true"
  raw.dnsmasq: |
    auth-zone=lxd
    dns-loop-detect
name: lxdbr0
type: bridge

và điều này sẽ gây ra dnsmasq, đang được điều hành bởi lxd, để phát hiện các vòng lặp DNS. Điều này, ít nhất là đối với tôi, đã giải quyết vấn đề và dừng lại systemd-resolveddnsmasqsử dụng 100% CPU.


2

Đây là giải pháp cho (X) Ubuntu 18.04 Bionic.

Cài đặt dnsmasq

sudo apt install dnsmasq

Vô hiệu hóa trình nghe được phân giải systemd trên cổng 53 (không chạm vào /etc/systemd/resolve.conf, vì nó có thể bị ghi đè khi nâng cấp):

$ cat /etc/systemd/resolved.conf.d/noresolved.conf 
[Resolve]
DNSStubListener=no

và khởi động lại nó

$ sudo systemctl restart systemd-resolved

(thay thế hoàn toàn vô hiệu hóa nó bằng cách $ sudo systemctl disable systemd-resolved.service )

Xóa /etc/resolv.conf và tạo lại. Điều này rất quan trọng, bởi vì decv.conf là một liên kết tượng trưng đến /run/systemd/resolve/stub-resolv.conf theo mặc định. Nếu bạn sẽ không xóa liên kết tượng trưng, ​​tệp sẽ bị ghi đè bởi systemd khi khởi động lại (mặc dù chúng tôi đã vô hiệu hóa systemd được giải quyết!). Ngoài ra NetworkManager (NM) kiểm tra xem đó có phải là một liên kết tượng trưng để phát hiện cấu hình được giải quyết bởi systemd không.

$ sudo rm /etc/resolv.conf
$ sudo touch /etc/resolv.conf

Vô hiệu hóa ghi đè /etc/resolv.conf bởi NM (cũng có một trình quản lý RC tùy chọn, nhưng nó không hoạt động, mặc dù nó được mô tả trong hướng dẫn sử dụng NM):

$ cat /etc/NetworkManager/conf.d/disableresolv.conf 
[main]
dns=none

và khởi động lại nó:

$ sudo systemctl restart NetworkManager

Nói với dnsmasq để sử dụng độ phân giải từ NM:

$ cat /etc/dnsmasq.d/nmresolv.conf 
resolv-file=/var/run/NetworkManager/resolv.conf

và khởi động lại nó:

$ sudo systemctl restart dnsmasq

Sử dụng dnsmasq để giải quyết:

$ cat /etc/resolv.conf 
# Use local dnsmasq for resolving
nameserver 127.0.0.1

1
Sau khi thử một vài giải pháp khác, giải pháp của bạn là giải pháp cho vấn đề của tôi trên Linux Mint 19.1. Cảm ơn rất nhiều!
Renan Lazarotto

1

Tôi đã giải quyết nó theo cách này:

Thêm hoặc bỏ ghi chú dòng sau trong / etc / default / dnsmasq :

IGNORE_RESOLVCONF=yes

Tạo tệp độ phân giải của riêng bạn (/etc/resolv.personal) để xác định máy chủ tên. Bạn có thể sử dụng bất kỳ máy chủ tên ở đây. Tôi lấy hai từ https://www.opennic.org

nameserver 5.132.191.104
nameserver 103.236.162.119

Trong /etc/dnsmasq.conf thêm hoặc bỏ ghi dòng sau:

resolv-file=/etc/resolv.personal

Sau đó khởi động lại dnsmasq và vô hiệu hóa trình phân giải mặc định: systemd-phân giải.

sudo service dnsmasq restart

sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved

1

Tôi không chắc tại sao cả hai dịch vụ đều cố gắng sử dụng cùng một địa chỉ. Có lẽ bạn có thể sắp xếp chúng như trong trường hợp của tôi trên Xubfox 18.04.1, trong đó cấu hình của chúng là như sau:

xy@zq:~$ sudo netstat -tulpn | grep 53
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      13549/systemd-resol 
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      9632/dnsmasq 

Để giải quyết systemd bằng dnsmasq của tôi, tôi chỉ cần đặt:

#/etc/systemd/resolved.conf 
[Resolve]
DNS=127.0.0.1

Trong cấu hình dnsmasq của tôi, tôi đặt máy chủ tên bên ngoài:

#/etc/dnsmasq.conf
nameserver x.x.x.x
nameserver y.y.y.y

Sau khi khởi động lại mọi thứ:

# sudo systemctl restart systemd-resolved.service
# sudo systemctl restart dnsmasq.service

systemd-yet sẽ đặt máy chủ DNS mặc định thành dnsmasq trong:

#/etc/resolv.conf
nameserver 127.0.0.1

Dòng cuối cùng làm tôi ngạc nhiên, vì vậy tôi nhìn nó. Có vẻ như trong trường hợp của bạn, /etc/resolv.conflà một liên kết tượng trưng đến /run/systemd/resolve/resolv.conf. Rõ ràng đây là một trong bốn chế độ khác nhau (!) Có thể hoạt động được giải quyết bởi systemd. Tôi đoán nó phụ thuộc vào cách phân phối của bạn thiết lập nó, tức là nó đúng với Xubfox 18.04.1 của bạn, nhưng nó có thể khác với hệ thống.
nguồn

0

Tôi không thể có được dnsmasq để bắt đầu sử dụng các giải pháp được tìm thấy trực tuyến, tức là vô hiệu hóa giải quyết systemd, thay đổi dnsmasq.conf để thực hiện "liên kết động" thay vì "liên kết giao diện". Tôi đã có thể làm cho nó khởi động khi khởi động bằng cách khởi động dnsmasq Sau mạng-online.service thay vì network.service:

[Unit]
Description=dnsmasq - A lightweight DHCP and caching DNS server
Requires=network.target
Wants=nss-lookup.target
Before=nss-lookup.target
After=network-online.target #This line changed

Cảm ơn đã đăng cách tiếp cận bạn đang sử dụng. Lưu ý rằng thông thường khi bạn đặt hàng theo mạng-online.target, bạn cũng có nghĩa vụ phải thêm network-online.target vào danh sách Wants=. freedesktop.org/wiki/Software/systemd/NetworkTarget
sourcejedi

0

Đây là những gì làm việc cho tôi (sau nhiều giờ đau đớn) trong Mực nang vũ trụ Ubuntu 18.10. Tôi đã làm điều này để tận dụng dnsmasqcơ chế bộ nhớ đệm tương đối mạnh mẽ hơn và để tránh các lỗ hổng trình phân giải NGINX . Lưu ý rằng tôi đang sử dụng phiên bản Ubuntu Server (không NetworkManager/ nmcli, chỉ systemd-networkd) và phiên bản này đang chạy trên AWS EC2, vì vậy tôi cũng cần giữ DNS và DHCP hoạt động với miền tìm kiếm EC2 mặc định. Tôi không muốn vô hiệu hóa systemd-resolvedhoàn toàn vì tôi không biết làm thế nào điều đó có thể ảnh hưởng đến các bản cập nhật trong tương lai. Mọi thứ ở đây được chạy dưới dạng root / sudo trừ khi có ghi chú khác (điều này xảy ra theo mặc định khi được truyền vào dưới dạng Dữ liệu người dùng EC2).

## Configure dnsmasq to work with systemd-resolved
# Set static hostname with hostnamectl
hostnamectl set-hostname mydomainname
# Add an entry for the hostname to /etc/hosts
tee --append /etc/hosts <<EOF
127.0.0.1 mydomainname
EOF
# Disable stub listener for resolvconf and set DNS to loopback
tee --append /etc/systemd/resolved.conf <<EOF
DNSStubListener=no
DNS=127.0.0.1
EOF
# Tell dnsmasq to ignore resolvconf
tee --append /etc/default/dnsmasq <<EOF
IGNORE_RESOLVCONF=yes
EOF
# Create dropin directory
mkdir -p /etc/systemd/system/dnsmasq.service.d
# Create systemd dropin to make sure systemd-resolved stops before dnsmasq starts
tee /etc/systemd/system/dnsmasq.service.d/resolved-fix.conf <<EOF
[Unit]
After=systemd-resolved.service
[Service]
ExecStartPre=bin/systemctl stop systemd-resolved.service
ExecStartPost=bin/systemctl start systemd-resolved.service
EOF
# Create custom resolvconf with name servers (I usec cloudflare)
tee /etc/resolv.mydomainname <<EOF
nameserver 1.1.1.1
nameserver 1.0.0.1 
nameserver [2606:4700:4700::1111] 
nameserver [2606:4700:4700::1001] 
EOF
# Configure dnsmasq
tee /etc/dnsmasq.d/mydomainname.conf <<EOF
# Region comes from:
# EC2_AVAIL_ZONE=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)
# EC2_REGION=${EC2_AVAIL_ZONE%?}
domain=$EC2_REGION.compute.internal
resolv-file=/etc/resolv.mydomainname
listen-address=127.0.0.1
port=53
interface=lo
bind-dynamic
domain-needed
bogus-priv
dnssec
dns-forward-max=300
cache-size=1000
neg-ttl=3600
EOF
# Reload to pick up dropin
systemctl daemon-reload
# Stop systemd-resolved
systemctl stop systemd-resolved
# Start dnsmasq
systemctl restart dnsmasq

Xác minh rằng 127.0.0.1#53đang được sử dụng để giải quyết và DNSSEC đang hoạt động với một cái gì đó nhưdig +trace facebook.com


Bạn có biết tại sao bạn vẫn cần hack tập tin đơn vị này khi bạn đã thiết lập DNSStubListener=nokhông?
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.