ZoneFeeds FAQ
This FAQ provides answers to common questions about ZoneFeeds features related to internationalized domains, Punycode, supported TLDs, pagination, and the RDAP Dossier.
Internationalized Domains and Punycode
Q: What is Punycode and why does it exist?
A: Punycode is an ASCII-compatible encoding used to represent Unicode characters in domain names. DNS only supports ASCII characters, so Punycode allows internationalized domain labels to work while remaining compatible with DNS infrastructure.
Example:
- Unicode: 银行
- Punycode: xn--t6qv86b
ZoneFeeds decodes Punycode to analyze domain intent and detect abuse.
Q: How does ZoneFeeds convert Punycode to Unicode?
A: ZoneFeeds follows a standard, step-by-step process:
- Label Segmentation: Split the domain at dots.
Example:xn--e1afmkfd.xn--p1ai→xn--e1afmkfd,xn--p1ai. - Prefix Detection: Labels starting with
xn--go to the Punycode decoder. - Decoding: RFC 3492 Punycode algorithm reconstructs Unicode characters.
- Validation: Checks allowed Unicode blocks, prohibited code points, and IDNA contextual rules.
- Normalization: Converts to NFC form, lowercases, and strips compatibility characters for consistency.
Q: What is mixed script detection?
A: ZoneFeeds analyzes labels to detect:
- Single script usage
- Mixed scripts within a label
- Mixed scripts across labels
Domains with mixed scripts are treated as higher risk for phishing and impersonation.
Q: How does Unicode confusable mapping work?
A: ZoneFeeds maintains a map of visually similar characters across scripts to detect deceptive domains:
- Latin
avs Cyrillicа - Latin
ovs Greekο
This helps detect domains designed to visually mimic trusted brands.
Q: Can Unicode domains be converted back to ASCII?
A: Yes. ZoneFeeds generates ASCII fingerprints by mapping Unicode labels to lookalike ASCII characters and applying confusable substitutions. This allows direct comparison with ASCII brand dictionaries.
Q: How are errors handled in Punycode processing?
A: ZoneFeeds explicitly handles:
- Invalid or malformed Punycode
- Label collisions after normalization
- Overlong or maliciously crafted encodings
Domains triggering these issues receive elevated risk indicators.
Supported Top Level Domains (TLDs)
Q: What TLDs does ZoneFeeds support?
A: ZoneFeeds supports:
- Generic, brand, geographic, industry-specific, and internationalized TLDs
- 366 currently supported TLDs, with coverage expanding over time
Q: Can I see examples of supported ASCII TLDs?
A: Common examples include:
| Category | Examples |
|---|---|
| Brand/Corporate | .apple, .amazon, .google, .microsoft |
| Generic | .com, .org, .net, .info |
| Country-specific | .london, .nyc, .asia |
| Sponsored/Adult | .xxx |
Q: What about internationalized TLDs?
A: These TLDs are represented in Punycode and analyzed by script or language family. Examples:
| Punycode TLD | Script/Language |
|---|---|
| xn--11b4c3d | Arabic |
| xn--1ck2e1b | Japanese (Katakana) |
| xn--1qqw23a | Chinese (Han) |
| xn--6frz82g | Greek |
| xn--80aqecdr1a | Cyrillic |
| xn--9dbq2a | Hebrew |
| xxx | Sponsored gTLD (Adult Content) |
ZoneFeeds decodes, normalizes, and analyzes these domains to detect phishing, homograph attacks, and cross-script impersonation.
Q: Why is internationalized domain support important?
A: Attackers increasingly use Punycode and Unicode domains to:
- Evade ASCII-only detection
- Impersonate brands in multiple scripts
- Launch phishing campaigns targeting non-English users
Normalization and confusable mapping ensures these threats are detected early.
Q: How does ZoneFeeds pagination work?
A: ZoneFeeds uses cursor-based pagination for performance and consistency.
Pagination Fields
| Field | Description |
|---|---|
pit |
Elasticsearch Point In Time identifier |
after |
Base64 encoded cursor value for next page |
- The first request returns a
pit. - If more results exist, a
next_cursoris also returned. - To fetch the next page:
- Pass both
pitandafterin the next request - Include all original query parameters from the initial request (
start,end,search,limit) - PIT is valid for 2 minutes.
- If the PIT expires, a new initial request is required.
Data Fields & Timestamps
Q: Is the timestamp field in ZoneFeeds' data related to domain creation date?
A: No. The timestamp field is the time ZoneFeeds observed the domain in (or removed from) the registry zone file — it is not the domain's registration, last-update, or expiration date.
For actual domain lifecycle information (registration date, last changed date, expiration date), open the RDAP Dossier by clicking the domain in the Search Results table. The dossier surfaces these values directly from the registry's RDAP server, so you do not need to query WHOIS or external RDAP services yourself.
RDAP Dossier
Q: What is the RDAP Dossier?
A: The RDAP Dossier is a side panel that opens when you click a domain in the Search Results. It shows live registration data from the registry — registrar of record, registration and expiration dates, EPP status codes, abuse contacts, nameservers, DNSSEC posture, and the raw RDAP JSON.
See the RDAP Dossier guide for a full field-by-field walkthrough.
Q: Which plans include the RDAP Dossier?
A: The RDAP Dossier is available on Basic and Enterprise plans. It is not included in the Trial plan.
Q: How fresh is the data in the RDAP Dossier?
A: RDAP data is fetched on demand from the authoritative registry server (for example, rdap.verisign.com for .com) when you open the dossier. The exact fetch time is shown in the Timestamps → RDAP fetched field inside the panel.
Q: Why do the nameservers in the RDAP Dossier sometimes differ from the ones in the Search Results table?
A: They come from two different sources:
- The Search Results table shows nameservers observed in the zone file
- The RDAP Dossier shows nameservers as recorded at the registry
Most of the time they match. When they don't, it usually means the delegation has recently changed, or there is a registry-vs-authoritative inconsistency worth investigating.
Q: What do status codes like client transfer prohibited mean?
A: These are standard EPP (Extensible Provisioning Protocol) status codes set by registrars and registries. client transfer prohibited means the registrar has locked the domain against being transferred to another registrar — a common protection on active, legitimate domains. ICANN maintains the authoritative list at https://icann.org/epp.
Q: Is the RDAP Dossier available via the API?
A: Not currently. The RDAP Dossier is a web UI feature. The public API continues to return zone-file observation data only.