블로그 - 寧屏 기술 공유 및 제품 업데이트

• 닝핑 광고 차단: DNS 기반 스마트 광고 차단 솔루션
• DoH와 DoT 기술 비교 분석
• DNS 프라이버시 보호 및 사용자 프로파일링 방지 전략
• 심층 분석: 寧屏 DNS 프록시 기능으로 네트워크 제한을 돌파하고 프라이버시 보호 실현
• AdGuardPrivate 명칭 변경 공지
• DDNS 기능 추가
• ECS에 대한 더 나은 지원
• NullPrivate - AdGuard Home 기반 강화형 DNS 서비스
• HTTP/3 프로토콜 전면 지원
• 사용자 정의 클라이언트 이름 기능 출시
• 광고 차단의 필요성: 디지털 시대의 주의력과 프라이버시 보호
• 서비스 리소스 최적화 전략 안내
• 기본 버전 메모리 상한 조정
• 언제든지 지원 서비스 제공
• 전용 링크 설정 방법
• 새로운 업그레이드 — 강화형 광고 차단 규칙
• 체험판 서비스 상세

닝핑 광고 차단: DNS 기반 스마트 광고 차단 솔루션

오늘날 디지털 시대에 광고는 인터넷 생태계의 중요한 구성 요소가 되었지만, 과도한 광고는 사용자 경험을 해칠 뿐 아니라 개인정보 유출 위험도 초래할 수 있습니다. 닝핑(NullPrivate)은 개인정보 보호에 특화된 DNS 서비스로, AdGuard Home과 유사한 DNS 필터링 기술을 채택하여 사용자에게 효율적인 광고 차단 솔루션을 제공합니다.

닝핑 광고 차단의 작동 원리

닝핑의 광고 차단 기능은 DNS(도메인 시스템) 필터링 기술을 기반으로 하며, 다음과 같은 워크플로우를 따릅니다:

flowchart TB
    A[사용자 기기] --> B{DNS 쿼리 요청}
    B --> C[닝핑 DNS 서버]
    C --> D[도메인 데이터베이스 조회]
    D --> E{광고 또는 추적 도메인?}
    E -->|예| F[빈 주소 또는 루프백 주소 반환]
    E -->|아니오| G[정확한 IP 주소 반환]
    F --> H[광고 로딩 차단]
    G --> I[정상적인 웹사이트 접속]

DNS 요청 모니터링

기기에서 웹사이트에 접속하려고 할 때, 먼저 DNS 서버에 도메인에 해당하는 IP 주소를 쿼리합니다. 닝핑을 기본 DNS 서버로 설정하면, 닝핑이 이러한 쿼리 요청을 수신하고 분석합니다.

스마트 필터링 메커니즘

닝핑은 방대한 광고 및 추적 도메인 데이터베이스를 유지 관리합니다. 사용자가 접속하려는 도메인이 광고 또는 추적 범주에 속하는 것으로 감지되면 시스템이 즉시 해당 요청을 차단합니다.

고효율 응답

차단된 요청에 대해 닝핑은 빈 주소 또는 로컬 루프백 주소(예: 127.0.0.1)를 반환하여 광고 콘텐츠 로딩을 방지합니다. 정상적인 웹사이트 접속 요청에 대해서는 올바른 IP 주소를 제공하여 사용자가 목표 사이트에 정상적으로 접속할 수 있도록 합니다.

기술적 이점

고효율성

• 네트워크 레벨 차단: DNS 해석 단계에서 광고 로딩을 차단하여 웹 콘텐츠 다운로드를 기다릴 필요 없음
• 밀리초 단위 응답: 로컬라이즈된 DNS 응답 메커니즘으로 웹페이지 로딩 속도에 거의 영향을 주지 않음
• 모든 기기 보호: 한 번 설정하면 네트워크 내 모든 기기를 보호

정확성

• 다층 필터링: 정확한 도메인 매칭, 와일드카드 규칙, 정규 표현식 지원
• 스마트 분류: 필터링 규칙을 광고, 추적기, 악성 소프트웨어 등으로 분류 관리
• 동적 업데이트: 신뢰할 수 있는 소스로부터 최신 필터링 규칙을 정기적으로 가져옴

개인정보 보호

• 흔적 없는 브라우징: 사용자 접속 기록을 기록하지 않아 브라우징 프라이버시 보호
• 데이터 유출 감소: 광고주 및 추적기가 사용자 데이터를 수집하는 것을 차단
• 로컬 처리: 대부분의 필터링 작업이 로컬에서 수행되어 데이터 유출 위험 감소

AdGuard Home과의 유사점

닝핑은 광고 차단 측면에서 AdGuard Home과 동일한 핵심 기술 원리를 채택하고 있습니다:

1. DNS 기반 필터링 메커니즘: 둘 다 DNS 쿼리를 차단하여 광고 도메인 해석을 방지
2. 필터링 규칙 관리: 사용자 정의 필터링 규칙 및 화이트/블랙리스트 구성 지원
3. 네트워크 범위 보호: 전체 LAN에 광고 차단 서비스를 제공
4. 오픈소스 커뮤니티 지원: 오픈소스 커뮤니티에서 유지 관리하는 필터링 규칙 목록의 혜택을 받음

사용자 경험 최적화

닝핑은 설계 단계에서 사용자 경험에 특히 중점을 두어, 광고 차단 기능이 효율적이면서도 정상적인 사용에 방해가 되지 않도록 합니다:

투명한 관리

• 상세한 차단 통계 정보를 제공하여 보호 효과를 사용자에게 알림
• 유연한 화이트리스트 구성을 지원하여 중요 웹사이트를 오차단 방지
• 실시간으로 적용되는 규칙 업데이트로 기기 재시작 불필요

사용 편의성 설계

• 설정 절차를 간소화하여 일반 사용자도 쉽게 사용 가능
• 다국어 지원으로 다양한 사용자 요구 충족
• 다양한 네트워크 환경 및 기기 유형과 호환
• 안정적이고 신뢰할 수 있는 DNS 서버 지원

개인정보 보호

• 엄격한 개인정보 보호 조치로 사용자 프라이버시 보호
• 사용자 개인 식별 정보를 수집하지 않음
• 사용자 데이터 보안 보장

사용 권장사항

최상의 광고 차단 효과를 얻기 위해 사용자에게 다음을 권장합니다:

1. 규칙 적절히 구성: 실제 필요에 따라 적절한 필터링 규칙 목록 선택
2. 정기적으로 업데이트 확인: 필터링 규칙 라이브러리가 최신 상태인지 확인
3. 차단 통계 확인: 통계 데이터를 통해 광고 차단 효과 파악
4. 화이트리스트 즉시 조정: 오차단된 정상 웹사이트를 화이트리스트에 추가

결론

닝핑은 첨단 DNS 필터링 기술을 통해 사용자에게 효율적이고 정확하며 개인정보 보호에 중점을 둔 광고 차단 솔루션을 제공합니다. 우리는 사용자가 광고로부터 보호받으면서도 정상적인 네트워크 사용 경험에 영향을 주지 않도록 노력하고 있습니다. 닝핑을 선택하면 더욱 깔끔하고 안전한 네트워크 환경을 만날 수 있습니다.

디지털 시대에 모든 사람은 깨끗하고 프라이빗한 사이버 공간을 가질 자격이 있습니다. 닝핑은 바로 이러한 목표를 달성하기 위해 설계되었으며, 사용자가 자신의 디지털 라이프를 다시 통제할 수 있도록 돕습니다.

DoH와 DoT 기술 비교 분석

DNS over HTTPS(DoH)와 DNS over TLS(DoT)는 두 가지 일반적인 암호화 DNS 전송 방식으로, 서로 다른 프로토콜 스택을 통해 DNS 쿼리의 안전한 전송을 구현합니다. DoT 표준은 RFC 7858에 정의되어 있으며, DoH는 DNS Queries over HTTPS (DoH)로 표준화되었습니다. 이 두 기술의 본질적 차이를 이해하려면 네트워크 프로토콜 계층 구조 분석이 필요합니다.

네트워크 프로토콜 계층 구조

현대 네트워크 프로토콜 스택은 계층적 설계를 채택하여 각 계층이 서로 다른 기능을 제공합니다. DNS는 애플리케이션 계층 프로토콜로서 특정 전송 방식에 구애받지 않고 다양한 운반 프로토콜 위에서 실행될 수 있습니다.

애플리케이션 계층(L7)에는 HTTP/1.1, HTTP/2, HTTP/3, FTP 및 DNS와 같은 프로토콜이 포함됩니다. 주목할 점은 HTTP/3의 의미론은 여전히 애플리케이션 계층에 있지만 QUIC가 전송 운반체로 사용된다는 것입니다. 보안 계층은 애플리케이션 계층과 전송 계층 사이에 위치하며 주로 TLS와 그 변종으로 구성됩니다. TLS는 일반적으로 TCP 위에서 실행됩니다(예: HTTPS 및 DoT). DTLS는 TLS의 데이터그램 버전으로 UDP 위에서 실행될 수 있습니다. QUIC 프로토콜은 특이하게 TLS 1.3 핸드셰이크와 키 유도를 프로토콜 내부에 직접 통합했습니다.

QUIC는 L4.5 계층 프로토콜로 간주될 수 있으며, UDP를 기반으로 확장되어 기존 전송 계층의 기능을 제공합니다. 전송 계층(L4)에는 TCP, UDP 및 QUIC가 포함됩니다. 엔지니어링 구현 관점에서 QUIC는 UDP를 기반으로 하지만 자체적인 신뢰성, 혼잡 제어, 멀티플렉싱 및 암호화 핸드셰이크 기능을 갖추고 있어 엔지니어링 상 독립적인 전송 계층 프로토콜로 간주됩니다. 네트워크 계층(L3)은 IP 프로토콜(IPv4/IPv6)을 사용하여 데이터 패킷의 경로 선택과 전달을 담당합니다. 데이터 링크 계층(L2)에는 이더넷 및 Wi-Fi(802.11) 기술 등이 포함됩니다.

TLS는 암호화 수단으로 애플리케이션 계층과 전송 계층 사이에서 작동합니다. 만약 TLS 암호화를 DoT에서 제거한다면, DoT는 본질적으로 DNS over TCP가 됩니다. 이러한 계층적 설계는 암호화를 프로토콜 자체의 강제적 제약이 아닌 선택 사항으로 만듭니다.

Plain DNS의 특징

가장 일반적인 DNS를 Plain DNS라고 하며, UDP 또는 TCP 위에서 실행될 수 있습니다. UDP는 연결 설정이 간단하고 초기 쿼리 속도가 빠르기 때문에 가장 일반적인 운반 방식입니다. 하지만 UDP의 약점은 신뢰할 수 없으며 데이터 패킷이 네트워크에서 손실되기 쉽다는 점입니다. TCP는 핸드셰이크 횟수가 많아 초기 연결 속도가 UDP보다 약 30% 느리지만, 장기 연결을 설정한 후 응답 속도는 UDP와 동일합니다.

네트워크 운영사는 네트워크가 혼잡할 때 장비 부하를 완화하기 위해 UDP 패킷을 선택적으로 폐기합니다. 일부 운영사의 UDP 패킷 손실이 심한 지역에서는 DNS 쿼리에 TCP를 사용하는 것이 더 유리할 수 있습니다. TCP에는 재전송 메커니즘이 있어 패킷이 손실되더라도 데이터가 안정적으로 도달하는 것을 보장하는 반면, UDP 패킷 손실은 소규모 운영사 장비의 부하를 줄이지 못하고 재시도로 인해 더 많은 불확실성을 초래합니다.

애플리케이션 계층 중첩

DNS와 HTTP는 모두 애플리케이션 계층 프로토콜이며, DoH는 본질적으로 한 애플리케이션 계층 프로토콜이 다른 애플리케이션 계층 프로토콜을 중첩한 것입니다. DoH가 반드시 DNS over HTTPS일 필요는 없으며, 일반 HTTP를 사용하는 것도 가능합니다. 다만 암호화되지 않은 DoH는 평문 요청으로서 Plain DNS에 비해 아무런 이점이 없으며 극히 드문 특수 요구 시나리오에서만 사용됩니다.

이론적으로는 모든 애플리케이션 계층 프로토콜 위에 DNS를 운반할 수 있습니다. 예를 들어 DNS over FTP도 구현 가능하며, 해당 서버 및 클라이언트를 개발하기만 하면 됩니다. 이러한 유연성은 애플리케이션 계층 프로토콜 조합의 가능성을 보여줍니다.

flowchart TD
    subgraph L7["애플리케이션 계층"]
        A[DNS]
        B[HTTP]
        C[FTP]
    end
    
    subgraph Security["보안 계층"]
        D[TLS]
        E[DTLS]
    end
    
    subgraph Transport["전송 계층"]
        F[TCP]
        G[UDP]
        H[QUIC]
    end
    
    subgraph L3["네트워크 계층"]
        I[IP]
    end
    
    subgraph L2["데이터 링크 계층"]
        J[Ethernet]
        K[WiFi]
    end
    
    A --> D
    B --> D
    C --> D
    D --> F
    E --> G
    H --> G
    F --> I
    G --> I
    H --> I
    I --> J
    I --> K
    
    style A fill:#e1f5ff
    style B fill:#e1f5ff
    style C fill:#e1f5ff
    style D fill:#fff4e1
    style E fill:#fff4e1
    style F fill:#ffe1e1
    style G fill:#ffe1e1
    style H fill:#e1ffe1

전송 계층 중첩

QUIC 프로토콜은 UDP를 기반으로 하면서 전송 계층에서 연결 지향적 서비스를 제공합니다. QUIC는 TCP가 가진 연결 지향성, 혼잡 제어, 재전송, 흐름 제어, 분할 및 조립 등의 전송 계층 기능을 구현합니다. TCP에 비해 QUIC는 지연 시간이 더 짧습니다. UDP에 비해 QUIC는 더 진보적이고 신뢰할 수 있습니다.

프로토콜 조합 관계

애플리케이션 계층과 전송 계층 사이에는 필연적인 제한 관계가 없으며, 암호화는 추가되거나 추가되지 않을 수 있습니다. HTTP는 TCP 위에서 실행될 수도 있고 QUIC 위에서 실행될 수도 있습니다. DNS는 TCP 위에서 실행될 수도 있고, UDP 위에서 실행될 수도 있으며, QUIC 위에서 실행될 수도 있습니다.

이러한 가능성을 바탕으로 다음과 같은 조합 관계를 정리할 수 있습니다. Plain DNS는 UDP 또는 TCP에 DNS 프로토콜을 더한 것과 같습니다. HTTP/2는 TCP에 TLS 1.2 또는 TLS 1.3을 더하고 HTTP 프로토콜을 더한 것과 같습니다. HTTP/3은 QUIC에 TLS 1.3을 더하고 HTTP 프로토콜을 더한 것과 같습니다.

DoH(DNS over HTTPS)는 HTTP/2 또는 HTTP/3에 DNS 프로토콜을 더한 것과 같습니다. DoT(DNS over TLS)는 TCP에 TLS 1.2 또는 TLS 1.3을 더하고 DNS 프로토콜을 더한 것과 같습니다. DoQ(DNS over QUIC)는 QUIC에 TLS 1.3을 더하고 DNS 프로토콜을 더한 것과 같습니다.

flowchart LR
    subgraph DoT["DoT DNS over TLS"]
        direction LR
        T1[TCP] --> T2[TLS]
        T2 --> T3[DNS]
    end
    
    subgraph DoH2["DoH over HTTP/2"]
        direction LR
        H1[TCP] --> H2[TLS]
        H2 --> H3[HTTP/2]
        H3 --> H4[DNS]
    end
    
    subgraph DoH3["DoH over HTTP/3"]
        direction LR
        Q1[QUIC] --> Q2[TLS 1.3]
        Q2 --> Q3[HTTP/3]
        Q3 --> Q4[DNS]
    end
    
    subgraph DoQ["DoQ DNS over QUIC"]
        direction LR
        D1[QUIC] --> D2[TLS 1.3]
        D2 --> D3[DNS]
    end
    
    style T1 fill:#e3f2fd
    style T2 fill:#fff3e0
    style H1 fill:#e3f2fd
    style H2 fill:#fff3e0
    style Q1 fill:#e8f5e9
    style Q2 fill:#fff3e0
    style D1 fill:#e8f5e9
    style D2 fill:#fff3e0

성능 및 호환성 분석

프로토콜 계층 구조를 이해한 후 DoH와 DoT의 장단점을 분석할 수 있습니다.

TCP와 QUIC의 대비는 운영사의 실제 네트워크 환경을 고려하여 논의해야 합니다. QUIC는 비교적 새로운 프로토콜로 일부 구형 네트워크 문제를 해결했지만 근본적으로 UDP를 기반으로 합니다. 네트워크 지연 시간 관점에서 QUIC 기반 프로토콜의 지연 시간은 TCP보다 약 35% 낮으므로 DNS over HTTP/3과 DoQ(DNS over QUIC)는 이론적으로 DNS over HTTP/2와 DoT보다 성능이 더 좋을 것입니다.

하지만 실제 네트워크 환경에는 패킷 손실로 인한 재전송 지연 문제가 존재합니다. 네트워크 운영사는 네트워크가 혼잡할 때 UDP 패킷을 선택적으로 폐기하며, QUIC는 UDP로 식별되어 폐기 대상이 됩니다. QUIC가 재전송을 지원하지만 재전송으로 인한 지연으로 인해 QUIC의 실제 지연 시간이 TCP보다 더 높을 수 있습니다.

프라이버시와 보안 측면에서 DoH와 DoT는 모두 암호화된 트래픽으로 도청 및 변조되지 않습니다. DoT가 식별된 후 차단되는 문제는 주로 Android 시스템의 암호화 DNS 설정이 기본적으로 853 포트를 사용하기 때문에 853 포트가 민감한 포트가 된 것입니다. DoT 자체는 일반적인 일반 암호화 트래픽으로 DNS 전용 트래픽으로 식별되지 않습니다. 실제로 모든 포트에서 DoT 서비스를 제공할 수 있으며, 이는 Android에서는 타사 애플리케이션이 필요하지만 iOS에서는 기본적으로 모든 포트의 DoT 사용을 지원합니다.

확장성은 DoH의 중요한 장점입니다. HTTP로 캡슐화된 DNS와 Plain DNS에 비해 HTTP는 확연히 우수한 확장성을 갖추고 있습니다. 서비스 제공업체는 443 포트에서 DoH를 포함한 무수한 서비스를 제공할 수 있으며 기능 확장이 편리합니다. DoT와 DoQ는 일반적으로 전용 포트가 필요하며 확장 능력은 완전히 Plain DNS에 기반합니다. 이는 서비스 제공업체 관점의 차이로 일반 사용자에게는 아직 뚜렷한 인지도가 없습니다.

DNS 요청 처리 속도 면에서 HTTP 처리 속도가 Plain DNS보다 몇 CPU 클록 주기 느릴 수 있지만, 이러한 차이는 실제 사용에서 무시할 수 있습니다. 호환성 측면에서 DoH가 더 주류가 될 수 있는데, 서비스 제공업체에게 DoH의 확장성이 더 좋기 때문입니다.

현재 주요 플랫폼의 암호화 DNS 지원 상황은 각기 다릅니다. Chromium 커널 브라우저는 DoH를 지원합니다. Windows 11 시스템은 기본적으로 DoH를 지원합니다. Android 8 이상 시스템은 기본적으로 DoT를 지원합니다. Android 11 이상 시스템은 기본적으로 DoT와 DoH를 지원합니다. macOS 시스템은 기본적으로 DoT와 DoH를 지원합니다. iOS 시스템은 기본적으로 DoT와 DoH를 지원합니다.

실제 선택 권장사항

일반 사용자에게는 DoH 사용이 DoT보다 편안할 것입니다. DoH는 DoT에 비해 대부분의 시간 더 나은 지연 시간을 제공하며, 일부 시간 비슷한 지연 시간을 제공합니다. DoH는 DoQ에 비해 대부분의 시간 비슷한 지연 시간을 제공하며, 일부 시간 더 나은 지연 시간을 제공합니다.

이 결론의 전제는 서비스 제공업체가 DNS over HTTP/3 서비스를 제공하는 것입니다. 서비스 제공업체가 HTTP/3을 제공하지 않는다면 DoH와 DoT는 뚜렷한 차이가 없습니다. DoH는 네트워크 품질이 좋을 때 자동으로 DoH/3을 사용하여 낮은 지연 시간을 얻고, 네트워크 품질이 나쁠 때 자동으로 HTTP/2로 강등됩니다. 이러한 적응 능력은 서비스 제공업체가 구현해야 하지만 주요 서비스 제공업체는 일반적으로 구현하고 있습니다.

宁屏 사용을 권장합니다. 이 서비스는 DoT와 DoH/3을 지원하며 기본적으로 광고 차단 및 DNS 분할 기능을 갖추고 있습니다. 자체 배포가 필요하다면 해당 오픈소스 라이브러리를 사용할 수 있습니다.

네트워크 프로토콜 선택은 운영사 네트워크 품질, 서비스 제공업체 지원 상황, 장치 호환성 등 여러 요소를 종합적으로 고려해야 합니다. 대다수 사용자에게 DoH는 성능, 호환성 및 프라이버시 보호를 균형 있게 조화시킨 우수한 선택입니다.

DNS 프라이버시 보호 및 사용자 프로파일링 방지 전략

DNS 프라이버시 보호 및 사용자 프로파일링 방지 전략

독자: 네트워크 프라이버시와 데이터 거버넌스에 관심 있는 엔지니어/운영/보안 전문가
키워드: 로컬 리졸버, 재귀적 해석, 권한 서버, QNAME 최소화, ECS, DNSSEC, DoT/DoH/DoQ

배경 및 문제 개요

디지털 시대에 사용자의 네트워크 행동 데이터는 기업이 사용자 프로파일을 구축하는 중요한 원천이 되었습니다. 인터넷 인프라의 핵심 구성 요소인 도메인 이름 시스템(DNS)은 일상적인 네트워크 활동에서 인간이 읽을 수 있는 도메인 이름을 기계가 읽을 수 있는 IP 주소로 변환하는 중요한 역할을 담당합니다. 그러나 전통적인 DNS 쿼리는 일반적으로 UDP 포트 53에서 평문으로 전송되며, 이로 인해 사용자의 브라우징 기록, 애플리케이션 사용 습관 등 민감한 정보가 네트워크 사업자, 인터넷 서비스 제공자 및 다양한 중간자에 의해 쉽게 수집 및 분석될 수 있습니다.

사용자 프로파일링은 사용자의 다양한 행동 데이터를 수집하고 분석하여 구축된 사용자 특성 모델로, 기업은 이러한 모델을 활용해 정밀 마케팅, 콘텐츠 추천, 위험 평가 등의 상업 활동을 수행합니다. 이러한 서비스는 일정 부분 사용자 경험을 향상시키지만, 프라이버시 유출, 데이터 남용 및 잠재적 차별 가격 책정 등의 문제를 야기합니다. DNS 수준의 기술적 수단을 통해 사용자 프로파일링의 정확성을 줄이는 방법을 이해하는 것은 개인 프라이버시 보호의 중요한 경로가 됩니다.

본 문서는 DNS 기본 원리에서 출발하여 사용자 프로파일링 구축 과정의 데이터 수집 지점을 분석하고, DNS 기반 프라이버시 보호 전략을 논의하며, 다양한 시나리오에서의 구현 아이디어와 주의사항을 설명합니다.

기초 및 용어 정리

DNS 프라이버시 보호를 이해하려면 먼저 DNS 쿼리의 기본 프로세스와 관련 용어를 숙지해야 합니다. DNS 쿼리는 일반적으로 여러 참여자를 포함하며, 각 단계가 프라이버시 유출 지점이 될 수 있습니다.

flowchart LR
    A[클라이언트 장치] e1@--> B[로컬 리졸버]
    B e2@--> C[재귀 리졸버]
    C e3@--> D[루트 서버]
    D e4@--> E[TLD 서버]
    E e5@--> F[권한 서버]
    F e6@--> C
    C e7@--> B
    B e8@--> A
    C --> G[캐시 저장소]
    
    e1@{ animation: fast }
    e2@{ animation: slow }
    e3@{ animation: medium }
    e4@{ animation: fast }
    e5@{ animation: medium }
    e6@{ animation: fast }
    e7@{ animation: fast }
    e8@{ animation: slow }
    
    style A fill:#e1f5fe
    style B fill:#f3e5f5
    style C fill:#fff3e0
    style D fill:#f1f8e9
    style E fill:#f1f8e9
    style F fill:#f1f8e9
    style G fill:#fce4ec

로컬 리졸버(Stub Resolver)는 운영 체제 또는 애플리케이션 내의 DNS 클라이언트 구성 요소로, 애플리케이션의 DNS 쿼리 요청을 수신하여 재귀 리졸버로 전달하는 역할을 합니다. 재귀 리졸버(Recursive Resolver)는 일반적으로 ISP 또는 제3자 DNS 서비스에서 제공되며, 루트 서버, 최상위 도메인(TLD) 서버 및 권한 서버를 조회하는 완전한 도메인 이름 해석 과정을 수행하고 최종 결과를 클라이언트에 반환합니다.

권한 서버(Authoritative Server)는 특정 도메인 이름의 DNS 레코드를 저장하며, 도메인 정보의 최종 출처입니다. 캐시 메커니즘은 DNS 시스템의 중요한 구성 요소로, 재귀 리졸버는 반복 쿼리를 줄이고 해석 효율성을 높이기 위해 쿼리 결과를 캐시합니다. TTL(Time To Live) 값은 DNS 레코드가 캐시에 저장되는 시간을 결정합니다.

EDNS Client Subnet(ECS)은 재귀 리졸버가 권한 서버에 클라이언트의 서브넷 정보를 전달할 수 있도록 하는 확장 메커니즘으로, CDN 및 지리적 위치 서비스의 정확성을 높이는 것을 목표로 합니다. 그러나 ECS는 사용자의 지리적 위치 정보를 노출시켜 프라이버시 유출 위험을 증가시킬 수도 있습니다.

프라이버시 위협 및 동기

평문 DNS 쿼리는 사용자 프로파일링 구축에 풍부한 데이터 소스를 제공합니다. DNS 쿼리 기록을 분석함으로써 공격자 또는 데이터 수집자는 사용자의 브라우징 습관, 애플리케이션 사용 현황, 지리적 위치 정보 등 민감한 데이터를 획득할 수 있으며, 이를 통해 상세한 사용자 프로파일을 구축할 수 있습니다.

flowchart TD
    A[사용자 인터넷 행동] e1@--> B[평문 DNS 쿼리]
    B e2@--> C[ISP 리졸버]
    B e3@--> D[공개 DNS 서비스]
    C e4@--> E[사용자 접속 기록]
    D e5@--> F[쿼리 로그]
    E e6@--> G[행동 분석]
    F e7@--> G
    G e8@--> H[사용자 프로파일]
    H e9@--> I[정밀 광고]
    H e10@--> J[콘텐츠 추천]
    H e11@--> K[가격 차별]
    
    L[제3자 트래커] e12@--> M[크로스 사이트 연관]
    M e13@--> G
    
    N[장치 지문] e14@--> O[고유 식별자]
    O e15@--> G
    
    e1@{ animation: fast }
    e2@{ animation: medium }
    e3@{ animation: medium }
    e4@{ animation: slow }
    e5@{ animation: slow }
    e6@{ animation: fast }
    e7@{ animation: fast }
    e8@{ animation: medium }
    e9@{ animation: fast }
    e10@{ animation: fast }
    e11@{ animation: fast }
    e12@{ animation: medium }
    e13@{ animation: fast }
    e14@{ animation: medium }
    e15@{ animation: fast }
    
    style A fill:#e1f5fe
    style B fill:#fff3e0
    style C fill:#ffebee
    style D fill:#ffebee
    style E fill:#fce4ec
    style F fill:#fce4ec
    style G fill:#f3e5f5
    style H fill:#e8eaf6
    style I fill:#fff9c4
    style J fill:#fff9c4
    style K fill:#ffcdd2
    style L fill:#ffebee
    style M fill:#fce4ec
    style N fill:#ffebee
    style O fill:#fce4ec

DNS 쿼리 데이터는 사용자 프로파일링 구축에 몇 가지 측면에서 가치를 제공합니다. 첫째, 쿼리 빈도 및 시간 패턴은 사용자의 일상적인 생활 리듬을 드러낼 수 있습니다. 예를 들어 평일과 주말의 인터넷 사용 습관 차이, 야간 활동 패턴 등이 있습니다. 둘째, 쿼리된 도메인 유형은 사용자의 관심사와 취향을 반영할 수 있습니다. 예를 들어 뉴스 웹사이트, 소셜 미디어, 비디오 플랫폼, 쇼핑 사이트 등의 접근 선호도가 있습니다. 또한 서브도메인 접근 패턴은 더 정밀한 행동 분석을 제공할 수 있습니다. 예를 들어 사용자가 특정 소셜 플랫폼의 하위 기능 페이지에 자주 접근하는지 여부 등입니다.

지리적 위치 정보는 사용자 프로파일링의 중요한 구성 요소입니다. ECS 메커니즘과 재귀 리졸버의 위치 분석을 통해 사용자의 물리적 위치 또는 이동 궤적을 추론할 수 있습니다. 시계열 분석과 결합하면 사용자의 자주 방문하는 장소와 활동 범위를 식별할 수도 있습니다.

크로스 디바이스 신원 연관은 사용자 프로파일링 구축의 또 다른 핵심 단계입니다. DNS 쿼리의 특정 패턴(예: 서로 다른 장치에서 동일한 도메인에 대한 쿼리 시간 분포)을 분석함으로써 동일 사용자의 여러 장치를 연관시켜 더 포괄적인 사용자 프로파일을 구축할 수 있습니다.

상업적 동기는 사용자 프로파일링 구축을 주도합니다. 정밀 광고 게재는 주요 적용 시나리오로, 기업은 사용자의 브라우징 관심사를 분석하여 관련성 높은 광고를 표시함으로써 전환율을 높입니다. 콘텐츠 추천 시스템은 사용자 프로파일을 활용하여 개인화된 뉴스, 비디오 및 제품 추천을 제공함으로써 사용자 충성도를 강화합니다. 위험 평가는 금융, 보험 등 분야에 적용되며 사용자 행동 패턴에 따라 신용 위험 또는 사기 가능성을 평가합니다.

보호 전략 및 원리

DNS 프라이버시 유출 위험에 대응하여 업계에서는 암호화 전송, 쿼리 혼란 및 원천 제어 세 가지 방향을 중심으로 다양한 보호 전략이 발전해 왔습니다. 이러한 전략은 각각의 특징을 가지며 다양한 시나리오와 요구 사항에 적용됩니다.

flowchart TD
    A[DNS 프라이버시 보호 전략] --> B[암호화 전송]
    A --> C[쿼리 혼란]
    A --> D[원천 제어]
    
    B --> B1[DoT - DNS over TLS]
    B --> B2[DoH - DNS over HTTPS]
    B --> B3[DoQ - DNS over QUIC]
    
    C --> C1[QNAME 최소화]
    C --> C2[분할 쿼리]
    C --> C3[시간 순서 무작위화]
    
    C1 --> C1A[단계적 전송]
    C1 --> C1B[노출 감소]
    
    D --> D1[로컬 hosts 파일]
    D --> D2[신뢰할 수 있는 재귀 리졸버]
    D --> D3[DNS 필터링]
    
    D2 --> D2A[프라이버시 정책]
    D2 --> D2B[로그 미기록]
    D2 --> D2C[제3자 감사]
    
    style A fill:#e1f5fe
    style B fill:#e8f5e8
    style C fill:#fff3e0
    style D fill:#f3e5f5
    style B1 fill:#e8f5e8
    style B2 fill:#e8f5e8
    style B3 fill:#e8f5e8
    style C1 fill:#fff3e0
    style C2 fill:#fff3e0
    style C3 fill:#fff3e0
    style D1 fill:#f3e5f5
    style D2 fill:#f3e5f5
    style D3 fill:#f3e5f5

암호화 전송은 DNS 프라이버시 보호의 기본 수단으로, 주로 세 가지 기술을 포함합니다: DNS over TLS(DoT), DNS over HTTPS(DoH) 및 DNS over QUIC(DoQ). DoT는 TCP 포트 853을 사용하여 암호화된 DNS 쿼리를 전송하며 TLS 프로토콜을 통해 종단 간 암호화 보호를 제공합니다. DoH는 DNS 쿼리를 HTTPS 트래픽으로 캡슐화하여 표준 443 포트를 사용함으로써 기존 네트워크 환경에 더 잘 통합될 수 있으며 방화벽 또는 네트워크 관리 장비에 의해 식별 및 차단되는 것을 피할 수 있습니다. DoQ는 QUIC 프로토콜을 기반으로 하는 새로운 방안으로 UDP의 낮은 지연과 TLS의 보안성을 결합하며 연결 마이그레이션 등의 고급 기능을 지원합니다.

QNAME 최소화(RFC7816)는 쿼리 혼란 기술로, 재귀 리졸버가 상위 서버로 쿼리를 전송할 때 도메인 이름을 단계적으로 전송합니다. 예를 들어 “www.example.com"을 쿼리할 때 먼저 “com"을 쿼리한 다음 “example.com”, 마지막으로 “www.example.com"을 쿼리합니다. 이 방식은 상위 서버가 얻는 완전한 도메인 정보를 줄이지만 쿼리 지연이 증가할 수 있습니다.

분할 쿼리와 시간 순서 무작위화는 추가적인 쿼리 혼란 수단입니다. 분할 쿼리는 여러 DNS 요청을 다른 시간에 분산시켜 전송함으로써 쿼리 패턴을 통한 사용자 행동 연관을 피합니다. 시간 순서 무작위화는 쿼리 간격에 무작위 지연을 도입함으로써 시간 패턴 분석 가능성을 차단합니다.

원천 제어 전략은 DNS 쿼리 발생 단계에 주목합니다. 로컬 hosts 파일은 DNS 쿼리를 우회하여 자주 사용하는 도메인을 직접 해석함으로써 쿼리 기록 생성을 줄입니다. 신뢰할 수 있는 재귀 리졸버 선택은 엄격한 프라이버시 정책을 가진 DNS 서비스 제공업체(예: 쿼리 로그를 기록하지 않으며 제3자 추적을 허용하지 않는 서비스)를 선택하는 것입니다. DNS 필터링은 알려진 트래커와 악성 도메인을 차단함으로써 불필요한 데이터 노출을 줄입니다.

구현 경로 및 주의사항

DNS 프라이버시 보호 구현은 기술적 실현 가능성, 성능 영향 및 배포 복잡성을 고려해야 합니다. 구체적인 방안을 선택하고 실행할 때 프라이버시 보호 효과와 실제 사용 가능성 사이의 균형을 맞추어야 합니다.

암호화 DNS 배포는 여러 방식으로 수행할 수 있습니다. 운영 체제 수준 지원이 가장 이상적인 경우로, Android 9+, iOS 14+ 및 Windows 11은 모두 DoH 또는 DoT 지원을 내장하고 있습니다. 애플리케이션 수준 구현은 브라우저 내장 암호화 DNS 기능과 같은 특정 소프트웨어에 적용됩니다. 네트워크 장비 수준 배포는 라우터 또는 방화벽에서 암호화 DNS를 구성하여 전체 네트워크에 보호를 제공합니다.

QNAME 최소화 구현은 주로 재귀 리졸버가 담당하며, 사용자는 이 기능을 지원하는 DNS 서비스를 선택해야 합니다. QNAME 최소화는 프리페치 및 로드 밸런싱과 같은 완전한 도메인 정보에 의존하는 성능 최적화에 영향을 줄 수 있다는 점에 유의해야 합니다.

신뢰할 수 있는 재귀 리졸버 선택은 여러 요소를 고려해야 합니다. 프라이버시 정책이 최우선 고려 사항으로, 쿼리 로그 기록 여부, 로그 보존 기간, 데이터 공유 정책 등이 포함됩니다. 서비스 성능은 해석 지연, 가용성 및 글로벌 분포를 포함한 사용자 경험에 영향을 미칩니다. 서비스 투명성도 중요한 요소로, 운영 정책 공개 여부 및 제3자 감사 수용 여부 등이 있습니다.

DNS 필터링은 오탐(false positive) 및 미탐(false negative) 문제에 주의해야 합니다. 지나치게 공격적인 필터링은 정상적인 웹사이트 접근을 방해할 수 있으며, 지나치게 관대한 필터링은 프라이버시를 효과적으로 보호할 수 없습니다. 정기적인 필터 규칙 업데이트 및 사용자 정의 허용 목록 제공은 필요한 균형 조치입니다.

혼합 전략은 더 나은 프라이버시 보호 효과를 제공할 수 있습니다. 예를 들어 암호화 DNS와 QNAME 최소화를 결합하고 DNS 필터링으로 트래커를 차단하는 것입니다. 그러나 과도한 프라이버시 보호 조치는 네트워크 성능 및 호환성에 영향을 줄 수 있으므로 실제 요구 사항에 따라 조정해야 합니다.

위험 및 마이그레이션

DNS 프라이버시 보호 조치 배포는 다양한 위험과 도전에 직면할 수 있으며, 이에 대응하는 마이그레이션 전략 및 비상 계획을 수립해야 합니다.

호환성 위험이 주요 고려 사항 중 하나입니다. 암호화 DNS는 특정 네트워크 환경(특히 기업 네트워크 또는 제한이 엄격한 지역)에서 차단될 수 있습니다. 폴백 메커니즘이 매우 중요하며, 암호화 DNS를 사용할 수 없을 때 시스템은 우아하게 전통적인 DNS로 폴백할 수 있어야 하며 프라이버시 유출을 최대한 줄여야 합니다.

성능 영향은 신중하게 평가해야 합니다. 암호화 DNS는 특히 초기 연결 시 핸드셰이크 오버헤드로 인해 쿼리 지연을 증가시킬 수 있습니다. 캐시 최적화 및 연결 재사용은 부분적인 성능 문제를 완화할 수 있습니다. 암호화 DNS 서비스 선택 시 네트워크 지연 및 응답 시간을 고려해야 하며 지리적으로 너무 먼 서버는 피해야 합니다.

규정 준수 요구 사항은 기업 배포 시 고려해야 할 요소입니다. 일부 지역에는 데이터 보존 또는 모니터링 요구 사항이 있을 수 있으며, 이는 프라이버시 보호 조치와 상충될 수 있습니다. 배포 전 현지 규정 요구 사항을 이해하고 프라이버시 보호와 규정 준수 사이의 균형을 찾아야 합니다.

계층적 그레이스케일 배포는 위험을 줄이는 효과적인 전략입니다. 먼저 테스트 환경에서 방안의 실현 가능성을 검증한 다음 소규모 사용자 그룹으로 점차 확대하고 마지막으로 전체 배포합니다. 쿼리 성공률, 지연 변화 및 오류율과 같은 핵심 지표를 모니터링하고 구성을 적시에 조정해야 합니다.

사용자 교육 및 훈련도 소홀히 해서는 안 됩니다. 많은 사용자가 DNS 프라이버시의 중요성을 이해하지 못할 수 있으므로 명확한 설명 및 구성 지침을 제공해야 합니다. 특히 기업 환경에서 IT 부서는 직원들에게 프라이버시 보호 조치의 목적과 사용 방법을 설명해야 합니다.

시나리오별 제안

다른 사용 시나리오는 DNS 프라이버시 보호에 대한 요구 사항과 실행 전략이 각기 다른 특징을 가지므로 구체적인 환경에 맞춘 맞춤형 방안을 수립해야 합니다.

가정용 네트워크 시나리오에서는 라우터 수준 배포가 좋은 선택입니다. 암호화 DNS를 지원하는 라우터는 IoT 장치 및 스마트 홈 제품을 포함한 전체 가정 네트워크에 보호를 제공할 수 있습니다. 자녀 보호 기능 및 악성 웹사이트 필터링을 지원하는 가정 친화적인 DNS 서비스를 선택함으로써 프라이버시를 보호하는 동시에 추가적인 보안 기능을 제공할 수 있습니다.

모바일 오피스 시나리오는 네트워크 전환 및 배터리 소모에 특별히 주의해야 합니다. 연결 마이그레이션을 지원하는 DoQ 서비스를 선택하면 모바일 네트워크 전환 시 안정성을 높일 수 있습니다. 동시에 배터리 최적화 전략을 고려하여 빈번한 DNS 쿼리 및 암호화 작업으로 인한 과도한 배터리 소모를 방지해야 합니다.

기업 환경은 프라이버시 보호와 네트워크 관리 사이의 균형을 찾아야 합니다. 일반 직원 트래픽에 프라이버시 보호를 제공하고 특정 비즈니스 트래픽에 대해서는 관리 및 규정 준수 요구 사항을 충족시키기 위해 가시성을 유지하는 혼합 방안을 배포해야 할 수 있습니다. DNS 필터링은 기업 보안 정책과 결합하여 악성 도메인 및 데이터 유출 위험을 차단할 수 있습니다.

고프라이버시 요구 시나리오(예: 기자, 변호사, 의료 종사자)는 다중 보호 조치를 채택해야 할 수 있습니다. 암호화 DNS, VPN 및 Tor 등의 도구를 결합하여 다층적 프라이버시 보호를 실현합니다. 동시에 쿼리 로그를 전혀 기록하지 않는 서비스와 같은 익명 재귀 리졸버를 사용하는 것을 고려할 수 있습니다.

국경 간 네트워크 시나리오는 네트워크 검열 및 지역 제한에 특별히 주의해야 합니다. 일부 암호화 DNS 서비스는 특정 지역에서 사용 불가능할 수 있으므로 여러 대체 방안을 준비해야 합니다. 현지 네트워크 환경 특징을 이해하고 현지 조건에 가장 적합한 프라이버시 보호 전략을 선택해야 합니다.

개발 테스트 환경은 실험적인 DoQ 구현 또는 사용자 정의 혼란 방안과 같은 최신 프라이버시 보호 기술을 시도할 수 있습니다. 이러한 환경은 상대적으로 통제 가능하므로 신기술의 영향 및 호환성을 테스트하고 프로덕션 환경 배포를 위한 경험을 축적하기에 적합합니다.

FAQ 및 참고 자료

자주 묻는 질문

Q: 암호화 DNS는 사용자 프로파일링 구축을 완전히 방지합니까?
A: 암호화 DNS는 네트워크 계층의 중간자로부터 DNS 쿼리 내용을 엿보는 것을 방지할 수 있지만, 재귀 리졸버는 여전히 전체 쿼리 기록을 볼 수 있습니다. 로그를 기록하지 않겠다고 약속한 신뢰할 수 있는 서비스 제공업체를 선택하는 것이 중요하며, 브라우저 추적 방지 기능과 같은 다른 프라이버시 보호 조치와 결합하여 더 포괄적인 보호를 제공할 수 있습니다.

Q: QNAME 최소화는 DNS 해석 성능에 영향을 미칩니까?
A: QNAME 최소화는 여러 번의 상위 서버 쿼리로 인해 쿼리 지연을 증가시킬 수 있습니다. 현대 재귀 리졸버는 일반적으로 지능형 캐싱 및 병렬 쿼리를 통해 성능을 최적화하므로 실제 영향은 종종 예상보다 작습니다. 대부분의 사용자에게 프라이버시 이득은 약간의 성능 손실보다 훨씬 큽니다.

Q: DNS 프라이버시 보호가 효과적인지 어떻게 확인합니까?
A: dnsleaktest.com 또는 dnsprivacy.org에서 제공하는 검사 서비스와 같은 전용 테스트 도구를 사용하여 DNS 쿼리가 암호화 채널을 통해 전송되는지 확인할 수 있습니다. 네트워크 패킷 캡처 도구를 사용하여 DNS 트래픽이 암호화되었는지 확인할 수도 있습니다. 그러나 이러한 테스트는 기술적 구현만 검증할 수 있으며 서비스 제공업체의 실제 프라이버시 정책 이행 상황은 평가할 수 없습니다.

Q: 기업 네트워크에서 프라이버시 보호와 관리 요구 사항의 균형을 어떻게 맞춥니까?
A: 기업은 계층화된 전략을 채택할 수 있습니다. 일반 인터넷 접근에 프라이버시 보호를 제공하고 내부 비즈니스 트래픽에 대해서는 필요한 모니터링 기능을 유지합니다. 분할 기술을 지원하는 솔루션을 사용하여 도메인 이름 또는 사용자 그룹에 따라 다른 DNS 정책을 적용합니다. 명확한 프라이버시 정책 및 직원 커뮤니케이션도 중요합니다.

Q: 암호화 DNS는 네트워크 사업자에 의해 차단됩니까?
A: 일부 네트워크 환경에서는 특히 비표준 포트를 사용하는 DoT를 제한하거나 차단할 수 있습니다. DoH는 표준 HTTPS 포트 443을 사용하므로 일반적으로 식별 및 차단하기가 더 어렵습니다. 이 경우 여러 암호화 DNS 방안의 조합을 사용하거나 VPN과 같은 다른 프라이버시 도구와 함께 사용하는 것을 고려할 수 있습니다.

참고 자료

RFC 문서:

• RFC7858: DNS over Transport Layer Security (TLS) 사양
• RFC8484: DNS Queries over HTTPS (DoH)
• RFC7816: DNS Query Name Minimisation to Improve Privacy
• RFC9250: DNS over Dedicated QUIC Connections

도구 및 서비스:

• Cloudflare DNS: 1.1.1.1 (DoH/DoT 지원, 프라이버시 보호 약속)
• Quad9: 9.9.9.9 (DoH/DoT 지원, 악성 도메인 차단)
• NextDNS: 맞춤형 프라이버시 DNS 서비스
• Stubby: 오픈 소스 DoT 클라이언트

테스트 및 검증:

• dnsleaktest.com: DNS 유출 테스트
• dnsprivacy.org: DNS 프라이버시 테스트 도구
• browserleaks.com/dns: 브라우저 DNS 구성 검사

추가 자료:

• DNS 프라이버시 보호 기술 상세 설명
• 기업 DNS 보안 및 프라이버시 균형 전략

본 문서는 DNS 기본 원리에서 출발하여 사용자 프로파일링 구축 과정의 프라이버시 위험을 분석하고, 암호화 전송, 쿼리 혼란 및 원천 제어 등 보호 전략을 체계적으로 소개했습니다. 실제 배포 시 구체적인 시나리오와 요구 사항에 맞는 적절한 방안을 선택하여 프라이버시 보호, 성능 영향 및 호환성 요구 사항 사이의 균형을 맞추어야 합니다. DNS 프라이버시 보호는 지속적으로 발전하는 분야로, 기술 진화 및 규제 변화에 따라 보호 전략도 지속적으로 조정 및 개선되어야 합니다.

심층 분석: 寧屏 DNS 프록시 기능으로 네트워크 제한을 돌파하고 프라이버시 보호 실현

🌐 DNS 프록시 기능 심층 분석

오늘날 복잡한 네트워크 환경에서 기존 DNS 서비스는 여러 제약에 직면해 있습니다. 寧屏 DNS 서비스는 이제 상위 DNS 프록시 기능을 완전히 지원하여 사용자에게 더 유연하고 안전한 네트워크 액세스 경험을 제공합니다.

DNS 프록시가 필요한 이유?

특정 네트워크 환경(예: 기업 네트워크, 캠퍼스 네트워크 또는 특정 지역 네트워크)에서는 상위 DNS 서버에 직접 액세스하면 다음 문제가 발생할 수 있습니다:

• 네트워크 제한: 일부 DNS 서버(예: 1.1.1.1, 8.8.8.8)가 방화벽에 의해 차단됨
• ISP 간섭: 통신사가 DNS 쿼리를 리다이렉션하거나 오염시킬 수 있음
• 지리적 제한: 특정 지역의 DNS 서비스 접근이 제한됨
• 프라이버시 보호: 실제 IP 주소를 숨기기 위해 프록시가 필요함

🚀 핵심 기능 특성

DoH 및 DoT 프록시 지원

寧屏 DNS 서비스는 AdGuard Home을 기반으로 깊이 맞춤화하여 다음과 같은 핵심 기능을 추가했습니다:

1. 스마트 DNS 분할

   • 네트워크 환경을 자동 감지
   • 규칙에 따라 직접 연결 또는 프록시 경로를 스마트하게 선택
   • 사용자 정의 분할 구성 파일 지원

2. 프록시 프로토콜 완전 지원

   • HTTP 프록시 (http_proxy)
   • HTTPS 프록시 (https_proxy)
   • SOCKS5 프록시 (socks5)

3. 보안 암호화 전송

   • DoH (DNS over HTTPS) 프록시 지원
   • DoT (DNS over TLS) 프록시 지원
   • 종단 간 암호화로 프라이버시 보호

📋 상세 구성 가이드

환경 변수 구성

DNS 프록시 기능을 구성하는 것은 매우 간단하며, 시스템 환경에 적절한 프록시 변수를 설정하기만 하면 됩니다.

Linux/macOS 구성

# 임시 구성 (현재 세션)
export http_proxy="http://proxy.example.com:8080"
export https_proxy="http://proxy.example.com:8080"
export ALL_PROXY="socks5://[username:password@]proxyhost:port"

# 영구 구성 (~/.bashrc 또는 ~/.zshrc에 추가)
echo 'export http_proxy="http://proxy.example.com:8080"' >> ~/.bashrc
echo 'export https_proxy="http://proxy.example.com:8080"' >> ~/.bashrc
echo 'export ALL_PROXY="socks5://[username:password@]proxyhost:port"' >> ~/.bashrc
source ~/.bashrc

Windows 구성

# 명령 프롬프트
set http_proxy=http://proxy.example.com:8080
set https_proxy=http://proxy.example.com:8080

# PowerShell
$env:http_proxy="http://proxy.example.com:8080"
$env:https_proxy="http://proxy.example.com:8080"

Docker 컨테이너 구성

version: '3.8'
services:
  nullprivate-dns:
    image: nullprivate/nullprivate:latest
    environment:
      - http_proxy=http://proxy.example.com:8080
      - https_proxy=http://proxy.example.com:8080
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
      - "443:443/tcp"

고급 구성 옵션

인증 프록시 구성

프록시 서버에 인증이 필요한 경우 다음 형식을 사용할 수 있습니다:

export http_proxy="http://username:password@proxy.example.com:8080"
export https_proxy="https://username:password@proxy.example.com:8080"

특정 도메인 제외

일부 도메인은 프록시를 통해 액세스할 필요가 없을 수 있으며, no_proxy 변수를 설정할 수 있습니다:

export no_proxy="localhost,127.0.0.1,.local"

🔧 실제 적용 시나리오

기업 네트워크 환경

기업 네트워크에서는 외부 DNS 서버가 종종 방화벽에 의해 제한됩니다. 프록시를 구성하면 다음과 같은 이점이 있습니다:

• 기업 방화벽 제한 돌파
• 차단된 DNS 서비스 액세스
• 안전한 외부 네트워크 액세스 실현

캠퍼스 네트워크 최적화

캠퍼스 네트워크는 일반적으로 DNS에 대한 엄격한 제어가 있으며, 프록시를 구성하면 다음과 같은 이점이 있습니다:

• DNS 오염 및 하이재킹 방지
• 더 빠른 DNS 해석 속도 제공
• 학생 프라이버시와 학습 데이터 보호

가정 네트워크 보호

가정 사용자는 프록시를 통해 다음과 같은 이점을 얻을 수 있습니다:

• 가정의 실제 IP 주소 숨기기
• ISP의 인터넷 사용 추적 방지
• 더 안전한 어린이 인터넷 보호 실현

⚡ 기술 이점 비교

🛠️ 문제 해결 가이드

일반적인 문제 및 해결책

Q: 프록시 구성 후 DNS 해석 실패

가능한 원인:

• 프록시 서버에 액세스할 수 없음
• 프록시 서버가 HTTPS를 지원하지 않음
• 네트워크 연결 문제

해결책:

1. 프록시 서버 상태 확인: curl -x http://proxy.example.com:8080 https://www.google.com
2. 프록시 구성 확인: env | grep proxy
3. 寧屏 서비스 재시작

Q: 프록시 연결 시간 초과

가능한 원인:

• 프록시 서버 응답 속도가 느림
• 네트워크 지연 높음
• 프록시 서버 부하가 높음

해결책:

1. 프록시 서버 교체
2. DNS 시간 초과 설정 조정
3. 여러 프록시 서버를 구성하여 부하 분산

Q: 특정 도메인 해석 이상

가능한 원인:

• 도메인이 프록시 서버의 블랙리스트에 있음
• DNS 캐시 문제
• 프록시 서버 DNS 구성 문제

해결책:

1. DNS 캐시 지우기
2. 프록시 서버 구성 확인
3. 직접 연결 모드 시도

📊 성능 모니터링

프록시를 구성한 후 다음과 같은 방법으로 성능을 모니터링할 수 있습니다:

1. DNS 쿼리 지연: DNS 해석 속도가 개선되었는지 관찰
2. 성공률 통계: 프록시 연결의 성공률 모니터링
3. 트래픽 분석: 프록시 트래픽 사용 상황 확인
4. 오류 로그: 정기적으로 시스템 로그의 오류 정보 확인

🔒 보안 주의사항

1. 신뢰할 수 있는 프록시 선택: 신뢰할 수 있는 프록시 서비스 제공업체 사용
2. 암호화 활성화: HTTPS 프록시를 우선적으로 사용
3. 정기 교체: 보안 향상을 위해 정기적으로 프록시 서버 교체
4. 트래픽 모니터링: 정기적으로 프록시 트래픽 사용 상황 확인
5. 구성 업데이트: 네트워크 변화에 대응하기 위해 프록시 구성을 적시에 업데이트

🎯 요약 및 전망

寧屏 DNS 프록시 기능의 출시는 사용자에게 복잡한 네트워크 환경에서 DNS 서비스를 사용할 때 더 유연하고 안전한 솔루션을 제공합니다. 간단한 구성만으로 네트워크 제한을 돌파하고 더 우수한 DNS 해석 서비스와 프라이버시 보호를 실현할 수 있습니다.

향후 계획

• SOCKS5 프록시 프로토콜 지원
• 스마트 프록시 선택 알고리즘 추가
• 그래픽 구성 인터페이스 제공
• 다중 프록시 부하 분산 지원

🚀 지금 체험하기

寧屏 DNS 프록시 기능을 체험하고 싶은 사용자는 다음과 같이 할 수 있습니다:

1. GitHub 저장소 방문
2. 문서에 따라 배포
3. 프록시 환경 변수 구성
4. 더 안전하고 자유로운 네트워크 경험 즐기기

AdGuardPrivate 명칭 변경 공지

최근 AdGuard 측으로부터 공식 통지를 받았습니다. “AdGuard"는 등록 상표로, 별도의 사용 허가 없이는 해당 이름을 사용할 수 없으며, 접두사나 접미사를 추가하는 경우에도 침해 소지가 있을 수 있다고 안내받았습니다. 법적 리스크를 방지하기 위해 당사 서비스는 공식적으로 “NullPrivate"로 명칭이 변경되었습니다.

기존 사용자분들께는 서비스에 전혀 영향이 없으며, adguardprivate.com 도메인을 통해 계속해서 서비스를 제공합니다. 다만 공식 웹사이트와 연락처만 이전될 예정입니다.

신규 사용자가 NullPrivate이 AdGuard와 연관이 있다고 오해하는 것을 방지하기 위해 다음과 같이 안내드립니다. 당사 소프트웨어 제품은 AdGuardHome을 fork하여 개발되었으며, 새로운 기능이 추가되었습니다. 모든 코드는 오픈소스로 공개되어 있으며 동일한 GPLv3 라이선스를 준수합니다.

코드 저장소: https://github.com/nullprivate/nullprivate

사용자는 코드를 직접 확인하여 자체 배포도 가능합니다. 또한 당사가 제공하는 SaaS 버전은 계속해서 더욱 저렴한 가격과 안정적인 서비스를 제공할 예정입니다.

그동안 보내주신 성원에 감사드리며, 당사 서비스가 계속해서 여러분께 가치를 제공할 수 있기를 바랍니다!

DDNS 기능 추가

NullPrivate 서비스를 이미 보유하고 있다면, 이제 DDNS 기능을 사용할 수 있습니다.

개요

NullPrivate는 DDNS 스크립트를 오픈소스로 공개했습니다. 이 동적 DNS(DDNS)는 도메인을 구매할 필요 없이 개인 동적 DNS를 빠르게 설정할 수 있는 간단한 방법을 제공하기 위해 설계되었습니다. 이 DDNS 스크립트는 nullprivate.com을 위해 특별히 개발되었으며, NullPrivate의 핵심 기능을 활용하여 이 기능을 원활하게 구현할 수 있습니다.

사용 방법

1. NullPrivate가 배포되어 실행 중인지 확인하세요.
2. DNS 재작성으로 이동하여 DDNS 스크립트를 다운로드하세요.
3. 스크립트를 실행하세요.

Windows

Set-ExecutionPolicy Bypass -Scope Process
./ddns-script.ps1

Linux/macOS

chmod +x ddns-script.sh
./ddns-script.sh

기능 특징

• 빠르고 간편한 설정: 몇 단계만으로 구성을 완료할 수 있습니다.
• NullPrivate를 통한 DDNS 기능 구현: NullPrivate의 핵심 기능을 통해 DDNS를 구현합니다.
• 다중 플랫폼 지원: Windows 및 Unix 기반 시스템을 지원합니다.
• 다양한 인증 옵션: 쿠키(더 안전하지만 만료될 수 있음) 또는 사용자 이름/비밀번호(더 지속적이지만 보안성이 낮음) 인증을 지원합니다.

기존 DDNS와의 차이점

기존 DDNS와 비교하여 이 개인 DDNS는 다음과 같은 장점이 있습니다:

• 캐시 시간 없음: 변경 사항이 즉시 적용되며 DNS 캐시 만료를 기다릴 필요가 없습니다.
• DNS 전파 지연 없음: 업데이트가 즉시 사용 가능하며 DNS 전파 지연이 없습니다.
• 도메인 구매 불필요: 가짜 도메인을 사용하여 접근할 수 있으며 도메인을 구매할 필요가 없습니다.
• 개인 정보 보호: 개인 DNS 서비스에 연결된 사용자만 DNS를 해석할 수 있어 개인 정보가 보장됩니다.

빠른 시작 가이드

1. NullPrivate가 배포되어 실행 중인지 확인하세요.
2. Windows용 win/ddns.ps1 또는 Unix 기반 시스템용 unix/ddns.sh 스크립트의 지침에 따라 개인 DDNS를 구성하세요.

오픈소스 주소: https://github.com/NullPrivate/nullprivate-ddns

ECS에 대한 더 나은 지원

최상의 DNS 해석 경험을 위해 일부 권장 구성을 미리 설정해 두었지만, 사용자가 주의해야 할 설정이 하나 있습니다. 바로 “EDNS 클라이언트 서브넷"입니다.

EDNS 클라이언트 서브넷(ECS) 활성화

더 나은 경험을 위해 DNS 서버가 지리적으로 가장 가까운 서버 IP를 반환하도록 하려면 EDNS 클라이언트 서브넷(ECS)을 활용할 수 있습니다. 이 기능은 DNS 서버에 지리 위치 정보를 포함한 IP 서브넷을 전송하여 최적의 DNS 해석 결과를 반환하도록 합니다.

작동 원리:

ECS를 활성화하면 DNS 리졸버(예: AdGuard Home)는 DNS 쿼리에 클라이언트 IP 주소의 일부(보통 처음 24비트로 클라이언트가 속한 서브넷을 나타냄)를 포함하여 상위 DNS 서버로 전송합니다. 상위 DNS 서버는 이 서브넷 정보를 바탕으로 해당 지역에 가장 적합한 서버 IP 주소를 반환합니다.

sequenceDiagram
    participant Client
    participant DNS Resolver
    participant Upstream DNS Server

    Client->>DNS Resolver: DNS 쿼리
    DNS Resolver->>Upstream DNS Server: ECS(클라이언트 서브넷)가 포함된 DNS 쿼리
    Upstream DNS Server->>DNS Resolver: DNS 응답(지역화된 IP)
    DNS Resolver->>Client: DNS 응답(지역화된 IP)

개인정보 주의사항:

ECS를 활성화하면 DNS 해석의 정확성과 속도를 높일 수 있지만, 동시에 일정한 개인정보 영향이 발생할 수 있습니다. 클라이언트 IP 주소의 서브넷을 공유함으로써 대략적인 지리 위치 정보가 상위 DNS 서버에 기록될 수 있습니다. 상황에 따라 이 기능을 활성화할지 여부를 신중히 판단해 주세요.

절충 방법:

ECS를 활성화하면 접속 속도와 정확성 사이에서 균형을 이룰 수 있습니다. 개인정보 보호를 중시한다면 ECS를 비활성화할 수 있지만, 이 경우 접속 속도가 떨어질 수 있습니다. 최상의 접속 경험을 원한다면 ECS를 활성화할 수 있지만, 잠재적인 개인정보 영향을 인지해야 합니다. 해당 개인정보는 DNS 상위 서버가 수집하며, 본 서비스는 개인정보 보호정책에 따라 어떠한 정보도 수집하거나 이용하지 않습니다.

NullPrivate - AdGuard Home 기반 강화형 DNS 서비스

NullPrivate: 개인정보 보호에 특화된 DNS 서비스

공식 웹사이트에서 더 알아보기: NullPrivate

이 프로젝트는 AdGuard Home을 기반으로 2차 개발되었으며, GPL 3.0 오픈소스 라이선스를 따릅니다.

소스 코드는 다음에서 공개되어 있습니다: GitHub - NullPrivate/NullPrivate

기능 강화

원본 AdGuard Home과 비교하여 다음과 같은 기능을 추가했습니다:

• 📜 자동화된 SSL 인증서 관리
  • 자동 인증서 발급 및 갱신
  • 와일드카드 도메인 인증서 설정 지원
• 🛡️ 강화된 보안 기능
  • 스마트 속도 제한 보호
  • 중국 본토 지역 접속 경험 최적화
• ⚙️ 최적화된 시스템 설정
  • DHCP 서비스 비활성화, DNS 기능에 집중
• 🔄 DDNS 지원
• 🌉 프록시 기능 지원
  • 프록시를 통한 설정 파일 다운로드
  • DoH/DoT 프록시 지원
• 🚦 DNS 분할 기능 지원
• 🚫 게임 중독 방지 앱 리스트 지원

호스팅 서비스 장점

전문적인 DNS 호스팅 서비스를 제공하며 다음과 같은 특징을 가지고 있습니다:

• 🏢 알리클라우드 항저우 노드 배포
• 🌐 포괄적인 프로토콜 지원
  • IPv6 지원, 주요 IPv6 업스트림 직접 연결
  • DoT (DNS over TLS)
  • DoH (DNS over HTTPS)
  • HTTP/3 지원, 대기 시간 현저히 감소
• 📊 강력한 규칙 관리
  • 타사 화이트/블랙리스트 가져오기 지원
  • 100만 개 규칙 수용
• 📝 완비된 로그 및 통계
  • 72시간 쿼리 기록 보존
  • 24시간 상세 통계 분석
• ⚖️ 로드 밸런싱
  • 다중 서버 분산 배포
  • 스마트 부하 분배
• 💰 경쟁력 있는 가격

성능 및 효과 평가

DNS 레벨 광고 차단은 독특한 장점을 가지고 있습니다:

• 💪 장점

  • 제로 추가 전력 소모
  • 모든 기기 커버
  • 기기 네트워크 깨우기 빈도 감소
  • 무효 데이터 로딩 감소

• ⚠️ 한계

  • 브라우저 플러그인보다 차단 정확도 낮음
  • MITM 방식의 필터링 효과에는 미치지 못함

특히 모바일 기기 사용 환경에 적합하며, 개인정보를 보호하면서도 기기 배터리 수명을 고려합니다.

HTTP/3 프로토콜 전면 지원

NullPrivate은 HTTP/3 프로토콜을 전면 지원합니다. 모든 기존 사용자는 추가 설정 없이 자동으로 HTTP/3의 성능 향상을 경험할 수 있습니다.

주요 업데이트 설명

• iOS 사용자: DoH 프로토콜을 통해 HTTP/3를 직접 사용할 수 있어 네트워크 지연 시간이 더욱 단축됩니다
• Android 사용자: 시스템 제한으로 인해 현재 DoT 프로토콜을 사용 중이며, Google의 향후 버전 업데이트 후 지원 예정입니다
• 성능 향상: 초기 응답 속도가 HTTP/2 대비 크게 개선되었으며 연결 설정이 더욱 빠릅니다
• 스마트 전환: HTTP/3를 지원하지 않는 네트워크 환경에서는 시스템이 자동으로 HTTP/2로 전환되어 서비스 안정성을 보장합니다

HTTP/3 기술 심층 분석

HTTP/3는 HTTP 프로토콜의 최신 버전으로 Google이 개발한 QUIC 전송 프로토콜을 기반으로 하여 여러 혁신적인 기술적 이점을 제공합니다:

핵심 기능

1. UDP 기반 QUIC 프로토콜

   • 연결 설정 시간 현저히 감소
   • 개선된 다중화(multiplexing) 기능
   • 더 스마트한 패킷 손실 처리 메커니즘

2. 최적화된 성능

   • 제로 핸드셰이크 지연(0-RTT)
   • 개선된 혼잡 제어
   • 연결 마이그레이션 지원

3. 강화된 보안

   • TLS 1.3 통합
   • 암호화된 핸드셰이크 과정
   • 중간자 공격 위험 감소

연결 설정 과정 비교

사용 권장 사항

• 클라이언트가 HTTP/3 프로토콜을 지원하는지 확인하세요
• 클라이언트 버전을 최신으로 유지하세요
• 네트워크 환경이 제한된 경우 시스템이 자동으로 HTTP/2로 다운그레이드됩니다

주의 사항

• 일부 지역 네트워크는 UDP 트래픽을 제한할 수 있어 HTTP/3 성능에 영향을 미칠 수 있습니다
• 다른 네트워크 환경에서는 성능 차이가 발생할 수 있습니다
• 시스템은 네트워크 상태에 따라 최적의 프로토콜을 자동으로 선택합니다

참고 자료

• HTTP/3 규격 문서
• QUIC 프로토콜 상세 설명
• IETF HTTP/3 표준

사용자 정의 클라이언트 이름 기능 출시

기능 소개

사용자 경험을 향상시키기 위해 NullPrivate은 이제 사용자 정의 클라이언트 이름 기능을 지원합니다. 이 기능을 통해 다양한 기기에 독특한 식별 이름을 설정할 수 있어 기기 관리가 더 직관적이고 편리해집니다.

설정 가이드

기기 유형에 따라 설정 방법이 약간 다릅니다:

Android 기기

도메인 이름 앞에 사용자 정의 접두사를 추가하기만 하면 됩니다. 형식은 다음과 같습니다:

{기기 이름}.{기존 도메인}

예시: xiaomi-15pro.xxxxxxxx.nullprivate.com

iOS 기기

1. “설정 안내” 페이지로 이동
2. “클라이언트 ID” 입력란에 사용자 정의 이름 입력
3. 새로운 프로필 파일을 다운로드하여 적용

브라우저 설정 (DoH)

기존 DoH 주소 뒤에 사용자 정의 식별자를 추가합니다:

기존 형식:

https://xxxxxxxx.nullprivate.com/dns-query

새 형식:

https://xxxxxxxx.nullprivate.com/dns-query/{기기 식별자}

예시: https://xxxxxxxx.nullprivate.com/dns-query/pc1-browser

사용 권장 사항

• 기기 이름은 기기 모델, 위치 또는 용도와 같은 의미 있는 식별자를 사용하는 것이 좋습니다
• 특수 문자 사용을 피하고, 영문자, 숫자 및 하이픈 사용을 권장합니다
• 향후 관리를 위해 명명 규칙을 통일하여 유지하는 것이 좋습니다

주의 사항

• 사용자 정의 이름은 표시에만 영향을 미치며 서비스 성능에는 영향을 주지 않습니다
• 이름을 변경한 후에는 설정을 다시 적용해야 합니다
• 나중에 참조할 수 있도록 각 기기의 설정 정보를 잘 보관하는 것이 좋습니다

광고 차단의 필요성: 디지털 시대의 주의력과 프라이버시 보호

현대 광고 생태계 해체

광고주의 수익 모델

현대 광고 시스템은 복잡한 이해관계의 사슬 위에 구축되어 있습니다:

• 광고주는 매체 플랫폼을 통해 광고 게재자와 사용자를 연결합니다
• 수익원은 사용자가 아닌 광고 게재자의 광고비입니다
• 목표는 “전환율"을 극대화하는 것 — 광고 시청자를 유료 고객으로 전환시키기

전환율 전쟁

이 주의력 쟁탈전에서:

• 높은 전환율은 더 높은 광고 단가를 의미합니다
• 광고 게재 효율성이 수익에 직접 영향을 미칩니다
• “개인화 푸시"가 전환 향상의 핵심 전략이 되었습니다

개인화 광고의 진실

데이터 수집의 깊이

현대 광고 시스템은 다중 채널을 통해 사용자 정보를 수집합니다:

• 기기 식별자와 운영체제 데이터
• 크로스 플랫폼 행동 추적
• 소셜 관계 네트워크 분석
• 소비 패턴 프로파일링

정밀 타겟팅의 함정

편리해 보이는 개인화 푸시는 실제로는 위험을 내포하고 있습니다:

• 인지 편향을 이용한 수요 창출
• 사용자의 잠재적 불안 증폭
• 거짓된 긴급감 조성

주의력에 대한 광고의 침식

주의력 경제의 대가

• 빈번한 방해가 업무 효율성을 파괴합니다
• 의사결정 판단 능력을 방해합니다
• 인지 부담을 증가시킵니다
• 진짜 수요의 경계를 흐립니다

광고 전략의 진화

현대 광고는 단순한 정보 전달에서 진화하여:

• 강제적 기억 주입
• 감정 자극
• 불안 마케팅
• 사회적 압력

자기 보호 전략

핵심 보호 조치

1. 프라이버시 보호 우선

   • 앱 권한 제한
   • 데이터 공유 통제
   • 프라이버시 보호 도구 사용

2. 주의력 관리

   • 집중 시간대 설정
   • 정보 필터링 메커니즘 구축
   • 능동적 정보 획득 습관 기르기

3. 소비 의사결정 통제

   • 수요 평가 체계 구축
   • 구매 결정 지연
   • 합리적 판단 유지

기술적 지원: 사이버 심성

이 데이터 중심의 시대에 “사이버 심성” — 즉 디지털 세계에서의 신중함과 지혜 — 을 유지하는 것이 특히 중요해졌습니다. 여기에는 다음이 포함됩니다:

• 디지털 발자국 관리
• 개인 정보 보호
• 정보 흐름 제어

해결책

“닝핑"은 종합적인 보호 솔루션으로서 광고 차단뿐만 아니라 더 중요하게는 사용자에게 다음을 돕습니다:

• 개인 정보 보호
• 브라우징 경험 최적화
• 주의력 분산 감소
• 제어 가능한 정보 환경 제공

우리의 디지털 삶을 다시 통제하며, 광고 스팸 거부로 시작해봅시다.

서비스 리소스 최적화 전략 안내

배경 설명

사용자 수 증가와 기능 요구 사항 향상에 따라 일부 높은 리소스 소비 구성 옵션이 서비스 불안정을 유발할 수 있다는 점을 관찰했습니다. 서비스 품질을 보장하기 위해 심층 분석을 수행하고 해당 최적화 방안을 마련했습니다.

리소스 최적화 전략

1. 필터 업데이트 메커니즘 최적화

현황 분석

• 일부 사용자는 매시간 필터 업데이트를 설정함
• 매 업데이트마다 전체 다운로드-파싱-중복 제거 프로세스 필요
• 국제 대역폭 제한으로 인해 업데이트 시간이 길어짐
• 서버 리소스가 지속적으로 높은 부하 상태

최적화 방안

업데이트 간격을 최소 72시간으로 조정합니다. 이유는 다음과 같습니다:

• 대부분의 필터 목록 업데이트 주기가 24-72시간
• 무효한 리소스 소비 감소
• 서비스 안정성 확보
• 대역폭 사용 효율성 향상

영향 평가

• 긍정적 영향
  • 서비스 응답이 더 안정적
  • 리소스 사용이 더 합리적
  • 시스템 부하 감소
• 최소화된 영향
  • 규칙 업데이트가 여전히 합리한 주기 내 유지
  • 방어 효과에 영향 없음

2. 병렬 요청 전략

현재 상황

현재 대부분의 사용자가 병렬 요청 기능을 활성화했지만, 기존 아키텍처에서는 이점이 제한적입니다:

• 알리바바 클라우드 업스트림 서비스 지연 시간 차이가 보통 5ms 이내
• 알리바바 클라우드 공공 서비스의 요청 빈도 제한을 유발할 수 있음
• 불필요한 시스템 오버헤드 증가

사용 권장사항

• 로드 밸런싱 모드 사용 권장
• 병렬 요청은 다음 시나리오에 적합:
  • 업스트림 서비스 지연 시간 차이가 뚜렷할 때 (>200ms)
  • 서비스 품질이 불안정한 경우
  • 국가 간 액세스 시나리오

참고: 현재까지 병렬 요청으로 인한 속도 제한 문제는 발견되지 않았으며, 이 기능은 임시로 계속 개방됩니다.

3. 제3자 목록 관리

보안 고려사항

시스템 안정성을 보장하기 위해 일부 제3자 목록 지원을 임시로 비활성화했습니다:

• 외부 목록 규모 예측 어려움
• 리소스 초과 가능성
• 서비스 안정성 보장 불가

향후 계획

보다 안전한 제3자 목록 관리 방안을 연구 중이며, 향후 이 기능을 재개방할 예정입니다.

기본 버전 메모리 상한 조정

일부 사용자 환경에서 재시작이 빈번하게 발생하고 있으며, 로그를 확인한 결과 메모리 사용량이 상한 300MB에 도달하여 강제 종료되었음을 확인했습니다.

현재 단일 컨테이너 상한을 500MB로 조정하여 재시작 문제를 완화합니다.

환경에 로그인 또는 재시작 문제가 발생할 경우 언제든지 연락 주십시오. 고객의 문제를 해결하는 것이 저희의 책임입니다.

도움이 필요하신가요?

WeChat으로 연락 private6688
또는 이메일 보내기 service1@nullprivate.com
문제를 자세히 설명해 주시면 최대한 빠르게 회신 드리겠습니다.

언제든지 지원 서비스 제공

빠른 시작 가이드

서비스를 편리하게 시작할 수 있도록 상세한 사용 가이드를 제공하고 있습니다.

세심한 지원 서비스

전용 안내

새로 가입하신 일부 사용자는 처음 사용 시 어려움을 겪을 수 있음을 인지하고 있습니다. 이에 따라 저희는:

• 제품 문서 구조를 지속적으로 개선하고
• 명확한 설정 가이드를 제공하며
• 자주 묻는 질문에 대한 답변을 준비했습니다.

신속한 대응

사용자의 개인 정보를 보호하기 위해 비등록제를 채택하고 있지만, 이는 사용자 서비스에 전혀 영향을 미치지 않습니다. 다음 방법으로 저희에게 연락할 수 있습니다:

도움이 필요하신가요?

WeChat으로 연락 private6688
또는 이메일 보내기 service1@nullprivate.com
문제를 자세히 설명해 주시면 최대한 빠르게 회신 드리겠습니다.

전용 링크 설정 방법

일부 유료 AdGuardHome 서비스는 전용 링크를 제공하지만, 사용자가 백엔드 관리에 접근할 수 없도록 하며 관리자가 대신 규칙을 관리합니다.

이는 프라이빗 백엔드 관리 기능을 제공하지 않고, 단순히 도메인 리버스 프록시를 통해 서비스를 구현한 것으로 비용이 상대적으로 낮습니다.

이 기능을 구현하려면 서버를 임대하여 AdGuardHome 서비스를 실행하고, Nginx 리버스 프록시를 구성해야 합니다.

서비스 링크 5r69hxdx9onl70hp.example.com를 예로 들면, Nginx 핵심 구성은 다음과 같습니다:

http {
  server {
    listen 1080;
    server_name 5r69hxdx9onl70hp.example.com;
    location / {
      proxy_pass http://worker.example.com:5002;
      proxy_set_header Host $http_host;
    }
  }
  server {
    listen 1443 ssl;
    server_name 5r69hxdx9onl70hp.example.com;
    ssl_certificate /app/data/certs/5r69hxdx9onl70hp/fullchain.pem;
    ssl_certificate_key /app/data/certs/5r69hxdx9onl70hp/privkey.pem;
    location / {
      proxy_pass https://worker.example.com:5003;
      proxy_set_header Host $http_host;
    }
  }
}
stream {
  ssl_protocols TLSv1.2 TLSv1.3 SSLv3;
  map $ssl_preread_server_name $targetBackend {
    5r69hxdx9onl70hp.example.com worker.internal.com:5004;
  }
  server {
    listen 1853;
    proxy_pass $targetBackend;
    ssl_preread on;
  }
}

각 유료 사용자는 유사한 Nginx 구성을 하나만 추가하면 되며, 도메인 해석을 통해 서버를 가리키면 됩니다. 사용자가 많아지고 단일 애플리케이션 서비스 부담이 커지면 다른 백엔드로 프록시할 수 있습니다.

이러한 서비스는 진정한 개인화를 실현할 수 없으며, 사용자가 백엔드에 접근할 수 있어야 자신의 인터넷 데이터를 진정으로 제어할 수 있으며, 이는 우리의 프라이빗 서비스의 장점입니다. 한 사용자가 실제로 서비스를 독점하여 NullPrivate의 모든 기능을 사용할 수 있습니다.

새로운 업그레이드 — 강화형 광고 차단 규칙

규칙 업데이트 설명

더욱 강력한 광고 차단을 원하시는 사용자분들의 요구를 충족하기 위해 필터 규칙 전략을 전면적으로 최적화했습니다. 신규 규칙은 오차 차단률을 낮게 유지하면서 광고 필터링 효과를 크게 향상시켰습니다. 이번 업데이트는 사용자 피드백에서 비롯되었으며, 웹사이트 정상 접속이 보장되는 기반 위에 더욱 정밀한 차단 규칙을 추가했습니다.

규칙 목록 개요

아래 전문 규칙 목록을 정리해 드립니다. 자신에게 맞는 규칙을 선택하여 사용하실 수 있습니다.

기본 보호 규칙

콘텐츠 필터링 규칙

사용 권장사항

1. 점진적 적용

   • 기본 보호 규칙부터 우선 사용하는 것을 권장합니다.
   • 실제 필요에 따라 다른 규칙을 단계적으로 추가하세요.
   • 규칙 목록을 정기적으로 점검하고 업데이트하세요.

2. 성능 최적화

   • 동시에 너무 많은 규칙을 활성화하지 않도록 하세요.
   • 자신의 요구와 가장 관련 있는 규칙을 우선 적용하세요.
   • 사용하지 않는 규칙은 정기적으로 정리하세요.

3. 문제 해결

   • 오차 차단 발생 시 기록하고 즉시 피드백해 주세요.
   • 특정 규칙을 임시로 비활성화하여 테스트해 보세요.
   • 필요시 사용자 정의 화이트리스트를 활용하세요.

주의사항

• 일부 규칙은 특정 사이트 정상 접속에 영향을 줄 수 있습니다.
• 규칙 업데이트를 정기적으로 확인하세요.
• 잦은 오차 차단이 발생할 경우 즉시 저희에게 연락해 주세요.

보다 유연한 제어가 필요하신 분은 전문가용 서비스를 통해 완벽한 규칙 구성 커스터마이징을 지원합니다. 궁금하신 점이 있으시면 언제든지 피드백 주세요.

도움이 필요하신가요?

WeChat으로 연락 private6688
또는 이메일 보내기 service1@nullprivate.com
문제를 자세히 설명해 주시면 최대한 빠르게 회신 드리겠습니다.

체험판 서비스 상세

맞춤형 광고 필터링 규칙을 제공하는 서비스 제공자로서, 저희는 사용자가 서비스를 선택할 때 고려하는 점을 잘 알고 있습니다. 서비스 비용이 높더라도, 저희는 항상 사용자에게 최대한의 맞춤 유연성을 제공하는 것을 고수합니다.

서비스의 가치를 충분히 이해하실 수 있도록, 저희는 초특가 체험판을 준비했습니다. 이 버전은 모든 고급 기능을 포함하며 정식 서비스와 완전히 동일하여, 맞춤형 필터링의 독보적인 장점을 제로 리스크로 경험하실 수 있습니다.

체험판 안내:

• 할인 가격은 최초 사용 시에만 적용됩니다
• 연장 시 정식 서비스 플랜을 선택해야 합니다
• 계정 없이 설계되어 있어 체험판을 반복 구매할 수 있습니다
• 매번 새로 구매할 때마다 새로운 서비스 인스턴스가 생성됩니다
• 연장 시 기존 인스턴스의 모든 설정을 유지할 수 있습니다

저희는 이 우수한 서비스를 체험하시길 기대합니다. 사용 중 문제가 발생하더라도, 고객 지원팀이 언제든 전문적인 지원을 제공해 드립니다.

도움이 필요하신가요?

WeChat으로 연락 private6688
또는 이메일 보내기 service1@nullprivate.com
문제를 자세히 설명해 주시면 최대한 빠르게 회신 드리겠습니다.