%EC%9D%84%20LLMNR%EB%B3%B4%EB%8B%A4%20%EB%8D%9C%20%EC%95%88%EC%A0%84%ED%95%98%EB%8B%A4%EA%B3%A0%20%EA%B0%84%EC%A3%BC%ED%95%98%EB%8A%94%20%EC%9D%B4%EC%9C%A0%EB%8A%94%20%EB%AC%B4%EC%97%87%EC%9E%85%EB%8B%88%EA%B9%8C%3F.png)
도메인 이름 사용 =
부울 인수 또는 특수 값 "route"를 사용합니다. true인 경우 DHCP 서버로부터 수신된 도메인 이름은 Domains= 설정의 효과와 유사하게 이 링크의 DNS 검색 도메인으로 사용됩니다. "route"로 설정하면 DHCP 서버에서 수신된 도메인 이름은 DNS 쿼리 라우팅에만 사용되며 검색에는 사용되지 않습니다. 이는 매개변수 접두사가 "~"일 때 Domains= 설정의 효과와 유사합니다. 기본값은 거짓입니다.
이 옵션을 설정하면 모든 호스트 이름, 특히 단일 레이블 이름의 확인에 영향을 미치므로 신뢰할 수 있는 네트워크에서만 이 옵션을 활성화하는 것이 좋습니다. 단일 레이블 이름의 로컬 확인에 영향을 주지 않도록 일반적으로 검색 도메인보다는 제공된 도메인을 라우팅 도메인으로 사용하는 것이 더 안전합니다.
비교하다
LLMNR=
부울 또는 "구문 분석"입니다. true인 경우 링크-로컬 멀티캐스트 이름 확인이 링크에서 활성화됩니다. "해결"로 설정하면 구문 분석만 활성화되고 호스트 등록 및 공지는 활성화되지 않습니다. 기본값은 true입니다.
그러나 LLMNR은 단일 레이블 이름도 구문 분석할 수 있습니다. 누구든지 이것을 설명할 수 있나요?
원천:https://www.freedesktop.org/software/systemd/man/systemd.network.htmlsystemd 버전 239부터 시작합니다.
답변1
A Reason은 2015년에 출시되었습니다.
https://www.mail-archive.com/[이메일 보호됨]/msg31563.html
iiuc, 우려되는 점은 검색 접미사를 제어하여 다중 수준 도메인(즉, 점이 하나 이상 있는 도메인)이 스푸핑될 수 있다는 것입니다. 그러나 2개 이상의 레벨이 있는 이름의 경우 glibc는 대체 수단으로 검색 목록만 사용합니다.
물론, 검색 로직의 시작 부분에 영향을 미칠 수 있다는 것은 검색 로직의 끝 부분에 영향을 미치는 것보다 더 문제가 있지만, 여전히 "home.foobar.com"을 삽입할 수 있기 때문에 문제가 된다고 생각합니다. "를 A 도메인 "foobar.com"으로 설정합니다. 이 도메인 자체에는 "home.foobar.com"이 없고 "www.bar.com"만 있습니다...
물론, 기존(DNSSEC가 아닌) DNS는 결코 완벽하게 안전하지 않을 것입니다. 그러나 저는 여전히 더 안전한 옵션을 기본값으로 설정하고 다른 옵션을 허용해야 한다고 믿습니다.
검색 경로를 변경하는 것은 본질적으로 공용 네트워크에서는 의미가 없으며 네트워크를 잘 알고 어느 정도 신뢰하는 경우에만 의미가 있습니다. 따라서 선택하는 것이 나에게는 더 나은 선택인 것 같습니다.