systemd-resolved
사용해야 하는 소프트웨어( twingate
중요한 경우 클라이언트)가 openresolv
현재 사용 중인 소프트웨어와 작동 하지 않기 때문에 전환해야 합니다 . 관련 내용을 읽으면서 Split-DNS, Per-Interface-DNS 등의 개념을 배웠습니다.
그러나 나는 그 뒤에 있는 개념을 완전히 이해할 수 없습니다 Per-Interface DNS
. 나는 다른 ( Routing
또는 Search
)을 Domains
다른 서버에 매핑해야 할 필요성을 완전히 이해 DNS
하지만 이것이 존재와 어떤 관련이 있습니까?경계인터페이스로?
바람직한 행동은 "라우팅 도메인 ~foo.bar.com이 주어지면 30.40.50.60을 DNS 서버로 사용합니다.". 그러나 이것은 구성된 인터페이스와는 아무런 관련이 없습니다. systemd-resolved
주어진 인터페이스를 통해 쿼리를 마술처럼 라우팅할 수는 없습니다. DNS
서버가 를 사용하도록 교육할 수 있지만 foo.bar.com
커널 라우팅 테이블의 도움이 필요합니다. 해당 DNS
서버에 도달하십시오 30.40.50.60
.
예를 들어. eth0
완전히 다른 연결 IP가 있는 인터페이스 장치와 서버가 바인딩하고 수신하는 eth1
연결 IP가 있는 또 다른 인터페이스 30.40.50.60
에서 위 구성을 수행 할 수 있습니다 .DNS
따라서 다음과 같이 진행됩니다.
# ip addr for eth0
IP: 13.14.15.16
# resolvectl status for eth0
DNS Servers: 30.40.50.60
DNS Domains: ~foo.bar.com
# ip addr for eth1
IP: 30.40.50.60
# resolvectl status for eth1
DNS Servers: 13.14.15.16
DNS Domains: ~fun.gun.com
# ip route
30.40.50.60 dev eth1 <...>
13.14.15.16 dev eth0 <...>
보시다시피 DNS
eth0에 바인딩된 서버 정보가 resolvectl
실제로 실행되고 있고 eth1
그 반대의 경우도 마찬가지입니다. 따라서 이제 resolved
쿼리가 작성 되면 사용할 서버를 foo.bar.com
찾은 다음 거기로 쿼리를 라우팅하고 커널 라우팅 테이블은 쿼리가 전송되어야 함을 나타냅니다. 이는 그것과 아무 관련이 없습니다 .DNS
30.40.50.60
eth1
eth0
그렇다면 왜 그렇게 불리는가 Per-Interface DNS
? 또한 다음과 같이 간단히 설명하는 매핑 구성 파일(인터페이스 정보와 무관)일 수도 있습니다.
# Domain: DNS-server
~foo.bar.com: 30.40.50.60
~fun.gun.com: 13.14.15.16
# .. and so on
이는 어떤 방식으로든 인터페이스와 연결되는 것과는 아무런 관련이 없습니다.