[웹 기반기술 46] DNS - 이메일과 도메인 인증

도메인은 웹 주소만 담는 것이 아니라 전자우편의 신원도 담는다. 어떤 이름으로 오는 편지를 어느 서버가 받을지, 그 이름으로 나가는 편지가 정말 그 도메인에서 보낸 것인지가 모두 도메인의 레코드에 걸려 있다. 전자우편은 태생적으로 발신자를 쉽게 위조할 수 있게 설계되어, 이 위조를 막는 인증 장치들이 뒤늦게 도메인 위에 얹혔다. 이 장치들을 갖추지 않으면 도메인의 이름을 사칭한 편지가 퍼진다.

이번 편은 도메인과 전자우편 인증을 다룬다. 전자우편이 도메인 위에 어떻게 놓이는지, 발신 위조가 왜 근본적인 문제인지, 발신 서버를 밝히는 정책은 무엇인지, 서명으로 무결성을 지키는 방법은 무엇인지, 이 둘을 정책과 보고로 묶는 장치는 무엇인지, 도메인 소유 증명과 정렬은 어떻게 이루어지는지, 그리고 전자우편 인증의 함정은 무엇인지를 차례로 짚는다. 이 인증들을 갖추면 도메인의 이름이 사칭으로부터 지켜진다.

도메인 위에 놓인 전자우편

도메인으로 오는 전자우편은 전용 레코드가 안내하는 서버가 받는다. 이 레코드는 어느 서버가 그 도메인의 편지를 받을지를 지정하며, 우선순위를 함께 담아 앞선 서버가 응답하지 않으면 다음 서버로 넘어가게 한다. 웹을 안내하는 레코드와 전자우편을 안내하는 레코드가 따로이므로, 웹 서버와 메일 서버는 얼마든지 다른 곳에 둘 수 있다.

편지를 받는 일과 보내는 일은 서로 다른 경로를 탄다. 받는 경로는 이 안내 레코드로 정해지지만, 보내는 편지가 정말 그 도메인에서 나온 것인지를 받는 쪽이 확인하는 일은 또 다른 레코드들에 기댄다. 그래서 전자우편 인증은 받는 안내와 별개로, 보내는 편지의 진위를 검증하는 여러 정책을 도메인에 얹는 방식으로 이루어진다.

이 인증 정책들은 대개 자유로운 문자열을 담는 레코드에 실린다. 발신 서버를 밝히는 정책, 서명을 검증하는 열쇠, 위조 편지를 어떻게 처리할지 정하는 지침이 모두 이 레코드에 문자열로 담긴다. 받는 쪽 서버는 편지가 도착하면 발신 도메인의 이 레코드들을 조회해 편지의 진위를 판단한다. 도메인의 레코드가 곧 그 도메인이 보낸 편지의 신원 증명이 되는 것이다.

전자우편 인증을 갖추는 것은 두 방향의 이익이 있다. 하나는 자신의 도메인 이름이 사칭되어 스팸이나 사기에 쓰이는 것을 막는 것이고, 다른 하나는 자신이 보낸 정당한 편지가 위조로 오인되어 버려지지 않게 하는 것이다. 인증이 없으면 사칭에 취약하고, 잘못 설정하면 정당한 편지마저 차단된다. 그래서 이 설정은 정확히 갖추는 것이 중요하다.

발신 위조라는 문제

전자우편은 발신자 표시를 보내는 쪽이 마음대로 적을 수 있게 설계되었다. 편지에 적힌 발신 주소는 실제로 그 도메인이 보냈다는 증거가 아니라, 그저 보내는 쪽이 써넣은 값일 뿐이다. 그래서 아무나 남의 도메인 이름을 발신자로 적어 편지를 보낼 수 있다. 이 근본적인 허점이 사칭 편지와 사기의 온상이 되어 왔다.

이 위조가 위험한 이유는 받는 사람이 발신자 표시를 신뢰하기 때문이다. 익숙한 기관의 이름이 발신자로 적혀 있으면 사람들은 그 편지를 믿고 첨부를 열거나 링크를 누른다. 위조된 발신자 하나가 사람의 신뢰를 통째로 훔치는 것이다. 그래서 발신자가 정말 그 도메인인지를 기계적으로 검증하는 장치가 필요해졌다.

이 문제를 푸는 인증은 세 가지 축으로 이루어진다. 하나는 어떤 서버가 그 도메인을 대신해 편지를 보낼 수 있는지를 밝히는 것이고, 다른 하나는 편지에 도메인의 서명을 붙여 내용이 위조되지 않았음을 증명하는 것이며, 마지막은 이 둘의 결과를 종합해 위조로 판단된 편지를 어떻게 처리할지 정하는 것이다. 세 축이 함께 작동해야 위조를 효과적으로 막는다.

이 세 축은 각각 독립적으로도 어느 정도 작동하지만, 함께 갖추어야 온전하다. 발신 서버를 밝히는 것만으로는 편지가 중간에 변조되는 것을 막지 못하고, 서명만으로는 정책적 대응을 정할 수 없다. 세 장치는 서로의 빈틈을 메우도록 설계되었으므로, 하나만 갖추고 만족하기보다 셋을 함께 갖추는 것이 목표가 되어야 한다.

발신 서버를 밝히는 정책

첫 번째 축은 그 도메인을 대신해 편지를 보낼 수 있는 서버가 어디인지를 도메인이 미리 밝히는 것이다. 도메인의 레코드에 정당한 발신 서버들의 목록을 담아 두면, 편지를 받은 쪽은 그 편지가 온 서버가 이 목록에 있는지를 확인한다. 목록에 없는 서버에서 온 편지는 그 도메인이 인정하지 않은 발신으로 간주된다.

이 정책은 발신 경로를 검증하지만 편지의 내용까지 보증하지는 않는다. 목록에 있는 서버에서 왔다는 것은 발신 경로가 정당하다는 뜻일 뿐, 그 편지의 본문이 도중에 바뀌지 않았는지는 알려 주지 않는다. 또한 편지가 중간에서 전달되어 경로가 바뀌면, 정당한 편지인데도 목록에 없는 서버를 거쳐 검증에 실패할 수 있다. 이 한계 때문에 이 정책만으로는 부족하다.

정책을 지나치게 느슨하거나 엄격하게 잡는 것 모두 문제를 낳는다. 목록을 너무 넓게 열면 사칭을 걸러 내는 힘이 약해지고, 너무 좁게 잡으면 정당한 발신 경로를 빠뜨려 자신의 편지가 차단된다. 특히 외부 서비스를 통해 편지를 보내는 경우, 그 서비스의 서버를 목록에 포함하지 않으면 그 경로로 나간 편지가 위조로 오인된다. 발신 경로를 빠짐없이 파악해 목록에 담는 것이 중요하다.

이 정책은 문자열 레코드로 표현되며, 허용된 서버와 그 밖의 편지를 어떻게 볼지에 대한 지침을 함께 담는다. 목록에 없는 서버의 편지를 확실히 거부하라고 할 수도, 의심스럽게만 표시하라고 할 수도 있다. 도입 초기에는 느슨하게 두어 정당한 편지가 차단되지 않는지 살핀 뒤, 확신이 서면 점차 엄격하게 조이는 접근이 안전하다.

서명으로 무결성을 지키기

두 번째 축은 편지에 도메인의 서명을 붙이는 것이다. 발신 서버는 편지를 보낼 때 도메인의 비밀 열쇠로 서명을 만들어 편지에 담고, 그에 대응하는 공개 열쇠는 도메인의 레코드에 올려 둔다. 받는 쪽은 편지의 서명을 도메인 레코드의 공개 열쇠로 검증해, 그 편지가 정말 그 도메인에서 서명되었고 내용이 바뀌지 않았음을 확인한다.

이 서명은 발신 경로가 아니라 편지 자체의 진위를 보증한다는 점에서 앞의 정책과 다르다. 서명이 검증되면 그 편지가 도메인의 열쇠로 서명되었고 서명된 부분이 도중에 변조되지 않았음이 확실해진다. 편지가 중간에서 전달되어 경로가 바뀌어도 서명은 편지에 붙어 함께 이동하므로, 경로 변화에 상대적으로 강하다. 이 성질이 발신 경로 검증의 약점을 메운다.

서명의 신뢰는 비밀 열쇠를 지키는 데 달려 있다. 도메인의 비밀 열쇠가 유출되면 공격자가 정당한 서명을 위조할 수 있으므로, 이 열쇠는 발신 서버 안에 안전하게 보관되어야 한다. 공개 열쇠는 레코드에 공개되어도 무방하지만 비밀 열쇠는 새어 나가서는 안 된다. 열쇠를 주기적으로 교체하고 옛 열쇠를 정리하는 관리도 함께 필요하다.

서명 역시 그 자체로는 정책적 대응을 정하지 못한다. 서명이 없거나 검증에 실패한 편지를 어떻게 처리할지는 서명 장치가 정하는 것이 아니라, 세 번째 축이 정한다. 서명은 진위를 판별하는 근거를 제공할 뿐, 그 판별 결과에 따라 무엇을 할지는 별도의 정책이 결정한다. 그래서 서명은 세 번째 축과 결합될 때 온전한 힘을 갖는다.

정책과 보고를 묶기

세 번째 축은 앞의 두 검증 결과를 종합해 위조로 판단된 편지를 어떻게 처리할지 정하는 정책이다. 이 정책은 발신 경로 검증과 서명 검증이 모두 실패한 편지를 그대로 받을지, 의심스럽게 분류할지, 아예 거부할지를 도메인이 지정한다. 받는 쪽 서버는 이 지침을 따라 위조 의심 편지를 처리한다. 도메인이 자신의 이름을 사칭한 편지의 운명을 스스로 정하는 것이다.

이 정책의 핵심 개념은 정렬이다. 편지에 적힌 발신 도메인과 앞의 두 검증이 확인한 도메인이 서로 일치하는지를 따지는 것이다. 발신 경로나 서명이 검증되더라도 그 도메인이 편지에 표시된 발신 도메인과 다르면, 사용자가 보는 발신자는 여전히 사칭일 수 있다. 정렬은 사용자가 실제로 보는 발신자 이름까지 검증이 이어지게 하는 장치다.

이 정책에는 보고 기능이 함께 딸려 있다. 도메인은 자신의 이름으로 오간 편지들의 검증 결과를 주기적으로 보고받도록 설정할 수 있다. 이 보고를 보면 어떤 서버가 자신의 이름으로 편지를 보내고 있는지, 정당한 발신은 잘 검증되는지, 사칭 시도는 얼마나 되는지를 파악할 수 있다. 보고는 정책을 조이기 전에 현황을 파악하는 눈이 된다.

정책은 처음부터 강하게 걸지 않는 것이 안전하다. 위조 편지를 곧바로 거부하도록 강하게 설정했다가 정당한 발신 경로를 빠뜨렸다면, 자신의 정당한 편지가 대량으로 차단된다. 그래서 처음에는 아무것도 거부하지 않고 보고만 받는 관찰 단계에서 시작해, 보고를 통해 모든 정당한 경로가 검증됨을 확인한 뒤 점차 정책을 강화하는 순서를 밟는다.

소유 증명과 정렬의 실제

전자우편 서비스를 도메인에 연결할 때는 대개 소유 증명이 선행된다. 외부 편지 서비스가 그 도메인의 편지를 대신 다루려면, 그 도메인이 정말 요청자의 것인지를 확인해야 하기 때문이다. 지정된 문자열을 도메인의 레코드에 넣으면, 그 값을 넣을 수 있다는 사실이 소유를 증명한다. 도메인의 관리 권한을 신뢰의 근거로 삼는 이 방식은 앞서 다룬 인증서 검증과 같은 원리다.

외부 편지 서비스를 쓸 때는 그 서비스의 발신 경로와 서명 열쇠를 자신의 도메인 인증에 포함해야 한다. 그 서비스가 도메인을 대신해 편지를 보내므로, 발신 서버 목록에 그 서비스를 넣고 서명 열쇠를 도메인 레코드에 올려야 그 편지가 정당하게 검증된다. 이 연결을 빠뜨리면 외부 서비스로 보낸 편지가 사칭으로 오인된다. 외부 서비스 연동은 인증 설정과 짝을 이루어 이루어져야 한다.

정렬을 맞추는 일은 특히 외부 서비스에서 까다롭다. 외부 서비스가 자신의 도메인으로 편지를 보내면서 발신자 표시만 내 도메인으로 적으면, 검증은 통과해도 정렬이 어긋나 사용자가 보는 발신자가 검증된 도메인과 달라진다. 그래서 외부 서비스가 내 도메인 이름으로 발신하고 서명하도록 설정해, 검증된 도메인과 표시된 발신 도메인이 일치하게 맞추어야 한다.

이 설정들은 한 번에 완성되기보다 보고를 보며 다듬어진다. 처음 설정한 뒤 보고를 통해 어떤 경로가 검증에 실패하는지를 확인하고, 빠뜨린 발신 경로를 채우거나 정렬이 어긋난 서비스를 바로잡는 과정을 반복한다. 전자우편 인증은 한 번 켜고 잊는 것이 아니라, 보고를 통해 지속적으로 점검하고 조율하는 살아 있는 설정이다.

전자우편 인증의 함정

가장 흔한 함정은 정당한 발신 경로를 빠뜨린 채 정책을 강하게 거는 것이다. 여러 부서나 외부 서비스가 같은 도메인으로 편지를 보내는데 그중 일부를 인증 설정에 포함하지 않으면, 그 경로로 나간 편지가 위조로 처리되어 사라진다. 정책을 강화하기 전에 모든 발신 경로를 보고로 파악하는 관찰 단계를 충분히 거쳐야 한다.

두 번째 함정은 서명 열쇠를 방치하는 것이다. 열쇠를 한번 설정한 뒤 교체하지 않으면 유출 위험이 누적되고, 열쇠를 옮기거나 서비스를 바꾸면서 옛 열쇠 레코드를 지우지 않으면 낡은 열쇠가 남아 혼란을 준다. 열쇠는 주기적으로 교체하고, 쓰지 않게 된 열쇠 레코드는 정리해야 한다. 서명 장치도 관리가 필요한 살아 있는 설정이다.

세 번째 함정은 발신 서버 목록을 지나치게 길게 늘이는 것이다. 이 목록은 편지를 받는 쪽이 조회하는데, 목록이 여러 단계의 참조로 길게 이어지면 검증이 느려지거나 조회 한계를 넘어 실패한다. 발신 경로를 최소한으로 정리하고 참조 단계를 줄여, 목록이 간결하게 유지되도록 관리해야 한다. 많은 경로를 무작정 나열하는 것은 오히려 검증을 무너뜨린다.

마지막 함정은 인증을 웹과 무관한 것으로 여겨 소홀히 하는 것이다. 전자우편 인증은 웹 개발과 동떨어진 영역처럼 보이지만, 같은 도메인의 신뢰를 지키는 일이라는 점에서 웹의 인증서만큼이나 중요하다. 도메인의 이름이 사칭되면 그 도메인이 운영하는 웹 서비스의 신뢰까지 함께 훼손된다. 이렇게 전자우편이 도메인 위에 놓이는 방식, 위조의 문제, 세 축의 인증, 소유 증명과 정렬, 그리고 함정까지 이해하면 도메인의 이름이 편지에서도 지켜진다. 다음 편은 이 도메인이 검색에 어떻게 관여하는지를 다룬다.