geedge.lantern.io
detection confidence: medium public

A design document for "PDNS" specifies a recursive DNS resolver that dynamically monitors per-user behavior and applies differentiated blocking policy: NXDOMAIN or redirect-IP responses per target domain via BIND9 RPZ, a front-end "user reputation" score that adjusts per-user policy based on request history, and planned support for multiple ingress methods including encrypted DNS. The working prototype demonstrates source-IP-based user classification into block/passthru groups with policy synced via BIND9 zone transfer from a primary RPZ server.

用户控制功能,对不同的用户采取不同的请求控制策略,同时需要对用户信誉进行监控,根据用户请求情况调整请求控制策略...支持多种接入方式,包括各种加密DNS接入方式

Defense implications

censorsgeneric
techniquesdns-poisoning

extracted_by: claude-sonnet-5 · added 2026-08-26 · id: 2026-pdns-reputation-blocking-f975c8

Related findings

deployment

A 2020 MESA Lab monthly report describes building an encrypted-DNS gateway device and a self-hosted DoH server that was wired directly into a live "TSG platform WAN net interface", alongside a passive DoH-service-discovery pipeline that found 39 new DoH-serving domains in a single day of backbone ("科技网") traffic; a related note documents actively probing known DoH-serving IPs' upstream resolvers via a proxy network across 196 countries to check which still function.

detection

Geedge fingerprinted several V2Ray-based VPN apps by their fixed API/bootstrap domains rather than protocol characteristics — blocking "V2 Pro" via pro.mucacherry.org, "V2 VPN" via v2.mucacherry.org, and "V2Net VPN" via api.v2net.live plus 5 rotating free-node domains (free1-5.v2n3t2.online / v2n3t.online) the app uses to fetch node lists.

detection

PanGu defines a configurable DNS response-spoofing subsystem (NTC_DNS_FAKE_IP_CB, NTC_DNS_RES_STRATEGY) supporting named 'answer groups' with a configurable number of fake answers returned per group (service ID 0x40 'dns欺骗'), i.e. DNS injection is a general, group-configurable policy primitive in TSG rather than a single hardcoded fake-IP response.

detection

relationship-gtpc-user derives a single per-subscriber correlation key as Hashkey = md5(IMEI + IMSI + phone_number + vsys_id) from mobile-core GTP-C signaling, and a separate per-tunnel key gtp_uuid = md5(uplink_teid + "|" + downlink_teid). On every update it writes not just the primary user<->TEID row (tsg_galaxy:relation_user_teid) but up to four additional secondary-index rows into tsg_galaxy:gtpc_knowledge_base, one per identifier (IMEI, IMSI, phone number, APN) with a type-digit prefix ("0"/"1"/"2"/"3") and — for phone number and APN — the value's characters reversed before use as the row key, a range-scan-friendly key design that lets any of the four identifiers be used to look up the associated tunnel/session independently.

deployment

log-subscriber-hbase-datacenter is a Storm topology that, on a 300-second tick, scans a "national center" HBase cluster (national.hbase.zookeeper.servers) for subscriber_id/account rows changed in that window and replicates them into a separate "branch/regional datacenter" HBase cluster (center.hbase.zookeeper.servers, table sub:subscriber_info) — confirming a two-tier, hub-and-spoke data-federation architecture where subscriber-account correlation data is centrally maintained at a national level and periodically pushed down to per-datacenter local copies for regional/site-level querying.

deployment

radius-relationship-hbase and relationship-gtpc-user both ship byte-identical plaintext, hardcoded Kafka SASL credentials (a fixed admin username, product-branded password) in their default_config.properties — the same static credential shared verbatim across at least two independent TSG-OLAP pipeline components rather than injected per-deployment.