eyalm2000/adns 딥다이브
— VPN 없이 안드로이드의 숨은 DNS 스위치를 한 탭으로 켜는 광고 차단기

1프로젝트 한 줄 요약

즉 ADNS의 정체는 두 겹이다. ① 얇은 스위치: OS의 숨은 DNS 설정을 대신 눌러 주는 아주 작은 코어(핵심 로직은 사실상 네 줄이다). ② 두꺼운 콘솔: NextDNS 웹 대시보드를 거의 통째로 앱 안에 재구현한 관리 화면(코드의 대부분이 여기다). 광고를 막는 기술 자체는 놀랄 만큼 단순하고, 앱의 부피는 "그 스위치를 예쁘고 편하게 감싸는" 데서 나온다.

저자 Eyal Meirom(GitHub eyalm2000)은 이 앱을 MIT 라이선스로 공개하고, F-Droid 계열 IzzyOnDroid와 GitHub Releases로 배포한다. 재현 가능한 빌드(reproducible build)를 지원해 "배포된 APK가 소스와 일치함"을 제3자가 검증할 수 있게 했고(README 상단의 RB 배지), 광고 차단 앱에 요구되는 투명성·신뢰를 정면으로 챙겼다. 2026년 현재 버전은 2.0.0-beta3.1로, 2.0에서 Wi-Fi 규칙·상태 알림·범용 DNS 서버·NextDNS 로그/설정 관리가 대거 추가됐다.

2왜 주목받는가 — "VPN 없는 광고 차단"의 정체

안드로이드에서 루팅 없이 광고를 막는 길은 사실상 두 갈래뿐이었다. ADNS는 그중 잘 안 알려진 두 번째 길을 가장 매끄럽게 포장해 등장했다.

차별점 ① — VPN을 쓰지 않는다는 근본적 이점

ADNS의 핵심 세일즈 포인트. VPN 루프백 방식은 안드로이드가 VPN을 한 번에 하나만 허용하기 때문에, 회사 VPN이나 프라이버시 VPN을 쓰면서 동시에 광고 차단을 할 수 없다. ADNS는 VPN 슬롯을 전혀 쓰지 않으므로 진짜 VPN과 광고 차단이 공존한다. 또 상시 실행되는 백그라운드 서비스가 없어 배터리·성능 부담이 사실상 0이다.

차별점 ② — "설정 깊이 숨은 기능"을 꺼내 준다

Private DNS는 이미 모든 안드로이드 9+ 기기에 있다. 하지만 설정 → 연결 → 기타 연결 설정 → 개인 DNS처럼 4~5단계 깊이에 묻혀 있고, 서버 호스트명을 손으로 타이핑해야 한다. ADNS는 이걸 첫 화면의 큰 토글 + 퀵 설정 타일(알림창 아이콘) + 홈 화면 바로가기로 끌어올린다. "기능을 새로 만든 게 아니라, 숨은 기능의 접근성을 극적으로 높인" 앱이다.

차별점 ③ — NextDNS 관리 콘솔 내장 + 재현 가능 빌드

단순 토글을 넘어, NextDNS 계정을 앱 안에서 통째로 관리한다: 실시간 로그(무엇이 차단됐나), 통계, 차단/허용 목록 편집, 도메인 재작성(rewrite), 자녀 보호, 계정 공유까지. NextDNS 웹사이트를 열 필요가 없다. 여기에 재현 가능한 빌드로 "이 APK는 이 소스에서 나왔다"를 증명하니, 내 DNS를 통째로 맡기는 광고 차단 앱에 필요한 신뢰가 확보된다.

3기술 스택 전체 지도 — Kotlin·Compose·Shizuku·NextDNS

ADNS는 웹 서버·백엔드가 없는 순수 안드로이드 클라이언트다. 그래서 스택을 "프론트/백엔드"가 아니라 이 앱이 실제로 하는 네 가지 일로 나눠 보는 게 이해가 빠르다: 화면 그리기(UI), 특권 권한 얻기(privilege), NextDNS와 통신(network), 비밀 안전 저장(crypto).

① UI 층 — 100% Kotlin + Jetpack Compose

② 특권 획득 층 — Shizuku

③ 네트워크 층 — NextDNS 관리 클라이언트

NextDNS 연동은 단순 조회가 아니라 거의 완전한 관리 API다: 프로필 목록/생성/복제/이름변경/삭제, 페이지별 설정 GET/PATCH, 차단·허용 목록, 재작성(rewrite) CRUD, 통계·로그, 기기·접근 공유, 자녀 보호까지. 엔드포인트는 api.nextdns.io(메인) · ipv4.api.nextdns.io · link-ip.nextdns.io(DDNS)로 나뉜다.

④ 보안 저장 층 — Google Tink

사용자의 NextDNS 비밀번호는 절대 저장하지 않는다. 로그인은 이메일+비밀번호(2단계 인증 지원)로 API 키를 발급받는 데만 쓰고, 발급된 API 키만 Tink로 암호화해 SharedPreferences에 넣는다. 마스터 키는 Android Keystore(android-keystore://...)에 두어, 앱 데이터를 통째로 빼가도 키 없이는 복호화가 안 된다.

4아키텍처 심화 — 설정값 하나로 광고를 막는 법

ADNS의 "광고 차단 엔진"이라 부를 만한 코드는 놀랍도록 작다. Settings.Global이라는 시스템 설정 테이블에 두 개의 키를 읽고 쓰는 게 전부다. 핵심 어댑터를 그대로 옮기면:

// data/dns/AndroidPrivateDnsAdapters.kt — "차단 엔진"의 실체
class AndroidPrivateDnsSettings(private val resolver: ContentResolver) : PrivateDnsSettings {
    override fun readMode()      = Settings.Global.getString(resolver, MODE_KEY)
    override fun readSpecifier() = Settings.Global.getString(resolver, SPECIFIER_KEY)
    override fun writeMode(v: String)      = Settings.Global.putString(resolver, MODE_KEY, v)
    override fun writeSpecifier(v: String) = Settings.Global.putString(resolver, SPECIFIER_KEY, v)
    companion object {
        const val MODE_KEY      = "private_dns_mode"       // off / opportunistic / hostname
        const val SPECIFIER_KEY = "private_dns_specifier"  // DoT 서버 호스트명
    }
}

광고 차단을 켜기 = private_dns_specifier에 광고 차단 DNS 호스트명(예: ADNS-abc123.dns.nextdns.io)을 쓰고, private_dns_mode를 "hostname"으로 쓰는 것. 그러면 OS가 기기의 모든 DNS 질의를 그 서버로 TLS 터널링하고, 서버가 광고·추적기를 걸러 준다. 끄기 = 모드를 "off" 또는 "opportunistic"(자동)으로 되돌리기.

쓰고 끝이 아니다 — "쓰고 검증"

설정 쓰기는 실패하거나 다른 앱·OS가 되돌릴 수 있다. 그래서 PrivateDnsController는 쓴 다음 즉시 다시 읽어 기대값과 같은지 확인하고, 결과를 봉인 클래스(sealed class)로 돌려준다.

// data/dns/PrivateDnsController.kt — write-and-verify 상태기계
override suspend fun enable(hostname: String?): DnsWriteResult {
    val normalized = PrivateDnsHostname.parsePreservingCase(hostname)?.ascii
        ?: return DnsWriteResult.MissingHostname
    return writeAndVerify(expected = Hostname(normalized)) {
        settings.writeSpecifier(normalized) && settings.writeMode(MODE_HOSTNAME)
    }
}
// 결과 타입: Success / PermissionMissing / MissingHostname / Rejected / Failure

그런데 그 4줄을 실행할 "권한"이 문제

Settings.Global.putString은 WRITE_SECURE_SETTINGS 권한이 있어야 한다. 일반 앱은 이 권한을 못 가진다. ADNS는 Shizuku를 통해 우회한다. Shizuku가 띄운 shell 권한 프로세스 안에서 작은 서비스(PrivilegedService)를 돌리고, 그 서비스가 pm grant 명령으로 앱 자신에게 권한을 부여한다.

// PrivilegedService.kt — Shizuku shell 프로세스 안에서 실행됨
override fun grantWriteSecureSettings(packageName: String): Boolean {
    if (packageName != BuildConfig.APPLICATION_ID)          // 자기 패키지에만
        throw SecurityException("non-app 패키지엔 부여 거부")
    val proc = ProcessBuilder(
        "pm", "grant", packageName, "android.permission.WRITE_SECURE_SETTINGS"
    ).redirectErrorStream(true).start()
    if (proc.waitFor() != 0) throw RuntimeException("pm grant 실패")
    return true
}

Shizuku가 없는 사용자는 PC에서 딱 한 줄을 실행하면 된다(앱이 안내):

adb shell pm grant com.eyalm.adns android.permission.WRITE_SECURE_SETTINGS

전체 요청 흐름

주목할 점은 상태를 능동적으로 감시한다는 것이다. DnsRepository는 두 시스템 설정 URI에 ContentObserver를 걸고 이를 Flow로 노출한다. 그래서 사용자가 안드로이드 설정 앱에서 직접 Private DNS를 꺼도, ADNS의 퀵 설정 타일·상태 알림·앱 화면이 즉시 실제 상태를 반영한다. "내 앱이 켰다"가 아니라 "지금 OS가 실제로 이 상태다"를 진실의 원천으로 삼는다.

5디렉토리 구조 해부

구조가 말해 주는 핵심: 광고를 막는 dns/ 코어는 아주 작고, 부피의 대부분은 nextdns/(약 45개 파일)라는 NextDNS 웹 콘솔의 앱 내 재구현과 UI다. 즉 "차단"은 단순하고, "관리·편의"가 이 앱의 진짜 노동량이다.

6학습 포인트 — 여기서 훔쳐올 설계

배울 것 ① — "새 기능을 만들지 말고, 숨은 OS 기능을 꺼내라"

ADNS의 가장 큰 교훈은 기술이 아니라 발상이다. 광고 차단 엔진을 새로 짜는 대신, 이미 OS에 있는 Private DNS를 접근성만 극적으로 높여 제품으로 만들었다. "사용자가 원하는 기능이 이미 OS·플랫폼에 있는데 너무 깊이 묻혀 있진 않은가?"를 묻는 습관은, 앱 아이디어를 찾을 때 강력한 렌즈다.

배울 것 ② — Shizuku로 루팅 없이 특권 얻기

루팅 없이 시스템 설정을 건드리는 Shizuku + AIDL 서비스 + pm grant 패턴은 그대로 재사용 가능한 레시피다. 자동화·백업·시스템 튜닝 앱을 만들 때, VPN이나 접근성 서비스 같은 침습적 우회 없이 특권 작업을 수행하는 정석 경로를 보여 준다. OnboardingViewModel의 "권한 요청 → 서비스 바인드 → grant → 폴링으로 확인" 흐름이 참고 표본이다.

배울 것 ③ — 인터페이스/어댑터로 안드로이드를 테스트 가능하게

안드로이드 코드는 Context·ContentResolver 의존 때문에 테스트가 어렵기로 악명 높다. ADNS는 PrivateDnsSettings(순수 인터페이스) ↔ AndroidPrivateDnsSettings(실제 구현)처럼 경계마다 인터페이스를 두어, 컨트롤러·리포지토리를 가짜 구현으로 단위 테스트한다. 봉인 클래스 결과 타입(DnsWriteResult·ApiResult)과 결합해, "성공/실패의 모든 경로"를 테스트로 못박는 법을 보여 준다.

배울 것 ④ — 비밀은 Tink + Keystore로

API 키·토큰을 SharedPreferences에 평문으로 넣는 실수는 흔하다. ADNS의 TokenManager는 Google Tink AEAD(AES-256-GCM)로 암호화하고 마스터 키를 Android Keystore에 둔다. "비밀번호는 아예 저장 안 하고 API 키만, 그 키도 암호화해서"라는 최소 보관 + 암호화 원칙이 그대로 담겨 있다.

배울 것 ⑤ — 재현 가능한 빌드로 신뢰 만들기

내 DNS를 맡기는 앱은 "배포된 APK가 정말 이 오픈소스에서 나왔나"가 중요하다. ADNS는 빌드 결과에서 dependenciesInfo를 제거하는 등 재현 가능 빌드를 맞추고, rbtlog.dev 배지로 제3자 검증을 노출한다. 오픈소스 신뢰를 주장이 아니라 검증 가능한 사실로 만드는 실전 사례다.

7시스템 / 실행 요구사항

매니페스트의 권한 목록이 이 앱의 성격을 압축한다: 핵심은 WRITE_SECURE_SETTINGS, 그 외 INTERNET(NextDNS 통신), POST_NOTIFICATIONS(상태 알림), ACCESS_WIFI_STATE·위치 권한(Wi-Fi 규칙), FOREGROUND_SERVICE·RECEIVE_BOOT_COMPLETED(재부팅 후 상태 유지). 빌드 플레이버는 normal / foss 두 종으로, F-Droid 배포용 foss는 IS_FOSS=true로 비자유 요소를 배제한다.

8직접 해볼 수 있는 실습 과제

9관련 기술 심화 학습 로드맵

10핵심 키워드 사전

11참고 링크

저장소 · 배포

• github.com/eyalm2000/adns — 원본 저장소(MIT, Eyal Meirom)
• IzzyOnDroid — com.eyalm.adns — F-Droid 계열 배포(재현 가능 빌드 검증)

핵심 배경 기술

• Android — Settings.Global · RFC 7858 — DNS over TLS
• Shizuku — 루팅 없는 특권 실행 중개 도구
• NextDNS · AdGuard DNS — 필터링 DNS 서비스

안드로이드 개발 스택

• Jetpack Compose · Material 3 — 선언형 UI·디자인 시스템
• Google Tink · OkHttp / Retrofit — 암호화·네트워킹