Nebula 등대 DNS: 누가 어떤 레코드를 조회할 수 있나?

Nebula의 등대 역할은 사람들이 당연히 자동이라고 여기는 많은 일을 하지만, DNS 응답은 그중 하나가 아닙니다. 이름 서비스는 기본적으로 꺼진 선택적 리스너이며, 그래서 오버레이 안에서 이름 해석이 잘 되는 호스트도 동료의 노트북을 해석할 방법이 전혀 없을 수 있습니다. 켜기 전에 이 두 답이 다르다는 점을 염두에 두고 누가 접근해야 하는지, 어떤 레코드 유형에 응답할지 결정하세요.

리스너는 선택 사항이며 기본적으로 꺼져 있습니다

검색과 DNS는 별개의 서비스입니다. 등대는 피어가 서로를 찾도록 돕고 추가로 자신이 아는 호스트에 대한 이름 질의에 응답할 수 있지만, 그 두 번째 부분은 구성에서 명시적으로 켜야 합니다.

무엇이든 활성화하기 전에 어떤 인터페이스와 네트워크가 리스너에 도달해야 하는지 결정하세요. 의도하지 않은 인터페이스에서 응답하는 DNS 서비스는 아무도 읽지 않는 로그 한 줄도 없이 작은 정보 유출이 됩니다. 결정은 지금 하는 편이, 무언가 잘못된 응답에 의존한 뒤 나중에 좁히는 것보다 훨씬 저렴합니다. 설정 두 줄이 반년 뒤의 사고 기록보다 설명하기 쉽습니다.

A 레코드와 TXT는 대상을 공유하지 않습니다

이 두 레코드 유형은 서로 다른 조건에서 응답되며, 이를 하나의 서비스로 취급하는 것이 이 글이 막으려는 실수입니다.

이 비대칭은 의도된 것이지 실수가 아닙니다. 이름과 주소의 대응은 외부인에게 가치가 낮지만, 인증서 메타데이터는 오버레이의 신원을 설명합니다. 같은 프로세스가 둘 다 응답한다는 이유만으로 한 행의 가정을 다른 행으로 옮기지 마세요.

등대 자체의 호스트에 대해서만 응답합니다

이것은 사무실, 클라우드 VPC 또는 공용 인터넷을 위한 범용 리졸버가 아닙니다. 등대는 주어진 호스트 정보에서 응답하며, 그래서 이 기능은 모든 피어가 아니라 등대 노드에 있습니다.

오버레이와 무관한 이름이 실패하면 실제로 그것을 소유한 영역과 리졸버를 찾으세요. 오버레이 리졸버를 호스트의 일반 DNS 구성에 섞으면 일부 이름은 해석되고 다른 이름에는 아무것도 응답하지 않아 무작위로 보이는 장애가 생깁니다.

또한 부트스트랩 진입점도 살펴보세요. 첫 등대에 도달하는 데 쓰이는 호스트 이름은 검색이 의존하기 전에 일반적인 경로로 해석되어야 하므로, 여기서의 닭과 달걀 문제는 깨진 오버레이와 똑같이 보입니다. 보고 방식도 같은데, 결코 올라오지 않는 피어에 분명한 이유가 없습니다. 이 순서가 어려운 절반부터 시작한 사람을 잡기 때문에, 인증서를 건드리기 전에 이름 해석을 확인하세요.

바인드 주소를 확인한 뒤 외부에서 시험하세요

lighthouse.dns.host 과 lighthouse.dns.port 는 선택적 서비스가 어디에서 수신하는지 결정합니다. 이 값들은 바인드 주소가 의도 선언일 뿐 그 자체로 보안 통제는 아니므로 호스트 방화벽과 네트워크 정책과 함께 검토하세요.

dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +short

허용하려는 네트워크에서 질의하세요, 등대 자체에서가 아니라. 등대에서의 성공은 프로세스가 돌고 있다는 것을 증명할 뿐 외부 호스트가 무엇을 물을 수 있는지는 알려주지 않으며, 정작 중요한 질문은 그것입니다.

의도적으로 노출하세요

이름과 인증서 메타데이터는 유용한 운영 정보이며, 유용성은 양방향으로 작용합니다. 리스너가 오버레이 전용이어야 하는지, 어떤 레코드 유형을 허용할지, 구성이 바뀔 때 누가 검토할지 결정하세요.

그다음 등대 설정 옆에 적어 두세요. 해석 장애를 디버깅할 다음 사람은 그렇지 않으면 서비스가 늘 거기 있었다고 가정합니다. 또한 자신이 시험하는 곳 어디서든 늘 도달 가능했다고 가정합니다. 바인드 주소, 허용 네트워크, 레코드 유형을 기록한 한 문단이 그 사람의 오후를, 그리고 왜 뭔가 바뀌었는지 묻는 메시지를 당신에게서 아껴 줍니다.